I have been a microservices skeptic and favored monolith software architecture.

The social network that I built, nderground.net, was a monolith.

In additon to the problems discussed in this post, there is the problem of communication. Many groups use communication frameworks like RabbitMQ. This can make debugging and deployment more difficult.

Recently, however, I have had an experience that showed me how microservices can be an advantage.

I am consulting for a company with a large application that is divided into microservices. I am working on a complex database upgrade/port where all of the access to this database is isolated in the microservice.

The microservice architecture has had a couple of advantages. By confining all knowledge of and access to the database to a microservice, the architecture has guaranteed that access to the database has not creeped into other components. This makes the database upgrade easier becasue all issues are isolated in one microservice.

All of the software is currently using Java 8. For the upgraded database, the new driver only works with Java 11 and above. Because there is a microservice architecture, the module I am working on can be moved to Java 11, while the rest of the system can still use Java 8 until they decide to upgrade.

If the entire system had to be moved to Java 11 it might have killed the database upgrade project (although that would be an unfortuante choice).

The microservices architecture also allows isolated testing, so this component can be verified by the existing tests. These tests take about two hours to run. Testing the entire system in the database port would be more time consulting and complicated.

If there is a relatively small software engineering group, a monolith is the best choice since it can be developed and deployed more rapidly.

Once the system grows to the point where there is a larger group, microservice may be an advantage since it provides the isolation in the project I am working on.

As this post notes, there are always costs and tradeoffs. One of those is often that only a small group understands a particular microservice, since everyone else can treat it like a black box. In the case of the microservice I am working on, only a few engineers have experience with the software.