Microservices for those who pretend to be developers. Part 2

And so the day has come when I finally deigned to get up from the couch and finish writing the next article about microservices. For those who are not in the know – in the last part we found out how much incorrect punctuation and stupid jokes can irritate. Well, and discussed a little what microservices are and why they are needed at all. We will not deviate from the trends in this part, we will continue to dive into this wonderful world of machine translation, jokes for 300 and microservices.

Globally, there are two ways to move to a new architecture: either we do everything at once, or in parts. The first way looks pretty good on paper: we draw up the structure of the future microservice architecture, divide into teams, close the development of new features and completely switch to migration. It turns out very cool, fashionable and youthful: one mighty effort – and the pants became warm the system is already on microservices. But where is the catch in this wonderful plan? Let's try to figure it out.

• Difficulty in estimating the duration of work. Due to many pitfalls and unforeseen factors, it will be very problematic to accurately estimate the timing of the move to a new architecture. Accordingly, the move may be delayed indefinitely.

• The complexity of collaboration among a large number of programmers. One of the reasons for switching to microservices may be a greatly increased number of staff on the project. As a result, collaboration and implementation of new technologies (MR blocking, deployment for every sneeze, etc.) become more complex. Even if we have correctly divided the team, cutting everything at once will be like the fable “The Swan, the Crayfish, and the Pike.” A multitude of merge requests, overlapping tasks, and failures can greatly slow down the work.

• Risk of abandonment. It's unlikely, but if everything drags on for too long and no results are visible, they might close the shop.

• Stopping new features. The implementation of new features will be blocked for an indefinite period. This is a risk of losing users and clients. Business cannot afford a pause for months or even years in order to switch to a new architecture. Losses grow, and financial problems are added to the migration. On the other hand, in case of failure, this will be a great opportunity to find yourself on another project, or open a goose farm

On the other hand, the “piecemeal” approach is much more viable. Its essence, as the name suggests, is in a step-by-step migration. Instead of breaking the entire system, you gradually isolate individual components and turn them into microservices. All that remains is to determine priorities and those very components for microservices.

Of course, we can, as always, flip a coin and randomly select a piece of code to move into the new architecture. The plan is certainly good, but it is better to play it safe and consider a few more ways. So, where to direct your keen eye?

• The area where code changes most often occur. Migrating code where changes are never required is a cool idea, but not viable. Why prioritize something that never changes and works perfectly? You need to think the other way around and look at the part of the system that is constantly being refined and updated. The more often changes occur, the more problems the process of updating the entire monolith causes. By separating this part into a microservice, you can simplify development and merge requests, reduce the frequency of deployment, and save reduce the number of bugs. Now this section will be independently deployed and updated.

• The area that requires the most scalability. If there are sections of the system that bear the main load, it makes sense to move them out first. This will improve scalability and increase fault tolerance. It will also reduce the load on the main server. If necessary, you can buy several small servers and split the load between them using Load Balancer. With a monolith, this is also possible – but the price is significantly higher. And technically, it is much more difficult.

• Area with the least technical debt. You can also start the migration from those components with the least amount of “crutches”. This will reduce the number of nerve cells when switching to a new architecture.

  The advantages of this approach include:

• There is no hard deadline: the transition can be carried out gradually, without rushing and without burning out all the team's resources. Work continues as normal.

• Visible progress: each successfully migrated component is a tangible result for the team and the business.

• Business does not suffer: since the migration process goes in parallel with the development of new features, the business continues to grow and pay you money.

Migration process

Have you heard of strangler fig? It sounds like the title of a cool blockbuster, but it is actually a species of tropical and subtropical plants that share a specific “strangler” lifestyle. If you are interested in the details – strangler ficus. By analogy with this behavior, Martin Fowler created the strangler pattern. Its essence is simple – we “wrap” the old code and start taking out pieces from it. Let's consider in more detail:

First, we need to create a facade for users to redirect requests to new microservices.

Next, we determine the area with the highest priority and move this functionality into a separate microservice.

We redirect requests from the removed area to a new code block. It is not recommended to delete the old section:

• The transfer process may have new bugs. The repair process will take some time and the service should work.

• It's always nice to be able to get things back to the way they were without much effort.

We repeat the process.

As a result, we are completely switching to a new architecture. Profit.

Adviсe

• Leave the stack unchanged. If you had a relational database – leave it. Used Java? Firstly – my respect, and secondly – continue to do the same until the complete transition to microservices. Otherwise, you risk creating several unexpected problems for yourself. Remember the golden rule: “If it works – don't touch it.”

• Don't rush to refactor. First, transfer the entire architecture completely, otherwise you risk biting off more than you can chew. The reasons are the same.

• The more tests, the better. It is very important to understand that during the transfer process we did not create any new bugs and are fully compatible with other parts of the application.

• Define API. Pre-designed interfaces between microservices will help avoid confusion and failures when components interact. Measure seven times, cut once.

• Isolate a component: All internal dependencies should be taken out of the code so that each microservice can work independently from other parts of the system. In other words, the microservice should be as isolated as possible.

That's probably all for now. Write comments – it's always interesting to read how stupid I am and how everything written is heresy. Well, in the next part we'll talk about databases in microservices.