Debunking the Top Monolithic Application Myths
Monoliths are mysterious entities by definition. Across thousands of global organizations, monolithic applications often standalone, side by side, like their Stonehenge brethren — architectural masterpieces of the past evoking both awe and mystery. But unlike their prehistoric equivalents, monolithic applications are integral parts of today’s modern business fabric and key contributors to every business-critical process, from back office to supply chain to customer service to commercial engagement and more.
While these monoliths continue to contribute mightily to the business, the modernization of these applications is an ongoing source of frustration and pain. Many organizations have simply given up while others have migrated the entire monolith to the cloud as a stopgap via rehosting or replatforming — the old “lift and shift.” But it’s 2022, and there’s new hope, new tech and new approaches that are breaking down the myths that surround monolithic applications.
Myth #1: Monolith Modernization Is a Lost Cause
Every cloud provider, cloud native platform and system integrator has a model that includes virtually all the “R’s” in the modernization lexicon. Originally, the industry started with just five R’s of modernization: rehost, refactor, re-architect, rebuild or replace. As modernization matured and more consultants got involved, so did the number of R’s, including replatform, rewrite, retain and retire. It’s confusing because the practice of modernization has been more art than science. There’s been little data, mathematics and automation applied to the process of modernizing a monolith. There are books and best practices plus many consultants and solution architects willing to advise and deliver. These are great starts but typically are either focused on DIY (do-it-yourself) approaches or expensive, risky outsourced engagements.
All is not lost. There’s a new wave of tooling, applied AI and automation being applied to bridge the gap between all-DIY or all-outsourced options. The basis of these approaches is based on actual architectural analysis of the monolith, not just the underlying platform components that need to be migrated to new versions, but the actual business logic itself. The business logic is the meat of the application and where architects can begin to identify the domains that can lead to clearer microservice domain-driven designs. At a minimum, these represent more independent mini services or just plain services that operate with higher degrees of exclusivity. The lack of a foundational data-driven approach has led to application teams bailing out of modernization and choosing a migration tactic as a stopgap solution, which leads us to Myth #2.
Myth #2: Migrating Monoliths to the Cloud = Modernization
Migration of your applications to the cloud is a compelling objective and a “moonshot” vision that rallies IT and app teams to a greater goal. But to be clear, migration does not equal modernization. There are tremendous DevOps and data-center reduction benefits to be gained in a lift-and-shift migration of a monolith to the cloud. Almost all organizations achieve these short-term gains and in turn provide a windfall for cloud providers looking to accelerate and simplify the movement of enterprise workloads to the cloud. The mistake many technology leaders make is believing that their job is done — we are now modernized!
This myth is getting quickly busted: It’s now clear to most organizations that a monolith in the cloud has most of the same thorny issues it had on premises — slow engineering velocity, lack of scalability, difficult maintainability and low sustainability. Many call this phase “lift and shift regret” or “migration remorse” as costs start to rise and cloud benefits are still out of reach. To bust this myth, migration must be viewed and planned in the context of a larger, more strategic modernization strategy — migration is fine as long as it’s a steppingstone to a fully modernized monolith. The modernization of a monolith enables it to take advantage of the full value of cloud native architecture from containers and microservices to Kubernetes and serverless. Throw in the benefits of leveraging common CI/CD, security and DevSecOps policies and platforms, and your business case falls quickly into place, which leads us to Myth #3.
Myth #3: Building an Accurate App Modernization Business Case is Impossible
For most organizations, the most difficult part of application modernization is building an accurate business case for modernization projects. We’ve explored one of the missing elements to solving this problem in Myth #1: the lack of a data-driven foundation to the discussion between architects who are forecasting time and effort and the business leaders approving budget and resources. That lack of a common language and basis for measurement has resulted in a two-way breakdown in trust between leadership and management. Breaking that cycle requires data and measurement to start.
Start with an analytical measurement of the complexity of the monolith and the risk involved with changing the monolith. To understand complexity, this requires first identifying the communities or clusters of dependencies, which indicate where domains are evident and hence where microservices could be extracted. Complexity can be then calculated by the degree to which class dependencies are entangled between themselves, reducing the level of modularity of the code. Risk can be measured by the length of dependency chains, which determines how likely a change in one part of the application will affect an unrelated part of the application downstream. These all can roll up into an overall technical debt score, which reveals how much is currently being spent on debt versus innovation and thus the ROI and TCO business case benefit of a modernization project. From this strong quantitative position, business priorities are much easier to agree on, which leads us to bust Myth #4.
Myth #4: All Monoliths Are Created Equal
Monoliths come in all shapes and sizes, of differing business values and vastly different complexities. In fact, a monolithic architecture can be a relevant modern design model for a variety of use cases. A simple first step is to stack rank your monoliths by their business value today. Evaluate their business utility and engineering load, feature backlog and maintenance costs. Typically, these should be consistent in that the size of the team, the number of backlog features and the maintenance costs should line up with the business value of the enterprise monoliths. In fact, those monoliths resist the “legacy” label as they are still first-class citizens for the business and the engineering teams that support them. An aging monolith with dropping business value is a great candidate for simple replatforming or eventual retirement.
With the applications that are still viable business contributors, it’s essential to then fully assess their complexity and the risk associated with modernizing them (see Myth #3) to craft the best plan and thus a more accurate business case. By calculating the complexity, risk and resulting technical debt across these business-critical monoliths, you can move the less complex into faster application-modernization projects using AI-based automation tools to accelerate the process. The more complex monoliths — often termed “megaliths” — will take more time and should follow a more iterative refactoring approach to selectively extract one or two microservices at a time using a strangler pattern to switch control from the monolith over to the new services. These monolithic applications can exist anywhere, even in the cloud, so on to Myth #5.
Myth #5: Monoliths Are an On-Premises Problem
Granted, most of today’s monoliths still exist on premises, firmly anchored to their original infrastructure. But a growing number of monoliths have been successfully migrated to the cloud, where they now run in the IaaS infrastructure of the cloud provider, using the power, CPU, and memory of the provider, but unfortunately still operating as a monolith. These monoliths in the cloud might run successfully for a while, but when scalability issues arise, the only solution is to buy bigger and bigger images — more CPU and more memory — at more and more expense. These may require more expensive reserved instances that the cloud engineers consistently have to run at red-line levels — no elasticity, no horizontal scalability.
The same data-driven assessment methodology and prioritization approach described above is completely relevant to these monoliths in the cloud, perhaps even more so. Why? Data-driven assessment, AI-enabled modernization and post-migration refactoring are key competencies all solution and software architects require. A monolith in the cloud is so close to fully realizing its modernization destiny. The container, Kubernetes, DevOps, serverless and service mesh services are ready to fire up on the cloud provider as soon as the monolith refactoring process completes. Just untangle that monolith; see Myth #6.
Myth #6: Monolith Dependencies Are Impossible to Untangle
Architects tasked with maintaining, let alone modernizing a monolith under their responsibility, face a daunting challenge. Most times, they are not the original architect or developer, and even if they were, the monolith evolves over time, taking on more and more technical debt that can bury much of the original intent. Analogies abound for these tangled and dense monoliths: balls of mud, spaghetti code, birds’ nests and tangled balls of string. If you’ve ever spent hours untangling your holiday lights or fishing-line spooling disasters, you know the challenge.
AI can actually help here. When a system can express a monolith’s deep dependencies as a graph, graph machine learning can detect clusters and linkages that form potential communities of domain activity — which enables a range of benefits, from understanding complexity and risk of change to actually detecting potential microservices and boundaries between communities. Building the graph and models that support it requires a blend of dynamic and static analysis, but the end result is a much more efficient and effective modernization effort. Impossible monolith modernizations become possible, and they can become much more predictable and faster, leading to our final myth.
Myth #7: Monolith Modernization Takes Forever
After busting the six myths above, it should be clear that time and budget should be less a factor in what you modernize if you follow the recommendations. Now, the discussion should be what you should modernize that leads to business benefits and outcomes. Clear assessment and data-driven planning should also shape the way you approach modernization. The applications with higher complexity scores should follow an iterative, selective refactoring strategy, where the less-complex business-critical monoliths can move much more quickly through the process.
For the past decade, application modernization has been a people-intensive best practice, requiring broad training and cultural, organizational transformations. These practices are critical skills, but the lack of automation and enablement tools has slowed the process to a standstill due to skill gaps and failure fatigue. New tools are here that embrace these methodologies and raise them to new levels through AI and automation. The next step is to deploy a continuous modernization methodology that plugs into a CI/CD pipeline and detects and fixes technical debt throughout the life cycle of an application. The vFunction platform was purpose-built to help architects in their assessment and modernization projects and to bust the most monolithic of myths.
