Converting from monolith to microservices by example

Tram Ho

1. Why microservices?

Microservices is a service-oriented software system architecture that breaks down the system into small services that isolate business and data. Microservices has become popular in recent years, with outstanding advantages, it is replacing monolith applications. Some characteristics of microservices are as follows.

– Independent deployment

By dividing a large application into many smaller applications, the system becomes more flexible in deployment. Flexibility from technology selection to resource allocation. The system can achieve scalability, high availability criteria.

– Reduce dependency

Modules are clearly defined responsibilities, the constraints in the common use of business code, model and database are reduced.

– Oriented around the profession

Microservices are geared towards services that revolve around business, a service is an application that can run independently. Development teams will usually only have to focus on business development.

– Ability to develop, maintain and test

Different stacks can be applied together in the overall solution, even reused from another system without worrying about compatibility. Testing is also easier to deploy with small services, clear business. In this article, I will not go into depth to compare between monolith and microservices, see more at => Monolith vs. microservices .

2. The Microservices Layer?

If we are used to working with monolith, from coding all on the same repo, a dedicated server for configuration, a database for all purposes… then the transition to microservices is really a task. challenge. As a system designer, there are too many new things to understand and apply to get the best P/P (price/performance) and still be scalable. An effective microservices architecture is the proper coordination of tech stacks. We can divide microservices into 4 layers:

2.1. Infrastructure layer

The shift from traditional computing to distributed computing/cloud computing greatly facilitates the adoption of microservices architecture. Deploying microservices without infrastructure support takes significantly more work. At the bottom is the infrastructure with the basic components:

  • Servers
  • Host level logging/monitoring
  • Operating systems
  • Resource isolation
  • Configuration management

2.2. Communication layer

This layer is confusing, because it touches all the other layers in the ecosystem. It includes everything related to communication between applications, systems and services including:

  • DNS
  • Endpoints
  • Load balancing
  • Messaging
  • Network
  • Service registry
  • Service discovery

2.3. The Application platform

The third layer is where all the internal tools, systems, and services that microservices run on. A good application platform is where tools are centralized in terms of management, system-wide in scope. Development teams only need to care about the microservices they work on, not the stuff underneath. This layer includes:

  • Deployment management (tools and pipeline)
  • Development environment
  • Application-level logging and monitoring
  • Test, package, build and release tools

2.4. The Microservices Layer

Developers focus on this layer and focus on business. This layer should be independent of the layers below. It contains only the microservices and the configurations between them.

  • Microservices
  • Microservices configuration

3. Transform the Monolith to microservices in action

Let’s look at a traditional monolith application with the Presentation, Business logic, and Data access layers.

3.1. Business and Tech Stacks

Features of the current system

Business : E-commerce application.

Architect : 3 Tiers Application including Presentation, Business logic, Data access layer using Spring MVC, Spring Data

Database : Database using Mysql

Hosting : The application is deployed by jar file and database on the server located at the company

3.2. System issues are facing

  • Spring MVC is based on server side rendering architecture, multiple pages application, resulting in longer page loading
  • System downtime every time you upgrade to a new version, even the smallest feature of a module
  • The bottle neck phenomenon appears every time many people access or perform heavy tasks, lost orders, the order system does not work stably, even down the service. Increasing resource configuration is expensive when the system is under load, but still not enough to serve when the system is high.
  • Product search function is slow due to using traditional query
  • Manage your app’s build number and data manually, by backing up physical files (.jar, sql)
  • The trace log system is also manual by writing to the file, it is difficult to trace back when there is an error
  • The system contains many business modules, the code is complex and difficult to maintain, developing new features requires re-testing the entire system.
  • Product photos are stored directly on another server, difficult to manage

3.3. Converting the system to microservices

Convert business modules to microservices:

  • Authentication
  • Product management
  • Warehouse
  • Order/Payment
  • Shipping
  • Report
  • Client site
  • Cms site

Switch to architect:

As analyzed above, the most difficult problem to overcome in the issues is the problem that the application runs on a dedicated resource (VM) platform, leading to the inability to promptly scale according to the required amount of resources, directly affecting the quality. system and user experience. Consider architect transitions:

  • Deploy applications based on container orchestration (K8S concept), for scalability, high availability
  • Optimize product search by building more elastic services, synchronizing with Product database
  • Consider upgrading the database to a master-slave model to optimize read and write efficiency.
  • Load balancer balances the load for the instances when the system is in high load
  • API gateway helps to hide the architecture behind and centralized authentication/ request logging
  • Choice of message queue technology for asynchronous communication between microservices
  • Client site and cms site use client site rendering (angular/react) technology to achieve higher performance. The development of UI layer and business logic are separated
  • Separate databases for each service, increase resources for databases with many requests, even apply DB replica, master/slave => increase security and upgrade later
  • Use docker hub or private image registry to store service builds as image tags.
  • Applying technologies that can backup data as backup volume next to traditional file backup
  • Select a stack for file storage (product images, Database backup): Object storage technology (Sun S3)

3.4. Choose tech stack, provider and implementation

With the same system design, we can adjust the choice of tech stack and provider to suit the circumstances of each company. In the international market, there are big names in cloud providers and well-known app platforms such as AWS, GCP, Microsoft azure. In the country, there are providers such as VNG cloud, Viettel IDC, CMC, FPT, Sunteco Cloud with different prices and services. I will deploy this system on Sunteco Cloud , focusing on Sun Spinner, this is a service based on the concept of K8S, supporting Load balancing, HA and scability with just a few clicks. A Sun-spinner can contain one or more containers.

  • After building the services to the image format and pushing to the docker hub, setup the Sun Spinner clusters from the interface
  • Sun Spinner allows to run any image on docker hub or other registry images, completely through UI
  • Database can be deployed in 3 ways on Sunteco Cloud,
    • Create a mysql-spinner then use the persistance volume and mount it to the data stored path of mysql-spinner
    • The more traditional way is to use the Sun VM service to host the database with a dedicated resource
    • Database as a service (Coming soon)
  • The service-config is set up through the Secret / Configmap system and mounts directly to the Spinner. Simplify configuration management
  • Static web pages (landing pages) can be hosted on Sun VM or Sun S3 storage
  • Message queue uses Sun Highway (kafka as a service) Lifecycle of services: CICD => push to docker hub => Sun Spinner pull image => Service booting => Service running. There is a small suggestion that Spinner does not have an integration mechanism with the CICD system of enterprises, perhaps need an api callback to trigger the application update to the new version. Currently, you have to go to the Sunteco Cloud portal to manually update the new version or set up Sun Spinner with auto update policy. By simply facing the web application and the api gateway to the outside, the back end applications communicate with each other through the internal endpoint, message broker, which improves performance and security. I have not mentioned the problem of database relication, see you in the following articles.

4. Conclusion

You can consider converting all or part of your business applications with the smallest cost to get the best effect. Container technology allows applications to scale arbitrarily. Sunteco’s Sun Spinner has hourly pricing, which means that if the system is under normal load, the consumption is only equivalent to the VM of the same configuration, but when the system increases the load, the configuration is automatically scaled immediately to meet the needs. demand, when the system reduces the load, the configuration returns to the normal level. All these needs, if you build a K8S system yourself and then install it yourself, it will take a lot of resources and may not work stably. Migrating from monolith to microservices or building entirely new is not easy, but it is well worth the effort.


Share the news now

Source : Viblo