Before embarking on an application modernization journey, organizations and teams must ensure certain prerequisites are met and understood.
- Assess their infrastructure and application environment.
- Have an accurate inventory of their workloads and how they are related and dependent on each other.
- Build a VMware Cloud Software-Defined Data Center (SDDC).
Most applications can be modernized in some way. Applications could be modernized by leaving their architecture in its current form while improving the deployment process to use newer solutions. They can be modernized by leaving the code as is and changing the form factor in which the code is packaged, such as moving from a virtual machine to a container. Of course, application code can also be either partially or entirely rewritten. Any method you choose to improve your applications using new tools or processes can be considered application modernization, even migrating the application in its existing state.
Modernizing your data center can be broken down into discrete decisions about the applications that power your organization. With the application and workload inventory properly cataloged and dependencies identified, your organization now must decide the speed at which you will address your modernization efforts. The time needed does not always equal the allotted time to complete a modernization project. These business constraints must be identified and will influence which method of modernization you can take.
- Retain means leaving workloads in a private cloud environment.
- Retire means decommissioning workloads and/or converting to SaaS.
- Rehost / Migrate involves either changing the hypervisor. (e.g., migrate applications from one virtualized environment to another) which is known as Rehost or moving an application without changing the underlying hypervisor or application at a source code level (e.g., migrate VMs from one virtualized environment to another without requiring changes) which is known as Relocate.
- Refactor / Build involves changing the application at the source code level. Typically, applications are rewritten to take advantage of cloud microservices architecture and incorporate new services such as IoT, machine learning, and others.
- Replatform involves changing the operating system, such as going from Windows to Linux, modifying the application middleware, such as going from a self-managed database to a cloud provider-managed database or from a virtual machine to a container image.
The Modernization Continuum
Modernization does not have to occur as an abrupt change to an application but instead can be a gradual process that occurs over a more extended period of time. In this way, application modernization can be considered a continuum with no end state. The idea of a “modernized app” means that it uses modern infrastructure, tools, or processes compared to how it was initially built. In this way, there is no end to this modernization process, but it is instead repeated on applications until the business decides it’s not worth the cost to continue.
Applications may undergo a series of modernization stages before reaching their running architecture. Businesses may decide to improve the application’s underlying infrastructure by moving to new hardware or a cloud platform. Companies might improve an application’s functionality by re-platforming or refactoring the code, or businesses might begin by migrating to the cloud and then re-platforming. Each application in your portfolio might go through different paths in this modernization continuum.
This continuum allows application teams to lower risks by making smaller changes to the application instead of an entire code rewrite. At some point in the continuum, after sufficiently modifying an application, there is a diminishing return on the amount of value received from updating that app further. Because of this, the application should be continuously assessed after each stage to determine whether it should continue to be optimized. You should continue modernizing an application as long as it provides a positive return on investment to the business or the opportunity costs of updating the app are too high.
Future Application State
A vital part of an application modernization strategy will be defining how each application is expected to operate and perform in its future state. It is crucial to align application function, performance, availability, and recoverability characteristics in the cloud to its business objectives. An application's business objectives or requirements will not change with its deployment in a cloud platform.
How you meet these applications’ business objectives will vary with your organization’s cloud use case.
For applications being moved or operating in hybrid mode, its future state may still be subject to existing organizational parameters.
For example, operating in the cloud will remove some operational tasks like infrastructure upgrades that staff previously had to spend a lot of time managing. However, a migrated application will still likely need application updates and upgrades. These activities will still need to be completed, scheduled, tested, and planned for.
As applications are moved to the cloud, some common related enterprise functions and responsibilities will require review and re-evaluation. The following are some functions that should be considered:
- Application-level patching
- Application-level upgrades
- Whether the authentication services will be local, on prem, or in the cloud
- Whether backup services will be required and used
- Notification and reporting services needed in the cloud that were previously addressed through redundant hardware on premise.
- What network services will be needed in the cloud that were previously provided on site to applications. For example, load balancing services needed vs the load balancing solution deployed on site.
- Recovery plans to another service or another geographic region
- What security services, appliances, processes, and methods will replace security services leveraged on prem. For example, firewall functions.
With the exception of data center patching and upgrading, your organization may have these and many more functions or dependencies of applications that need to be well defined to meet business requirements in the cloud. This is in addition to documenting an application's performance in the cloud to understand if it is operating effectively. It is important to understand and document how the application is expected to be managed alongside all its related dependencies in order to fully modernize an application for the cloud.
For existing workloads, these environmental factors govern a lot of what the future state of a migrated or hybrid application may look like. Together, these functions, characteristics, and requirements will make up the entire state of an application in the cloud.
Use Known Patterns
As part of the modernization effort, you will begin to find patterns that work for your organization. Many applications will follow similar architectural designs, and it is wise to re-use these known patterns.
It is challenging to gain operational benefits if your applications are vastly different. Grouping applications into application patterns can provide some known solutions that can be recreated many times. Using a set of reproducible architectural patterns offers several benefits to the business.
- Shared institutional knowledge – Any time a new application pattern is created, it requires further understanding of maintaining the application. Using familiar patterns across the organization provides a shared language between teams. This shared institutional knowledge also allows developers to work across teams or projects with a working knowledge of the application patterns in use.
- Shared Operational Processes – Operations teams are often responsible for many applications, and modern application patterns often require new strategies to operate them. A standard set of operational processes can reduce the burden on shared operations teams who must monitor performance, security events, and outages.
- Licensing – There are financial benefits to standardizing on specific patterns. Software vendors often provide discounts for bulk purchases. Standardizing on specific software stacks may limit the flexibility of new application decisions but provide a reduced price for software if shared across the enterprise.
- Optimized Developer Time – Developers who have previously created applications in a specific pattern can re-use what they’re learned in subsequent applications. A smaller set of known architecture patterns or deployment solutions limits the number of tools a developer needs working knowledge of. It also reduces the number of decisions that need to be made when starting a new application, leading to a faster start.
When rebuilding applications for a cloud environment, you’re presented with many options for architecting those apps. When building these applications, consider the entire lifecycle of these applications. Will the application always live in the cloud it was initially deployed in? Will there be a need to move it to another cloud or duplicate the deployment in another cloud?
These considerations may determine what form factor the application's final form will be built as. For example, applications depending on native public cloud services may be pinned to that cloud unless there is an equivalent service in another. For these reasons, customers often choose to stick with a VMware virtual machine form factor that is compatible with any VMware-based infrastructure or a container form factor that can be run on any Kubernetes platform.
Start Fast and Learn
The first applications that are modernized will almost always present unforeseen challenges. You may find operational challenges with the deployment of the apps, recognize previously unidentified dependencies, or find that new services don’t work as expected. These challenges experienced are unlikely to be identified in a planning phase even with an abundance of analysis.
Since a planning phase won’t identify all issues with a modernization project, it’s essential to get started and let the work inform and tune the modernization process. Issues with creating your first modernized applications should not be seen as failures but rather an expected part of your modernization process, which is used to improve the process further.