Avoid the Term: Microservice
“Microservice” started as a noble trend of breaking apart monolithic applications. A few years in, the term has become another engineering buzzword that leads to confusion. Two individuals discussing microservices may have vastly different interpretations of the term.
Dangerous Overemphasis on “Micro“
You may have seen examples of overly-micro services in an organization near you. Another engineer may blindly implement the concept of "microservices" without fully understanding the implications. This could lead to unforeseen issues.
Sideeffects caused by extremely micro services include:
System load overhead. More services mean more connections between services, fewer resources being shared.
Management overhead. Unifying system configurations for huge amount of services is a daunting task, especially for those organizations that don’t have a thousand-people infra team like Google.
Increased cognitive load. Workload for documentation and onboarding is increased.
Increased complexity leading to outages. Complex systems pose greater challenges for troubleshooting and increase the likelihood of cascading failures.
Weird career incentives. Some engineers see creating a new service as a way to get a better performance rated or promoted.
When it’s OK to be Slightly More “Micro”
My advice for startups is always: start with monolith, break apart when necessary. Valid reasons to break apart monolithic include but not limited to:
The components are owned by functionally separate teams. Break apart application to increase development velocity.
The components have different performance profiles. Some components autoscales more rapidly than some other components. They may need to be written in different programming languages to improve performance.
The components should be located in separate locations. For example, public facing vs in a private subnet.
The components have different deployment schedules or risk profiles.
What to Replace the Term with
“Service-Oriented Architecture (SOA)”
When referring to a system architecture style that’s loosely coupled, SOA is much more specific and delivers clearer meaning.
“Service”
When referring to the individual application itself, “service” is usually sufficient to convey the message. You can break apart a monolithic application into two services, which are not necessarily “microservice”.
Conclusion
Decomposing a monolithic application isn’t always right or wrong, it’s dependent on the situation. The term "microservice" has become a vague buzzword that can lead to hasty implementation with unintended consequences. You have the choice of using terms with clearer definitions.