I have wanted to write an article on microservices architecture for a long time, but two things continually held me back — the more I delved into the topic, the more it seemed to me that what I know is obvious, and what I don't know still needs to be studied extensively. On the other hand, I believe there is already enough to discuss with a broader audience. So alternative opinions are welcome.
Conway's Law and the connection between business, organization, and information system
Once again, I will allow myself to quote:
“Any organization that designs a system (in the broad sense) will produce a design whose structure is a copy of the organization's communication structure.”
— Melvyn Conway, 1967
In my opinion, this law relates more to the practicality of organizing a business than directly to the information system. Let me explain with an example. Suppose we have a fairly stable business opportunity with a lifecycle long enough to justify organizing an enterprise (this is not a typo; I really like this term I borrowed). Naturally, the supporting system of this business will organizationally and process-wise match this business.
Business-oriented information systems
Let me illustrate with an example. Suppose there is a business opportunity to establish a pizza selling business. In version 1 (let's call it pre-information), the company was a pizzeria, cash register, and delivery service. This version lasted long in conditions of low variability in the external world. Then came version 2 — a more advanced one that could leverage an information system at its core for a business with a monolithic architecture. And here, in my opinion, a truly terrible injustice arises regarding monoliths — the so-called monolithic architecture does not correspond to the domain model of the business.If it were like that, the system wouldn't be able to function at all - which contradicts Conway's Law and common sense. No, a monolithic architecture perfectly aligns with the business model at this stage of development — I mean the stage when the system is already built and operational. It's a truly remarkable fact that regardless of the architectural approach, both the service-oriented architecture version 3 and the microservices architecture version N will work equally well. So what's the catch?
Everything flows, everything changes, or are microservices a means to combat complexity?
Before continuing, let's address some misconceptions regarding microservices architecture.
Proponents of the microservices approach often claim that breaking a monolith into microservices simplifies development by reducing the codebase of individual services. In my view, this statement is utterly ridiculous. Seriously, does the apparent interaction within a monolith and homogeneous code seem complex? If that were truly the case, all projects would initially be built as microservices, while practice shows that migrating from a monolith to microservices is much more common. Complexity doesn't just disappear; it merely shifts from individual modules to interfaces (such as data buses, RPC, APIs, and other protocols) and orchestrating systems. And that is complex!
The advantage of using a heterogeneous stack is also questionable. I won't argue that it's possible, but in reality, it's rarely encountered (To anticipate, it should indeed 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. I didn't mark the decreasing life cycle of a particular business version by accident — under modern conditions, accelerating the transition between versions is crucial for its success. The success of a product is determined by the speed of testing business hypotheses within it.And this is where, in my opinion, the key advantage of microservices architecture lies. But let's go step by step.
Let's move to the next stage in the evolution of information systems — service-oriented architecture (SOA). So, at some point, we identified in our product long-lived services — long-lived in the sense that when transitioning between product versions, there is a chance that the lifecycle of the service will outlast the lifecycle of the next product version. It would be logical not to change them at all — what we care about is the speed of transitioning to the next version. Unfortunately, we are forced to make constant changes to services — and here we can use everything, from DevOps practices to containerization, and anything else that comes to mind. But this is still not microservices!
Microservices as a means to combat complexity… configuration management
And now we can finally move to the defining role of microservices — it is an approach that simplifies configuration management of the product. More specifically, the function of each microservice describes a business function within the product according to the domain model — and these are things that live not in a short-lived version, but in long-lived business opportunities. The transition to the next version of the product happens literally unnoticed — you change/add one microservice, or perhaps just the scheme of their interaction, and suddenly find yourself in the future, leaving behind the sobbing competitors who continue to jump between their monolith versions. Now imagine that there is a sufficiently large number of microservices with predefined interfaces and business opportunities. You come in and build the structure of your product from ready-made microservices — simply by drawing a diagram, for example. Congratulations — you now have a platform — and you can click together your business. Dreams, dreams.
Conclusions
- The architecture of the system should be determined by the lifecycle of the components it consists of. If a component lives within the version of the product, there is no point in increasing the complexity of the system by applying a microservices approach.
- Microservice architecture should be based on the domain model — because the business opportunity is the most long-lived area.
- Delivery practices (DevOps practices) and orchestration are crucial for microservices architecture because the increasing speed of component changes demands higher quality and speed of delivery.
Source: habr.com
