In the last ten years, the adoption of the microservices architecture has risen significantly as a methodology for designing and managing distributed applications. Microservices represent an architectural paradigm centered on creating autonomous, self-contained services, known as microservices, with each one dedicated to executing a specific task.
Stated in this manner, it may only seem like a brilliant concept, a significant technological idea heralding profound shifts in our approach to application development. Anything like the invention of the wheel? Let’s draw a parallel.
At first, both represent revolutionary innovations promising enhanced efficiency and the attainment of more better results. Nevertheless, throughout human history, it quickly became evident that the wheel, on its own, couldn’t sustain the same progress it facilitated. The availability of the wheel made the transport of heavier loads possible but not on unpaved surfaces. So it eventually gave rise to the development of roads.
The microservices paradigm presents a similar situation.
Shifting to a microservices architecture, raises the challenge of reconfiguring how different parts of the application communicate. Mere transformation of in-memory method calls into remote procedure calls (RPC) over a protocol tends to lead to excessive communication, resulting in a relevant performance impact. Consequently, it becomes crucial to shift from a conversational communication model to a more substantial one that, instead of numerous small messages, facilitates the exchange of fewer but more comprehensive messages.
In reality, although the microservices architecture is often seen (mostly by top-level management biased by follower’s of other people’s success stories and best pratices) as a straightforward replacement for rewriting monolithic applications, its full implementation profoundly alters both the nature of the resulting application and its underlying network infrastructure. It’s akin to having the wheel without constructing flat roads, which could potentially worsen the situation.
As a result, the microservices architecture cannot be universally applied.
To grasp the essence of the microservices architecture, it’s instructive to begin by contrasting it with its architectural counterpart: the traditional monolithic style. Monoliths are software applications built as single, self-contained units.
The idea of monolithic software architecture has been a part of computer programming since the early days. During the initial phases of software development, programs were often crafted as single, large, self-contained pieces of code due to the limitations posed by the hardware and software systems of that era. This practice persisted until about a decade ago when concepts like modularization, object-orientation, and domain-driven design emerged, although they weren’t yet widely embraced. It’s also worth noting that monolithic software development doesn’t owe its existence to any specific individual or company. Instead, legacy applications are a natural result of cumulative programming efforts spanning at least two decades. Their monolithic structure simply reflects the technological constraints of the times they were built.
In software, not all monoliths are the same.
The frequently echoed slogan of microservices advocates, “Multiple Units Good, One Unit Bad,” often takes on the characteristics of technical propaganda. Much like the birds in George Orwell’s “Animal Farm” masterpiece, executives (and developers) too often endeavor to enthusiastically understand the principle and engage in a noble battle against a common adversary: outdated applications. They may miss all implications, though and found their expectations on other people’s success stories.
Microservices as an architectural style and software development approach cannot be pinpointed to a specific moment in time. Therefore, it’s fair to assert that the microservices style naturally evolved in response to the changing demands of the software industry. Companies such as Amazon and Netflix are frequently mentioned as pioneers of microservices, but in truth, no one embarks on a project with the primary goal of creating a new architectural style. Amazon, Netflix, and numerous other companies simply embarked on a journey to create their own approach for constructing highly scalable and distributed systems that could best meet their specific business requirements.
It was their success story, though, based on their fairly unique scenario and needs.
The bottom line is that microservices do not offer a one-size-fits-all solution, and it’s essential to recognize the value of a thoughtfully designed, modular monolith, along with the advantages of simplicity.
Pragmatic Opinions 