Scope of this white paper
A business is comprised of many processes and in turn requires different 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 first. The EAR (Enterprise Application aRchive) of the application has grown significantly 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 fix solution
Lift and shift
As a first step of the analysis, tear down the EAR file and see how many WAR files it contains. Check if any of the WAR files 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 files, which contains services that can run independently with or without a few modifications. 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
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 specific 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 efficiency, 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 define 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.
