Microservices is one of the most discussed and most misunderstood architectural patterns in software engineering. For every organisation that has benefited enormously from moving to microservices, there is another that spent a year migrating and came out with more complexity and less velocity than it started with. This article tells you what microservices actually are, when they make sense, and when they don't.
What a Microservice Actually Is
A microservice is a small, independently deployable software component that does one thing well and communicates with other services through well-defined APIs. "One thing" is deliberately vague — in practice it usually means one bounded business domain: the Order Service, the Customer Service, the Inventory Service. Each service has its own codebase, its own database, its own deployment pipeline, and its own team ownership.
The opposite of microservices is a monolith — a single, cohesive application that contains all the business logic and is deployed as one unit. Monoliths have a terrible reputation they don't entirely deserve. A well-built monolith is an entirely legitimate architecture for many organisations.
The Benefits — When They're Real
Independent deployability: The Order Service team can ship new features without coordinating with the Payment Service team. This is the primary concrete benefit of microservices, and it only matters if your current deployment process is a bottleneck — which it usually is at a certain scale.
Independent scalability: If your Search Service needs 10× the compute of your Checkout Service during peak load, you scale only Search. You don't need to provision 10× resources for everything.
Technology flexibility: Different services can use different programming languages and databases, chosen for what's appropriate to each domain rather than constrained by the monolith's technology choices.
Failure isolation: A failure in the Recommendation Service shouldn't take down Checkout. Service boundaries create natural bulkheads that limit the blast radius of individual failures — when implemented correctly.
The Costs — Which Are Real Too
Microservices move complexity from within a single application to the interactions between many applications. You now need to manage service discovery, network communication, distributed tracing, cross-service authentication, eventual consistency in data, and the operational overhead of running many independent deployable units. For a small team, this overhead frequently exceeds the benefit.
The rule of thumb: if your organisation has fewer than 50-100 engineers and a relatively simple domain, a well-structured monolith will almost certainly outperform a microservices architecture on every metric that matters — development speed, reliability, and operational cost. Microservices earn their place at scale.
The Strangler Fig Pattern: Migrating Without the Big Bang
The most dangerous microservices antipattern is the big-bang rewrite: halt all feature development, spend 18 months rebuilding the monolith as microservices, and release. This almost never works. The Strangler Fig pattern is the alternative: new features are built as microservices from the start; existing monolith functionality is extracted to microservices incrementally when there is a specific reason to do so. The monolith shrinks over time as the microservices layer grows around it.
The Organisational Prerequisite
Microservices are an organisational architecture as much as a technical one. They only work well when teams are structured around services — each team owning one or more services end-to-end, including operations. "You build it, you run it" is the operating model microservices require. Without that team ownership model, microservices produce more coordination overhead than the monolith they replaced, without the independent deployment benefit that justified the move.