The microservices hype of 2015 was real and understandable. Netflix was doing it. Amazon was doing it. The architecture promised independent deployability, independent scalability, and small teams who owned entire services end to end. The conference talks were compelling.
What the conference talks left out was what happened on Monday morning when you tried to implement this at your company.
I watched several teams go through the transition during 2015. A few of them succeeded. Several struggled. The pattern that emerged was clear: microservices are a solution to specific problems that large organisations have. If you do not have those problems, you are trading a set of problems you understand for a set of distributed systems problems you do not.
The first thing teams discovered was that distributed systems are genuinely harder than single-process applications. Network calls fail. They are slow. They add latency. They timeout. In a monolith, a function call either works or throws an exception. In a microservices architecture, a service call might fail, timeout, return a partial result, or succeed but take three seconds. Handling all these cases correctly requires patterns like circuit breakers, retries with backoff, timeouts, and bulkheads. These are not difficult concepts but implementing them consistently across many services is real work.
The second discovery was about data. In a monolith, a database transaction is easy. You change multiple tables atomically. In microservices, each service owns its data and you cannot have database transactions across services. Instead you need eventual consistency and saga patterns. Teams that had never thought about distributed transactions suddenly needed to.
The third discovery was operational complexity. Running five services requires more infrastructure than running one. Service discovery, distributed tracing, aggregated logging, health checks, and deployment pipelines all need to be solved for each service. Small teams found themselves spending most of their time on infrastructure rather than product features.
The teams that succeeded with microservices in 2015 had two things in common. First, they had real organisational scale problems that the architecture addressed: separate teams who needed to deploy independently, services with genuinely different scaling requirements, codebases so large that the monolith had become a productivity bottleneck. Second, they had strong platform teams who solved the infrastructure problems once so that application teams did not have to.
The teams that struggled had adopted the architecture for its own sake, driven by what was fashionable rather than by genuine problems. They got all the complexity and none of the benefits.
The honest advice I would have given in 2015, and still believe now: start with a monolith. Build it well. If and when you hit the problems that microservices solve, you will know, because those problems will be obvious and painful. Then, with a working product and a clear understanding of your domain, splitting services makes sense. But do not start there.