By Mathew Lodge

With vCloud Hybrid Service (vCHS), we’re firmly focused on solving enterprise customer cloud problems – especially making the transition from today’s investments in apps and data to a cloud future as easy as possible. And that means building a different kind of cloud – those that matter to enterprises. To make that very concrete for those familiar with Amazon Web Services (AWS), here are 10 things in vCHS to make that transition easier that you can’t do in AWS.

1. Free automatic availability monitoring and fast VM restart

vCHS includes hot standby redundant capacity to maximize the uptime of your application. It’s free and requires no configuration. vCHS automatically monitors all servers and if there’s a catastrophic failure, immediately re-starts all affected VMs on hot standby hardware in the same vCHS cluster. At reboot time, the VM’s file system is exactly as it was before the failure, preserving as much state as possible to allow the OS and application to recover quickly. It also has exactly the same network configuration – MAC addresses, IP addresses and so on – ensuring other VMs can communicate with the new VM without reconfiguration.

By contrast, AWS offers no redundant capacity, no automatic monitoring, and no fast VM restart. New EC2 instances don’t have the same MAC address and require extra configuration to get the same IP address. For redundancy you must buy extra instances, buy and manage a load balancer (assuming the app traffic can be load balanced), architect and code a state-sharing mechanism, buy and manage monitoring, and orchestrate VM re-start.

2. Free automatic proactive performance management

The same VMware technology that watches for server failure in vCHS also monitors the overall performance and health of servers. It’s free and there’s no configuration. If any particular server is overloaded, vCHS automatically live migrates VMs to a server with more capacity. There is no downtime and no “pausing” of the application – it just keeps on running.

The variability of AWS performance is legendary, leading users to devise cunning strategies to juice performance. One example: start more AWS instances than you need, conduct performance tests to see which ones perform well, and kill off the poorly performing instances. Rinse and repeat until you have enough working instances, and continue to monitor instances during their lifetime. With vCHS, this “Darwinian instance infanticide” isn’t necessary.

3. Non-disruptive maintenance

When AWS needs to do preventative maintenance on a server (e.g. a hypervisor security patch), your instance is going to die. There’s even an API where you can learn about when this will happen. vCHS uses live migration to move VMs to redundant server capacity, then performs maintenance on the affected server. The net? Your apps don’t stop because VMware needs to do server maintenance. There is no need for an “apology API.”

4. Create a VM of any size

With vCHS, you get to choose exactly the VM dimensions you want — any ratio of CPU, memory and disk up to the physical maxima. All VMs run on physical servers with 20Gbit/sec aggregate connectivity, unlike AWS servers with single 100Mbit or 1Gbit network cards. Unlike AWS, there is no need to process a complex decision tree of 29 instance choices (as of Feb 2014) to figure out which one you need (choose wisely because you can’t change it later). In vCHS, there is no need to over-buy CPU when all you want is high memory, or over-buy memory when all you want is good I/O.

On AWS, you have to buy up to the largest size that meets your memory or I/O requirement. If you get it wrong, then you have to pick a new instance and figure out if you can run what you want on it (not all AWS images run on all instance types), and how to transition your application without down-time, which leads me to…

5. Resize a VM or disk while it’s running

On vCHS you can add vCPU, memory and disk space to any running VM. Operating system support for adding CPU, memory and disk is present in Linux distros and Windows versions shipped since 2008. AWS instances cannot be expanded, and ensuring they can scale effectively requires careful planning (picking the right instance type and a fixed disk size) and writing code to do state sharing (adding parallel instances). Inadvertently making a bad sizing choice for horizontal scaling can put you in a world of operational pain – if, for example, your instances start running out of disk space, adding more of them just means more instances failing in exactly the same way because they’re all clones of each other.

VM and disk resize on vCHS can be a lifesaver for operations teams managing a critical application that is under load and needs more memory, disk or CPU right away. 

6. Get strong I/O performance as standard, with no clever tricks

Netflix only ever buys AWS instances that completely fill a physical server in order to eliminate the I/O performance variation that comes from multiple tenants sharing the same physical server. This is just one example of clever strategies AWS customers have devised to extract better performance, along with choosing “EBS optimized” instance types – i.e. instances that run on servers with a 1 Gig NIC card.

On vCHS, all servers have 20G of aggregate network bandwidth 20 times that of “EBS optimized” instances at AWS. Storage is a maximum of two network hops from server, unlike AWS, minimizing congestion. Couple that with the ability to have any size of VM, and you can get exactly the VM you want, with the I/O bandwidth you need.

7. Higher performance disk without paying for provisioned IOPs

The standard disk tier on vCHS is a blend of SSDs (flash) and enterprise high-end disk. The flash acts as a cache for most-recently-used blocks, and multi-tenancy of the disk subsystem is limited to improve good cache hit rates. Therefore, you get the acceleration of flash and high performance disk without having to buy higher-priced all-flash disk with I/O guarantees, or settle for AWS’ low-performance SATA-based EBS.

8. Bring your own VM without conversion, with full app vendor support

vCHS can run any VM you currently run on vSphere, Workstation or Fusion without any conversion into a proprietary format – and it’s supported by the software vendor for your application. You can also transfer and run practically any x86 physical machine running any operating system from DOS onwards, without having to switch to a special kernel or re-platform. There’s no waiting, or testing cycles to ensure that the converted VM actually works the same way. There is no arguing with your vendor about whether or not they support the deployment if it’s one of the 5,700 apps already certified on VMware.

With AWS, you must convert the VM, and that only works for a very small set of operating systems, and then covert it again if you want to export the VM. If the VM is at all dependent on any AWS services, you can’t run it in your own data center later because they don’t exist and they use proprietary APIs. You must also make sure that your software vendor can support your deployment on AWS.

9. Use the management tools you already have

vCHS can be managed by any of the VMware management toolset, third party tools that support the vCloud API, or offer generic REST API adapters. You can manage vCHS from the vSphere client (web or Windows), vCloud Automation Center (vCAC) and vCenter Operations (vCOps). This is huge for many customers because it means they don’t need a second operations team to manage cloud infrastructure – one that assumes the radically different AWS architecture and operational model, along with the “fix it yourself” approach to performance and availability.

10. Stretched layer 2 networks between data center and vCHS

VMware allows you to stretch an Ethernet (layer 2) network from your data center to vCHS, making it appear like a single flat LAN segment. The simplest way to do this is with Direct Connect, a dedicated link between your data center and vCHS. Traffic is simply bridged between vCHS and your data center using the virtual networking capabilities of vCHS. To applications, it looks like all VMs are “on net” in the same LAN segment, which is useful for those apps that have a rigid, pre-defined idea of how the network should work and can’t be easily reconfigured. AWS by comparison offers no layer 2 stretched networks, only IP (layer 3) network connectivity.

All of these capabilities are designed to make it easier to run today’s and tomorrow’s applications with high performance and high resiliency. There’s no reason going to the cloud should mean a wholesale re-architecture where you take on the burden of implementing and managing those.

For future updates, follow us on Twitter and Facebook at @vCloud and Facebook.com/VMwarevCloud.

For more information about the VMware vCloud Hybrid Service, visit vCloud.VMware.com.