This post was originally featured on TheNewStack, sponsored by vFunction.
As digital natives and startups continue to leverage microservices, Kubernetes and cloud platforms like AWS, Azure, and Google Cloud Platform, enterprises who are still maintaining and running business critical monolithic applications face a distinct disadvantage.
Tightly-coupled, interdependent, complex Java EE or .NET applications were never designed to deliver on the advantages of cloud-based microservices architecture, such as elasticity, scalability, increased engineering velocity, and faster release cycles.
In working with software architects around the world across hundreds of monoliths and tens of millions of lines of code, vFunction has identified three must-have competencies for enterprises looking to select, accelerate, and execute the right continuous modernization strategy for their monolithic applications.
- Data-Driven Assessment: Teams that are struggling to prioritize which applications to modernize and build accurate business cases for those projects require very specific data that can guide them through this process.
- AI-Enabled Modernization: Applications architects who are already struggling with a massive monolith modernization project need new tools that can help automate painful decomposition and iterative refactoring processes.
- Post-Migration Refactoring: Migrations that simply lifted and shifted their apps to cloud platforms like AWS, Azure, or Google Cloud, become quickly disappointed with the lack of cost savings, elasticity, and engineering velocity.
Let’s look at these three modernization competencies in more detail.
Read More: Migration Strategies Basics: Lift and Shift, Refactor, or Replace?
Modernization Competency #1: Data-Driven Assessment
Organizations with a broad application estate are faced with many instances of monolithic applications across their business environments. Most likely these existing applications have complex class and resource interdependencies across business domains.
Most organizations faced with modernizing a broad application estate are finding themselves with more questions than answers at this point. Where to start, which application to target first, and what’s the ROI are the primary questions. You need to start with actual modernization-focused data collected from your applications.
Without detailed data that can measure technical debt, complexity, and risk, most teams suffer from “analysis paralysis”, where precious time is wasted on collecting data irrelevant to actually modernizing the applications. This leaves teams frustrated by the inability to find a clear path forward because they are unable to determine the primary target applications and the related ROI and business cases to support kicking off modernization initiatives.
Questions to ask
- Which applications should be targeted first?
- Which applications should be retired or discarded?
- Which applications should be rewritten or refactored?
What the Experts Say
“To start the process, you should select applications for modernization that have high business value and are carrying significant technical debt. Specifically, these applications should be ones that are still very actively developed on the one hand, but that the development process for them is the least effective (e.g., new features, release cycle time, etc.), on the other. This is quite a challenge since the visibility into the former is not trivial and measuring the latter is even trickier.”
-Ori Saporta, Chief Architect and Co-Founder of vFunction, Inc.
Read More: What is Refactoring in Cloud Migration? Judging Legacy Java Applications for Refactoring or Discarding
Modernization Competency #2: AI-Enabled Modernization
After selecting a monolith to modernize, the next challenge is actually refactoring and re-architecting an application that can easily have over 5 million lines of code and 5,000+ classes. The dense dependencies and lack of architectural visibility make progress slow and tedious.
One approach is to target the easier, “low-hanging fruit” services first–but unfortunately after that, modernization velocity tends to significantly slow down due to system complexity and the risk of making impactful changes. Without an intelligent platform that can surface hidden business domains and tangled interdependencies to suggest a path forward, these projects most often slow down, stall out, or are fully abandoned altogether.
Faced with slow progress and no automated tools to help, teams often experience decreasing morale as the modernization project begins to stall, and a catalyst is needed to help accelerate the velocity of their initiatives and rekindle team energy and focus.
Questions to ask
- Which domains currently exist in the monolith but are otherwise hidden?
- How does making changes to a class impact other system components?
- How can I selectively refactor one or more critical services and iterate through my monolith?
What the Experts Say
“When it comes to these huge legacy applications, it is usually very clear to the organization that refactoring is required. The issue then becomes not if, but how to get started. Existing solutions are seriously lacking in providing the necessary insights into the inner workings of the existing code base. This applies both to how classes are dependent on each other in theory (static analysis) and also how these dependencies come into play during the actual runtime of the application. With this information, they can then proceed to pick specific workloads to extract and test with confidence that they are not “missing” anything.”
-Ori Saporta, Chief Architect and Co-Founder of vFunction, Inc.
Modernization Competency #3: Post-Migration Refactoring
Migrating a monolith to the cloud–often called a “lift and shift” migration–should be the beginning of your modernization journey, not the end goal. Whether you simply re-hosted in the cloud or re-platformed your application, migration remorse kicks in when you see rising costs with no increases in development velocity or scalability.
Using the lift and shift migration strategy, many organizations have been able to move functionality onto a cloud platform and even containerize their monolith. Parts of the application are now running in the cloud, much to the relief of executive teams with a cloud readiness mandate to achieve.
This rarely solves their core challenges or leads to meeting business objectives–after all, they’ve now just shifted what is still a monolith into the cloud. Lifting and shifting may solve some tactical concerns–such as alignment with DevOps best practices and improved security–but fails to deliver on the primary benefits of full application modernization for the cloud, like development agility and velocity, quicker release cycles and scalability.
As frustration among system architects, software developers, and senior managers on the hook for the cloud migration continues to build, it makes sense to strategically refactor your legacy application’s business logic into decoupled, isolated microservices.
Questions to Ask
- For which applications was the lift and shift strategy adequate or not?
- Which expected benefits of the cloud are you missing?
- Where can you begin to leverage the elasticity and native scalability of the cloud to scale out one or more specific services versus the whole monolith?
What the Experts Say
“You are already in the cloud–great step one. And you now have access to hundreds of new cloud services that you unfortunately can’t access since you are running a monolith on a simple IaaS image–basically using the cloud provider’s compute capacity versus your own. Leverage the momentum of a successful migration as quickly as possible! As an architect, start with an assessment (see Competency #1) to lay the groundwork and build a data-driven plan. Next, select one or two key services (see Competency #2) that will benefit your business or your architecture by removing from the monolith, perhaps allowing you to scale, add new APIs, and share with other applications. So many container-based or serverless services are now at your fingertips and easily accessible to you from your cloud provider–the time to modernize is now!”
-Bob Quillin, Chief Ecosystems Officer at vFunction, Inc.
Read More: Flip the Script on Lift-and-Shift Modernization, with Refactoring
The Path Forward – Migration vs Modernization
When considering next steps, it’s useful to determine whether your team is able to move forward by migrating or modernizing. The differences here are important to understand:
- Migration strategies, such as lifting-and-shifting, present a more tactical approach that is generally more short-term in nature, similar to patching software without fundamentally changing the code or its architecture.
- Modernization strategies, such as rewriting, refactoring or rearchitecting, take a more long-term approach, requiring code modifications, deep engagement from architects and developers, and executive buy-in for the project plan.
To decide the best path, forward leverage Competency #1. Architects and decision-makers should begin with vFunction Architectural Observability Platform to assess the technical debt of their monolithic applications, accurately identify the source of that debt, and measure its negative impact on innovation. These insights will help teams early in the cloud journey to determine the best strategy moving forward.
Using vFunction Code Copy, architects can exercise Competency #2 and automatically transform complex monolithic applications into microservices–utilizing both deep domain-driven observability via a passive JVM agent and sophisticated static analysis–by analyzing flows, classes, usage, memory, and resources to detect and unearth critical business domain functions buried within a monolith.
Whether your application is still on-premise or you have already lifted and shifted to the cloud (Competency #3), the world’s most innovative organizations are applying vFunction on their complex “megaliths” (large monoliths) to untangle complex, hidden, and dense dependencies for business critical applications that often total over 10 million lines of code and consist of 1000’s of classes.
You can request a demo of the complete vFunction Platform for you and your team.
