VMWare+AWS -“Breaking Myths”

vmware_aws

VMWare+AWS partnership has been a hot topics since the day both giants announced their partnership. Many customers are showing their interest to adopt this strategy so that they can take advantages from both the worlds. Last week I got chance to attend session focused on this topic and many caveats got clear as how this integration can be seen and what will be the future road-map. One major thing which came into picture was however the workload will be running inside Amazon data center but the inline architecture will be purely on VMware which means that there will be dedicated physical hosts running ESXi hypervisor, leveraging vSAN storage policies and using NSX for its networking.

Here are the key points which will be accounted after deploying workload using this combination:

  1. Customer needs to have AWS account in order to start with this product suit, which then further be binded with their VMware account
  2. There will be primarily 3 types of deployment choices given to the customer (i) Standalone VMware Cloud deployment (ii) Hybrid VMware cloud (on-premisis & cloud data center) & (iii) Cloud to cloud (VMC to VMC) deployment model
  3. Even though the workload will be running on vSphere suit but still access to AWS services like S3, RedShift or Cloudfront  can be leveraged by the customer
  4. An entirely new product portfolio of vRealize operation suit is being written using which monitoring and forensic operations can be performed
  5. VM running on-premises can be vMotion-ed to AWS cloud – this is achieved by NSX component which will create stretch LAN using which vm sitting on-premises can talk to vm deployed inside AWS cloud
  6. For customer who doesn’t have NSX component in their on-premises environment can use AWS direct-connect plugin to serve the purpose by creating VPC
  7. Since customer’s workload is running inside AWS datacenter hence the situations like Host Fails, Upgrading host, Cluster size consistency can be avoided as VMware will take ownership of these activities and customers need not to worry during these situations
  8. Being vSAN  as underline storage scaling up the capacity isn’t a problem. Even during the situation where entire host needs to be ejected for maintenance or provisioning a new host such activities can be performed on the fly. (*Please not that the host needs to be removed from vSAN cluster before performing node replacement activity)
  9. VMware will manage hypervisor & management stack of the workload while AWS will take ownership for hardware/physical components
  10. There will be a single point of support for customer which will be owned by VMware and if it requires assistance from Amazon services VMware will co-ordinate on behalf of customer

Some caveats to this deployment will be as below:

  1. Customer logs into in-cloud vCenter server with external PSC (runs in-cloud) with Single or multiple SSO domains
  2. Customer will not have root access to ESXi host neither they can install third party VIBs or make changes to vDS configurations
  3. While deploying vSphere workloads in Amazon customer will have dedicated hardware running vSphere suit however they will not be able to view the underline hardware specs – an entirely new code has been written for vSphere suit to not share hardware information available on the dashboard. This thought goes with AWS policy which gives freedom to the customer as on which hardware they are running their workload

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.

Up ↑

%d bloggers like this: