What Changed
Microservices emerged as a response to the failure modes of large monoliths — the kind of codebase where changing a button required a 45-minute deploy pipeline and sign-off from three teams.
Containerisation, orchestration platforms like Kubernetes, and the normalisation of API-first design made microservices operationally viable for smaller teams. What used to require a platform team of 20 can now be managed by 2–3 engineers with the right tooling.
The Real Cost
The promise of microservices is organisational: independent deployability, isolated failure domains, and the ability for teams to move without coordination.
The cost is operational complexity that compounds. Every service boundary is a network call. Every network call can fail. Every failure mode needs graceful handling.
- Service discovery and load balancing
- Distributed tracing and observability
- Cross-service authentication
- Data consistency without shared databases
- Versioning and backward compatibility
When to Use Them
The honest answer: later than you think. Most products still finding product-market fit will be better served by a well-structured monolith. Speed of iteration matters more than architectural purity at that stage.
Reach for microservices when you have distinct scaling requirements per domain, organisational boundaries that map cleanly to service boundaries, and a platform team that can absorb the operational complexity.
Closing
Microservices are a tool, not a goal. The question is not 'should we use microservices' but 'what problem are we solving, and is this the right tool for it.'
For most teams, the answer is: start with a modular monolith, extract services when the pain is real, and instrument everything from day one so you can see what's actually happening.