Application modernization using microservices architecture
Scope of this white paper
A business is comprised of many processes and in turn requires diﬀerent types of applications to support these processes. The IT landscape of any business is complicated and integrated with each other serving various business needs. As businesses grow and their customer base increases, new lines of businesses are added which stretch the existing IT applications and infrastructure to their limits. The older systems start displaying resource limitations and became costlier to scale and maintain. This results in a lack of agility to respond to changing market needs and calls for enterprise application modernization. Legacy applications typically are monolithic with a 3-tier architecture which results in the lack of agility and scalability. Today, microservices architecture is commonly used for digital projects as well as application modernization. This white paper, will talk about application modernization by using microservices architecture and the implementation approach.
Software is moved to a service oriented architecture to cater to evolving business needs. Gradually, applications became too huge to manage with various integrations as it evolved to support all business areas. This also made it necessary to modernize the hardware with virtual machines. In spite of the SOA’s promise, it is becoming a bottleneck for application scaling as it is unable to meet the workload needs and basic requirements like on-demand scaling, reduced testing cycles, cost reduction and faster time-to-market.
Decompose the monolithic application
How to start
Let us consider a monolith Java application and try to analyse the problem ﬁrst. The EAR (Enterprise Application aRchive) of the application has grown signiﬁcantly and building, deploying, or testing has become time consuming. This is resulting in multiple down times and performance degradation with a lot of temporary patches added as a quick ﬁx solution
Lift and shift
As a ﬁrst step of the analysis, tear down the EAR ﬁle and see how many WAR ﬁles it contains. Check if any of the WAR ﬁles can run decoupled from other applications. If yes, try to deploy and scale it with modern scalable infrastructure. Next, break the WAR and check if it has multiple JAR ﬁles, which contains services that can run independently with or without a few modiﬁcations. If yes, as it may have been built based on SOA principles, containerise them and scale it if required. This approach is termed as ‘lift and shift’, with maximum re-use of the existing source code.
Microservice architecture has evolved from SOA principles where a big application is divided into a collection of loosely coupled services that interoperate and scale to serve both the functional and non-functional needs. Now, the question is how to decompose the monolith application, which did not meet the business needs by lift and shift. Let us be open minded - apart from the common approaches, conclusions, and best practices available, it is ok to deviate from them if a speciﬁc application demands it. This section of the white paper discusses patterns to decompose the existing application
Domain driven design
The migration of a big monolithic application to a microservice architecture is a promise made by IT to business to reduce cost, increase operational eﬃciency, and gain competitive advantage. Architecture design holds the key to success with a forward-looking vision with a 5 to 8-year timeline. In domain driven design approach, we divide the functionalities based on the domains they serve with a bounded domain context where the entities talk to each other. This way, we can deﬁne a clear set of domain objects [aggregates] and the entities and avoid chatty services. In subdomain decomposition, we will go a step deeper, where we decompose the applications based on subdomains in each business domain with loosely coupled services adhering to common closure principle. For example, a business in the manufacturing and retail domain, may have major domains, such as manufacturing, warehouse and retail. In retail, it may have order, price, customer, loyalty, etc.