From Monolith to Microservice
This year is approximately reaching its end. Our team keeps improving services to deliver a better experience for customers. Not limited to upgrading our architecture system. Here, I am one of the Engineer Manager of Ralali.com will explain to you about it in a few series of articles. Please enjoy part one!
As a matter of fact, we started to use the monolith system or hexagonal architecture as an approach to build software applications where all software code is packaged or stored in a single code base repository. Usually, applications are deployed in a deployment package, such as a jar or war for applications that are created using the Java programming language, application that runs on one main.go file for the application that created using Golang, or application that runs on one index.php file for the application that created using PHP.
Architecturally, monolith system or hexagonal architectural applications can be described as below:
As illustrated above, we can see that all modules of the application are in one system. Taking the RSMS (Restaurant Management System) application as an example. The picture shows the main function (core of application) is in the innermost layer and contains all the business logic. The core application is surrounded by several adapters and some integration modules that access the external system.
In the initial stages, since this application was made and successfully released to the public and used, the monolith or hexagonal architecture application runs smoothly and has many advantages, including:
- Very simple and easy to make. IDE (Integrated Development Environment) and other developer tools can easily help with application development.
- Even though there is a very radical change to the business process, repair work will still be relatively easier and can be completed following the target time. We can change the code and database schema and then build and deploy.
- Test and deployment are quite easy and directly lead to the target according to its purpose. Not too complicated and not wordy in the process.
- Easy to scale out. Only by copying the source code, build, deploy to other server and use load balancing to split and balance the request, the application will be scale-out.
However, throughout time, all of the above things have become increasingly complicated. After a few years passed, the RSMS application has changed to a very large application due to the many features added to the system. The number of teams is also getting bigger (also stronger, of course) and the development process tends to be slower and barely burdensome. Bugs everywhere, the team has to break a leg to fix it, and agile development wasn’t working. If we describe it, the process of developing RSMS applications after several successful years will be as illustrated in the following figure.
Unfortunately, the team faces the following problems :
- The application becomes very complex and disturbing for each team member. The application becomes very large for all team members to understand. As a result, fix bugs and the process of adding new features becomes difficult and very time-consuming. Finally, the target time cannot be fulfilled.
- The development process takes a long time. Because the source code is getting bigger, it takes a long time to build and debug the application. A power of IDE (Integrated development environment) is also limited in displaying codes that will be edited or added and the application also requires a long time to be able to go up and run in production
- The process of scale-out of the application is arduous and requires a huge cost. Because all business processes are deployed in one environment and the same database but all modules have different characteristics, so the most likely way is to clone application deploy it in the largest hardware resource as possible.
- The next problem is the application is not reliable. Because to do the overall test is difficult so the application often has a lot of bugs. Finally, the application often has to be turned off to make improvements.
- The last problem for the team is that the architecture forces them to use technology stack that’s becoming increasingly obsolete. The monolithic architecture makes it difficult to adopt new frameworks and languages.
To address the solution for those problems, our squad then will be welcoming something more beneficial: Yep, “The Microservice Architecture System”. We will discuss all kinds of stuff about it from our engineering team capability in the next section. Keep up the good work for CRAZY impactful engineering!