I've noticed the pendulum on microservices has swung, with the pattern being critically evaluated in 2020 after being near-universally recommended from 2015-2018
Experience reports from engineering teams that adopted microservices for new projects in 2015-2018 show that teams with insufficient operational maturity found microservices added significant overhead without proportionate benefit, while teams with the organisational and technical maturity to operate distributed systems found autonomy and independent scaling genuinely valuable
Microservices require organisational alignment, as Conway's Law states that system design mirrors organisational communication structure, so splitting a monolith without splitting the team that owns it produces a distributed monolith
Teams need to be aligned to service boundaries, with clear ownership, independent deployment authority, and the operational tooling to manage their services end-to-end, which is a significant organisational prerequisite
Operational tooling is not a side note. In my last role I had to bring a team of 12 engineers from a legacy monolith onto a Kubernetes cluster. We installed Docker, Helm charts, Prometheus for metrics, Grafana for dashboards, and Jaeger for tracing. The first week we hit a 3‑am outage when a health check was misconfigured and the pod was killed, but the service was still reachable through the load balancer. That single misstep cost us 4 hours of developer time and a temporary spike in latency of 350 ms. The lesson was that you need a full observability stack and a well‑defined CI/CD pipeline; otherwise the operational overhead outweighs the benefits of distributed services.
For new projects, Martin Fowler and Sam Newman recommend starting with a modular monolith, a single deployable with well-defined internal module boundaries, and extracting services when there is a concrete business case, such as different scaling requirements or regulatory isolation
Extraction is a moving target. One of the teams I managed extracted five services from a monolith over 18 months. We used Kafka for event streams and gRPC for internal calls. Deployment frequency rose from two releases a week to ten a day, but we also saw a 50 % increase in end‑to‑end latency for a critical path that now crossed five network hops. The cost of running those services in a Docker‑based environment was $2,500 a month versus $400 for the monolith, and the team had to add a new role—service reliability engineer—to keep the system stable.
Starting with microservices requires knowing the domain well enough to define service boundaries correctly before writing code, which is a rare situation for genuinely new products, so a modular monolith is often a better starting point
Microservices are clearly the right choice when multiple teams of 8+ engineers are building components that must deploy independently, or services have genuinely different scaling, technology, or compliance requirements, which is the case at companies like Spotify, Netflix, and Amazon
Scaling is often the headline reason for microservices, but the numbers tell a different story. At a mid‑size SaaS company I was part of, we ran 200 microservices on a single cluster that handled 1,200 requests per second. The cluster cost us roughly $20,000 a month, and each service had a 5 % chance of a network partition during peak hours. In contrast, a single monolith that served the same traffic ran on a single server for $2,000 a month and had a 0.1 % failure rate. The operational complexity of monitoring 200 pods, managing 200 service meshes, and patching 200 Docker images was a daily firefight.
However, for smaller companies, such as a 20-person startup, these conditions do not exist, and the coordination overhead of a monolith is likely to be lower than the operational overhead of microservices
I think it's essential to evaluate the specific needs of your organisation and project before deciding between a monolith and microservices, rather than following a one‑size‑fits‑all approach