The "micro-" prefix ruins everything. It's not about size.
 
Microservices are widely misunderstood, misused, and lately, maligned.

💡 Microservices are more a management solution, than a technological one.
💡 Correctly done, each service represents a complete business domain or functional area. 

"Macro" fits better than "micro," though something with the word "domain" in it would do a lot more justice. 

Using the microservices approach, dependencies between teams are reduced, and services are more loosely coupled (i.e. fewer interdependencies). This promises to improve the following:

These improvements make the system as a whole more complex, especially concerning:

Like most decisions in engineering, it's a trade-off. It's a sliding scale, between the complexities of managing  people and processes at one end, and more complex technology operations at the other.

The larger the scope of the product (in terms of business domains), the more engineers you need, and the more appealing it becomes to split your platform into distinct services. This typically happens once your engineering department grows past twenty people, and has teams specialising in well demarcated and divergent domains.

The best way to split is usually by business domain and functional area. These services end up being quite chunky, and I wouldn't call them microservices. By the way, if anyone can decide on a whim to create a new service, you’re doing it wrong. Creating a new service must be a carefully considered decision. The more trivial the functionality, the more it should be combined into a related, pre-existing service.

Examples of functionally- and business domain-oriented services:

👉 Your architectural design should be informed by business realities. Solid technological decisions are not made in a vacuum — they are business-driven.

Thanks for reading this far! I will appreciate your comments, questions, suggestions, clarifications and especially corrections via this LinkedIn post.