The pendulum on microservices has swung. The pattern that was near-universally recommended from 2015-2018 is being critically evaluated in 2020, with more nuanced guidance on when it's appropriate.
What the experience report shows
Engineering teams that adopted microservices for new projects in 2015-2018 have five years of production experience. The experience reports are consistent: teams with insufficient operational maturity (distributed tracing, service mesh, GitOps deployment, SRE practices) found microservices added significant overhead without proportionate benefit. Teams with the organisational and technical maturity to operate distributed systems found the autonomy and independent scaling genuinely valuable.
The organisational prerequisite
Microservices require organisational alignment. Conway's Law states that system design mirrors organisational communication structure. Splitting a monolith without splitting the team that owns it produces distributed monolith: services that deploy together because they are tightly coupled. Microservices require teams that are aligned to service boundaries, with clear ownership, independent deployment authority, and the operational tooling to manage their services end-to-end.
The modular monolith as a starting point
For new projects, Martin Fowler and Sam Newman (author of Building Microservices) both recommend starting with a modular monolith: a single deployable with well-defined internal module boundaries. Extract services when there is a concrete business case: different scaling requirements, different deployment frequency, regulatory isolation. Starting with microservices requires knowing the domain well enough to define service boundaries correctly before writing code, a rare situation for genuinely new products.
When microservices are clearly right
Microservices are unambiguously the right choice when: multiple teams of 8+ engineers are building components that must deploy independently, services have genuinely different scaling, technology, or compliance requirements, or the organisation is large enough that the coordination overhead of a monolith exceeds the operational overhead of microservices. These conditions exist at Spotify, Netflix, and Amazon. They do not exist at a 20-person startup.