An application modernization initiative can deliver tremendous business value. Reducing technical debt can move people from their day-to-day toil, into engineering work that moves the company's bottom line. Injecting security early in the software development lifecycle can reduce the company's risk. And higher velocity software deployments allow companies to test new ideas with their customers more rapidly, which can become a competitive advantage.

But the idea of modernizing fleets of applications might cause anxiety. The application landscape in some environments may feel like a delicate dance between components. Often, administrators carefully make approved changes in hopes that the change won't affect other services. It feels uncomfortable to even think about making lots of small changes frequently, but this is a critical part of modern application delivery.

In this blog post, we'll explore the journey you might be undertaking and where VMware can help with your app modernization initiative. In the sections below, I'll break down some common milestones for modernizing your application portfolio. As you dive into each of the steps below, remember that these steps can be completed on a subset of your entire application portfolio. These steps would come into play for whatever applications are in-scope for your modernization efforts.

Discover

The discovery phase of modernization is often skipped by companies in attempts to go faster. It might also be the most crucial part of the process. Without completing this phase, you are often working on assumptions with little understanding of the current reality. These assumptions will manifest into risks to the project, so it's important to eliminate as many assumptions as we can during this phase.

Gather some data about your applications.

Do you know:

  • Which applications are the most troublesome for your users or customers?
  • Which applications require the most updates over the course of a year?
  • Which applications accrue the most downtime?
  • Which applications are dependent on each other for proper operation?
  • Which applications will require new licensing or support contracts?
  • Which applications have similar archetypes?
  • Which applications haven't had any code updates in the past twelve months?

This data is critical to planning your application modernization process. Data found during discovery can be used as business justification for app transformation. The data collected would help you:

  • Identify software that should be retired and save you on support
  • Find software that loses business due to poor customer satisfaction
  • Locate software that hasn't been getting patched and is a liability
  • Find a way to reduce outages by updating troublesome apps
  • Find apps that are running cost effectively in their current form and don't require updating

It's worth it to spend a little time up front to prevent re-work down the line. Understanding what services communicate with each other can be very complex. Identifying and mapping this complexity is paramount to how your modernization program is designed and scheduled. Trust me on this one, finding your application dependencies before you start rebuilding or moving your apps, will really feel worth it when you're migrating applications. Unraveling a dependency problem after a cloud migration can become a real headache, costing both time and money to resolve.

How can VMware help-

VMware has several options to help with the discovery process, which can take as little as a few weeks of effort to complete. vRealize Network Insight (vRNI) and Application Transformer for VMware Tanzu can both be used to get a view of the application landscape. vRNI can identify those dependencies and remove your own assumptions about what applications are talking to each other. Application Transformer can help you identify and categorize your applications and their patterns so you can plan your modernization waves or phases.

Plan

Once discovery has concluded, the result can be combined with business goals to determine the modernization strategy. During this phase you're making a lot of decisions that will set the tone for the delivery steps.

How will you decide which apps to modernize?

Modernizing all your applications is time consuming. You will have to choose which applications to start your modernization efforts with. Often, we recommend starting with applications that have the highest business value and lowest technical complexity. This provides you with an opportunity to gain quick wins while doing tasks that matter from a business perspective. This also gives you an opportunity to start building these new Modern Apps muscles for your next set of apps.

Here are some common areas where companies will focus their efforts:

  • The top revenue generating apps
  • The apps with the most overhead
  • Apps from a specific business group
  • A specific availability tier of apps
  • The easiest to modernize

How will the apps get modernized?

Each of the applications may have a different modernization method. Tools like App Transformer can categorize your applications into archetypes so instead of dealing with 100s of applications, you might be able to deal with 10s of types of applications, or at least a more manageable number. Those archetypes will still need a method for their application strategy.

During this decision, you'll likely group your applications into their own modernization journey. Will they be refactored completely? Will they move to new hardware or cloud? Will they be re-platformed to a managed service? Or will the app be retired because it's not adding business value and is consuming IT resources?

Where will you define your Landing Zones?

You know what you want to do with the applications, but you're not sure where you'll modernize them. We often refer to these locations as landing zones as they define where an application archetype will "land" after it's been modernized. You've decided some of the applications are going to use a specific cloud provider's capability, so you know where they're going. But what about the others? If we're working with a hybrid cloud environment, those dependencies are going to be critical. You probably want to prevent having a slower WAN connection between your dependent apps, so moving one app, may have consequences for other applications.

