Get best of the week

Microservices: what is it, why is it and when do you need to implement them

I wanted to write an article on the topic of microservice architecture for a long time, but two points stopped all the time - the further I got into the topic, the more it seemed to me that what I know was obvious, and that I didn't know, I still had to study and study. On the other hand, I believe that there is already something to speculate about in a wide audience. So alternative opinions are welcome.

Conway Law and the relationship between business, organization and the information system


Once again, I allow myself to quote:
“Any organization that designs a system (in the broad sense) will receive a design whose structure copies the structure of teams in this organization”
- Melvyn Conway, 1967
In my opinion, this law is more likely related to the expediency of organizing a business, rather than directly to the information system. I will explain with an example. Suppose we have a sufficiently 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 the term that I took away) Naturally, the supporting system of this business will be organizational and process consistent with this business .

Business Orientation Information Systems




I will explain with an example. Suppose there is a business opportunity to organize a pizza business. In the V1 version (let's call it pre-informational), the company was a pizzeria, cash desk, delivery service. This version was long-lived in conditions of low variability of the surrounding world. Then came version 2, which was more advanced and able to use the information system as its basis for a business with a monolithic architecture. And here, in my opinion, there is simply terrible injustice with respect to monoliths - supposedly monolithic architecture does not correspond to the domain business model. Yes, if that were so, the system would not have been able to work at all, contrary to the same Conway law and common sense. No, monolithic architecture is fully consistent with the business model at this stage of business development - of course I mean the stage when the system is already 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?

Does everything flow, does everything change, or are microservices a way to deal with complexity?


Before continuing, we will consider some misconceptions regarding the microservice architecture.

Proponents of 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 utter nonsense. Seriously, does the obvious interaction within a monolith and a homogeneous code seem complicated? If this were true, all projects would initially be built as microservices, while practice shows that migration from a monolith to microservices is much more common. The complexity does not disappear anywhere, it simply moves from individual modules to interfaces (whether it be data buses, RPC, APIs and other protocols) and orchestration systems. And it's hard!

The advantage of using a heterogeneous stack is also dubious. I will not argue that this is also possible, but rarely occurs in reality (Looking ahead - this should be the place to be - but rather as a consequence rather than an advantage).

Product Life Cycle and Service Life Cycle


Take another look at the chart 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 acceleration of the transition of a business between versions that is crucial for its success. Product success is determined by the speed of testing business hypotheses in it . And here, in my opinion, the key advantage of 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 SOA architecture. So, at some specific moment, we highlighted long-lived services in our product- long-living 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 - the speed of transition to the next version is important to us . But alas, we are forced to make constant changes to services - and here everything suits us, and DevOps practices, and containerization, and so on - everything that comes to mind. But these are still not microservices!

Microservices as a tool to combat 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. More specifically, the function of each microservice describes exactly the business function inside the product according to the domain model - and these are things that live not in a short-lived version, but in a long-lived business opportunity. And the transition to the next version of the product is literally imperceptible - you change / add one microservice, and maybe just the scheme of their interaction and suddenly find yourself in the future, leaving crying competitors who continue to jump between versions of their monoliths. Now imagine that there is a fairly large volume of microservices with predefined interfaces and business opportunities.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 get your own business. Dreams Dreams.

findings


  • The architecture of the system should be determined by the life cycle of its constituent components. If a component lives within the product version, there is no point in increasing the complexity of the system using a microservice approach.
  • Microservice architecture should be based on a domain model - for the reason that business opportunity is the most long-lived area
  • Delivery practices (DevOps practices) and orchestration have one of the most important values ​​for microservice architecture - for the reason that increasing the rate of change of components places increased demands on the speed and quality of delivery

More articles:


All Articles