Skip to main content

Moving from monolith to microservices

Migrating monolith to microservices starts by first defining your Domains.  Organizing your reusable components and services into a Domain Driven Design for microservices is key to a successful monolith conversion and implementation of a microservice-based architecture. Because it is so key, it should be the first step you take in your cloud-native journey.  This is often called Domain Driven Design (DDD).

The good news is that you can start the migration process by looking at your current monolithic application in terms of components and Domains. From that perspective, you can slowly and successfully see what migrating monolith to microservices will look like. DeployHub supports a Domain microservices catalog that helps you build out your Domains for component sharing and reuse. It facilitates migrating to microservices by helping you visualize your common services and defining a location for publishing and sharing. 

Domains are critical when you begin to decompose functions into independently deployable services. They allow you to catalog similar microservices together, making it easier for other developers to find and share them.

How to convert monolithic application to microservice

Let’s review a simple way of how to convert monolith to microservices. We will use a simple example to get you pointed in the right direction. Migrating monolith to microservices can be a task.

Let’s break it down by visualizing the monolith into components. If we take a simple web store application, you may have a .jar file, the database, the infrastructure components, and environment variable settings.  While the .jar file may be your primary focus, you need to start seeing the database, infrastructure, and environment variables as independent components of your overall application. You can build a strategy for managing each of these layers as individual services.  DeployHub does this using Domains.

Domains track, catalog, and expose reusable components allowing them to be easily shared, a critical step in the shift to microservices.  Domains are managed using DeployHub’s back-end versioning engine. This is not suggesting that all microservices of the same Domain are installed in the same container. Each microservice remains independent and in its own container.

DeployHub tracks the logical Domains so all microservices of a similar type can be more easily cataloged, referenced, and tracked.

Your monolithic Domains may include:

  • Infrastructure Components (java runtime, Tomcat, Environment. Variables)
  • Database and SQL (.sql)
  • The Website Frontend (.jar)

To visualize this, we can use a triangle that shows the lowest to the highest level of dependencies. This is a simple organizational method that can be useful for our more complex service-based architectures.


Monolithic Dependencies

With DeployHub, these Domains are controlled by different User Groups and can contain lower-level Sub-Domains. For example, Operation Teams may control the Infrastructure Domain, DBAs the middle-tier and developers control the website frontend. As you break down your application into services, you will expand on these Domains. Starting at this monolithic level helps you begin thinking ‘functions’ and prepares you for the next step.

Migrate to Microservices with Domains

One of the first steps to migrate monolith to microservices is to take an application and break it down into its smaller parts, or Domains. We then organize these parts in a fashion that will allow reuse.

If we think about the potential microservices for a simple store website, we’ll have:

  • the website front-end
  • a cart
  • credit card processing
  • a check-out system
  • advertisements and recommendations
  • sign-up
  • login
  • shipping
  • taxes.

We can show how to start migrating monolith to microservices and decompose our monolithic by representing it in a simple triangle.  We start by expanding the triangle into specific sections, the most commonly reused at the bottom, and team-specific at the top. Think about what’s most common. Like our monolithic, the lowest level is infrastructure and database. In our microservice-based architecture, these are followed by credit card processing and the login/sign-up.

Above that, we may have the cart and on top of that are the more specific pieces such as the ads and recommendations. At the peak of the triangle is the front-end. While this seems like a simple exercise, it allows you to begin to see the patterns in all applications across the organization. The lower-level sections should be reused.

migrate to microservices

Microservice Domains

This triangle shows how we build up from the most common pieces and represents how we would define Domains. Each section of our triangle becomes a Domain.

Domains and Sharing

Say we have another team that’s writing a store website, Website B. With DeployHub they find common pieces based on the Domains. Once you define your Domains, your developers can begin publishing and deploying microservices under the Domain structure making it possible for other teams to easily find and then reuse the services. When our next team creates a new store, they begin the process of re-use.

Shared Microservices

Between Website A and B we have accomplished a level of reuse for all the shareable layers from the infrastructure to the cart. This allows us to write the login, sign up, the cart, and the credit card processing once. DeployHub facilitates this level of design by supporting a highly customizable Domain structure allowing you to migrate monolith to microservices by defining your triangle into a catalog. The domains catalog makes it easy to find and share the microservices.

The OOPS in Object-Oriented Programming – Let’s Not Repeat that Mistake

Object-Oriented Programming (OOPS) attempted to achieve a similar level of reuse. Part of the problem of OOPS was the inability for teams to accurately run builds where linking was carefully managed from a central ‘common’ location.

To solve this problem, developers would add the ‘common’ object, like our login service, to their local repository so the build could use it. Their build would always reference that version of the library. Updates to the library would be private. There would be little (if any) contribution of updates to the ‘common’ version. This mistake could be easily repeated in microservices. That would be unfortunate and represent a failure in the implementation of a service-based architecture.

The question always is ‘how backward compatible is the new versions?’ Are we breaking any signatures on the methods? If we’re not breaking any of the interfaces, then can we consume those latest versions? And which application is consuming what version of a service?

For example, website B is going to use v2 of the login and website A will use v3. We need to track which Website is using which version. If you want to deprecate v2, it will require Website B move to v3. What is needed is a method for impact analysis to accurately make these types of decisions.

This tracking ability is key to a successful migration of monolith to microservice implementation and part of DeployHub’s Domain dependency management features. DeployHub is a microservice catalog tool that provides this level of tracking, versioning, and reporting to make every microservice deployment successful and visible for high-frequency updates.