{"id":79498,"date":"2020-04-27T19:42:07","date_gmt":"2020-04-27T17:42:07","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat"},"modified":"2020-04-27T19:42:07","modified_gmt":"2020-04-27T17:42:07","slug":"mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat","title":{"rendered":"Microservices: What They Are, Why You Need Them, and When to Implement Them","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

I have wanted to write an article on microservices architecture for a long time, but two things continually held me back \u2014 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.
\n<\/a><\/noindex><\/p>\n

Conway's Law and the connection between business, organization, and information system<\/h2>\n

\nOnce again, I will allow myself to quote:<\/p>\n

\u201cAny organization that designs a system (in the broad sense) will produce a design whose structure is a copy of the organization's communication structure.\u201d
\n\u2014 Melvyn Conway, 1967\n<\/p><\/blockquote>\n

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.<\/p>\n

Business-oriented information systems<\/h2>\n

\n\"Microservices:
\n
\nLet 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 \u2014 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 \u2014 the so-called monolithic architecture does not correspond to the domain model of the business.<\/b>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 \u2014 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?<\/p>\n

Everything flows, everything changes, or are microservices a means to combat complexity?<\/h2>\n

\n Before continuing, let's address some misconceptions regarding microservices architecture.<\/p>\n

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! <\/p>\n

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 \u2014 but rather as a consequence than an advantage).<\/p>\n

Product life cycle and service life cycle<\/h2>\n

\nTake another look at the diagram above. I didn't mark the decreasing life cycle of a particular business version by accident \u2014 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.<\/b>And this is where, in my opinion, the key advantage of microservices architecture lies. But let's go step by step. <\/p>\n

Let's move to the next stage in the evolution of information systems \u2014 service-oriented architecture (SOA). So, at some point, we identified in our product long-lived services<\/b> \u2014 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 \u2014 what we care about is the speed of transitioning to the next version<\/b>. Unfortunately, we are forced to make constant changes to services \u2014 and here we can use everything, from DevOps practices to containerization, and anything else that comes to mind. But this is still not microservices! <\/p>\n

Microservices as a means to combat complexity\u2026 configuration management<\/h2>\n

\n And now we can finally move to the defining role of microservices \u2014 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 \u2014 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 \u2014 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 \u2014 simply by drawing a diagram, for example. Congratulations \u2014 you now have a platform \u2014 and you can click together your business. Dreams, dreams. <\/p>\n

Conclusions<\/h2>\n

<\/p>\n