Lecture
For a while, everyone went crazy over microservices. It was impossible to open your favorite news aggregator and not see that some unknown company until now tells about the salvation of its engineering department with the help of microservices. Perhaps you yourself even worked in a company that was caught up in the excitement of tiny, magical small services that would solve all the problems of a large, neglected, full legacy code base.
Naturally, in reality everything turned out quite the opposite. When you look back at what happened, the vision is closer to 100% than when you look with hope into the future.
Let us consider what is embedded in the concept of “microservice”, what are the advantages of microservices in different areas of activity.
Creating a microservice that meets the requirements in the context of business and project management is of great importance for most developers and IT professionals - this is exactly what brings the gain.
Microservice is a piece of code aimed at solving one task that continues to function and work correctly, even if “the whole world has stopped”.
From the point of view of project management, the value of microservice is that it passes and continues to work without direct dependencies on other systems. For example, since it has its own data store, and it does not make any external API calls to obtain the necessary information for the work, it does not matter for microservice whether the shared database is working / whether it has access to the API. This greatly reduces the overhead of coordination with other teams, because the team that owns the service can accomplish their tasks much easier without being blocked by other dependencies. Quality assurance efforts are also significantly reduced, since a fully autonomous service cannot be compromised by side effects from other code, which, for example, updates the same common database. If we draw an analogy with food and drinks, then the reason for creating a microservice can be described as follows: your coffee maker will work regardless of whether a toaster is connected or not.
For a business, a properly implemented microservice architecture implies the best options for the product:
Microservice is a state machine. His condition is a transactional boundary.
Imagine a traffic light:
The color that should appear depends on the color that the traffic light shows at the moment. If “currentColor = green”, then the “Switch to next color” command can only work correctly if no one else switches the light to the next color while your “Switch to next color” command is being processed.
So any “microservice” that does not represent a transactional border will be subject to side effects from other components of the system (as in the example of a traffic light). And it will no longer match the business and management understanding of microservices.
Any single piece of code that can be viewed as a black box, where the only way to communicate with it through its API, can be viewed as a “microservice”. When microservice evaluates business rules, it uses the sources of information that were passed in previous API calls, as well as the parameters of the current API call, to make decisions.
An example of microservice work in the search for events or event collaboration based on architecture. Publish-subscribe is a good solution for coordinating the flow of information between services, because it leads to a weaker link than in alternatives.
The well-known Bezos memo decrypts this both for entire commands and for “microservices” of any size. For what reasons - see above in “Business and Project Management”.
No need to read about installing a central heating thermostat to simply adjust the temperature of the freezer.
Microservice is a set of components (for example, containers, logical or physical databases, etc.) that provide a certain part of business functions. They can be created, destroyed, scaled and controlled as a whole. They continue to work correctly, even if all other services do not work.
A good indicator of the quality of the implementation of microservice and the design of its infrastructure is the ability to control, alert and scale based on business needs, rather than technical criteria. For example, "Payment processing does not work (... but order execution continues to work normally)".
If payment processing does not work, how can everything “work in normal mode”?
Working in normal mode means no errors and no wrong decision due to incorrect data. This can be achieved through ultimate consistency. For example, order execution is triggered by the PaymentProcessed event. None of these can occur if the payment processing does not work, so execution will complete orders whose payment processing occurred before the shutdown, but not subsequent ones. When payment processing returns to online, the execution service will start receiving PaymentProcessed events for the missed orders and will gradually catch up. From the UX point of view, this means that the enterprise has options for developing fault-tolerant applications. That is, instead of a complete failure in work, functions that are processed by unaffected microservices may remain available to users.
There is no perfect definition, but people who are promoting this area have been able to describe a good set of requirements for the system, according to which it could be attributed to the “microservice” architecture.
You can say it is not a monolith. In practice, this means that microservice works only with a small, as limited as possible task area. It performs the minimum functions to achieve a specific goal in your stack. Here is a more specific example: let's say the bank has a “Login Service”, and you certainly don’t want this service to have access to the financial transactions of your customers. You will take this area to some “Transaction Service” (keep in mind - it’s very difficult to give names).
In addition, people often assume that microservices must communicate with other services remotely. Since they are separate processes and often run far away from others, such processes usually communicate with each other over the network using REST or some other RPC protocol.
So far everything seems simple enough - you just need to wrap small pieces of the system in some REST API, and let everyone communicate with each other over the network. In my experience, there are 5 "truths" in which people believe, and which are not always true:
“You don’t need to add a network constraint to justify writing better code.”
The truth of life is that neither microservices nor any other approach when modeling the technical stack is a requirement for writing cleaner and more supported code. Of course, once the moving parts are smaller, the ability to write lazy and ill-considered code is reduced. But it's like saying that theft can be defeated by removing goods from shop windows. You have not solved the problem, you just removed a lot of features.
A popular approach is to build architecture in such a way that logical "services" own parts of the domain. This is similar to the concept of microservices, because the dependencies that control the system will be explicit. And business logic will not fit into different angles. In addition, this approach does not entail an excessive use of the network and possible problems associated with this.
Another advantage of this approach is that it resembles Service Oriented Architecture, built on the basis of microservices: if you decide to go to microservices, then most of the work has already been done, and you probably already have a good understanding of the subject areas for proper separation of its parts. Real SOA begins with a code, and continues over time at the level of the physical topology of the stack.
"Distributed transactions are never easier."
It may seem different from the outside, but most subject areas (especially in new companies that need to create prototypes, make pivots and generally redefine the area itself many times) cannot be divided into neat, clear boxes. Often, an arbitrary part of the system is required to obtain data on another part in order to work correctly. Everything becomes even more complicated when she delegates the operation of writing data to another part, outside of her subject area. When you go beyond your influence zone, and you need to use other parts to store or change data, then you are in a country of distributed transactions .
When several remote services are involved in a single request, the complexity greatly increases. Can I refer to them in parallel or do I need to apply sequentially? Are you aware of all possible errors in advance (at the application level and at the network level) that can occur at any time, at any part of the chain, and what will these errors mean for the request itself? Often, each of the distributed transactions requires its own approach to error handling. And to understand all the mistakes and understand how to solve them is a very, very big job.
"You can greatly improve the performance of the monolith if you add a little discipline"
This misconception is difficult to refute, because in reality we can often speed up a separate system if we reduce the number of tasks or the number of dependencies that are loaded, and so on.
But overall, this is not systemic evidence. I have no doubt that if you switched to microservices, the code isolated in these services could be accelerated, but you should not forget about the delays caused by network requests. A network is never as fast as internal communication, it is sometimes “fast enough”.
In addition, many stories about increasing productivity are actually related to the advantages of a new language or a whole technological stack, and not just microservice architecture. If you rewrite the old Ruby on Rails, Django, or NodeJS application in a new language like Scala and Go (two popular choices for the microservice architecture), the performance will improve, if only because of improvements in the performance of new technologies in general. But these languages don't really matter if you call their processes "micro." They work faster because of simple factors like compilation.
Also, in most applications in startups, the net performance of the processor and memory is almost never a problem. Usually the problem is in I / O, and additional network calls only increase I / O.
When many engineers work in isolated code bases, then the syndrome "is not my problem."
It may seem that when small teams work on small pieces of the puzzle, everything will be easier. But in the end, this configuration can lead to problems.
The biggest problem is the need to run an ever-growing number of services for any, even the smallest change. That is, you need to invest time and effort to build and maintain a system where every engineer can run everything locally. Such things as Docker can simplify this moment, but someone will still have to maintain the configuration throughout the life of the project.
In addition, it complicates the writing of tests. To write a normal set of integration tests, you need to understand all the services associated with a particular operation, take into account all possible errors, and so on. It will take more time to understand the system than to develop the system. And although I will never tell an engineer that to understand a system is a waste of time, I still want to warn him against adding premature complexity.
And finally, this configuration creates social problems. Bugs can live simultaneously in several services and require changes at the level of several teams. They need to synchronize and coordinate their efforts. In addition, people can lose their sense of responsibility and try to push as many problems as possible to another team. When engineers work together on the same code base, the understanding of the system grows simultaneously with the understanding of each other. They are more likely to work on solving problems together, instead of being the kings and queens of small isolated principalities.
“Microservice can be scaled in breadth as well as a monolith”
Packing services into separate units and scaling them with, say, Docker is a good approach for horizontal scaling, without a doubt.
However, this can be done not only with microservices. The approach works in the case of monolithic applications. You can make logical monolith clusters that handle portions of traffic. For example, incoming API requests, front-end control panels and background tasks can be in the same code base, but it is not necessary on each machine to process all three types of requests.
The advantage here is the same as in the case of microservices: individual clusters can be configured depending on the load, and they can also be scaled individually in response to traffic spikes. Microservice architecture from the very beginning pushes to such an approach, but nothing prevents you from applying the same method for scaling a monolithic stack.
“When you, as an engineering organization, are ready,”
I want to end this article with a discussion of when the right time will come to microservices (or, if you have already begun, how to understand if this was the right moment).
The most important thing on the way to a good, working microservice architecture is a simple understanding of its subject area. If you do not understand it, or are still trying to understand it, microservices will bring more problems than solutions. But if you already have a deep understanding, then you know the boundaries and dependencies, and the microservice approach can be the right step.
Another important point is your work environment, especially how it will look in the context of distributed transactions. If you know the paths of each category of queries in the system, and you understand where, how and why these paths can break, then you can build a distributed model for processing queries.
In addition to understanding the environment, there is the topic of monitoring the environment. It goes beyond the discussion of microservice vs. monolith, but monitoring should be at the heart of engineering efforts. You will likely need a lot of information about different parts of the system to understand why one of the parts behaves badly or even generates errors. If you have an established monitoring system for the components of the system, then you will be able to understand the behavior of the system during horizontal scaling.
And finally, if you actually demonstrate the benefits of your engineering organization and the business as a whole, then moving to microservices will help grow, scale, and make money. Of course, building interesting systems and trying new things is great, but in the end any company has the most important indicator. Если приходится откладывать релиз новой фичи, которая принесет компании деньги, из-за поста в каком-то блоге про "монолиты это плохо", то придется оправдывать это решение. Иногда это того стоит. Иногда — нет. Знать, когда нужно настоять и уделить время поможет вашей репутации в долгосрочной перспективе.
Надеюсь, теперь у вас появился набор условий и вопросов, которые нужно разрешить если кто-то предложит микросервисный подход. Как я говорил в начале, моей целью не было доказать, что "микросервисы это плохо". Но спрыгивать на микросервисы не подумав обо всех возможностях деталях и вопросах — это напрашиваться на проблемы в будущем.
If I ask for my advice, I would look in the direction of "internal" services based on clean, well-defined modules in the code. They can already be brought to these services in the future, if the need arises. This approach is not the only possible one, and certainly not a panacea for bad code. But it will help you move forward faster than if you dig into microservices before the right one.
"Microservice" is no different from many components that make up the complex equipment that surrounds us every day:
The reasons why microservices work in more developed industries are: easier division of labor, simple interaction with mechanisms and the speed of their creation with fewer errors.
Comments
To leave a comment
Web site or software design
Terms: Web site or software design