Why microservices are better than components or how ideas in IT degrade
Let's try to start with a quote:
At the current rate of development of the programming industry, applications cannot remain stagnant. Developers must find a way to breathe new life into programs that are already shipped to users. The solution is to break the monolithic application into individual parts, or microservices (Figure 1).
…
Traditionally, an application consisted of individual files, modules, or classes that were compiled and linked into a cohesive whole. Developing applications from microservices—called microservice architecture applications—is a completely different process. A microservice is like a mini-application; it is delivered to the user as binary code, compiled and ready to use. There is no longer a single whole. In its place are specialized microservices that connect at runtime to other microservices to form the application. Modifying or extending an application simply means replacing one of its constituent microservices with a new version.
If you are interested in where this quote comes from and what is wrong with it, please see the cat.
This is a quote from a book that was written more than 25 (this is not a mistake!) years ago. The quote is just not entirely correct. Here's a more complete version:
At the current rate of development of the programming industry, applications cannot remain stagnant. Developers must find a way to breathe new life into programs that are already shipped to users. The solution is to break the monolithic application into individual parts, or microservices (Figure 1).
As technology evolves, the microservices that make up an application can be replaced by new ones (Figure 2). The application is no longer static, doomed to become outdated before it goes live. Instead, it gradually evolves with old microservices being replaced by new ones. It’s easy to create completely new applications from existing microservices
Traditionally, an application consisted of individual files, modules, or classes that were compiled and linked into a cohesive whole. Developing applications from microservices—called microservice architecture applications—is a completely different process. A microservice is like a mini-application; it is delivered to the user as binary code, compiled and ready to use. There is no longer a single whole. In its place are specialized microservices that connect at runtime to other microservices to form the application. Modifying or extending an application simply means replacing one of its constituent microservices with a new version.
What is the modern idea of microservices? It may be that complex applications should be divided into simple ones and, if possible, these simple applications should be distributed on different computers (even on different servers). It would seem that the following question should immediately arise: “Why do it this way, because the operation of a distributed system is associated with additional overhead and additional delays associated with interaction over the network or even with interaction between conditional services in different processes on the same machine?” But such a question is simply not customary to ask in a decent nano-technological society, in which all costs are presented as nano-costs, and microservices are the word of progress and simply the path to a better future. You know, the latest fashion is the interaction between microservices through a text interface based on ancient HTTP, the so-called Rest API, and not some kind of SOAP, for example, or God forbid CORBA. Actually, initially there was no Rest API, there was simply an HTTP protocol designed for communication between the browser and the server for navigation and management of content stored on the server, but progressive thought does not stand still and advanced developers quickly realized that it is possible to write entire pieces of a distributed program, which will communicate with other pieces of this distributed program via the same HTTP protocol. And this is cool! With such experience, any effective managers with money will tear you away. Of course, this method of interaction within one program (system) carries quite a lot of redundancy and creates additional delays, but who cares when such a fashionable name for this performance as RESTful web services has been invented, when any programmer can do it with pride and even with some arrogance to say: “I work through RESTful interfaces, develop microservices”, try to argue something against this method of work.
If you haven’t yet guessed where I got this quote from, I’ll tell you a secret, I hope it won’t shock you too much, although they usually sit at the computer, so it’s okay.
Source of quotes
This is a quote from the translation of the book “Inside COM”. by: Rogerson, Dale, 1966-. Publication date: 1997. Of course, the book was dedicated to Component architecture, and not Microservice architecture, I simply replaced in the quotes all the words with the same root as the word “component” with words derived from the word “microservice”. But you may notice that if we consider the word “component” as the opposite of the word “monolith”, then the replacement is completely correct, since in our modern times “microservice” still acts as the opposite of “monolith”, nothing changes in this regard. The task of resisting the Monolith is apparently not very simple, so the developers use the tactic of replacing the candidate for opposition.
But what was proposed by the authors of the concept of dividing applications into components:
the ability to replace components on the fly in a running application (for example, while the function for which the component is responsible is disabled),
reusing components in another application – in an application with a different set of functions,
but the most important thing is the independent development and reworking of the code of this individual component, based on the simple fact that this component is designed and included in the application as an external component,
but ancient programmers then considered the ability to distribute and transmit parts of programs to users in the form of binaries to be the height of perfection!
But now everyone understands that this kind of sucks, which is much better when the user of the program downloads the sources of this program from the repository, pulls up all the dependencies necessary to compile this program, compiles this program and the libraries missing for its compilation and starts using this program as an advanced and respected representative of the IT community, having performed some special deployment-configuration procedure for this successfully compiled program! The ability to distribute programs and their parts in the form of binaries is simply not respect for the end user of any program, you don’t trust him to even touch the source code of this program!
But seriously, what is the difference between a component application architecture, let us call it microservice architecture, and a monolithic one? In fact, the word in the title is not so important if we correctly understand the meaning and the goals arising from this meaning.
So the main meaning of any service architecture (not monolithic) is to build the architecture in such a way as to be able to transfer improved or corrected parts (let’s call them services then) of this system to the user of a working system in some way form (not even necessarily binaries, but as the code of some class in an interpreted language, for example) so that the user can painlessly replace such a part of the program in his working system, following some simple procedure that is absolutely understandable from the point of view of this user (for example, primitive copying files), rather than re-deploying the entire system for any change. If in your application or in a distributed system there are such parts that are available for such processing and substitution, or if you can add such parts to your application-system. which are picked up by the system on the fly and somehow expand the functionality of your system application, only in this case can you say that you have a microservice architecture, in my old-fashioned opinion. And if not, then perhaps you are still only on the path to a microservice architecture. By the way, at one time, the same fashionable word as microservices was the word Plugins, which the IT community really liked, unlike the word component, which involuntarily evokes associations with an organization that not only promoted the component approach, but also successfully implemented it and is still successful uses.
Unfortunately, the progressive IT community, in its attempt to distance itself from the term component, is also moving away from the goals of building an effectively managed system architecture, in which changes in one part of the system do not lead to reconfiguration and reassembly of the entire system. In that ancient book you can read not only what encapsulation and polymorphism are, but also why they are needed and how they are implemented and how they work in practice and with code examples. There is one big problem with this book – it must be read very carefully and at first, although not necessarily until the end, towards the end very special applications begin that will not be useful to everyone in practice. Unfortunately, in our time, in the times of clip consciousness, this is a practically impossible wish.
I found the following analogy from this book very interesting and instructive:
Did you study physics at school? If you were taught physics using elements of higher mathematics, then knowledge of the latter was a necessary preliminary requirement. By studying mathematical analysis, you learned to apply it in different areas. Only by studying and understanding differential calculus as such were you able to use it to solve physics problems. This sequence of learning did not always exist. Isaac Newton first invented differential calculus as a tool of classical mechanics and dynamics. Only later did it become clear that this powerful tool had applications beyond the boundaries of physics.
In my opinion, attempts to come up with an alternative to component architecture are similar to attempts to invent another differential calculus, or at least similar to attempts to retell the theory of differential calculus in other terms, simply because the community is somehow very biased towards the author of this original theory, or even not to the author, but to the organization for which this author worked (actually a group of authors). Therefore, I want to end with one more quote from this book:
If you write programs for UNIX, Macintosh, Linux, VMS, or any other operating system, this book will also be useful to you. The concepts contained in COM do not only work on the Windows operating system; COM is not a big API. COM is a programming method that is on par with methods such as structured or object-oriented programming. You can use the COM approach on any operating system. Of course, Windows provides code that makes COM-style programming easier, but most of this code is easy to implement on your favorite platform.
The moral of this story is very simple. Feel free to read the fundamental works of ancient programmers! Only having a serious base of fundamental, time-tested knowledge can you count on a positive result in the present, otherwise it’s just a lottery with scanty chances of getting the desired result.
