When someone says they want to modernize an application for the cloud, what exactly do they mean? Users have one point of view: they hope the upgrade will bring improved experiences, higher reliability, faster performance, and ideally more frequent feature deployments. Architects, software developers, and devops engineers have different answers about what application modernization means. This is because there are several technical approaches to application modernization and the optimal choice is not always obvious.
For example, a workflow application used by dozens of users, written in the latest versions of Java and MySQL, can be easily lifted and moved to a public cloud. This approach requires little code rewriting, but likely requires configuration changes, updating CI/CD, and re-automating tests. On the other hand, if the same application is written in Cobol and runs on a mainframe, there is a good chance it will need an overhaul before it can run in the cloud.
There are still several technical options between lift and replace and full overhaul; these are known as the 7 Rs of cloud application modernization. There are slight differences from one source to another, but they represent the top-level upgrade options well.
Factors to consider
Organizations have hundreds to thousands of legacy applications, applications with significant technical debtand others with consumer or business migration benefits. Architects and technical managers often use different modernization approaches depending on business needs and technical challenges.
The first issues to consider are the impacts on business operations and consumers. Mission-critical applications with higher usage will require different technical approaches than episodic applications. Any upgrade will require communication with users, testing and training people on workflow changes.
Nita Putran, senior vice president of cloud and infrastructure at Persistent Systems, provides an overview of some of the business considerations when choosing application modernization approaches and roadmaps. She says: “One of the biggest challenges organizations face is identifying and knowing which applications need to be removed and moved, redesigned or rewritten and in what order. Application upgrades require careful balancing of speed to market with scalability, cost optimization, mitigating future technical debt and operational disruptions.”
Garth Fort, Chief Product Officer at Splunk, shares how devops teams benefit from application modernization. “There can be many benefits to cloud migration, including reducing costs, improving security and resilience, and making it easier to scale customer service delivery,” he says. “For devops teams, this can improve staff agility and productivity, allowing teams to focus on the customer experience.”
Devops teams and architects must review the business, technical, operational, and security factors of each application and then consider these approaches to cloud-modernize the application.
Retire applications that are no longer valuable
Still have applications to support dial-ups, faxes or other legacy ways of doing business? When applications perform functions that are no longer needed, the appropriate modernization strategy is to retire them.
Sometimes the decision to retire an application is clear: business users have agreed to close it, or retiring the application has no impact on business operations. But even when applications have low usage or perform a business function, their business value must be weighed against modernization and ongoing maintenance costs.
Amit Patel, senior vice president at Consulting Solutions, says, “To improve the user experience, companies need to consider retirement strategy. Moving away from outdated legacy applications creates improved efficiency, resulting in a better user experience for your customers. A reduced attack surface also leads to greater security.”
Replace apps with SaaS, commercial or open source options
Fort explains that replacement may be appropriate when proprietary solutions are no longer needed. He says, “Application replacement is when an organization stops relying on its own custom applications and migrates to pre-built third-party applications provided by a vendor and hosted in the cloud.”
Examples include customer relationship management tools, content management systems, or custom workflow tools developed when equivalent SaaS, commercial, or open source solutions did not meet business needs at the time. Today, business users may find better and cheaper third-party options than their own that need updating.
Move the application to the cloud
Applications that meet business needs and run on supported software stacks may be candidates for migration. Instead of running them on dedicated hardware or virtual machines, the architecture and devops team finds technical and business advantages by moving them to cloud environments. For example, it may be easier to configure development and test environments, automatically scale production, and configure disaster recovery environments with the application running in a public or private cloud.
But Bob Quillin, chief ecosystem officer at vFunction, says, “Migration doesn’t mean modernization.” He explains, “There are devops benefits that can be achieved with the lift-and-shift method of migration. Almost all companies make short-term profits, but the mistake many technology leaders make is to believe that the work stops there.”
The move can provide infrastructure flexibility, improved security, and cost reductions, but it doesn’t address application and core code maintenance issues.
“Here’s the reality: the cloud monolith has the same hard problems it had on-premises — slow engineering speed, lack of scalability, and difficult maintenance,” Quillin explains. “This phase is known as ‘lift-and-shift regret,’ as costs rise and the benefits of the cloud are still out of reach. To dispel this myth, migration must be seen and planned in the context of a larger, more strategic modernization strategy.”
Replatform components that have operational advantages
Many interpret “lift and move” as a migration option that requires minimal involvement from the development team and will not need to upgrade code or major configuration changes. The hope is to get some benefits from the migration without the added work and cost of re-engineering the code.
But between the code and the infrastructure are database platforms, frameworks and components – and opportunities to re-platform them during migration. Although a new platform usually requires developers, it may not require significant code changes, especially when stock, standardized, or near-equivalent platforms are replaced in the stack.
Tomer Sheeran, co-founder and chief product officer at Dremio, shares one example. “Instead of picking up and moving a legacy data warehouse or data lake to the cloud, cloud migration introduces opportunities to adopt open lake architectures and networked data approaches to data management.”
Cloud architects can modernize data warehouses and data lakes to deploy them as public cloud services, offering operational and cost benefits. Other replatform options include migrating service buses, moving to an organization’s standard CI/CD tools, or changing content delivery networks.
Reuse, refactor or rebuild applications that offer long-term business impact
Once architects and devops teams decide to upgrade code as part of application modernization, they have several options:
- Reuse the application’s existing data models, services, and APIs, but redesign the user experience.
- Code refactoring to improve performance, security, maintainability and other non-functional upgrades.
- Rebuild modules and capabilities to improve functionality, fix defects, or reduce technical debt. Some will restructure monolithic applications into microservices.
Which approach is best for your application? Patel shares his perspective: “The restructuring and re-architecting strategy, although the most expensive approach, should be considered when companies want to move to a more agile devops model. This strategy also supports continuous innovation, ultimately helping to increase productivity.”
Devops teams can also consider phased approaches. For example, they can first re-host applications running on supported platforms to gain the operational benefits of running them in private or public clouds. They can then consider reusing low-usage applications that are not upgraded frequently and re-architecting other applications where there is a business need for frequent improvements.
Application upgrades are not without cost or risk. For organizations with thousands of applications, it can take years to fully modernize the portfolio. Devops teams and architects must use the lens of practicality and review all factors before choosing an application modernization strategy.
Copyright © 2022 IDG Communications, Inc.