{"id":2944,"date":"2025-11-28T14:40:36","date_gmt":"2025-11-28T14:40:36","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2025\/11\/28\/you-want-microservices-but-do-you-really-need-them\/"},"modified":"2025-11-28T14:40:36","modified_gmt":"2025-11-28T14:40:36","slug":"you-want-microservices-but-do-you-really-need-them","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2025\/11\/28\/you-want-microservices-but-do-you-really-need-them\/","title":{"rendered":"You Want Microservices, But Do You Really Need Them?"},"content":{"rendered":"

Do you know who managed to cut costs by a staggering 90% by abandoning microservices for a monolith<\/a> in May 2023? Not a cash-strapped startup or an indie project\u2014Amazon itself<\/strong>, for its Prime Video service. The same AWS that earns billions every year<\/a> by selling microservices infrastructure admitted that, sometimes, a good old monolith wins.\u00a0<\/p>\n

This reversal from the company that practically wrote the playbook on distributed systems sent shockwaves through the cloud-native community. Amazon later removed the original blog post, but the internet never forgets, as you\u2019ll see later.<\/p>\n\n

I\u2019ve been speaking up against unnecessary or premature use of microservices architecture<\/a> for five, six years now. After Amazon Prime Video went back to a monolith, I came across several eminent architects who are also speaking against microservices as default.<\/p>\n\n

And yet in most tech circles, microservices are still viewed as the only way to build modern software. They dominate conferences, blogs, and job listings. Teams adopt them not because their requirements justify it, but because it feels like the obvious (and r\u00e9sum\u00e9-boosting) choice. \u201cCloud-native\u201d has become synonymous with \u201cmicroservices-by-default\u201d, as if other approaches are as obsolete as floppy disks.\u00a0<\/p>\n\n

Microservices do<\/strong> solve real problems, but at a massive scale. Most teams don\u2019t actually operate at that scale.<\/p>\n

With this article, I urge you to reflect on the question the industry has mostly stopped asking: Should microservices be the default choice for building at scale?<\/strong> We\u2019ll look at reversal stories and insights from seasoned architects, and weigh the trade-offs and alternatives. After considering all of this, you can decide whether your problem really needs a constellation of microservices.<\/p>\n\n

Microservices: The Agility-Complexity Trade-Off<\/h2>\n\n

On paper, microservices look impressive. Instead of one big monolith, you split your application into many small services. Each one can be written in any language, owned by a small team, and deployed on its own schedule. If you need more capacity, you can scale only the part that\u2019s under load. The promise is elegant: independent deployability, autonomous teams, multi-language stacks, and elastic scaling.<\/p>\n\n

But the catch is that every split creates a seam, and every seam is a potential failure point. Inside a monolith, function calls are instant and predictable. Across services, those same calls become network requests: slower, failure-prone, sometimes returning inconsistent data. With dozens (or hundreds) of services, you need version management, schema evolution, distributed transactions, tracing, centralized logging, and heavy-duty CI\/CD pipelines just to keep things running.<\/p>\n\n

This Gartner diagram<\/a> captures the trade-off perfectly: microservices exchange the simplicity of one codebase for the complexity of many.<\/p>\n\n

\n \"microservices\n <\/div>\n\n

At a massive scale (think Netflix), that trade-off may be worth it. But when operational benefits don\u2019t outweigh the costs, teams end up paying a steep price in debugging, coordination, and glue code just to hold their product together.<\/p>\n\n

Microservices make sense in very specific scenarios where distinct business capabilities need independent scaling and deployment<\/em>. For example, payment processing<\/strong> (security-critical, rarely updated) differs fundamentally from recommendation engine<\/strong> (memory-intensive, constantly A\/B tested). These components have different scaling patterns, deployment cycles, and risk profiles, which justify separate services.<\/p>\n\n

The success of microservices hinges on clear business domain boundaries that match your team structure, as Conway\u2019s Law<\/a> predicts. If your organization naturally splits into autonomous teams that own distinct capabilities, microservices might work. (So, most \u201cone-and-a-half pizza\u201d<\/strong> startups don\u2019t qualify, do they?)\u00a0<\/p>\n\n

That\u2019s why microservices work effectively for companies like Amazon and Uber\u2014although not always<\/strong>.<\/p>\n\n

In fact, most organizations lack the prerequisites: dedicated service ownership, mature CI\/CD, robust monitoring, and crucially, scale that justifies the operational overhead<\/em>. Startups that adapt microservices prematurely often regret their decision<\/a>.<\/p>\n\n

So ask yourself:<\/p>\n\n

Are you using microservices to solve an independent scaling problem, or are you inviting more complexity than your solution needs?<\/p>\n\n

The Great Microservices Reversal<\/h2>\n\n

Ironically, even though tech giants are the ones that are most likely to benefit from microservices, many of these very same companies are walking back their microservices architectures, and the results are eye-opening.<\/p>\n\n

Amazon Prime Video: 90% Cost Reduction with a Monolith<\/h3>\n\n

In May 2023, Amazon engineers admitted the unthinkable: Prime Video had abandoned microservices for a monolith. Their Video Quality Analysis (VQA) team had built what looked like a textbook distributed system: AWS Step Functions and Lambda monitored thousands of video streams through independent, scalable components. On paper, it was serverless perfection.<\/p>\n\n

In practice, it was a disaster. \u201cWe realized that distributed approach wasn\u2019t bringing a lot of benefits in our specific use case,\u201d said Marcin Kolny in the now-archived Prime Video Engineering blog<\/a>. Their \u201cinfinitely scalable\u201d system crumbled at just 5% of expected load<\/strong> due to orchestration overhead.<\/p>\n\n

The fix was embarrassingly simple: collapse everything into a single process. It resulted in 90% lower costs and faster performance<\/em>.\u00a0<\/p>\n\n

Twilio Segment: From 140 Services to One Fast Monolith<\/h3>\n\n

Back in 2018, Twilio Segment, a customer data platform, documented a similar reversal in their brutally honest post \u201cGoodbye Microservices\u201d<\/a>.<\/p>\n\n

Their system had sprawled into 140+ services, creating operational chaos. At one point, three full-time engineers spent most of their time firefighting instead of building. As they admitted, \u201cInstead of enabling us to move faster, the small team found themselves mired in exploding complexity. Essential benefits of this architecture became burdens. As our velocity plummeted, our defect rate exploded.\u201d<\/p>\n\n

Their solution was radical but effective: collapse all 140+ services into a single monolith. The impact was immediate. Test suites that once took an hour now finished in milliseconds. Developer productivity soared: they shipped 46 improvements to shared libraries in a year, up from 32 in the microservices era.\u00a0<\/p>\n\n

Shopify: Sanity over Hype<\/h3>\n\n

Shopify runs one of the largest Ruby on Rails codebases in the world (2.8M+ lines). Instead of chasing microservices, they deliberately chose a modular monolith<\/a>: a single codebase with clear component boundaries.<\/p>\n\n

Shopify\u2019s engineers concluded that \u201cmicroservices would bring their own set of challenges\u201d, so they chose modularity without the operational overhead.<\/p>\n\n

All these examples beg the question:<\/p>\n\n

If even the pioneers of microservices are retreating, why are we still treating it as gospel?<\/p>\n\n

Expert Voices against Microservices Mania<\/h2>\n\n

Some of the most respected voices in software architecture\u2014people behind many of the systems we all admire\u2014are also cautioning against microservices and repeating mistakes they\u2019ve seen play out at scale. (After all, cheerleaders don\u2019t play the game; cloud DevRels rarely build at scale.)<\/p>\n\n

Rails Creator: Simplicity over Sophistication<\/h3>\n\n

David Heinemeier Hansson<\/a> (DHH), the creator of Ruby on Rails, has long advocated simplicity over architectural trends. His analysis of the Amazon Prime Video reversal<\/a> puts it bluntly:<\/p>\n\n

\u201cThe real-world results of all this theory are finally in, and it\u2019s clear that in practice, microservices pose perhaps the biggest siren song for needlessly complicating your system.\u201d<\/strong><\/p>\n\n

DHH\u2019s image of a siren song is apt: microservices promise elegance but leave teams wrecked on the rocks of complexity.<\/p>\n\n

Microservices: Mistake of The Decade?<\/h3>\n\n

Jason Warner, former CTO of GitHub<\/a>, doesn\u2019t mince words while commenting on microservices:\u00a0<\/p>\n\n

\u201cI\u2019m convinced that one of the biggest architectural mistakes of the past decade was going full microservice.\u201d<\/strong><\/p>\n\n

Warner understands scale: GitHub runs at internet scale, and he\u2019s led engineering at Heroku and Canonical. His critique cuts deeper because it\u2019s lived experience, beyond theoretical advice<\/a>:<\/p>\n\n

\u201c90% 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.\u201d<\/strong><\/p>\n\n

GraphQL Co-Creator: \u201cDon\u2019t\u201d<\/h3>\n\n

Then there\u2019s Nick Schrock, co-creator of GraphQL<\/a>. If anyone had a reason to cheer for distributed systems, it\u2019d be him. Instead, he says:<\/p>\n\n

\u201cMicroservices 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.\u201d<\/strong><\/p>\n\n

\n \"microservices\n <\/div>\n\n

He goes on to describe microservices as organizational gambles<\/a>:<\/p>\n\n

\u201c[Y]ou end up with these services that you have to maintain forever that match the org structure and the product requirements from five years ago. Today, they don\u2019t make a lot of sense.\u201d<\/strong><\/p>\n\n

The person who literally built tools to fix distributed system pain says don\u2019t distribute unless you must<\/strong>, maybe it\u2019s time to listen.<\/p>\n\n

Other Voices Questioning Microservice Maximalism<\/h3>\n\n

Other engineering leaders are also reconsidering microservice maximalism.\u00a0<\/p>\n\n

At Uber, Gergely Orosz admitted<\/a>:<\/p>\n\n

\u201cWe\u2019re moving many of our microservices to macroservices (well-sized services). Exactly b\/c testing and maintaining thousands of microservices is not only hard \u2013 it can cause more trouble long-term than it solves the short-term.\u201d<\/strong><\/p>\n\n

Uber still runs microservices where they\u2019re justified, but they\u2019re choosing their battles<\/a>.<\/p>\n\n

Kelsey Hightower<\/a>, known for his work with Kubernetes and Google Cloud, cut through the microservices hype with CS101:<\/p>\n\n

\u201cI\u2019m willing to wager a monolith will outperform every microservice architecture. Just do the math on the network latency between each service and the amount of serialization and deserialization of each request.\u201d<\/strong><\/p>\n\n

He subsequently deleted this tweet, but the network math still grades microservices.<\/p>\n\n

When pioneers like these, including those who actually solved distributed systems at scale, start waving red flags, it\u2019s worth taking note.\u00a0<\/p>\n\n

My question here is:<\/p>\n\n

If GitHub\u2019s CTO thinks 90% of companies don\u2019t need microservices, are you sure yours is part of the 10%?<\/p>\n\n

The Hidden Costs of Microservices<\/h2>\n\n

Microservices demand such caution because of these hidden costs that teams often underestimate.<\/p>\n\n

Operational Costs<\/h3>\n\n

A monolith is simple: in-process function calls.\u00a0<\/p>\n\n

Microservices replace that with networks. Every request now travels across machines, through load balancers, service meshes, and authentication layers, creating more failure points and infrastructure needs. You suddenly need service discovery (how services find each other), distributed tracing (tracking requests across services), centralized logging (aggregating logs from multiple services), and monitoring systems that understand service topology.<\/p>\n\n

Each of these is necessary, but together they\u2019re complex and expensive. Duplicated data requires extra storage. Constant service-to-service calls rack up network egress fees. Cloud costs scale faster<\/a> than the apps they host. Prime Video\u2019s workflow spent more on orchestrating S3 data transfers<\/a> between services than on actual processing.\u00a0<\/p>\n\n

Developer Productivity Drain<\/h3>\n\n

In microservices, the hard part isn\u2019t writing code; it\u2019s navigating distributed system interactions.<\/p>\n\n

In \u201cThe macro problem with microservices<\/a>\u201c, Stack Overflow identifies a critical productivity drain: distributed state forces developers to write defensive code that constantly checks for partial failures.\u00a0<\/p>\n\n

In a monolith, a developer can follow a code path end-to-end within one repo. In microservices, one feature might span four or five repos with different dependencies and deploy cycles. Adding a single field triggers weeks of coordination: you need to update one service, then wait for consumers to adopt, version your APIs, manage rollouts, and so on. Different teams will also typically maintain different microservices using different tech stacks, so there\u2019s a risk that they unintentionally break something as well. Breaking changes that a compiler would catch in a monolith now surface as runtime errors in production.<\/p>\n\n

Testing and Deployment Complexity<\/h3>\n\n

Monolith integration and end-to-end tests are faster because they run locally, in memory. Distributed systems don\u2019t allow that luxury: real confidence requires integration and end-to-end tests across numerous service boundaries. So these tests are slower, more brittle, and require staging environments that resemble production, all of which effectively double infrastructure costs and slow feedback loops.<\/p>\n\n

Many teams discover this only after their test suite becomes a bottleneck<\/a>. Deployment orchestration adds another layer. Rolling updates across interdependent services require careful sequencing to avoid breaking contracts. Version incompatibility disturbs frequently: Service A works with Service B v2.1 but breaks with v2.2.<\/p>\n\n

Failed deployments leave systems partially updated and difficult to recover.<\/p>\n\n

Data Management and Consistency<\/h3>\n\n

The most underestimated complexity of microservices lies in data consistency across service boundaries.<\/p>\n\n

Monoliths benefit from ACID transactions: operations complete entirely or fail entirely. Microservices split that across services, forcing you to build distributed saga<\/a> (multi-step workflows with rollback logic), live with eventual consistency<\/a> (data only becomes correct after a delay), or write compensation logic<\/a> (extra code to undo partial failures). What was once a single database transaction now spans network hops, retries, and partial failures. Debugging inconsistent orders or payments gets much harder when state is duplicated across services.\u00a0<\/p>\n\n

As research confirms<\/a>, data duplication, correctness challenges, and transactional complexity are the top pain points in microservice systems.<\/p>\n\n

The Compounding Effect<\/h3>\n\n

These complexities multiply. Operational overhead makes debugging harder, which slows testing, which makes deployments riskier, which creates more incidents. Microservices don\u2019t just shift complexity from code to operations; they tax every part of your engineering process.\u00a0<\/p>\n\n

Unless your scale demands it, that tax often outweighs the benefits.\u00a0<\/p>\n\n

Think about it:<\/p>\n\n

If every network hop adds complexity and cost, does your use case really justify the price?<\/p>\n\n

Beyond Microservices: Smarter Architectural Alternatives<\/h2>\n\n

Before defaulting to microservices, it\u2019s worth considering how simpler, well-structured architectures can deliver comparable scalability without the distributed complexity tax. Two noteworthy alternatives are modular monoliths and service-oriented architectures.<\/p>\n\n

Modular Monoliths: Structure without Distribution<\/h3>\n\n

Unlike traditional monoliths that become tangled messes, modular monoliths<\/a> enforce strict internal boundaries through clear module APIs and disciplined separation. Each module exposes well-defined interfaces, enabling teams to work independently while deploying a single, coherent system.<\/p>\n\n

\n \"modular\n <\/div>\n\n

As Kent Beck explains in \u201cMonolith -> Services: Theory & Practice\u201d<\/a>, modular monoliths manage coupling through organizational discipline rather than distributed networks. The key difference: modules still communicate via explicit contracts like microservices, but they use fast, reliable function calls instead of HTTP requests that are vulnerable to network latency and partial failures.<\/p>\n\n

Why does it work?<\/p>\n\n