Microservices vs monolith as an economic decision, not a fashion choice
When leaders debate microservices vs monolith, they rarely start with money. Yet the most honest comparison between microservices and a monolithic architecture is a cost model, not a conference diagram. For a delivery manager owning a roadmap, the architecture choice is a business decision disguised as software engineering.
Take a typical benchmark: a microservices architecture running on Kubernetes can easily reach around 800 dollars per month in cloud spend, while an equivalent monolithic application on a single virtual machine might sit near 120 dollars with similar user traffic and features. This figure comes from a simple methodology: price a small managed Kubernetes cluster with three worker nodes, a managed database per service, and baseline observability, then compare it with one VM, one database, and shared monitoring for a single deployable. For example, assume three t3.medium-class nodes at roughly 40 dollars each, three small managed databases at 60 dollars each, and 80 dollars for logging and metrics, versus a single t3.large-class VM at about 80 dollars, one 40 dollar database, and the same 120 dollars of shared observability. That 680 dollar gap is only the visible part of the software iceberg, because it excludes SRE staffing, observability platforms, and the extra testing and deployment pipelines that distributed systems demand. When you read internal FinOps reports or public case studies, you often see that an application estate built as microservices quietly doubles the total cost of ownership compared with a well tuned monolith.
Architecture choices also shape how fast your team can ship software and how often it breaks. A tightly coupled monolithic application with a single code base can feel slow to change, but it keeps service boundaries inside the same process and avoids network flakiness between services. A microservice architecture promises independent services and faster software development, yet it often replaces simple in process calls with complex distributed systems that increase failure modes and operational complexity.
Five hard questions to answer before you split a monolith
Before you move from a monolithic architecture to microservices, you should answer five questions in writing. How many teams will work on this application, and do they truly need independent deployment of their services to meet business goals? As a rough threshold, if you have fewer than three cross functional teams or fewer than 15 engineers on the product, the coordination savings from microservices are usually small compared with the operational overhead. Where are the natural service boundaries in your domain model, and can you keep data ownership clear without a shared database that turns microservices monolithic again?
Next, ask whether your service level objectives differ meaningfully between parts of the entire application. If your checkout service, search service, and admin services all share the same uptime and latency targets, a modular monolith with strong internal architecture and microservices style boundaries may be enough. When SLOs diverge sharply, for example when one capability needs 99.95 percent uptime and sub 200 millisecond latency while others can tolerate 99.5 percent and slower responses, a microservice architecture can let you scale and harden the most critical applications while keeping less critical services cheaper and simpler.
Geography matters more than most slide decks admit. If your teams are spread across regions and time zones, microservices vs monolith becomes a question of communication overhead versus runtime complexity. In that case, a microservices architecture with clear service boundaries can mirror the organisation chart, but you must budget for the extra testing, deployment, and observability work that every microservice and every set of distributed systems will require. This is where reading a deep analysis of what modern platform engineering actually costs, such as the piece on platform engineering economics, becomes essential.
Cost model template: the real price of each service per year
To compare microservices vs monolith rigorously, build a cost model per service per year. Start with direct cloud costs for each service, including compute, storage, network egress, and managed databases that support the microservice architecture. Then add the shared platform costs for Kubernetes clusters, service meshes, API gateways, and observability tools that all services and applications consume.
Next, layer in people costs tied to architecture choices. A microservices architecture usually demands SREs, platform engineers, and FinOps specialists to manage distributed systems, while a monolithic architecture can often run with a smaller operations team. When you allocate salaries, on call premiums, and training across the entire application portfolio, you often find that each microservice costs tens of thousands of dollars per year in fully loaded expenses.
Finally, include the cost of complexity in your model. Every extra service boundary adds more testing scenarios, more deployment pipelines, and more failure modes that your software engineering teams must handle. When you read post incident reviews, you will often see that estates built as microservices suffer from cross service outages that would have been single process bugs in a monolithic application, and this operational drag is a real business cost. As a simple worked example, take a system with 10 services at 70 dollars per month each in infrastructure, plus 1,000 dollars per month of shared platform spend and 240,000 dollars per year of operations salaries; allocating platform and people costs evenly yields roughly 30,000 dollars per service per year, which you can compare directly with a single monolith running on one VM and a smaller ops team. If you halve the number of services to five while keeping platform and headcount constant, the per service cost jumps to around 54,000 dollars, illustrating how service count and shared overhead interact in a basic sensitivity analysis.
Three signals you have over decomposed your architecture
Many organisations end up with monolithic microservices, where they pay for distributed systems but keep monolithic behaviours. The first signal is deploy coupling: if changing a single feature forces you to deploy five or six services together, you have recreated a monolith across the network. In that situation, your microservices architecture is tightly coupled in practice, even if the diagrams show clean service boundaries.
The second signal is a shared database that quietly undercuts the architecture microservices story. When multiple services write to the same tables, you no longer have independent applications; you have a distributed monolith with extra failure points. This pattern makes testing harder, because integration tests must cover the entire application behaviour across services and the shared schema, which slows software development and increases risk.
The third signal is rising cross service incident frequency. If most production incidents involve more than one service, your microservices monolithic mix is not isolating failures effectively. At that point, leaders should read their incident data as a mandate to consolidate services, reduce complexity, and move back toward a modular monolithic architecture that keeps the code base cohesive while still enforcing internal boundaries.
The modular monolith path: enforcing boundaries inside a single deployable
Amazon Prime Video made headlines when it consolidated a complex microservices architecture back into a monolith and cut costs by roughly 90 percent for a critical video monitoring workload. In their public engineering blog, the team described how removing per service overhead, cross service network calls, and duplicated infrastructure produced the saving, providing a verifiable reference point for leaders building their own cost models. Their write up explicitly compared an AWS Lambda and Step Functions based design with a containerised monolithic application running on EC2, and the numbers in this article mirror those published figures. Shopify has long run billions in transactions on a modular monolith, proving that a single deployable can support massive business scale when the internal architecture is disciplined. These examples show that monolithic architectures are not legacy by default; they can be a strategic choice when combined with strong software engineering practices.
In a modular monolithic application, you treat internal modules almost like application microservices. Each module owns its data, exposes clear interfaces, and avoids tightly coupled dependencies on other modules, even though everything lives in one process and one deployment unit. This approach keeps testing and deployment simpler than in distributed systems, because you can run the entire application locally while still respecting service boundaries in the code.
Modern languages make this pattern practical. In Java, you can enforce module boundaries with explicit packages and build tooling that prevents cross module imports, while in Go and TypeScript you can structure the code base into domain oriented packages that mimic microservices boundaries. For leaders, the key is to design the architecture so that moving a module out into its own service later is a refactoring, not a rewrite, which preserves strategic options as the software and the business evolve. For a deeper view on how cross platform application development patterns support this evolution, the analysis on the evolution of cross platform app development is a useful complement.
Migration stories in both directions and when a mixed estate is healthy
Real organisations rarely live at the extremes of pure microservices or a pure monolith. Many start with a monolithic application, extract a few high change services into a microservice architecture, then stabilise with a mixed estate that reflects actual business needs. The healthiest portfolios treat architecture as a living decision, not a one way migration project.
One common pattern is to carve out a high volatility feature as a microservice while keeping the rest of the entire application as a monolith. For example, a pricing engine or recommendation engine can run as a separate service with its own deployment cadence, while order management and billing remain in a monolithic architecture for simplicity. This lets teams experiment quickly in one part of the software without forcing every application to pay the complexity tax of distributed systems.
The reverse migration also happens. Teams that over decomposed into dozens of services often consolidate back into fewer, larger services or even a single deployable, especially when they read their FinOps data and see the cost of idle services. As a rule of thumb, once you exceed 25 to 30 microservices for a single product and need a dedicated platform or SRE team to keep up, it is worth running a consolidation experiment on a subset of the estate. A mixed model software portfolio, where some applications built as microservices coexist with robust monolithic applications, is often the most pragmatic outcome, and it aligns with analyst views that a modular monolith should be the default while microservices are reserved for cases where independent scaling and deployment clearly justify the extra complexity. For ongoing trends and patterns in this space, the deep dive on what is trending in microservices architecture is a valuable reference.
Practical decision playbook for product and delivery leaders
For a product or delivery manager, the microservices vs monolith debate must translate into concrete steering committee talking points. Start by framing architecture options in terms of business outcomes: time to market, reliability, and total cost of ownership over several years. Then map each outcome to specific software engineering choices, such as the number of services, the shape of service boundaries, and the level of operational tooling required.
When you evaluate a new application, ask whether a single deployable can meet your near term needs with a modular design. If yes, a monolithic architecture with strong internal boundaries is usually the lowest risk starting point, because it keeps testing, deployment, and debugging straightforward while your team learns the domain. As the business grows and some parts of the code base demand independent scaling or faster deployment, you can selectively extract microservices where the ROI is clear.
Finally, keep your architecture decisions legible to non technical stakeholders. Use simple diagrams that show how services and applications interact, highlight where distributed systems add complexity, and quantify the cost of each extra service in both cloud spend and people time. The most resilient organisations treat architecture as a portfolio level lever, continuously rebalancing between monolith and microservices so that the software serves the business, not the keynote demo, but the third quarter in production.
Key figures that shape the microservices vs monolith debate
- In public cloud benchmarks, a microservices architecture on Kubernetes for a mid sized workload can cost around 800 dollars per month in infrastructure, while an equivalent monolithic application on a single virtual machine can run near 120 dollars per month, implying more than a sixfold difference in baseline cloud spend before people costs. This comparison assumes three small worker nodes, a managed database per service, and standard observability versus one VM, one database, and shared monitoring, and is consistent with pricing calculators from major cloud providers at current list rates.
- Amazon Prime Video reported that consolidating a distributed microservices based monitoring system into a monolith reduced infrastructure costs by roughly 90 percent for that workload, illustrating how network hops, per service overhead, and duplicated infrastructure can dominate the cost structure of distributed systems. Their engineering blog post provides a detailed breakdown of the architecture before and after the migration.
- Shopify processes billions of dollars in transactions annually on a modular monolith, showing that a single deployable with strong internal architecture can meet extreme scale requirements when the code base is carefully structured and performance optimised. Public talks and engineering write ups from Shopify engineers describe how they enforce boundaries inside the monolith.
- Industry surveys from major consultancies have found that teams adopting microservices often underestimate operational overhead, with many organisations reporting the need to hire dedicated SRE and platform engineering teams once they exceed 20 to 30 services in production. These surveys typically combine self reported cost data, headcount numbers, and architecture diagrams from hundreds of enterprises.
- Analyst firms now increasingly recommend a modular monolith as the default architecture for new enterprise applications, reserving microservices for cases where independent scaling, differentiated SLOs, or complex organisational geography clearly justify the extra complexity and cost. Their published notes often include decision trees and cost models that mirror the questions outlined in this article.
FAQ: microservices vs monolith for modern software leaders
When is a monolithic architecture the better choice than microservices
A monolithic architecture is usually better when your team is small, your application domain is still evolving, and you do not need independent scaling or deployment for different parts of the system. In these cases, a single deployable with a cohesive code base keeps testing, debugging, and operations simpler. You can still design strong internal service boundaries so that future extraction into microservices remains possible if the business demands it.
What are the main hidden costs of microservices
The main hidden costs of microservices come from operations and coordination rather than pure development. Each service needs its own deployment pipeline, monitoring, alerting, and sometimes its own data store, which multiplies the work for SRE and platform engineering teams. You also pay in complexity, because distributed systems introduce network failures, cross service incidents, and more elaborate testing strategies that a monolithic application can often avoid.
How do I know if my organisation has overused microservices
You have likely overused microservices if most feature changes require coordinated deployments across several services, if multiple services share the same database tables, or if production incidents frequently involve more than one service. These are signs that your architecture is tightly coupled in practice, even if it is distributed in structure. In such cases, consolidating services or moving toward a modular monolith can reduce complexity and improve reliability.
Can a modular monolith scale as well as microservices
A modular monolith can scale very well for many business applications, especially when the code base is optimised and the infrastructure is sized appropriately. Horizontal scaling of a single deployable behind a load balancer can handle high traffic, as demonstrated by companies like Shopify. Microservices become necessary mainly when different parts of the system have very different scaling or reliability requirements that justify independent services.
Is it possible to mix monolith and microservices in the same portfolio
Yes, many mature organisations run a mix of monolithic applications and microservices in the same portfolio. They keep stable, well understood domains in a monolithic architecture while carving out high change or high scale capabilities into separate services. This mixed approach lets leaders align architecture with business needs, rather than forcing every application into a single pattern.
