Migrating a Monolithic Architecture to Microservice Architecture
Microservice is a hot topic these days. But why does everyone talk about microservice? What is a monolithic architecture and what is microservices architecture? I will explain that by going through the migration process from a monolithic architecture to a microservice architecture. I will also introduce the characteristics, advantages of microservices architecture, and some of its challenges.
What is Monolithic Architecture?
Monolithic architecture means that we put all the functions of an application into a single archive package to deploy and run. For example, if you use Java, all your functions are packaged into a Jar package or a War package. This style of architecture can be called a single application style architecture, also known as a monolithic architecture.
Advantages of Monolithic Architecture
What are the advantages of this architecture? It has many advantages, including relatively simple and familiar to everyone. Also, it is IDE-friendly. IDEs are typically designed to develop, deploy, debug, profile a single application easily. It is very easy to deploy, for example, since there is only a single war package or jar package, or an executable program, you can easily deploy it in one directory or multiple directories.
Disadvantages of Monolithic architecture
Of course, this monolithic architecture also has its shortcomings. The shortcomings mainly lie in the complexity of the system, especially in complex systems such as online shopping malls and e-bankings. These single application code base will be huge and difficult to maintain, it is also difficult to understand.
Besides, because the code base is extremely large, it takes a lot of time to start up. When we used to make a single application, it would take half an hour to start, so we all have enough time to go to play table tennis.
It lacks scalability. Since all the functions are placed in the same application, and if I want to change a tiny function, for example, I modify the user registration function a little bit, but the logistics module has not changed, even the logistics module has not changed, I have to be able to redeploy it again, it’s painful and inefficient.
There are many other disadvantages because it is a single code base, so we can only use one technology stack, all Java, all C++, all Python, etc., which will have many restrictions. These are the shortcoming of monolithic architecture.
How to Solve the Deficiencies of Monolithic Architecture?
Now that there are these deficiencies, how can we solve them? The methodology of the solution in the software world is the same as in the usual world. When we face complicated problems in our lives, our method is to Divide and Conquer, which is the same as this software world. The monolithic architecture is simply all in one, that is, putting everything together. If I want to solve the problems that are just sort of, I have to go through some divisions.
First of all, the vertical division will divide out completely irrelevant applications. For example, a user registration module and a picture display module are completely non-interfering. We can divide it into multiple separate modules, make them less coupling.
When the system slowly becomes more and more complicated, and a single module may be more complicated, we may consider dividing and conquering again, that is, horizontal division. What is horizontal division? For example, the logistics module may need to access user information, the credit module may also need to access user information, and so on. If all modules access the same user database, the database loading will be extremely high. Therefore, we divide them horizontally, we put all the user-related ones into a lower-level user management module and the order-related ones into an order management module. This is the second step to solve single architecture defects. If the modules are still very complicated even after these two steps of division, we will introduce the microservices model to the system.
The Microservice Model
The microservice model does not have a strict definition at present, but it can be roughly divided into the following characteristics. The entire system is divided according to the business scenario, for example, the user management module just mentioned may include user registration, user login, etc. We divide it according to the business scenario so that its scalability can be better. At the same time, the services communicate through several language-agnostic mechanisms, including the RESTful style of HTTP, which is the commonly used one.
Also, each service is autonomous. To put it simply, my data belongs to me. Just as an example, the user data is managed by the user management module. To let the user data be accessed by others, you require others to fetch the data through your user management module, rather than direct access to your database.
There is another feature, because after it is divided into more and more small services, in the end, its deployment may be difficult, so the microservice model requires a feature of automated deployment.
Of course, when you develop more and more microservices, you may need to consider a method to manage them. For example, a city had only one enterprise before, you can contact it easily. But when thousands or hundreds of enterprises have developed in the future, you can’t find them and deal with them one by one. Maybe there will be a bureau of industry and commerce. When I’m looking for this service, I first look for the public bureau, look for that company providing this particular service and I will find the contact address. Then I will find another company to communicate with him. This is a characteristic of centralized management.
Next, the distribution of microservices across different machines is certainly natural, multiple services, multiple machines, multiple instances are deployed to form a distributed system. Based on these characteristics, Microservice has advantages, which are exactly what the monolithic architecture lacks.
Another advantage includes a better understanding of the code. In the past, all the code was put together, and everyone may not understand it, which is very complicated. But a service module may only have one simple function such as user registration, user login, credit query and so on. Such a simple function module, the code is simple and easy to maintain, and the development efficiency is high. It also has good expansion capabilities. For example, I want to add an email notification during the registration process. Yes, there is no need to edit the user registration code.
The choice of the technology stack is more flexible because we communicate with each other through language-agnostic protocols. For example, the mall recommendation system can be implemented with popular Python, and the product management system still uses Java. It doesn’t matter, because the communication protocols are language agnostic, which is one of its advantages.
Besides, the version update is more agile, because each module is separately maintained.
The most important thing is that it is more robust, which means that if a single module hangs up, not all of them hang up. For example, the logistics system has been suspended for an hour, but I can still purchase goods, register, and log in. This is a huge advantage for the microservice.
The Challenges of Microservice
Of course, there is no perfect thing in the world. These advantages will bring some other difficulties. What are the difficulties brought by microservices? First of all, its complexity will be higher, because it has numerous services, and you will have difficulties in managing them.
Also, because the services are distributed on different machines and different processes, their transactions are difficult to control. Considering a use case like cash transfer between bank accounts, a user deducted money from one microservice, and then called another service to transfer the cash. With the previous monolithic architecture, it can ensure the immediacy of transactions through the database. Then if it is distributed, it needs to ensure the immediacy of transactions through complex mechanisms. I will continue to talk about it in a later article.
Another challenge is the division of services. Now we do not have a standard of how to divide it. Different companies or even different departments within a company would have their division strategies.
The last one is the deployment. I just mentioned that because there are more services, it is much more difficult to deploy than a single architecture. In the past, the software may have only one application and one service, the deployment is easy. Now an application may have hundreds or even thousands of services, and deployment will have great challenges.
First of all, we briefly introduce what is monolithic architecture, its advantages, and disadvantages, we must continue to solve its disadvantages through a divide and conquer method, and then gradually evolved to a microservice architecture, which its characteristics and its advantages provide a huge improvement of the software design. At the same time, we also introduced some challenges that microservices architecture will face to achieve these advantages.