Microservices make the world easier (and here and not)
About microservices now say everything. Almost every meeting, conference and mitap does not go without a story about what microservices are and how good they are, how they reduce the complexity of a project and so on.
The main message of all these reports is that microservices help to avoid the excessive complexity and complexity of the project. But, as for me, it’s impossible not to get rid of the difficulty at all, you cannot redo the project so that everything at once becomes simple. Difficulty from one area to another.
For example: there was a very complicated tangled monolith, we broke it into several services, each of them looks great, anyone can deal with the code, but what happens to the environment? Complexity grows: it is distributed transactions, which need to be logged so that it is a single transaction; CI / CD and delivery are added for each service; the interaction scheme becomes nontrivial.
The most controversial theses or statements that I heard on the reports and with which I am ready to argue: The
entrance to the monolith project is more expensive for new team members. For some reason, it is customary to estimate the cost of entering the project by how quickly the new developer will begin to do the tasks. Yes, in a small service, he will figure it out very quickly and issue the task very quickly (especially according to the specification, “what they wrote, then I did”).
But what about the other team members?
The new tester will deal with the integration model. Testing a service is good, but in addition to testing a service contract, you need to check the business process that affects several services.
At first, a new analyst can break his head at all, until he understands all the intricacies of internal challenges.
Microservices allow you to release more often. Microservices are updated faster, because they are separated into several parallel tasks that are being developed and tested in parallel, and all that remains is to check the integration (without taking into account time for analytics).
You can also do this with a monolith, it all depends on the task decomposition. Most often, at the very beginning there will be one task - to make the general functionality (to correct the common database, or to modify the interface), and then everyone will saw their subtasks and give them to testing.
And the release time features, for which the business pays, will be the same. The feature will be closed only when all components are released. Microservices can solve 99% of tasks, but until the last feature closes, they will not be released into battle.
When using microservices, the infrastructure becomes more complex . This is due to the fact that it is necessary to support the work of not one application, but many services. It is necessary to monitor the performance of all services, to understand well the dependencies of services by version, to have CI / CD plans for assembling services and delivery, and mechanisms for responding to service outputs out of order so that everything else does not fall.
It seems to be simple things, and in the monolith we must do the same. Only in the monolith we work on one application, and with the increase in the number of services, the complexity grows, which requires higher skills from support.
Microservices add complexity- New libraries, new functionality to support distributed transactions, to handle errors of other services, send repeated requests, rollback transactions. For the most part, these mechanisms will be common, and most developers will not get into the "guts", but will only use them.
But there may be mistakes in them that will have to be repaired. If we can handle the fix without problems, then it will take time and advanced controls to roll out the changes across 200–300 services. And if you need to rebuild services with an updated library, or even redo the challenges (they fixed it, didn’t foresee it), then all this will not be fun.
How usually begin stories about the wonderful world of microservices? “We had a monolith, it was a solid clump of dirt, in which everything is confusing and incomprehensible,” plus another terrible picture will be shown. And the monolith has already become something frightening, “you will work badly, your project will turn into a monolith”. But no.
A monolith can be (and should) be understandable, structured, with a 'good' code, with documentation, as well as a microservice project can turn into an even bigger clump of dirt if you do not engage in development processes and do not monitor the quality of development.
Good question, and you can only answer. Because only you know what business problems you decide, what the project will be like. There is no silver bullet, there is no ideal architecture that can be used and there will always be “happiness”.
And in the monolith, and in microservices, follow the documentation and keep it up to date. The documentation is better than without it.
Build a development process in which the quality of the code will only increase (review, unit tests). But about the quality you can write a whole book, this is a topic for a separate big conversation.
Simple and understandable code is not about microservices, a code should be a priori.
Test automation is also about the quality of the code.
Automate everything that can be automated - CI / CD. Probably, there is such a stack of technologies that is very difficult to tighten in CI / CD, but 99% of assemblies / supplies can be automated.
The main message of all these reports is that microservices help to avoid the excessive complexity and complexity of the project. But, as for me, it’s impossible not to get rid of the difficulty at all, you cannot redo the project so that everything at once becomes simple. Difficulty from one area to another.
For example: there was a very complicated tangled monolith, we broke it into several services, each of them looks great, anyone can deal with the code, but what happens to the environment? Complexity grows: it is distributed transactions, which need to be logged so that it is a single transaction; CI / CD and delivery are added for each service; the interaction scheme becomes nontrivial.
The most controversial theses or statements that I heard on the reports and with which I am ready to argue: The
entrance to the monolith project is more expensive for new team members. For some reason, it is customary to estimate the cost of entering the project by how quickly the new developer will begin to do the tasks. Yes, in a small service, he will figure it out very quickly and issue the task very quickly (especially according to the specification, “what they wrote, then I did”).
But what about the other team members?
The new tester will deal with the integration model. Testing a service is good, but in addition to testing a service contract, you need to check the business process that affects several services.
At first, a new analyst can break his head at all, until he understands all the intricacies of internal challenges.
Microservices allow you to release more often. Microservices are updated faster, because they are separated into several parallel tasks that are being developed and tested in parallel, and all that remains is to check the integration (without taking into account time for analytics).
You can also do this with a monolith, it all depends on the task decomposition. Most often, at the very beginning there will be one task - to make the general functionality (to correct the common database, or to modify the interface), and then everyone will saw their subtasks and give them to testing.
And the release time features, for which the business pays, will be the same. The feature will be closed only when all components are released. Microservices can solve 99% of tasks, but until the last feature closes, they will not be released into battle.
What else do not speak
Complexity grows
When using microservices, the infrastructure becomes more complex . This is due to the fact that it is necessary to support the work of not one application, but many services. It is necessary to monitor the performance of all services, to understand well the dependencies of services by version, to have CI / CD plans for assembling services and delivery, and mechanisms for responding to service outputs out of order so that everything else does not fall.
It seems to be simple things, and in the monolith we must do the same. Only in the monolith we work on one application, and with the increase in the number of services, the complexity grows, which requires higher skills from support.
Microservices add complexity- New libraries, new functionality to support distributed transactions, to handle errors of other services, send repeated requests, rollback transactions. For the most part, these mechanisms will be common, and most developers will not get into the "guts", but will only use them.
But there may be mistakes in them that will have to be repaired. If we can handle the fix without problems, then it will take time and advanced controls to roll out the changes across 200–300 services. And if you need to rebuild services with an updated library, or even redo the challenges (they fixed it, didn’t foresee it), then all this will not be fun.
Monolith is not a big ball of mud
How usually begin stories about the wonderful world of microservices? “We had a monolith, it was a solid clump of dirt, in which everything is confusing and incomprehensible,” plus another terrible picture will be shown. And the monolith has already become something frightening, “you will work badly, your project will turn into a monolith”. But no.
A monolith can be (and should) be understandable, structured, with a 'good' code, with documentation, as well as a microservice project can turn into an even bigger clump of dirt if you do not engage in development processes and do not monitor the quality of development.
So what to use?
Good question, and you can only answer. Because only you know what business problems you decide, what the project will be like. There is no silver bullet, there is no ideal architecture that can be used and there will always be “happiness”.
And in the monolith, and in microservices, follow the documentation and keep it up to date. The documentation is better than without it.
Build a development process in which the quality of the code will only increase (review, unit tests). But about the quality you can write a whole book, this is a topic for a separate big conversation.
Simple and understandable code is not about microservices, a code should be a priori.
Test automation is also about the quality of the code.
Automate everything that can be automated - CI / CD. Probably, there is such a stack of technologies that is very difficult to tighten in CI / CD, but 99% of assemblies / supplies can be automated.