Many organizations have a need to adopt and operate a hybrid cloud environment for various reasons, including leveraging heavy investments in on-premises technologies, unique requirements for data to be closer to other on-premises systems, specific security requirements, low latency requirements, etc. Organizations are also looking for platform destinations to deploy and migrate applications. Adopting and operating a hybrid cloud environment is easier said than done. You must pay careful attention to various components of the architecture, including storage, networking, security and management tools.
In the context of migrating applications to the most suitable platform and the associated tooling, there are two areas that need appropriate due-diligence:
- Platform Awareness – the ability of the migration tool, or the application deployment package to be aware of the target platform where the app will be deployed or migrated to. In many instances there is a need for bidirectional movement (Move from current environment to a new platform and move back to the original platform). The primary example of such a requirement is in a DR scenario where the application will continue to run on the current platform and can leverage the new platform in a DR scenario.
- Business Continuity – the avoidance of any potential disruption and consequent downtime. There are various mechanisms to avoid or minimize downtime during migration, including blue-green migrations/deployments, active/active/passive configurations and graceful failover using rolling migrations for individual components. The migration pattern you choose will drive the magnitude of the changes required for migrating applications to a new or different platform.
This article provides an overview of various approaches and tools (specifically for Rehost) that can be used for migrations and how migration tools fit into the hybrid cloud environment.
Approach, Patterns and Tools
A migration approach, or how you migrate applications, is closely tied to a specific Migration pattern. Rehost and Replatform for example address different technical stacks – For example, moving a VM “as is” in a Rehost scenario versus using a new DB platform and migrating data with Replatform.
In a rehost migration pattern, even though the application is not undergoing any major architectural changes, many properties of the server/application configuration (e.g., DNS, IP Address, MAC address) are typically updated to match the characteristics of the target cloud platform. These changes necessitate a careful assessment of the application (asset details, dependencies, connections, ports, etc.) to account for the changes needed for the application to be migrated. On the other hand, with a Replatform or Refactor migration pattern, changes are typically done at a higher technical stack (Database, Middleware, Message Queuing etc.) and the underlying networking stack details from the current state are not as significant as in a Rehost scenario.
To address the hybrid cloud scenarios, many new offerings/approaches are emerging including – Cloud provider based on-premises solution (Azure Stack, recently announced AWS Outposts), cloud provider providing third party Hypervisor support (VMWARE Cloud on AWS), and third party Hypervisor based solutions (Ex. VMWARE HCX). These offerings enable new approaches for organizations to migrate applications.
For example, an application can be migrated/deployed to Azure stack which provides many Azure cloud capabilities for organizations in their premises. On the other hand, VMWARE cloud on AWS provides an extension of the on premises VMWARE infrastructure where applications can be moved to AWS using native VMWARE functionality and further it provides an option to move the applications back to the on premises environment.
In addition to the capabilities and offerings from cloud providers, and hypervisor-based solutions, there are additional approaches including containerization and third party tools that allow platform agnostic deployment using various orchestration tools. These tools abstract the underlying platform and allow workloads to be moved to any platform thus providing portability.
The table below provides a high level summary of various migration patterns, approaches and potential migration tools:
Rehost Specific Migration Tool Options
A Rehost migration pattern is generally used for either a COTS (Custom Off the Shelf) application, where application architecture is not amenable or cannot be changed, or other migration patterns are not viable in the short run. Even with “as is” move, there are many potential benefits including leveraging target platform’s capacity, right sizing, backup and disaster recovery, global reach, etc.
There are many approaches for a Rehost migration pattern, including disk replication, import and export image, repackaging, hypervisor native capabilities of snapshot and move, and newer containerization approaches where apps can be tweaked with the move. However, not all approaches support bidirectional movement of applications.
The following section describes each of these methods and the associated tools:
1. Disk Replication based approach
In a disk replication approach, a local agent on a VM is used to read and replicate the disk blocks and a target image is created This image is an exact replica of the source vm. The migration tools automate some of the changes that are required for the VM to run on the target platform including IP address change, cloud native drivers ingestion etc. Either continuous replication or a scheduled replication approach can be used and the approach is based on the specific tool being used. For example AWS SMS uses a point-in-time snapshot and scheduled replication mechanism and CloudEndure uses a continuous replication mechanism.
The cloud provider tools provide limited capability for bidirectional movement of applications where as the third party tools provide hybrid or multi cloud movement capabilities.
2. Snapshot, Export Import Based Approach
In this approach, the hypervisor provides an VM export capability were a VM can be exported to an image which then can be converted to a cloud native image. This image is then used to launch the target instance in the target platform. This instance is a replica of the source vm.
The cloud providers provide an export capability to export the vm when running on their platform. This capability can then be used to copy and import the vm on an on-premises environment, if required. (With certain limitations where only an imported image can be exported). With the maturity of the replication based tools, and the challenges associated with the conversion of images, export import based approach is not commonly used these days.
3. Hypervisor Native – VMWARE HCX based approach
This unique approach based on VMware technology accelerates migrations and avoid infrastructure-related changes during the migration process. Many enterprises have invested significantly in a VMware based solution and its supporting components, including automation, orchestration, service catalogue, etc. and want to continue to leverage their existing investments instead of replacing them in the immediate short term.
VMware HCX (formerly known as Hybrid Cloud Extension and NSX Hybrid Connect) is an abstraction solution that provides mobility and hybrid capabilities across different versions of VMware vSphere, on-premises and in cloud environments. It offers various capabilities, including VMware vMotion, Bulk Migration, High Throughput Network Extension, WAN optimization and VPN capabilities. HCX enables clients to seamlessly migrate workloads between different environments, without any application or configuration modifications. Applications can be moved between multiple on-premises environments, as well as from and to the VMware Cloud on AWS, using native VMware management capabilities.
The following are the components of the HCX solution and the diagram below depicts the various components and their interactions:
- HCX Manager (HCX-MGR) provides a framework for deploying the service appliances. It integrates with vCenter Server and uses vCenter SSO authentication. There are two versions of HCX: HCX Enterprise and HCX Cloud. HCX Enterprise is deployed on-premises, while HCX Cloud is deployed on the cloud provider side
- HCX WAN Interconnect Virtual Appliance provides migration and cross-cloud vMotion capabilities over the Internet, and private lines to the target site.
- HCX WAN Optimization Virtual Appliance service improves the performance characteristics of private lines or Internet paths, data deduplication and line conditioning.
- HCX Network Extension Virtual Appliance provides a high performance (4-6 Gbps) Layer 2 extension capability. It allows keeping the same IP and MAC addresses during a virtual machine migration.
HCX supports various scenarios including – Cross vCenter version migration (Ex. vSphere 5.x and vSphere 6.x), Migration from/to on-premises and public cloud, Disaster Recovery.
There are two main options for migration:
- vMotion. This is also known as live migration with zero downtime. When you initiate a live VM migration from on-premises to cloud, VM is permanently moved there. This scenario uses an HCX Cloud Gateway (CGW) virtual machine and a dummy host (mobility agent). When you initiate vMotion action for migration, the mobility agent securely proxies the vMotion traffic from the on-premises environment out to the CGW. VM then gets transferred to cloud and lands on the CGW instance of the cloud platform, and eventually onto the ESXi host on the target platform. In this option, the migration of data happens in real time and with minimal downtime.
- Bulk Migration. A bulk migration option migrates multiple workloads and allows for the seeding of data to reduce downtime. Bulk migration uses the native vSphere replication technology to replicate VMs to cloud, and when initial sync is completed, you can specify a scheduled switchover time for migration. During migration, the deltas are pushed to the target platform, making it easier to switch with minimal downtime. This option also allows you to retain a copy of the source VM.
Pros and Cons of VMware HCX
There are many pros and cons for using the HCX approach to achieve migration and portability goals. The pros and cons for a specific organization may vary depending on factors, such as migration objectives and goals, investment and ROI timelines, skill sets, etc. But here are the pros and cons, in general.
- Speeds up large, as-is (rehost) migration efforts by reducing the overhead for updating and reconfiguring applications during and after migration. This is because HCX abstracts the physical and virtual layers to simulate an environment similar to the current state.
- All current skills and tools can be used post migration (e.g., monitoring solutions such as vRealize Operations and Automation, etc.).
- Avoids many upfront investments that may be required for public cloud adoption using native features and functionalities.
- Organizations can gain immediate benefits from the new platform. Scale and geo distribution are a few examples of these benefits, although not all native features can be used.
- Facilitates bidirectional movements of the VMs from on-premises to cloud and vice versa, providing flexibility to choose appropriate cloud models.
- Even though this solution reduces the migration effort, it requires careful planning for the deployment of various complex components (routing, VLANs, VPN, L2 layer extension, WAN optimization).
- Enterprises will need to continue and maintain their investments in current technologies, which may negate any potential cost benefits from native public cloud platform technologies.
- Even though this solution uses many public cloud features and functionality, it inhibits using some of the native ones, thus limiting the potential benefits. For example, AWS features like autoscale may not work on the VMware cloud on AWS. This, however, can be mitigated with autoscale DRS from VMware.
4. Azure Site Recovery based approach
Azure site recovery provides a replication solution primarily when the destination or target is either Azure or an on-premises datacenter. It supports the following scenarios:
- Migrate Azure VMs between regions
- Migrate On-premises virtual machines and physical servers to Azure
- Migrate On-premises vm/machines to a secondary datacenter
- Migrate Azure Stack to Azure
- Mirate AWS vm’s to Azure
The following are the components of Site recovery:
- Configuration server – The configuration server is an on-premises vm that runs Site Recovery components, including the configuration server, process server, and master target server
- Mobility Service – The mobility service is installed on each server that is to be replicated. Hyper-V based vm’s do not need the mobility service to be explicitly installed
Azure Site recovery supports “Azure Automation” and the concept of ‘Runbooks” to create recovery plans and orchestrate recovery of vm’s. This simplifies the migration process by automating and accounting for dependencies with the numerous migration tasks.
Even though Azure SIte Recovery supports all possible scenarios including hybrid cloud (except moving away from Azure to other cloud providers), the setup and configuration of various components requires detailed planning and careful evaluation of all the pre-requisites and is one of the comprehensive solutions when the target is either Azure or an on premise datacenter.
5. Containers Based Approach
Containerization technology is evolving and has continued to provide flexibility and options for workload portability by abstracting the underlying platform. In the context of a Rehost migration pattern, various tools (Image2Docker, CloudAtlas etc.) and container technology can be used to scan for an application component on the source platform, create a corresponding lightweight container image based on the specific component in use and deploy the image to the target platform. This approach is a hybrid between various migration patterns and it leverages a Rehost approach without making significant architecture changes to the application. Alternately, instead of the “as is” move, ideally part of the applications can be broken into microservices where possible and ported onto containers on the new platform. This approach may potentially provide portability across multiple target platforms and applications can be deployed to the most suitable or optimal platform of choice.
As organizations are looking for flexibility, and options to deploy their applications on the most compelling and suitable platform, there are many options, approaches and tools in the marketplace. The need for hybrid scenarios will continue to exist but new technologies, and solutions will blur the lines between migration patterns and abstract the underlying platform. In addition these technologies provide an interim optimal stage for organizations that are not able to take on the Refactor of their applications. Containers and various orchestration tools hold the promise for a true hybrid/multi cloud scenarios but need careful planning, vetting of the capabilities before adoption. It is critical to evaluate the pros and cons for each of the potential solutions before embarking on a specific path. Enterprises that have a large investment in specific technology (ies) should start small and quickly test some of the new approaches to vet viable options and set the appropriate path.