I have read several sources and tried to find out a simple explanation, but unfortunately everywhere there are a lot of words with extensive explanations, but nowhere there is a simple picture, literally a few sentences that would explain the main idea. I wanted to find something that would be easy to understand, a short explanation, but at the same time where the main idea was explained, so that the rest of the words would be secondary. And here, in my opinion, everything is bad, because I have not found such a concise presentation. Is this a sign that the concept of microservices is rather vague and misleading? This worries me. There are also quite a few articles that have caveats against using microservices, and in which there are thoughts that in most cases microservices are not required, your tasks are not so complex, and yout team is not so numerous to use microservices. As a result, I developed a somewhat dismissive attitude towards the idea of microservices. Is it true that microservices is a buzzword that repeats a few old ideas and collects them together?
First, I list the ideas (as I understand it) that are used to explain microservices:
Microservices are usually explained as the opposite of a monolith. For example, there is a monolithic application that implements several functions. A microservice is an opposite of a monolith, in which individual functions are designed as separate applications interacting with each other using some kind of protocol. Here, the term "microservices" literally stands for "small services". If we consider this explanation from the point of view of working instances, then although a monolith can have several simultaneously working instances, in this explanation this is not the main idea. In this explanation, the main thing is to separate the work to be done and the program code into separate parts.
Another idea in explaining microservices is asynchronous processing of requests and interaction of individual instances with each other. This is a rather old idea, it is not clear why this is considered as some kind of mandatory part in microservices. Well, let's say we don't have asynchronous processing and what we cannot say that we have microservices? In my opinion, this is clearly a secondary feature that I would like to have, but which is not mandatory.
Separate your team on small teams working on separate services with separate codebases, with different programming languages and separate databases. Here, the main idea is to reduce the number of connections between teams. The connectivity between services will be minimal if the only linkage is an interaction protocol. This should speed up development and be easier to make changes in code, as the different teams can work independently. If the changes don't change the protocol, then the other parts of the system do not notice it.
Using virtualization and containerization. Here, the main problem that is being solved is the ease of deployment and scalability of the application. It looks like everyone uses virtualization, any fashionable thing should have virtualization, let's use it too.
Service auto-discovery ability. Services find each other automatically, it is easy to add new instances and move them. There is no need to reconfigure the system when the instance topology changes.
I was looking for something in common in all these ideas and I think I found it. So, here is my definition: microservices are a system built from several instances, such that it is easy to add, remove running instances and scale the entire system, so that even in the case of instance crush, the system continues to perform. Thus, none of the above ideas is mandatory, but only an optional extension. We have to start from what problem we have and take an idea that helps to solve this problem. From this point of view, the main thing is the ability of the system to have several running instances, so if some of them stop working, then this does not affect the functioning of the system. We even may have a monolith, the main thing is the ability to run several instances of the monolith and the ability to work in parallel. That is, the idea of dividing the system into separate functions (into small services) becomes secondary and optional. Actually my question is how true is my understanding of the main idea of microservices?