How will the applications be operated?

If you're modernizing your applications, there's a good chance you need to modernize the way you operate those applications too. Do you still backup the app the same way if it's in a container vs in a virtual machine? Do you deploy and patch your applications the same way in their new form? Do you monitor your applications with an agent or some sort of scraping method? The fact of the matter is, a container and a virtual machine are deployed, monitored, patched, and backed up, using very different techniques.

How about a scenario where your application isn't being changed at all, but rather the way you operate that app is the thing that's changing? A manually updated virtual machine that requires monthly patching, vs a virtual machine built from scratch each month through code would seem like modernization to me, even if the app is the same architecture. Our goal here is to make positive improvements to the way the applications are run to improve deployment time, decrease risks, or reduce failures, regardless of the architecture of the application.

How can we help-

The VMware Application Navigator is a consulting engagement that can not only help gather discovery data but also use that data to streamline your approach. Leveraging these industry consultants is a great way to avoid unforeseen pitfalls in your strategy and quickly get you into an execution phase.

The VMware Application Navigator team will help you identify those modernization opportunities and break through the analysis paralysis to create an action plan for your application portfolio.

Deliver

Modern applications are modern, simply because they were created using newer technology or processes. Newer means that not everyone is familiar with them and that means you're going to break stuff. You could be learning containers over VMs. You could be learning GitOps processes vs your more familiar ClickOps processes. The delivery phase is where you'll really begin to learn how to modernize and use the new applications.

Your first apps will feel like a challenge to implement, but also a rewarding experience. The skills you learn during the migration of applications, setting up Kubernetes clusters, and re-platforming your applications will aid you in your operational tasks that lie ahead. Some of these new deployment strategies that you've learned, will also become your patching or disaster recovery strategy in the future. So, while you're here, be sure to move fast and break a few things. You're learning and you should factor that into the process.

How can we help-

You may find this phase challenging simply because of the number of new things to try to learn and implement. VMware has a variety of free resources available to the public to level up their skills on things like Kubernetes and VMware Tanzu.

If you'd like a more guided approach, a VMware Tanzu Labs engagement may prove more useful. During this engagement, VMware engineers will help you setup infrastructure, teach you how to operate containers, help you re-factor your applications, or a combination of these tasks. Use the Tanzu Labs engineers to help prepare your Kubernetes environments for production; complete with logging, monitoring, security, and management techniques, to get you ready to host applications.

Operate

It might seem like the hard part is over once you've gotten past the refactoring or migrating part. But day 2 operations of a modernized system are not trivial tasks. They involve distributed and asynchronous execution of tasks across tiers of cloud. Being able to observe the environment holistically will become an important piece to being able to operate the landscape effectively.

Operating your new application landscape will pose its own challenges. Now you're tasked with operating different types of application architectures. You're working with different tools that are better suited to your new application patterns. You're adapting different processes so you can update your applications during production hours without a change request. And you're even trying to manage the security, and governance of multiple clouds, each with different ways of interacting with them.

How can we help-

VMware has the right tools to help you manage the swath of applications you'll need to manage in a modern IT landscape. Running containers on Kubernetes and have a VM footprint? Consider VMware Cloud on AWS as a landing zone to manage both types of architectures, in a familiar console, with less re-skilling necessary to be effective. If you're journey includes the frequent deployment of virtual machines, then vRealize Automation can help manage your VM footprint across clouds. And if you're running several Kubernetes clusters, Tanzu Mission Control can help enforce consistent policy across those clusters for better control. VMware also has CloudHealth which is a great way to get visibility across multiple cloud providers in a single console.

Lastly, of course we can't forget the entire line of Tanzu family products used to better operate and secure your Kubernetes workloads.

Summary

Application modernization can take many forms. You can modernize the way you operate applications, you can refactor applications to take advantage of modern architectures, and you can modernize the infrastructure where your applications run. VMware can help you along this journey no matter where you're at:

  • Discovering your application portfolio and identifying high value targets.
  • Putting an action or business plan together based on business goals.
  • Standing up production ready Kubernetes clusters and delivering your applications.
  • Managing your multi-cloud environment with tools like Tanzu Mission Control and Cloud Health.

Attachments

  • Original Link
  • Original Document
  • Permalink

Disclaimer

VMware Inc. published this content on 09 February 2022 and is solely responsible for the information contained therein. Distributed by Public, unedited and unaltered, on 09 February 2022 19:38:01 UTC.