Mircroservices — it's not about size!
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:
Productivity — of each team
Agility — of each service
Evolvability — of the system
Scalability — of the system, or parts of it
Fault isolation
These improvements make the system as a whole more complex, especially concerning:
End-to-end testing
Troubleshooting
Communications and networking
Deployment
Operations
Data consistency and management
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:
Authentication
Product catalogue
Customer lifecycle management
Order processing
Payment processing (integrates with credit card processors etc.)
Messaging (sends emails & SMS, and tracks delivery)
These could just as easily be modules in a monolith, too. Using a modular approach, and with awareness of distributed computing concepts, a monolith can achieve all of the above benefits.
👉 Your architectural design should be informed by business realities. Solid technological decisions are not made in a vacuum — they are business-driven.