Map Your Journey to Monolith Modernization
Breaking a monolith application into smaller, more manageable pieces has many benefits. Yet, decomposing a monolith application can be challenging as many are fragile and this task must be handled with care. As such, in today’s article, we’re going to share what resources you’ll need to modernize your monolith.
Think of this not as a recipe, but rather as the ingredients you will need to gather before getting started.
Gather Skills and App Knowledge
If your monolith is like many, dozens of coders worked on it over the years. In the process, it ballooned from an app with a singular focus to an app with many goals. In these cases, it’s helpful to gather as much tribal knowledge as possible about the app. Know where these resources are and marshal them internally before getting started. Their knowledge of the monolith’s dependencies and other nuances will be incredibly helpful on the journey.
While it’s important to have as much in-depth knowledge as possible about the monolith, it’s also imperative to have a team skilled in cloud native technologies like microservice architectures. If you don’t have these skills in-house, consider hiring a consultant who will teach your team how to fish while helping modernize the monolith.
Key questions to answer before getting started include:
- What is the desired outcome(s) of the modernization initiative? Is it reduced costs, operational efficiencies, greater innovation or something else?
- Do you have in-house resources with in-depth knowledge of the monolith? Who are they, specifically? Are they available to help with the modernization effort, and, if so, when/on what schedule?
- What depth of knowledge do your resources have about the app? Are any of these resources part of the original developer team?
- Last, can developers map the app’s services, dependencies, etc? Can they share where it is fragile and/or the limitations of technologies used?
Plan Your Route
Lewis Carroll once wrote, “If you don’t know where you’re going, any road will take you there.” Having a concrete plan and a defined path to monolith app modernization is critical to achieving your goal. Some approaches to monolith modernization offer fuller cost optimization than others which will result in better cloud ROI. For example, containerization will help you achieve functionality like auto-scaling and CI/CD capabilities whereas a completely serverless structure will take full advantage of the cloud’s elasticity and cost efficiencies.
Bear in mind that with greater benefits comes greater up-front investments. Therefore, a clear cost-benefit analysis should be completed to know which approach is best for your specific app and the benefits you hope to achieve.
Defining Modernization Criteria
Depending on the outcome of your cost-benefit analysis, there are three common modernization destinations. Note that this is not a linear exercise where you move from one square to the next, but rather one where you decide your destination based on a series of criteria and desired outcomes. Indeed, moving linearly is likely to cost you more in time and resources than if you were to leapfrog directly to your desired end state.
Infrastructure Automation
Sometimes also referred to as cloud infrastructure ready, this approach should be reserved for applications with low business value. We call these apps Sustain Apps as they serve to sustain the business rather than drive new revenue. (We refer to revenue-generating apps as Invest Apps.)
For these apps, infrastructure automation allows you to reinstall the app in the cloud on new VMs, allowing you to clear technical debt like configurations that accumulated over time and are no longer relevant. Simultaneously, this approach allows you to fold in new best practices — for example, growing security with new vulnerability detection.
Immutable Infrastructure
Also known as cloud services ready, re-platforming, or containerization, this approach allows the monolith to take advantage of cloud infrastructure, especially from the up-versioning of components like an OS or database. In the process of containerization, application code is changed to use base platform services like Amazon RDS and Amazon Elasticache, and advanced Amazon EC2 services like autoscaling and ELB. Replatforming is a good choice when the original development team is unable to help, and/or when the application is not a fit for advanced technologies like Lambda.
Serverless or Managed Infrastructure
This approach is also often called cloud-native or refactoring. It is ideal for the full modernization of monolith applications as it allows you to take complete advantage of advanced technologies like serverless and architectures like microservices. This path entails refactoring the services composing the application while retaining the business logic. The app is broken into different tiers and pieces with services, like databases, swapped out for the cloud service equivalent.
The new cloud native application has many benefits, including small, composable pieces that allow development groups to work autonomously and concurrently, thereby growing team utilization. Teams speed time to market with the help of advanced automation and codebases that have been split into individual services. And, unlike the original monolith, updates can be quickly pushed to customers. Last, risks are reduced as developers no longer need to understand the intricacies of the monolith codebase to avoid a change that could take down the entire app.
Just as a chef ensures they have all the ingredients on hand before beginning a dish, collecting these ingredients before you begin your journey to monolith modernization will help ensure success. Gather internal knowledge, obtain the appropriate technology and process skills, and determine the best path for your specific monolithic application based on cost-benefit analysis, and you will be ready to start the journey to monolith modernization.
Feature image via Pixabay.