Microservices - It's Not The Size That Matters!

The diagram above is NOT something you want! That is how to do microservices the wrong way.

In many ways "micro" is not the best name for what a "microservice" is or should be. A lot of time is wasted trying to understand or explain what "micro" means. Ok, it means "small". So? How does smallness help us partition a large application? And when does micro become nano and when does it become monolith? I can see hundreds of meeting hours spent in semantic debates about what "small" means in our environment or our application. How many lines of code? Some say 100 is the magic number. How many logical operations? You can see where that may make us review philosophy books!

I prefer an alternate term, probably a synonym at this stage, as the "micro" term has stuck. I think a better name reflecting a better concept is Independent Service, or iService. How do we partition an app into a set of independent services (not necessarily micro or nano or any particular size) ? Size is actually irrelevant, as many writers have suggested. It can become relevant after the independence characteristic has been satisfied.

Now the debate inside companies considering adoption would be focused on dependencies and isolation of services, not size. 

Oh, by the way, as a side  note before you leave: after you achieve independence, make the service as small as you can!