Migrating Monolithic Applications to Microservices

DZone 's Guide to

Migrating Monolithic Applications to Microservices

Learn about the specific challenges of migrating applications from monolithic to microservices architecture, and what a target architecture generally looks like.

· Microservices Zone ·
Free Resource

"Monolithic" is the traditional unified model where a whole application is packaged into a single artifact and running as one process.

Typical problems in the monolith are

  • The complexity of adding new functionalities on top of the existing application.
  • Performance issues due to a recent spike in transactions.
  • Managing compliance and security in the modern world.
  • Upgrading technology issues and its depended frameworks.

What Are Microservices?

Microservices is a software architecture where a bunch of services running in their own separate space are used to move towards cloud offerings in the API economy.

Characteristics of monolithic vs microservices architecture:



Interdependent services

Independent services

Tightly coupled

Loosely coupled

Application specific services

Reusable services



Migrating From the Monolith to Microservices

The following steps are necessary to migrate a monolith to microservices:

  • Metadata Extraction
  • Business Logic Extraction
  • Implementing the Target Architecture

As part of the nature of a monolithic application, it has multiple modules, which are intercommunicating. To identify those modules extracting the metadata of the application is the first step of the migration. It includes data flow, boundary context, running platform, etc. With this, the application can be split into a presentation layer, a business logic layer, and data access layer components. Communication between these layers can be achieved via remote HTTP calls so that there is a clear separation between each layer.

Once the layers are identified, each layer to be divided into multiple services. In the presentation layer, the services may be identified by the user navigation flow. Typically, the home page would be deployed as one service and each transaction page would be deployed as a separate service. Each transaction could have one or more models. Based on the nature of the transaction, models need to be identified and the relationship between models needs to be established.

A lot of third-party tools, like Rational, are available on the market to generate the models from the existing application with the relationships. Based on the model, the business logic is grouped and individual services created. If a model depends on another model, the depending objects will be passed as remote objects via HTTP so that each service can be deployed in its own self-contained platform. In case of latency in remote service calls, asynchronous communication would be introduced.

Next, to run each service, the required resources and dependencies are identified. Normally, environment-specific values are maintained outside the deployment, like security keys, logging properties, etc. Those configurations need to be bundled and moved along with the service. In case of containerization/cloud deployment, new additional details like memory allocation and network port configuration will be added along with the existing configuration information.

The source code for each service to be maintained as individual projects in source code management tools (SCM) like GIT, SVN, etc., so the existing SCM structure must be changed to accommodate microservices. Application-wise, resources maintained in SCM will be divided into service-specific resources so that services can be built individually without depending on other services. In case of any new changes, each resource version can be maintained, specific to the service.

Service-specific identified models and their dependent classes are realigned in the SCM. In case of business logic shared across services, shared business logic can be moved as an individual component and services can make a remote call to that component to achieve loose coupling and high cohesion. Once functional requirements are migrated into the target architecture, non-functional requirements like security, scaling, etc can be designed and implemented.

The diagram below represents a typical target architecture:

Image title

microservices architecture ,microservices ,monolith

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}