Why microservices? Because evolution [tech]
It’s 2022, and the microservices vs monolith arguments are still popular. I’ve also had recent conversations with friends on this topic. So it’s about time for me to add my 2 cents.
Firstly let’s acknowledge that microservices is a bad name. Is micro supposed to be a certain size? At the peak of microservices hype, many were already trying to get started with nanoservices. Some of that exuberance has subsided to rational levels now, but confusion still exists.
Instead of using monoliths and microservices, let’s stick to teams building systems. At a small scale of either teams or systems I’d always recommend the simplest approach that works for the problem to be solved. At a larger scale things get interesting. For an approach to solve this we should look at nature.
At some point in the past (estimated 1.5 billion years ago) life evolved from unicellular to multicellular organisms. According to the article, initially cells grouped together for better defenses against predators. Later cells start performing specialized functions and evolve separately. Watch the video below showing even more complex evolutionary transitions.
Building software has constraints very similar to organisms. As required features increase, complexity of the system increases making change difficult. At some point the number of individuals or teams working on the system also increases beyond a threshold causing conflicts in change, deployment issues. Hence the single celled organism needs to divide and specialize into sub parts. Since the sub-parts are still part of a whole, appropriate communication mechanisms and functioning protocols need to be established.
As complexity grows it is inevitable that eventually a system needs to be broken up into smaller cooperating sub-systems. Because evolution. Each sub-system can also independently specialize and break up even further in the future.
Decomposing systems is not a guarantee to success. Complexity does not disappear, but should become manageable. Hence setting correct expectations with all stakeholders is essential. What and how to decompose and specialize is what architecture is all about.
PS Another one of my favorite responses about latency or availability is .. because physics.