Migrating application from Monolithic to Microservices
What is a Monolithic application?
An application built as a single deployable unit. (a monolith) is often associated with a database, an API backend layer and a client-side user interface.
What is a Microservice
A microservice is a single service that is built to execute a specific application feature. In the microservices based architecture, the application is the distributed combination of multiple services, each having a specific goal. Each microservice is completely functional on its own and deployable independently.
Each microservice is loosely coupled and it interfaces with other microservices through well-defined APIs.
Why should you migrate from Monolithic to Microservices?
- You have an existing web application that is hosted on a monolithic platform and that you want to modernize.
- The goal of migrating to microservices architecture is to provide a more robust and scalable environment for individual features of the application, so that they can be more easily managed and updated
- This leads to faster improvements on each migrated feature, providing users with value along the way.
- The migration can be done feature by feature, in order to avoid a large-scale migration event and its associated risks specially if the existing application is in production.
- This makes the application easier to understand, develop, test, and become more resilient to architecture erosion.
- Microservices architecture enables parallel development by small autonomous teams.
- They can develop, deploy, and scale their services independently.
- Since each microservice is independent, architecture of an individual service can improve through continuous refactoring.
- Microservices-based architectures enable continuous delivery and deployment.”
Different ways we can undertake migration
1. Lift and shift
In a lift and shift approach for migration the features from a monolithic application are shifted to a microservices based target application with very few modifications or code refactoring. Goal is to make the feature functional as-is in the target application with minimal changes. This migration will require the least amount of time and the amount of refactoring is kept to a minimum.
Lift and shift migrations relatively easier to perform because there is no need for new expertise and your team can use the same set of tools and skills. These migrations also support off-the-shelf software. However, they do not take full advantage of cloud platform features, like scalability and other factors because we are doing only minimum changes.
2. Improve and shift
In an improve and shift migration, the application features are individually upgraded or modernized and resulting refactoring is done while migrating it.
The modern features can take advantage of cloud-native capabilities, and not just to make them work in the new environment but also to improve performance, features, cost, or user experience. If the current architecture of an application feature is not supported in the target environment on its own, then refactoring is necessary to make it adaptable.
You can also add major update to the workload is necessary in addition to the updates you need to make to migrate and also improve scalability and high availability. You can also architect the improvement to increase the portability of the app.
3. Rip and replace
With this approach, an existing application feature is complete. It redesigned and re-written from scratch. The existing application is decommissioned.
Since you are writing the new application from scratch, it will take full advantage of the modern Cloud features, such as horizontal scalability, managed services, and high availability. You can also add all the pending features from the existing application and add them to new app.
However, such kind of migrations are relatively lengthy. You need to evaluate the extra efforts redesign and rewrite the app as part of its lifecycle.
You team also needs to gear up with upgraded skills and add new tools required.
Microservice for New Applications
- One common advises to start a new solution is always to start with a monolith, keep it modular and split into microservices once the monolith becomes a problem. This makes your progress fast in the beginning especially if your team is small and you do not want to deal with challenges of the microservice architecture.
- However, developing such a well-modular application can be a problem since it is hard to keep modules isolated from each other as you would do it for microservices (see Stefan Tilkov’s article about that). Microservice architecture naturally forces you to develop well isolated services, but in a modular monolithic application it’s easy to tight couple modules to each other and design weak module boundaries and API contracts.
- ABP.IO framework can help you in that point by offering a microservice-compatible, strict module architecture where your module is split into multiple layers/projects and developed in its own VS solution completely isolated and independent from other modules.
- Such a developed module is a natural microservice, yet it can be easily plugged-in a monolithic application. All standard ABP.IO modules are developed based on this guide. So, you can use these modules by embedding into your monolithic solution or deploy them separately and use via remote APIs. They can share a single database or can have their own database based on your simple configuration.
