The Horror of Microservices in Small Teams

The Horror Begins

Microservices sound appealing because each team can work independently without affecting others, making maintenance and scaling easier, and allowing different technologies within the same project; however, by 2021 it is no longer advisable to build any application as a monolith.

Unfortunately, microservices are not suitable for every environment; before adopting them blindly you must verify the value they provide. The author has seen typical projects with 4–6 developers where the client demanded a microservice architecture, the IT manager agreed, and the team began designing the application.

User management, access control, scheduling, order processing via third‑party APIs—each is labeled a microservice, leading to a situation where everyone has multiple microservices, sometimes even defying physical laws.

Microservice Highlights

When you start this journey, each microservice must have its own CI/CD pipeline, database, and versioned API.

In a small team you may end up building all these services yourself. One person (let’s call her Ellie) may need to adjust and test multiple services simultaneously, debugging them in parallel without writing extensive distributed‑system code.

The first version of the application is delivered to the customer, but rolling updates introduce multiple versions of services that must remain compatible or be gracefully upgraded.

In the worst case you end up with a distributed monolith, experiencing all the drawbacks of microservices without reaping their benefits.

Where Are the Benefits?

Companies like Amazon and Netflix pioneered microservices, emphasizing the “two‑pizza team” rule: a team should be small enough that two pizzas can feed it, and each team should own its service completely.

In monolithic applications, managing code and dependencies across hundreds of developers is cumbersome. Microservices decouple components, allowing teams to work independently, choose their own technology stacks, and avoid coordinating with dozens of other teams.

Microservices are not required for managing large software; they are useful when many people use the software.

What Should You Do Now?

Microservices do not automatically lead to chaos, but you must consider whether they truly add value for your situation. If the added complexity outweighs the benefits, you can skip them.

A good development paradigm is to keep things simple. If a simpler solution achieves the same result, there is no reason to adopt a more complex architecture.

Microservices add complexity: you must manage all services, control the entire application, and handle version compatibility, which may not be justified for a product that will not become the next Netflix.

Instead, enjoy the benefits of a relatively monolithic application: faster development, no need to coordinate inter‑service communication, no heavy Docker images, and easier debugging, especially when using frameworks like Spring Boot.

You don’t have to commit fully to either monoliths or microservices; you can partition the application into meaningful modules—perhaps following Domain‑Driven Design—while still adhering to the Twelve‑Factor App principles, sharing build pipelines, and deploying a single version.

How Do I Scale?

If your product is successful and you need more features and teams, consider splitting the application into microservices at the right time.

When the codebase is well‑structured and modules are decoupled, splitting should not be overly difficult, though it does require effort.

Choose the appropriate architecture at the right moment and maintain simplicity, focusing on code quality and architecture.