Microservices adoption anti-pattern: More the merrier

So far in this series I’ve covered the following anti-patterns

Another anti-pattern that I’ve seen is More the merrier. It occurs when an organization intentionally creates a very fine-grained microservice architecture. Perhaps they take the micro part of microservices too literally. Or perhaps, they believe that the more services the better.

Consequences

On the one hand, defining more services has several benefits. Each service is smaller and easier to understand and change. It’s also easier and faster to test.

But on the other hand, there are several potential problems with an excessively fine-grained microservice architecture. Defining more services moves complexity from within the services to between the services. Each additional service makes development, testing and deployment more complicated. Also, there are diminishing returns with increasing the number of services. For example, at some point, services are small enough to understand and change and fast enough to test. Defining more services also increases the risk that changes will require multiple services to change it lockstep, which requires more coordination and planning and slows down development.

A better approach: start with one service per team

The microservice architecture accelerates software delivery by structuring an application as a set of loosely coupled services owned by a small, high performance, cross functional team. Consequently, a better approach to service decomposition is to start with one service per team since that’s the bare minimum needed for the teams to be loosely coupled.

Define more services only when it solves a problem.

Additional services should only be defined when doing so clearly solves a problem with, for example, maintainability or testability.

Split services that become too large

A service typically grows in size and complexity over time. It can become more difficult to maintain and test, which can reduce development velocity. In this situation, the service’s team should consider splitting the service into two. Each of the resulting services will be smaller and hence more maintainable and testable. The team can develop, test and deploy each service independently.

Split teams (and their services) that become too large

The growth of a service might cause its team to grow in size. Eventually, the team might become so large that it reduces development velocity. In this situation, a team should consider splitting itself and its service into two. Each of the two new teams is smaller and able to much more easily develop, test and deploy their smaller service.

To learn more

Read my Microservices patterns book
Read or watch my O’Reilly Software Architecture conference keynote
Talk to me about my microservices consulting and training services including how I can help you create a microservices migration roadmap for your organization
Learn more about microservices at adopt.microservices.io