You Want Microservices, But Do You Really Need Them?
Microservices: The Agility-Complexity Trade-Off
p. “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.”
p. “Microservices make sense in very specific scenarios where distinct business capabilities need independent scaling and deployment.”
p. “For example, payment processing (security-critical, rarely updated) differs fundamentally from recommendation engine (memory-intensive, constantly A/B tested). <b>These components have different scaling patterns, deployment cycles, and risk profiles, which justify separate services.</b>“
The Great Microservices Reversal
Amazon Prime Video: 90% Cost Reduction with a Monolith
p. “Their “infinitely scalable” system crumbled at just 5% of expected load due to orchestration overhead.”
p. “The fix was embarrassingly simple: collapse everything into a single process. It resulted in 90% lower costs and faster performance.”
Twilio Segment: From 140 Services to One Fast Monolith
p. “Their system had sprawled into 140+ services, creating operational chaos.”
p. “Their solution was radical but effective: collapse all 140+ services into a single monolith. The impact was immediate.”
p. “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.”
Shopify: Sanity over Hype
p. “Instead of chasing microservices, they deliberately chose a modular monolith: a single codebase with clear component boundaries.”
Expert Voices against Microservices Mania
If even the pioneers of microservices are retreating, why are we still treating it as gospel?
Rails Creator: Simplicity over Sophistication
p. ““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.””
Microservices: Mistake of The Decade?
p. ““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.””
The Hidden Costs of Microservices
Operational Costs
p. “A monolith is simple: in-process function calls.”
p. “Microservices replace that with networks.”
p. “through load balancers, service meshes, and authentication layers, creating more failure points and infrastructure needs.”
p. “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. “Duplicated data requires extra storage. Constant service-to-service calls rack up network egress fees.”
Developer Productivity Drain
p. “In microservices, the hard part isn’t writing code; it’s navigating distributed system interactions.”
p. “Stack Overflow identifies a critical productivity drain: distributed state forces developers to write defensive code that constantly checks for partial failures.”
p. “one feature might span four or five repos with different dependencies and deploy cycles.”
p. “Different teams will also typically maintain different microservices using different tech stacks, so there’s 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.”
Testing and Deployment Complexity
p. “Monolith integration and end-to-end tests are faster because they run locally, in memory.”
p. “Deployment orchestration adds another layer. Rolling updates across interdependent services require careful sequencing to avoid breaking contracts.”
p. “Version incompatibility disturbs frequently: Service A works with Service B v2.1 but breaks with v2.2.”
Data Management and Consistency
p. “Monoliths benefit from ACID transactions: operations complete entirely or fail entirely.”
The Compounding Effect
p. “Operational overhead makes debugging harder, which slows testing, which makes deployments riskier, which creates more incidents. Microservices don’t just shift complexity from code to operations; they tax every part of your engineering process.”
Operational Overhead → Hard Debugging → Slow Testing → Deployment Risk → More Incidents...
Beyond Microservices: Smarter Architectural Alternatives
Modular Monoliths: Structure without Distribution
p. “As Kent Beck explains in “Monolith → Services: Theory & Practice”, modular monoliths manage coupling through organizational discipline rather than distributed networks.”
Service-Oriented Architecture: The Middle Ground
p. “Service-oriented architecture (SOA) sits between monoliths and microservices, favoring larger, domain-driven services instead of dozens or hundreds of tiny ones.”
p. “Instead of splitting authentication, user preferences, and notifications into separate microservices, SOA might combine them into a single “User Service”, simplifying coordination while preserving autonomy and targeted scaling.”
Choosing Wisely: Fit over Hype
p. “In all likelihood, you’re not Google (you don’t need Google-level fault tolerance), or Amazon (you don’t need massive write availability), or LinkedIn (you don’t handle billions of events a day). Most applications don’t operate at that scale, demanding fundamentally different solutions than ultra-distributed architectures.”
Docker: Built for Any Architecture
p. “Docker isn’t just for microservices—it works great across all kinds of architectures like monoliths, SOA, APIs, and event-driven systems. The real benefit is that Docker gives you consistent performance, easier deployment, and flexibility to scale up your apps no matter what architectural approach you’re using.”
Wrapping Up
p. “Will you design for cloud-native hype or for your own business requirements?”