AWS Migration Made Safe and Simple
Cloud migration is complex with uncertainty
If you take a look at AWS guide to enterprise on how to migrate on-prem VMs to cloud since 2014, you’ll find the workflow is getting more complex each year and the task more daunting.
The current migration process
Before getting started, you need first to run some inventory tool to scan what VMs and their operating systems are in your organization, then use dependency tool to map dependencies between VMs or Apps on these VMs. The dependency map quickly turns into a spider web as apps need database and need other apps to work together to form a service. The dependency tools are not 100% accurate, so you need to interview developers to make up for the deficiency in the tools. If an app was developed years ago or the developer is no longer with the company, you get stuck with the migration. After months of working with the tools and diligently interviewing people, you still feel uncertain about having achieved 100% accuracy in understanding the dependencies.
Here is a diagram describing the functional dependency problem, where an on-prem VM A6 with the IP address 172.16.1.11 is moved to AWS to a new IP address, 192.168.0.11. On-prem VM A1 and B3 may have trouble reaching A6 as its IP address has been changed. Traffic from migrated A6 may have trouble reaching back to B3 due to firewall rule blocking.
In addition to these functional dependencies between apps, there are non-functional dependencies. Since a VM changes its IP address after migrating to AWS, on-prem firewall rules, Active Directory, DNS entry and load balancers relating to this VM will need to be changed too.
After dependencies are mapped out, you then need to decide what to do with the apps. Your option is to re-architect or modify dependent upon apps to adjust to the new IP address of the migrating VM. Those modification is some times small, some times impossible.
As a result, you need to hire system integrators and an army of consultants. The migration project exceeds budget and timeline; Still you do not have the confidence and certainty that all services will continue to work after migration — did I miss anything in the assessment?
What is the root cause of the complexity and uncertainty?
As you see from the above illustration diagram, the root cause of the complexity and uncertainty is the inability to maintain the IP address of a migrating VM.
The inability to maintain IP address of a migrating VM leads to the inability to maintain the dependencies automatically, which in turn lead to having to discover the dependencies and then to manage them to make sure they don’t break after migration.
Why can’t one preserve a migrating VM’s IP address? Wouldn’t that remove all the complexities and uncertainties?
It turns out this is not a trivial problem.
vmware has the HCX technology to migrate a VM to vmware cloud while maintaining its IP address. vmware executive also blogged about it. But AWS does not have such a solution. AWS and all public cloud providers lack the underlaying network infrastructure to natively support the capability.
Re-architect Apps
Current practice advocates to re-architect apps after dependencies are discovered before migration take place. The idea is to modernize on-prem apps to take advantage of public cloud services and become cloud native, and also to make sure app dependencies are made independent of IP addresses.
Such approach in practice is unrealistic. It is costly to re-write a software that took decades to develop, as the new software also needs that much time to stabilize. More importantly it is challenging for developers to write a cloud native application before they develop expertise in cloud services — most likely you’ll get it wrong the first time. It makes more sense to migrate the apps first then overtime to re-architect them to be cloud native.
IPmotion made AWS migration safe and simple
Introducing IPmotion from Aviatrix in collaboration with AWS.
Aviatrix IPmotion allows you to migrate a VM while preserving its IP address, thus automatically maintains all dependencies. Here is an illustration of IPmotion solution, where the address of a VM, 172.16.1.11 is preserved after it is moved to AWS.
The solution consists of an on-prem virtual appliance (Aviatrix CloudN) and IPmotion gateway. Connectivity is established between on-prem subnet and cloud subnet such that any on-prem VMs in the datacenter can reach migrated VMs in the cloud subnet as if they are still on-prem.
Benefits with Aviatrix IPmotion
- Migration made safe Being able to preserve IP addresses of migrating VMs assures that dependencies be maintained and migration projects be successful without anxiety to failure.
- Migration made simple The requirements for dependency tools and interviewing process are significantly reduced or removed. The requirements to modifying depending apps are removed. You can now follow a simple deterministic process to migrate VMs.
- Migrate at your own pace As migration becomes a deterministic process with IPmotion, you can migrate VMs at your own pace without having to migrate a group of related VMs all at once, knowing the dependencies are maintained.
To Learn More
If you are not familiar with the subject, there are tons of online materials on cloud migration practice.
Here are some additional readings about Aviatrix IPmotion.
Migrating VMs with Aviatrix IPMotion and AWS Migration Hub Service
