Microservices vs. Monoliths: Why Some Big Companies Are Moving Back to Monoliths

In the software development world, adopting microservices has become synonymous with being modern and scalable. However, when faced with real-world challenges such as cost, complexity, and scalability issues, some companies are rethinking their architectural choices. Surprisingly, they’re finding their way back to monolithic architectures. This raises the question: Have we misunderstood the role of monoliths in software development?

The Stigma Around Monoliths

For many developers, the term “monolithic” conjures images of tightly coupled, unmanageable spaghetti codebases. Perhaps it’s the prefix “mono” that creates an instant bias, implying rigidity or lack of sophistication. But is every monolithic application inherently bad? The short answer is no. With proper planning, a well-structured monolithic system can outperform a poorly implemented microservices architecture in numerous ways.

The Five Key Reasons for the Shift Back

1. Cost : Amazon Prime Video’s switch to a monolithic architecture resulted in a 90% cost reduction. This shift allowed them to avoid the high operational costs associated with maintaining distributed microservices, such as increased cloud expenses and communication overhead. Microservices often demand extensive infrastructure, including containers, orchestration tools, and monitoring systems. These add up quickly, especially for smaller teams or companies with limited resources.
2. Complexity: Managing dozens, if not hundreds, of interconnected services can be a nightmare. Dependencies between services often lead to cascading failures, making debugging and maintenance highly complex. In contrast, a single codebase in a monolith simplifies the development and debugging process, particularly for smaller teams.
3. Scalability: While microservices excel in scaling specific parts of an application, they’re not always necessary for applications with predictable growth patterns. A monolithic application, when paired with robust database systems, caching mechanisms, and CDNs, can handle significant traffic without needing to split into microservices.
4. Performance: Network latency is a hidden cost in microservices. Each service-to-service call adds overhead, impacting the overall performance. Monolithic systems, being self-contained, eliminate such communication delays, leading to faster response times.
5. Organizational Fit: Microservices require mature DevOps practices, cross-functional collaboration, and advanced monitoring. For teams not ready for such practices, the architecture can quickly spiral out of control. A well-structured monolith is often easier to manage and doesn’t demand a steep learning curve from developers.

Amazon's 90% Cost Reduction: A Bold Move Back to Monolithic Architecture

Amazon’s decision to revert from microservices to a monolithic architecture for its Prime Video platform shocked many in the tech industry. The move wasn’t driven by nostalgia but by practical considerations. Their internal case study revealed several critical inefficiencies with microservices, including soaring operational costs and difficulties in managing dependencies between services. By consolidating into a monolith, Amazon achieved a staggering 90% cost reduction. This was partly due to reduced cloud expenses and a significant decrease in the resources needed to manage inter-service communication.

Additionally, this change streamlined the development process. Developers no longer needed to navigate through a labyrinth of services to debug or update features, accelerating the deployment cycles. Amazon’s experience highlights a fundamental lesson: the best architecture isn’t necessarily the trendiest but the one that aligns with operational realities and business objectives. This case serves as a reminder that monoliths, when properly designed, can be a viable and cost-effective solution for even the largest enterprises.

The Case for Good Monoliths

Not all monolithic applications are doomed to be legacy nightmares. A well-designed monolith with:

• Independent, modular codebases.
• Proper API layers.
• Optimized database designs.
• Caching and CDN integration.

can provide a maintainable and scalable solution for many businesses. It is especially effective for projects where the development team is small, the application’s scope is clear, and the operational scale doesn’t demand hyper-specialization.

Other Companies Still Using Monolithic Architectures

While microservices dominate discussions, many successful companies continue to leverage monolithic structures. Examples include:

• Shopify: Despite its scale, Shopify’s core architecture remains monolithic, enabling the company to deliver consistent performance and manageability.
• Basecamp: The project management tool has long championed simplicity and efficiency with its monolithic architecture.
• Tesla: Tesla’s software, responsible for managing intricate vehicle systems, operates on a centralized monolithic codebase to maintain reliability.
• Craigslist: A pioneer of online classifieds, Craigslist has maintained a monolithic system for decades, focusing on simplicity and low operational overhead.
• GitHub: Although GitHub has been gradually moving towards a more service-oriented architecture, many core functionalities of the platform still rely on a monolithic codebase.
• Twitter: Twitter started as a monolithic Ruby on Rails application and has since evolved into a more distributed architecture. However, parts of its platform still run on a monolithic architecture.
• Airbnb: Airbnb started with a monolithic architecture and has gradually adopted a more service-oriented approach. However, parts of its core platform still rely on a monolithic codebase.

These companies demonstrate that monolithic architectures, when executed thoughtfully, can support large-scale operations and complex functionalities without the need for microservices.

When to Choose Monolithic Over Microservices

• Early-Stage Projects: Startups or smaller teams often benefit from the simplicity of a monolithic approach. It’s faster to develop and iterate without the complexity of maintaining multiple services.
• Predictable Workloads: If your application’s traffic patterns are steady and don’t require scaling specific modules independently, a monolith may suffice.
• Limited Resources: Teams with fewer developers or DevOps expertise may struggle to maintain a complex microservices ecosystem.

Lessons from Industry Leaders

Amazon’s decision to shift back to monolithic systems for Prime Video’s core services reflects a broader lesson: architecture should align with business needs, not trends. Similarly, companies like Shopify and Basecamp have shown that monoliths can scale effectively when designed thoughtfully.

Conclusion

The decision between microservices and monolithic architectures isn’t binary. Both have their strengths and weaknesses, and neither is a one-size-fits-all solution. What matters most is understanding your organization’s needs, capabilities, and long-term goals. A well-planned monolith can often provide better manageability, lower costs, and superior performance than a fragmented microservices system.

So next time you’re starting a project, ask yourself: Do we really need microservices, or is a well-designed monolith the simpler and smarter choice?