​One of the go-to wars around microservices is how small they should be (I have beef with this beef, but that’s another topic for another day).

Some people say they should be no bigger than the code that fits on your screen.

Some people say they should be no bigger than what’s necessary to encompass their reason for existing.

Some people say they should encompass a ‘bounded context’. 

Some people say you should be able to rewrite a microservice as quickly as you could find and fix a bug in it.

They’re all right, and they’re all wrong.

How big or how small ​a service ​should be​ is relative to your comfort level.

If your monolith is 1MM lines of code, anything 10,000 lines or less is going to be small.

If your monolith is small (50,00 lines of code), then 10,000 lines of code isn’t very ‘micro’.

If you have five people on your team, having 10,000 lines of code per service (with 5 services) seems reasonable.

If you have fifty-five people on your team, then 10,000 lines of code services (5 services) gives you a lot of collaboration points and a higher potential for merge conflicts.

Micro is relative.  How you size your services, depends on a lot of context that ‘some people’ don’t have.  Don’t worry about how others size their services, do what makes sense for your context, your business, and your team.

And because I can’t resist, here’s an image of all the sci-fi ships sized, relative to one another.