Provides infrastructure layer compute capabilities, including both bare metal and virtual servers with various optimizations includins compute, memory, IO, and disk. Also supports accelerations options such as GPUs, FPGAs, Inferentia and Trainium.
Provides image recognition capability for images (in batch or real-time) and video that provides a analysis of the content such as real-world objects, faces, celebrities, and path mapping.
Provides a publish/subscribe notification service with multiple subscription types including Amazon Simple Queue Service (SQS), Amazon Kinesis Data Firehose, AWS Lambda, generic HTTPS endpoints, SMS and email.
A serverless, fully-managed, message queue service that supports producing, store, and consuming messages and enables loose coupling between applications.
Provides private networking capability spanning multiple availability zones and supporting subnets, routing, network access control groups, security groups and gateways.
Provides tracing of service invocations in distributed applications for observability, allowing users to diagnose issues or optimize their service interactions.
All about Cloud, mostly about Amazon Web Services (AWS)
Live Migration of Instances. Will AWS ever support it?
2016-03-03 / 548 words / 3 minutes
VMware’s vSphere is a virtualization platform which has wide adoption in the enterprise. vSphere vMotion is a feature which allows the live migration of virtual machines from one physical server to another. During ”live migration” the virtual machine is not stopped so software which was running, network connections which were open and storage operations which were in progress continue to run without interruption.
Amazon Web Services doesn’t currently support this feature, but will it ever?
The Over-Provisioning Scenario
One benefit of vSphere is the ability to over-provision virtual machines. The sum of the CPU and memory, network bandwidth and even storage allocated to the virtual machines on a single physical server could far exceed the actual amount of CPU, memory, network bandwidth and storage that exists on that server. This is great for organizations which typically use tiny amounts of a systems capacity. It allows a much greater density of virtual machines on a physical server but what happens if all those VMs suddenly need all the CPU, or all the memory that they’ve been allocated
Under this scenario, a feature of vSphere Virtual Center, the Dynamic Resource Scheduled (or DRS), will move virtual machines around a cluster of physical servers in order to balance the workload, and keeping the VMs running during this rebalancing is critical. Live migration is a must.
Amazon doesn’t over-provision. A physical server is partitioned and instances are allocated to the partitions. Every VMs gets the CPU, Memory, network bandwidth and storage that it has been promised. There is no need to support live migration in order to balance workloads across physical servers.
The High-Availability Scenario
Enterprise applications can have a very long lifetime, and often once they are written, they are rarely updated. Old software architectures often rely on expensive physical hardware for high availability, such as redundant power supplies and cooling equipment.
VMware vSphere is designed to support enterprise applications by providing capabilities like High Availability (which restarts a VM that fails) and Fault Tolerance (which runs an entire copy of a VM on another physical server). The ability to live migrate VMs across physical servers is a part of the reliance on the underlying infrastructure to provide high availability.
More modern application architectures, such as microservices, intrinsically support high availability because they typically run active/active in a highly distributed system. Amazon steers organizations towards this approach by providing AutoScaling groups which can span Availability Zones. If a physical server at an Amazon datacenter fails, it is up to the user to ensure that another in a different Availability Zone is able to pick up the load. The Amazon EC2 Service Level Agreement provided by Amazon is based on this approach and states that it is not liable for outages “(v) that result from failures of individual instances or volumes not attributable to Region Unavailability;”
At Re:Invent 2015 though, Amazon seemed to be more focussed on the enterprise than ever before, rolling out features like AWS Import/Export Snowball and AWS Database Migration Service designed for organizations that weren’t born in the cloud. A live migration tool would certainly help such organizations to run their legacy applications in the cloud.
Based on these arguments, I don’t see that Amazon really needs to support a live migration feature, but it might want to!
All data and information provided on this site is for informational
purposes only. cloudninja.cloud makes no representations as to accuracy,
completeness, currentness, suitability, or validity of any information
on this site and will not be liable for any errors, omissions, or
delays in this information or any losses, injuries, or damages
arising from its display or use. All information is provided on an
as-is basis.
This is a personal weblog. The opinions expressed here represent my
own and not those of my employer. My opinions may change over time.
