The first law of distributed systems is, don’t distribute!

M. Fowler

If you still feel the need to consider moving to a distributed architecture then microservices is a good alternative to a monolith.

Robust and Stable

Microservices encourages a design where components are highly cohesive and have low coupling. This is an implicitly stable design.

Scalable

A monolith needs to be scaled as one entity, in a microservices architecture, every service and its underlying database can be scaled independently.

Ease of deployment

Modifying a monolith in production is like changing the wheels of a car as its moving. Deploying changes in a microservices architecture is more like a tire change at a F1 pitstop.

Teams can quickly make changes, fix bugs without stepping on each other teams toes.

Why are organisations adopting Microservices?

Here is a quote from Sam Newman that pins this down.

…the single biggest reason that organisations adopt microservices is to allow for more developers to work on the same system without getting in each others way

Sam Newman

Should you use Microservices?

Are you a small team?

There is a vast ecosystem of great open source tooling that can help you setup your own microservice architecture. However, if you are a small team, its probably not a good idea to “roll your own”.

We made this mistake. Our log aggregation SaaS was initially built with a self assembled stack that was really a distributed monolith. We spent weeks on plumbing and reliability rather than on features that delivered actual business value. Juggling all the moving parts in our stack took a lot of effort.

Small teams should really invest time on the business value of their software and use managed services by AWS, GCP or Azure to take care of the microservices infrastructure.

Are you a large team?

If you are a large team and having difficulties or even teething pains with your monolith, then it would be a good idea to consider incremental steps towards microservices. One of the best analogies, I’ve heard here is to think of microservices as a volume dial. Changes should be introduced step by step and not 0 to 10.