Instead of introducing
Several months have passed since the launch of the first microservices. And now, in our opinion, is the time to tell about the experience gained.
Immediately it is worth making a reservation about what will be in this article and what will not be in the article. The article will not describe architectural solutions and descriptions with the rationale for these decisions. We will not focus on the technology stack on which we created microservices.
The main focus of the article will be on those global problems that our team faced throughout the project.
This article will be the first of many. And its goal, first of all, is to introduce into our problems in the context of the transition to a microservice architecture and smoothly lead to the following topics, which reveal in detail certain aspects of the transition.
How it all began
The decision to switch to a microservice architecture was made about a year and a half ago. Our challenge was to prepare for the rapid growth of our company. We had to become more flexible in terms of technical solutions, increase the speed of making changes and, of course, increase the resiliency of our systems.
After the decision was made to switch to a microservice architecture, a separate unit was created from experienced and proactive guys. The determining factor for considering a candidate for transfer to a new department was high expertise in one or several existing information systems.
Since there was no clear understanding of the work front at that time, the team was formed somewhat spontaneously. But at the same time, the principle of self-sufficiency was already being laid - developers, analysts and testers in the team should have their own.
Two paths were chosen at once as a strategy for switching to microservices:
- we take out into microservices what (as we thought) is easiest to take out;
- We bring into microservices the one whose transfer to microservices solves the most problems for both business and IT.
The first way was good because in the process the team would acquire the necessary expertise and fill their hand, thereby increasing their efficiency for subsequent work. The second way was to provide a kind of quick win for the team, showing the correctness of the chosen decision to switch to microservices for the company and motivating the team for new feats.
The team was at the beginning of the journey. It was a happy time: the future looked bright and cloudless, and it seemed to us that we had a plan.
First difficulties
And, of course, since we're talking about microservices, we can't help but talk about monoliths. These are our main information systems.
The architecture of our individual systems is best illustrated by this picture taken from the article by Stefan Tilkov "Don't start with a monolith". As we can see, the functional blocks in the monolith are extremely closely related to each other. This is a serious obstacle to the process of transferring a separate functionality to a microservice.
For reference, our monoliths are about 13 years old, and the average monolith's codebase is about 1.2 million lines.
In other words, the team faced the following issues over and over again:
- extremely time-consuming process of analyzing the existing functionality;
- often lack of understanding of what exactly we are bringing into the microservice;
- the complexity of integrating the monolith with the new microservice.
Considering that, in addition to solving these problems, the team also needed to increase expertise in a new stack and a new design approach, progress did not go very quickly.
Nevertheless, after a few months, the team began to show the first results - the first microservices friendlyly provided their APIs to everyone. The team believed in themselves and knew for sure that they were doing everything right. Well, many things in our life are quite illusory.
First successes and new difficulties
Despite the first difficulties, the team received both new experience and first results. But some unaccounted for risks have arisen preventing the launch of microservices.
- It turned out that the monoliths were not ready to work with the new stack, and the integration was delayed.
- - .
- , , , , .
The first two problems were solved quite simply - by writing separate clients to integrate the monolith and microservice and adjusting the monolith functionality accordingly. But the third problem has not been fully resolved to this day.
Resource inconsistency was partially addressed through collaborative resource scheduling. It seemed that the team took into account all their mistakes, there was an understanding of what and how to do correctly, and by the beginning of 2020 about a dozen microservices had been written (some turned out to be not micro services at all) waiting for integration and release into production. They covered with their functionality most of the business-critical processes, such as calculating the cost and delivery time, bringing new regions and offices to the selling site, searching and selecting goods, etc.
We confidently moved forward, having already solid experience and having filled a lot of bumps. It seemed that we were faced with all the pitfalls, and now it remains only deliberately, step by step, to implement our plan.
Well…
Quarantine, labor exploits and finally success
The beginning of the year made significant adjustments to our plans, and this is due to the consequences of the new coronavirus that spread at that time. Obviously, there is no need to explain what is at stake: everyone already knows a lot on this topic.
The outbreak of the pandemic and the accompanying economic crisis forced our company to slightly reconsider its development priorities. And as a result, IT priorities changed - new tasks were set, designed to quickly remake business processes to fit new realities.
The changes also affected plans for microservices. Due to the reallocation of resources, the integration of microservices with monoliths, and, consequently, the release of the microservices themselves were again delayed.
Here, finally, it is necessary to dwell in more detail on what was happening in the team and how the team felt.
First, demotivation. Due to the lack of a solid result for a long time, and there were no fully ready-made and integrated microservices in production for almost a year, the team was very morally burned out (against this term, but nevertheless). The efficiency has declined greatly. Not without rare, but vivid emotional breakdowns.
Secondly, quarantine and a complete transition to remote control. Of course, we have a wealth of experience in working on a remote basis: almost ⅔ of the developers are remote workers. But everyone who worked on microservices worked together in the same office, and the transition to remote work did not affect the effectiveness of the team in the best way. On the one hand, the fact that it took time for restructuring and transition to a new format of work. On the other hand, it was during the period of decreasing team motivation that more personal communication and mutual support within the team was required.
Thirdly, the team needed to show the result. Indeed, the entire team, despite the internal and external problems, clearly understood: the further fate of the entire enterprise depends on how quickly we can squeeze our goals to a solid result. Many in our company were ready to admit the experiment of switching to microservices as untimely, unsuccessful and to disband the department.
For almost two months, the team worked 12-15 hours, often seven days a week. And she was able to achieve the desired goal - four microservices, fully working and fully integrated with monolithic systems, came into full production at once.
It is important to note that we did not use any tricky techniques to motivate the team, there is no know-how to share. It's just that day after day the team did the following:
- frequent Skype calls with updating the current status of work and prompt resolution of emerging issues;
- maintaining a positive attitude in the team with constant checking of the resource state of each.
As a result
Instead of a conclusion, I would like to dwell on the conclusions that we made for ourselves ...
- Cross Teams. To successfully implement such ambitious projects, there must be a fully dedicated and autonomous team with sufficient resources to solve any problem. In our case, this means that the team creating microservices on a new stack should have guys from the monolith development teams. If we had understood this earlier and were able to push this idea to the end, this would have allowed us to avoid mistakes associated with insufficient expertise in business processes and inconsistency of resources for the integration of microservice and monolith.
- . , , . . , , , , . .
- . , . .
Now, having done the work on the mistakes, we can say with confidence: the experiment, which began almost a year and a half ago, can be considered successful. And now, from the category of just an experiment, the project of transition to a microservice architecture is becoming one of the key IT strategies in our company.
In the future, we will return to this topic and talk in more detail about the technology stack, individual solutions, and much more. We have accumulated enough material and experience.