Itzy Sabo

May 8, 2023

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:
  1. Productivity — of each team 
  2. Agility — of each service
  3. Evolvability — of the system 
  4. Scalability — of the system, or parts of it
  5. Fault isolation

These improvements make the system as a whole more complex, especially concerning:
  1. End-to-end testing
  2. Troubleshooting
  3. Communications and networking
  4. Deployment
  5. Operations
  6. 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.

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

About Itzy Sabo

👋 I'm Itzy Sabo, an Engineering Management Expert & Fractional CTO.

What if your engineers could deliver more business value, faster?