I wanted to write an article on the topic of microservice architecture for a long time, but two points stopped me all the time - the further I plunged into the topic, the more it seemed to me that what I know is obvious, and what I donβt know is still to be studied and studied. On the other hand, I think that there is already something to discuss in a wide audience. So alternative opinions are welcome.
Conway's law and the relationship between business, organization and information system
Let me quote again:
βAny organization that designs a system (in the broadest sense) will receive a design whose structure replicates that of the teams in that organization.β
β Melvyn Conway, 1967
In my opinion, this law is more related to the expediency of organizing a business, rather than directly to the information system. Let me explain with an example. Let's say we have a fairly stable business opportunity with a life cycle of such a duration that it makes sense to organize an enterprise (this is not a typo, but I really like this term, which I stole) Naturally, the enabling system of this business will be organizationally and process appropriate for this business .
Business orientation of information systems
Let me explain with an example. Let's say there is a business opportunity to start a pizza business. In the V1 version (let's call it the pre-information version), the company was a pizzeria, a cash register, and a delivery service. This version was long-lived in conditions of low variability of the surrounding world. Then version 2 came to replace it - more advanced and able to use the information system at its core for a business with a monolithic architecture. And here, in my opinion, there is just a terrible injustice towards monoliths - supposedly monolithic architecture does not match the domain business model. Yes, if it were so, the system would not be able to work at all - in contradiction with the same Conway law and common sense. No, the monolithic architecture is fully consistent with the business model at this stage of business development - of course, I mean the stage when the system has already been created and put into operation. It is an absolutely remarkable fact that regardless of the architectural approach, both the service-oriented architecture of version 3 and the microservice architecture of version N will work equally well. What's the catch?
Everything flows, everything changes, or are microservices a means of dealing with complexity?
Before continuing, let's look at some misconceptions about microservice architecture.
Supporters of using the microservice approach often say that splitting a monolith into microservices simplifies the development approach by reducing the code base of individual services. In my opinion, this statement is complete nonsense. Seriously, the obvious interaction within a monolith and a homogeneous code seems complicated? If this were indeed the case, all projects would initially be built as microservices, while practice shows that migration from a monolith to microservices is much more common. Complexity does not disappear anywhere, it just moves from individual modules to interfaces (be it data buses, RPC, APIs and other protocols) and orchestrating systems. And this is difficult!
The advantage of using a heterogeneous stack is also questionable. I will not argue that this is also possible, but in reality it rarely occurs (Looking ahead - this should be the case - but rather as a consequence than an advantage).
Product life cycle and service life cycle
Take another look at the diagram above. It was not by chance that I noted the decreasing life cycle of a separate version of a business - in modern conditions, it is the acceleration of the transition of a business between versions that is decisive for its success. The success of a product is determined by the speed of testing business hypotheses in it. And here, in my opinion, the key advantage of the microservice architecture is buried. But let's go in order.
Let's move on to the next step in the evolution of information systems - to a service-oriented architecture SOA. So, at some specific moment, we highlighted in our product long-lived services - long-lived in the sense that when switching between product versions, there is a chance that the life cycle of the service will be longer than the life cycle of the next version of the product. It would be logical not to change them at all - we the speed of transition to the next version is important. But alas, we are forced to make constant changes to services - and here everything is fine with us, and DevOps practices, and containerization, and so on - everything that comes to mind. But it's still not microservices!
Microservices as a means of combating complexity ... configuration management
And here we can finally move on to the defining role of microservices - this is an approach that simplifies product configuration management. In more detail, the function of each microservice describes exactly the business function within the product according to the domain model - and these are already things that do not live in a short-lived version, but in a long-lived business opportunity. And the transition to the next version of the product takes place literally imperceptibly - you change / add one microservice, and possibly just the scheme of their interaction, and suddenly find yourself already in the future, leaving behind crying competitors who continue to jump between versions of their monoliths. Now imagine that you have a fairly large volume of microservices with predefined interfaces and business capabilities. And you come and build the structure of your product from ready-made microservices - just by drawing a diagram for example. Congratulations - you have a platform - and now you can call your own business. Dreams Dreams.
Conclusions
- The system architecture should be determined by the life cycle of its components. If the component lives within the product version, it makes no sense to increase the complexity of the system using a microservice approach.
- Microservice architecture should be based on a domain model - for the reason that a business opportunity is the most long-lived area
- Delivery practices (DevOps practices) and orchestration are one of the most important for microservice architecture - for the reason that an increase in the rate of component change places increased demands on the speed and quality of delivery
Source: habr.com