One less microservice than you need

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?


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


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

Always 1 less than you need


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

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:

splitting out a service

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

Agree? Disagree? Send me a tweet!