The typical portfolio for an enterprise includes about 1,000 applications. They can go as large as 11,000, as Dave McCann, vice president at Amazon Web Services (AWS) with responsibility for AWS Migration, Marketplace, and Control Services, recently informed the audience at FutureStack19. Most include a mix of custom-built and off-the-shelf software, and about 80% of them will soon move to the cloud, said McCann. Looking just at the 10,000 largest AWS customers, that adds up to 5-6 million applications.
Those migrations, in turn, will require businesses to make millions of choices about the best approach to modernizing each application — from deciding whether or not to make code or architectural changes, to prioritizing opportunities to improve performance. Whether organizations have a handful of applications or thousands, the choices they face may seem overwhelming.
Here is a three-step guide to follow to help customers and partners successfully implement on their application modernization journeys.
1. Determine your business strategy
True modernization requires an organizational shift in mindset. It requires a flush of processes and procedures and incorporating new ways of thinking. It requires supporting DevOps principles, it requires thinking dynamically about resources, and it requires service-oriented team ownership principles to enable application scalability.
While there are many approaches towards migrating your application that AWS suggests, true application modernization requires a more thoughtful approach:
- Rehost. Simple rehosting of your application requires the least effort and achieves the least benefit. It’s the 'lift-n-shift' approach discussed above.
- Replatform. Additional benefits can be achieved by moving key components of your application to managed services in AWS. This might involve moving your database to a managed database, or moving to other SaaS- or IaaS-based managed services.
- Refactor. The greatest benefit is achieved when you rearchitect and rework your application to take advantage of new technology and new methodologies. This might involve moving toward a service-based architecture, incorporating serverless technology such as AWS Lambda into your application, or using other cloud native capabilities.
Keep in mind that modernization strategies should be iterative and a different strategy can apply to different portions of your application. Companies can start with one approach, reap some initial benefits, and then continue to modernize through other approaches to obtain more benefits. Each modernization step should include a way to measure its value to the business. And each step should also move the needle on your pursuit of digital transformation — along with the culture, process, and technology changes that must happen as part of it.
2. Gather data to inform business decisions
The next step is to get a clear understanding of each application and its interdependencies. To do this, take baseline measurements to help teams understand how each application performs in its current environment, how they behave under different load patterns, what is the experience that users of the applications are going through, and how does all of this relate to underlying infrastructure performance. A key factor that is commonly overlooked is a deep dive into the type of errors that are occurring within these applications and investigating why they are happening. For applications that drive critical business KPIs, getting a clear baseline that shows the correlation between the business KPIs and the underlying technology performance needs to be looked at as well.
This gives companies the foundation for making informed, data-driven decisions as they develop their modernization roadmaps. Otherwise, teams would just be relying on guesswork, anecdotes, and ‘gut feelings’ to understand how an application is functioning now — and whether or not modernization would improve it.
3. Weigh the tradeoffs
Next, companies need to identify and understand the risks and benefits of each approach — from the relatively lowest risk/lowest benefit choice of rehosting to the highest risk/highest benefit approach of refactoring. There may be situations where teams want or need to take a component of an application and modernize it in the cloud. An excellent example would be to replace a legacy relational database with a combination of a caching solution backed by a cloud native database, when the application makes thousands of similar calls to the database layer during the course of a transaction.
In general, companies need to consider the time, cost, complexity, and risk of each modernization approach in comparison to the improvements and outcomes they can achieve — agility, scalability, reliability, performance, better customer experience, reduced costs, reduced management efforts, and more.
Mitigating risks and optimizing outcomes requires proper planning, informed data-driven decision making, and the adoption of best practices such as the pillars found in the AWS Well-Architected Framework (WAF).
The ebook, The Enterprise Guide to Continuous Application Modernization, explains how ‘lifting and shifting’ legacy applications to AWS doesn’t automatically result in applications that can take full advantage of the elasticity, resiliency, ease of deployment and management, and flexibility that the cloud offers. You must do more than lift-n-shift in order to truly take advantage of the cloud and truly modernize your application and your company.
It’s important to set a framework that helps companies clearly identify the impact of the changes that they are making. Carefully measuring the KPIs that they establish during the baselining process will provide a clear and concise view. With modernization, there are many decisions to make, but taking a data-led, best-practice approach can reduce risks and optimize outcomes. I’d like to hear your thoughts — feel free to comment below — on how you plan to leverage these best practices to make the most informed decision possible as you move to the cloud.