Microservices: When the Cure Becomes the Problem

The Hype of Microservices Architecture

Microservices architecture has become a buzzword in the tech world. While it’s often touted as a modern and trendy solution, it inversely increases the technical debt of a system. This approach contradicts the "Keep It Simple and Stupid" (KISS) principle and most important, it is confused with an increase of scalability and performance when it has never been made for such.

The Performance Myth

Any monolithic architecture is by design more performant than the microservices one. Because of the lack of round trips between services, the modules being all in one place the communication happens directly in the CPU and the RAM and does not involve the network.

Scalability Simplified

Contrary to popular belief, a stateless monolithic application can achieve horizontal scalability effectively. By deploying replicas and using custom entry points, you can assign specific responsibilities to each instance without splitting the codebase. This not only enhances fault tolerance but also maintains simplicity in deployment and management.

When to Consider Microservices

So when to use the microservices architecture then? The answer lies in team collaboration. When multiple teams are involved in building and maintaining a system, managing a single codebase can become cumbersome. Frequent merge requests and collaboration bottlenecks can slow down development, especially when dealing with stale code or unreleased features.

In such scenarios, adopting a microservices architecture allows teams to work independently. Each team can develop, test and release features at its own pace, avoiding interdependencies that can block progress. However, this independence comes with its own set of challenges.

The Complexity Trade-Off

Microservices introduce significant complexity, necessitating a dedicated team to manage the service mesh and ensure seamless communication between services. For smaller teams, this complexity can be overwhelming and lead to poor implementation choices right from the project’s inception.

Start with Monolith, Scale Strategically

For most projects, starting with a monolithic approach is more productive and practical. As the project evolves, you will naturally create supporting services, such as real-time event management or analytics. These satellite services complement the monolith without disrupting its core functionality.

Avoid the Hype Train

Be careful to not follow the hype train when you are building your project (microservices, AI, web3, your daily new JS framework, etc.). Most of the time your project don't need them.

Conclusion: Build your systems with pragmatism, not trends. Embrace monolithic architecture where it fits and transition to microservices only when the scale and collaboration demands truly justify the shift.