Migrate a Monolithic Application to Microservices

Monolithic Architecture

Monolithic applications are big fat complex single applications that have high complexity. Besides, they are hard to maintain and not easily deployable as well. Failure in one part can bring the whole system down. higher database complexity, improper resource utilization, etc.

To give you a better idea of what monolithic architecture is, here are some of its characteristics:

  • They are a really large single application that serves all the types of browsers, mobile applications, or any 3rd party integrations.
  • They are very complex and have huge structures and files.
  • Monolithic apps are very hard to maintain. (In terms of coding standards, bug fixing, etc).
  • Continued Development will be difficult as large applications cannot deploy very frequently. (Due to the fear of failure, deployment can be time-consuming, you should have to interrupt background jobs before deployment so it will increase the risk factor which leads to fear of deploying frequently).
  • Scaling applications can be difficult. For example, if there is a single application that is doing all the tasks, there might be a chance that some modules need more CPU consumption, some need higher RAM and some need higher graphics or higher I/O operation. When we provide the application higher ram or CPU it doesn’t mean that the module that really needed is consuming that resource.
  • Horizontal scaling is very hard.
  • Development teams usually find scaling monolithic apps difficult. Once an application gets over a certain size, it is really hard to maintain by a single team and then have to divide a team module wise and interference of modules to each other leads to a developer having a broad understanding that will become time-consuming and also affect the productivity of newly introduced developers.
  • Technology becomes a bottleneck. Once an application started development in specific technology then needs to stick with that technology though it becomes outdated.
  • Overloaded IDE due to the large application which will take too much time to open the application and build it or deploy it. So, the developer needs to spend a lot of time on this.
  • Large applications take a longer time to start up which will have an impact on deployment as well as affect the productivity of the developer.


Application load process


The above image illustrates the typical architecture of a monolithic application, where a single application contains all the services which are responsible to do all the tasks.

What is Microservice?

A microservice is an architectural concept. It is a distinctive method of developing software systems that try to focus on modules and divide the whole system into fragments in a way that each module becomes an independent service. In simple words, it involves dividing a single huge system that is hard to maintain into smaller services that are independent and highly maintainable.

The Following are the main characteristics of microservices:

  • Each Service should be loosely coupled.
  • Each Service should be highly maintainable and scalable.
  • Each Service should be independently deployable.
  • Each service has specific responsibility based on business capabilities.
  • Each service should be owned by a small team.

For example, looking at the below image, one can easily identify that there are different types of services that have their own databases.

Microservices with their own databases


Here, systems have been divided into a number of microservices which are working without interfering with each other. This is the beauty of the microservices architecture, where each service is one small module which can be worked with minimum interference with other microservice and each service has its own responsibility and can be deployed individually and can be owned by a small team.

Migrating Legacy Application To Microservices

Strangling the monolithic application

There are mainly two approaches for migrating monolithic apps into microservices.

  • Implement new features or functionality in a separate microservice.
  • Extract the new microservice from the existing Monolithic code base.

In this approach, if there is a single monolithic application, new features should be developed in a microservice that contains the separate database and functionality. In this process, if you want any data from the monolithic application, Relative APIs should be built inside the Monolithic App or a new standalone application should be created which will be responsible to just serve the monolithic application.

It is called a glue, which will become a mediator between monolithic and microservices. After this, when the developer has time, they can move the modules from monolithic to the new microservices. After a certain period of time, one can have only microservices without any monolithic application.

Suppose there is one Food Order and Delivery Management Monolithic application and someone wants to strangle that application into microservice by extracting some functionality into a microservice, the image below figure shows what a person needs to do when they have to extract some functionality from monolithic app into microservice:

Extracting functionality from monolithic app into microservice


1. First, Split the code within the Monolithic Application. Meaning, divide the code separately like Order Code and Delivery Code which will be loosely coupled code and reside in same monolithic application

Split the code


2. Split the Database and separate the database of the extracted service. Here, one should have to add integration glue. This means that a developer has to create a plan to sync between two databases. It can be managed by Triggers or by Code.

Split the database


3. Define the Separate Service for the Functionality that you want to separate. Here, it is Delivery Management. So, create a separate service for that module.

Define a service


4. Use Extracted Service as a standalone service. This can be achieved by API gateway. So, API gateway will be responsible to accept the required and divert that request to Monolithic app or newly extracted service.

Use delivery service


5. Now it’s time to remove the delivery management code from existing Monolithic Application

Delete old code


Wrapping Up

By following these steps, one can migrate a typical monolithic application into a microservice-based architecture. If you haven’t noticed, having an ideal monolithic to microservices migration strategy is crucial. Without it, the cloud migration process could be chaotic.


Comments

Post a Comment

Popular posts from this blog

Microservice: Create JPA App Using Jakarta Persistence API in Payara Micro

  Before We Begin: In this tutorial, we will configure this application with the following components in mind: The microservice application will be a Mavenized Java application. We will use MySQL DB Server as a relational database. The JDBC data source will be a transactional data source ( XADataSource ). JDBC Driver Library Configuration With Maven You need a JDBC driver to connect your Java application with a relational database. The driver is usually provided by the database vendor. Fortunately, most database vendors have released their JDBC drivers to a Maven repository. If you use Maven to build your application, you can add your JDBC driver by adding code that is similar to the following example to your  pom.xml  file. XML 1 < dependencyManagement > 2 < dependencies > 3 <!-- https://mvnrepository.com/artifact/mysql/mysql-connector-java --> 4 < dependency > 5 < groupId > mysql </ groupId > 6
Read more

How to Improve Decision Making With Better Data Quality

Image
  The term "data quality" on the search engine results in six million pages, which clearly expresses the importance of data quality and its crucial role in the decision-making context. However, understanding the data helps classify and qualify it for effective use in the required scenario.  Understanding the Quality of Data Good quality data is accurate, consistent, and scalable. Data should also be helpful in decision-making, operations, and planning. On the other hand, lousy quality data can cause a delay in deploying a new system, damaged reputation, low productivity, poor decision-making, and loss of revenue. According to a report by  The Data Warehousing Institute , poor quality customer data costs U.S. businesses approximately $611 billion per year. The research also found that 40 percent of firms have suffered losses due to insufficient data quality.  Organizations worldwide are heavily investing in data management and processing to achieve good quality data, but the r
Read more

How to build a project in eclipse developed in Oracle JDeveloper with oc4j

Image
Adding Oracle Ant Tasks to Eclipse Eclipse -> Ant -> OC4J Mucking around with Eclipse lately, I wanted to use the <oracle:> Ant tasks from the IDE. OC4J comes with its own standard Ant distribution which has the <oracle:> Ant tasks already seeded within it. One option therefore was to swap the distribution of Ant being used by Eclipse with the one in the OC4J distribution. But that seemed a little severe -- how about we add the <oracle:> tasks to Eclipse instead. After a bit of trial and a bit more of error, I have it working. In the end, the steps required to make it work are quite simple, with one major consideration: it's necessary to have an OC4J environment local to the Eclipse IDE. The <oracle:> Ant tasks are packaged to run within the context of OC4J. The Manifest.mf file of the JAR files contain Class-Path entries which define the other required libraries. So take it as a given, that as a minimum you need an OC4J environme
Read more