When Microservices Fail: 5 Scenarios to Avoid Their Use

Microservices are not a silver bullet; like any technology, they have limits. Michael Churchman recently discussed scenarios where microservices are appropriate and where they should be avoided.

Microservices are small, independently deployable services defined around a specific business capability. An application can consist of many microservices, each managed and deployed separately, allowing updates or failures in one service without bringing down the entire system.

While microservices offer better manageability for large, complex applications compared to monolithic architectures, they are not always the best choice, especially for smaller systems or when retrofitting existing applications.

1. Insufficient Complexity

As Martin Fowler noted, “don’t adopt microservices unless your system is complex enough to be hard to manage.” Microservice architectures introduce overhead in service design, communication, management, and resource usage; if an application cannot leverage these benefits, the costs outweigh the gains.

2. Small Teams, Large Workload

Consider a medium‑sized, moderately complex application maintained by a small team. In a monolith, communication is straightforward and optimizations are easier. Switching to microservices would increase the team’s workload, requiring more time for even minor changes and additional orchestration effort.

3. Too Small to Split

Not every application is large enough to be broken into microservices. For a suitably sized system, further decomposition can increase complexity rather than reduce it.

4. Coexisting with Legacy Systems

Most developers deal with legacy code daily. Before refactoring a legacy system into microservices, one must assess its lifecycle stage, criticality, and the effort required for a complete replacement. Without a clear migration strategy, the transition can be disastrous.

5. Tight Integration Requirements

Applications that demand tight component integration and real‑time processing—such as embedded systems or autonomous‑vehicle sensor pipelines—may suffer from added latency introduced by service boundaries. In resource‑constrained environments, monolithic designs often remain more suitable.

In summary, if your application is large and complex, microservices can improve manageability, but if it already works well, chasing the microservice trend may be counterproductive.

Original source: “5 Reasons Not to Use Microservices”.