Modernization Operations

Operate in the Cloud

Workloads built or moved to the cloud still need a plan for operations. Applications that keep the same form factor during a migration such as a VMware virtual machine may need to be added again to logging platforms, monitoring tools, and security patching strategies since they are now located in a different data center. Applications that change form factors such as a re-platformed application may require entirely new operations routines to ensure they are monitored, secured, audited, etc. 

Verifying Application Functionality

An organization’s applications team are the key stakeholders to verify application functionality after a migration or transition. As such, they should have been a part of the migration event planning activities and received advanced notification. Some of the key joint planning tasks to address post migration can include:

• The validation time can range from few minutes to some hours depending on the tasks agreed for validation.
• Ensure the application team is using the application functionality tests and has confidence of the expected timeline.
• Conclude with an approved or unapproved validation answer from application team, which in some rare circumstances may trigger a revert of the workloads to the sources.

Verifying Application Performance

Application performance can be a subjective topic during and after a migration. Interpretation of performance profile and metrics will need to be definitively agreed upon prior to migration. This will allow all parties to reach consensus based on agreed upon metrics quickly. Ensure identification and collection of proper KPI’s during planning. Proper KPI metrics should be monitored with enough time to provide adequate data for comparison of application performance before and after migration to minimize performance evaluation and narrow a scope of investigation if the application is not performing once migrated.

VMware Wavefront or vRealize Operations Cloud could be helpful in monitoring application KPI’s.

Post-Migration Cutover Events

Virtual machines migrated from a data center into the cloud, still require the same operational processes as virtual machines on-premises. Moving virtual machines to the cloud may provide additional options not available to you previously with an on-premises virtual machine.

Network Connectivity - The post-migration cutover refers to making the target SDDC the new “home” for a given set of migrated virtual machines. The exact process depends on the IP addressing strategy that is chosen for migrated workloads. If you’ve opted to change workload IP addresses, then a cutover would mean ensuring that the new address space is reachable by end-users and that all DNS has been updated to reflect the change. If instead, you’ve opted for workloads to keep their IP addresses, then a cutover would involve disconnecting any layer-2 extensions for migrated networks and configuring routing such that the migrated networks are reachable via a routed path to the SDDC (VPN, other specific Cloud connectivity).

Asset Tracking – Virtual machine objects being moved between data centers may have an impact on security, licensing, and costs. As virtual machines are moved to a different location, such as the cloud, these asset or configuration databases should be updated to reflect the new state of your applications after a migration.

Monitoring – Many times, ownership of virtual machines by Infrastructure teams may change if the virtual machine exists in the cloud instead of on-premises. It is important that monitoring is appropriately configured and alerts go to the right teams as workloads are moved to different data centers.

Disaster Recovery – Add your virtual machines to a new disaster recovery routine. You may be using a second cloud location to protect against a regional disaster or you may start using your on-premises locations as your fail over location. It is vital to ensure that your disaster recovery routines are still viable after migrating your virtual machines to cloud infrastructure.

Post-refactor or Re-platform Events

Modern applications often require different operational tasks to maintain them. As monolithic applications are broken down into multiple components, how the application needs to be maintained has changed. Consider the following operational tasks on a modernized application that doesn’t consist of a virtual machine.

Recoverability – If an application is made up of a set of disposable microservices, there shouldn’t be state data within services, so they don’t require backups. However, the backing services for a monolith might’ve been a single source, meaning a single item to backup. In a distributed system, multiple backing services may need to be protected from failure, and subsequently, more backup routines are needed.

Deployment – Monolithic applications result in a virtual machine being provisioned. Microservices may require for many services to be deployed. If your corporate deployment process involves opening and closing tickets to deploy a service, the number of tickets being created will dramatically increase. A continuous deployment methodology may be a better fit for a modern application architecture.

Observability – Within a virtual machine, it is common to have an agent installed to gather performance metrics or logs. With microservices-based architectures, logs are distributed, meaning that to correlate logs between services, you must first aggregate them. Performance metrics in a container-based solution are often published by the application and scraped by a solution such as Prometheus.

Security Updates – Virtual machines running a monolith are often left in place for long periods and patched regularly to mitigate vulnerabilities. Container-based workloads aren’t patched in place but are rebuilt and redeployed with a fresh image. Be prepared to rebuild microservices as part of a regular security mitigation process.

Network Security – In a simple two-tiered application between a virtual machine and a database, there is one network path to secure. When using microservices, there may be many network paths to secure. A service mesh solution such as Tanzu Service Mesh might be used to secure these connections with mutual transport layer security (mTLS).