Last week a friend shared this tweet with me:

Completely unscientific and hugely subjective question of the day: what is a sensible number of microservices?

@evnsio

my initial reaction was

I'd always say as few as you can get away with. They are great for solving certain problems but they add deployment/runtime complexity that someone needs to think about. #monolithfirst

@meadsteve

and, after a little more thought, I followed up with

Always 1 less than you need

@meadsteve

I wanted to clarify why I thought this way. I’m making the following assumptions:

• Two services is more complicated than one service.
• The added complexity of an extra service can be reduced with good tooling but never to zero.
• If we can’t design a well structured monolith we won’t have good microservice boundaries either.

For a system you’ll, fairly obviously, have one of the following situations:

1. Exactly the right number of services.
2. More services than you need.
3. Less services than you need.

Ignoring number 1 completely, because I doubt I’ll ever get things right on the first try, would I prefer to be in state 2 or state 3? If in doubt I will always prefer a decision that’s easier to reverse/change. Splitting out a new service from an existing service usually looks something like this:

The process of splitting required drawing up some boundaries, moving the newly bounded code to its own service then running it. These services can now be worked on fully independently. This is one of the strengths of a microservice. However as time goes on the codebases will diverge. This will get to the point where recombining them is no longer sensibly possible. Frameworks could have changed, internal storage could be different, maybe one has been rewritten in a different language. So although splitting is easy. Recombining is not. This makes it somewhat of an irreversible decision.

So this causes a general trend for service numbers to increase rather than decrease. Given this I’d rather have less services because I know I can always increase towards my goal. But once I have too many I’m likely stuck.

Martin fowler wrote the following 5 years ago, and I believe it still applies today: MonolithFirst