In my on-premises VMware experience, VMotion was a game-changing technology, so I was very surprised to find that there is no equivalent for EC2 instances on AWS. The basic premise with VMotion is that it divorces a Virtual Machine (VM) from the underlying physical server. VMware’s vSphere goes even further, using VMotion to provide mobility within a cluster of physical hosts and abstract away the individual hosts into a cluster. On AWS, the VM service is EC2, and it offers no way to move an EC2 instance (VM) to another physical host without powering the instance off. The crucial architectural difference here is that vSphere wants us to stop thinking about individual physical servers, and AWS wants us to stop thinking about individual VMs. On-premises it is common to have a single VM that offers a service, i.e., this is the CRM server. The CRM server VM is critical and must remain operational at all times, so we want to migrate a running VM to a new physical server. On AWS, we build services, rather than individual servers, the service should remain operational even if one of its servers has a performance problem or an outage. Rather than one single server for CRM, we might have five servers in EC2 instance and a load balancer to deliver the CRM application. If one instance is overloaded or fails, the load balancer uses the instances that are still operational. When we use EC2 autoscaling, the instances are created automatically and can even be destroyed automatically if they fail. A single EC2 instance is a disposable resource, so there is no need to migrate one between physical servers. This disposability of the compute resource is a common characteristic with cloud-native applications. If you are looking for VMotion on AWS, then you are probably building or bringing a legacy architecture in the public cloud. Aim to move away from on-premises style architecture as soon as possible in your public cloud journey.
© 2020, Alastair. All rights reserved.
RSS - Posts