In a surprising move that shook the tech world, Amazon’s Prime Video service recently transitioned from a microservices architecture back to a monolithic system, resulting in a staggering 90% cost reduction. This decision, made in May 2023, has sparked significant discussion within the software development community, particularly because Amazon Web Services (AWS) is known for championing cloud-native, microservices-based solutions. The reversal from a company that practically wrote the textbook on distributed systems has led many to question the default adoption of microservices for modern software development.
The initial blog post detailing Amazon’s decision was later removed, but the details remain accessible, illustrating how even the most established companies are reevaluating their tech strategies. It’s a significant development, especially given that AWS generates billions annually from its microservices infrastructure. The shift prompts a critical reflection on whether microservices should be the go-to choice for building scalable applications.
For several years, industry experts have voiced concerns about the premature or unnecessary adoption of microservices. Following Amazon’s transition, more architects have begun questioning the wisdom of choosing microservices by default. Despite this, microservices continue to dominate tech conferences, blogs, and job listings, often being perceived as the only path to modern software development. This perception persists, even though many teams adopt microservices not out of necessity but because it seems like the obvious choice, often seen as a resume-enhancing move.
Microservices can indeed address specific, large-scale problems. However, the reality is that most teams do not operate at such a scale. This article aims to reignite a crucial conversation: should microservices be the default option for building at scale? We’ll explore stories of architectural reversals, insights from seasoned architects, and evaluate the trade-offs and alternatives. By the end, you’ll have a clearer understanding of whether your project truly requires a microservices architecture.
### The Agility-Complexity Trade-Off of Microservices
On paper, microservices appear to be an elegant solution. By breaking down a large application into smaller, independent services, each part can be developed, deployed, and scaled independently. This setup promises independent deployability, autonomous teams, language diversity, and elastic scaling.
However, every division introduces complexity. Within a monolithic system, function calls are immediate and predictable. In contrast, microservices transform these calls into network requests, which are slower and more prone to failure. Managing a system with dozens or hundreds of services requires version control, schema evolution, distributed transactions, tracing, centralized logging, and a robust CI/CD pipeline, just to maintain basic functionality.
A well-known diagram from Gartner captures this trade-off: microservices exchange the simplicity of a single codebase for the complexity of managing many. While this complexity may be justifiable at massive scales, such as those of Netflix, in many cases, the operational costs outweigh the benefits, leading to increased debugging, coordination challenges, and extensive glue code to keep everything functioning.
Microservices make sense when distinct business capabilities require independent scaling and deployment. For instance, a payment processing service, which is security-critical and rarely updated, differs fundamentally from a recommendation engine, which is memory-intensive and frequently A/B tested. These components have varying scaling patterns, deployment cycles, and risk profiles, justifying separate services.
The success of microservices hinges on aligning business domain boundaries with team structures, as predicted by Conway’s Law. If your organization naturally divides into autonomous teams owning distinct capabilities, microservices might be appropriate. However, most small startups, often referred to as “one-and-a-half pizza” teams, do not fit this structure.
While microservices have proven effective for companies like Amazon and Uber, many organizations lack the necessary prerequisites: dedicated service ownership, mature CI/CD processes, robust monitoring, and, critically, the scale to justify the operational overhead. Startups that adopt microservices prematurely often regret the decision.
### The Great Microservices Reversal
Ironically, some of the tech giants that stand to benefit the most from microservices are now stepping back, with results that are hard to ignore.
#### Amazon Prime Video: 90% Cost Reduction with a Monolith
In May 2023, Amazon engineers acknowledged what seemed unthinkable: Prime Video had moved away from microservices to embrace a monolithic architecture. The Video Quality Analysis (VQA) team had initially implemented a distributed system using AWS Step Functions and Lambda to monitor thousands of video streams through independent, scalable components. While this setup appeared serverless and ideal on paper, in practice, it was problematic. The distributed approach brought little benefit, and the “infinitely scalable” system faltered under just 5% of the expected load due to orchestration overhead.
The solution was surprisingly simple: consolidate everything into a single process. This change led to a dramatic 90% cost reduction and improved performance.
#### Twilio Segment: From 140 Services to One Fast Monolith
In 2018, Twilio Segment, a customer data platform, shared a similar experience in their candid post “Goodbye Microservices.” The company’s system had ballooned to over 140 services, resulting in operational chaos. Engineers found themselves firefighting instead of innovating, and the anticipated benefits of microservices turned into burdens as development velocity plummeted and defect rates soared.
Their solution was drastic yet effective: they consolidated all 140 services into a single monolith. The change had immediate benefits. Test suites that previously took an hour to run now completed in milliseconds, and developer productivity surged. They shipped 46 improvements to shared libraries in a year, up from 32 during the microservices era.
#### Shopify: Sanity over Hype
Shopify maintains one of the world’s largest Ruby on Rails codebases, with over 2.8 million lines of code. Rather than following the microservices trend, Shopify opted for a modular monolith—a single codebase with clear component boundaries. Shopify’s engineers concluded that microservices would introduce their own challenges, so they chose modularity without the operational overhead.
These examples raise an essential question: if even the pioneers of microservices are retreating, why do we still treat it as the gospel truth?
### Expert Voices against Microservices Mania
Some of the most respected voices in software architecture are cautioning against the overuse of microservices and highlighting the mistakes they’ve witnessed when implementing them at scale.
#### Rails Creator: Simplicity over Sophistication
David Heinemeier Hansson (DHH), the creator of Ruby on Rails, has long advocated for simplicity over following architectural trends. In his analysis of Amazon’s reversal, he succinctly states: “The real-world results of all this theory are finally in, and it’s clear that in practice, microservices pose perhaps the biggest siren song for needlessly complicating your system.” DHH’s metaphor captures the allure of microservices, leaving teams adrift on the rocks of complexity.
#### Microservices: Mistake of The Decade?
Jason Warner, former CTO of GitHub, doesn’t mince words when discussing microservices: “I’m convinced that one of the biggest architectural mistakes of the past decade was going full microservice.” Warner, who understands scale from his time at GitHub, Heroku, and Canonical, emphasizes the lived experience over theoretical advice: “90% of all companies in the world could probably just be a monolith running against a primary db cluster with db backups, some caches and proxies and be done with it.”
#### GraphQL Co-Creator: “Don’t”
Nick Schrock, co-creator of GraphQL, might be expected to champion distributed systems, yet he warns: “Microservices are such a fundamentally and catastrophically bad idea that there are going to be an entire cohort of multi-billion companies built that do nothing but contain the damage that they have wrought.” Schrock highlights the long-term maintenance challenges, with services reflecting outdated organizational structures and product requirements.
When those who have successfully navigated distributed systems at scale begin waving red flags, it’s worth paying attention. Consider whether your company truly needs microservices, especially if GitHub’s CTO suggests that 90% of companies don’t.
### The Hidden Costs of Microservices
Microservices come with hidden costs that teams often underestimate.
#### Operational Costs
A monolith is straightforward: it involves in-process function calls. Microservices, on the other hand, rely on networks. Each request traverses machines, load balancers, service meshes, and authentication layers, creating more failure points and infrastructure needs. This requires service discovery, distributed tracing, centralized logging, and monitoring systems that understand service topology. These are essential but collectively complex and costly. Duplicated data demands extra storage, and constant service-to-service calls increase network egress fees, with cloud costs scaling faster than the applications they host.
#### Developer Productivity Drain
In microservices, the challenge lies in navigating distributed system interactions rather than writing code. Stack Overflow’s “The macro problem with microservices” highlights a productivity drain: distributed state forces developers to write defensive code that continually checks for partial failures. In a monolith, a developer can follow a code path end-to-end within one repository. In microservices, one feature might span multiple repositories with different dependencies and deployment cycles, requiring extensive coordination. Breaking changes that a compiler would catch in a monolith now surface as runtime errors in production.
#### Testing and Deployment Complexity
Monolith integration and end-to-end tests are faster as they run locally in memory. Distributed systems lack this luxury: confident integration and end-to-end tests must span numerous service boundaries, leading to slower, more brittle tests and requiring staging environments that mirror production. These effectively double infrastructure costs and slow feedback loops.
#### Data Management and Consistency
The most underestimated complexity of microservices lies in data consistency across service boundaries. Monoliths benefit from ACID transactions, while microservices require distributed saga (multi-step workflows with rollback logic), eventual consistency (data becomes correct after a delay), or compensation logic (extra code to undo partial failures). Debugging inconsistent orders or payments becomes more challenging when state is duplicated across services.
### Beyond Microservices: Smarter Architectural Alternatives
Before defaulting to microservices, consider how simpler, well-structured architectures can deliver comparable scalability without distributed complexity. Two noteworthy alternatives are modular monoliths and service-oriented architectures (SOA).
#### Modular Monoliths: Structure without Distribution
Unlike traditional monoliths that become tangled, modular monoliths enforce strict internal boundaries through clear module APIs and disciplined separation. Each module exposes well-defined interfaces, allowing teams to work independently while deploying a single, coherent system. Modules communicate via explicit contracts like microservices but use fast, reliable function calls instead of vulnerable HTTP requests.
#### Service-Oriented Architecture: The Middle Ground
SOA sits between monoliths and microservices, favoring larger, domain-driven services instead of numerous tiny ones. These services often communicate via an enterprise service bus (ESB), reducing orchestration overhead while preserving separation of concerns. SOA simplifies coordination while enabling autonomy and targeted scaling.
### Conclusion: Choosing Wisely
The architecture you choose should be justified by the problem you’re solving. Most applications don’t operate at the scale of tech giants like Google, Amazon, or LinkedIn and don’t need ultra-distributed architectures. For most systems, well-structured modular monoliths or SOA deliver comparable scalability and resilience as microservices but without the distributed complexity.
Docker, a versatile tool, works well across various architectures, providing consistent performance, easier deployment, and scalability regardless of your architectural approach.
Ultimately, the choice of architecture should be driven by your actual needs, not trends. Consider whether you genuinely need microservices or if a simpler architecture could better serve your business requirements.
For more Information, Refer to this article.
