Rant: VMware Cloud on AWS Marketing and Reality

VMware started talking about VMware Cloud on AWS a while ago, and my first response was “yeah, it’s just vCloud Air but they wanted to get rid of CapEx, so it’s running on someone else’s servers”

Last week Frank Denneman published a technical overview of the solution and I was mostly correct.

VMware Cloud on AWS is a service and that means that we will not using product versions when we refer to the service. 

Meaning: we want to charge you perpetually (and we also have to pay Amazon’s infrastructure, so there you have it).

VMware Cloud on AWS is operated by VMware. [and later] Host failures remediation is the responsibility of VMware. If a host fails permanently, VMware replaces this ESXi host without user intervention. 

Here’s the only significant operational difference I can see between VMware Cloud on AWS and yourself doing the same thing in your data center or with Amazon’s dedicated host instances. Licensing (CapEx) versus service (OpEx) is obviously another one.

At initial availability, the VMware Cloud on AWS base cluster configuration contains four hosts.

This looks like they won’t give you vCloud Air account where you could consume resources on demand, but a fixed-size private cloud implementation running on AWS infrastructure.

At initial availability, the Cloud SDDC is restricted to a single AWS region and availability zone (AZ).

So much for reliability. It’s a nice proof-of-concept, but environments that actually care about availability would have to wait.

In future VMware Cloud on AWS releases, through the partnership of VMware and AWS, multi-AZ availability will be possible for the first time ever, by stretching the cluster across two AZs in the same region.

Makes perfect sense. Let’s link two availability zones (failure domains) with a layer-2 extension (what you need if you want to stretch a cluster) and making them into one. Hooray!

With this groundbreaking offering, refactoring of traditional applications will no longer be required to obtain high availability on the AWS infrastructure. 

Awesome! More unicorn dust and flat-earth magic. This is not how you get higher availability, but some vendors never stop peddling their warez. Time to reuse a picture from another blog post.

However, that section of Frank’s blog post described VSAN synchronous replication. Apart from “no need to refactor” that wasn’t too bad. However, wait till we get to networking:

At initial availability, users connect to VMware Cloud on AWS via a layer 3 VPN connection.

So far so good. This is how AWS works today and it makes perfect sense.

Future releases of VMware Cloud on AWS, however, will support AWS Direct Connect and allow cross-cloud vSphere vMotion operations.

**** NO! This is the **** that only ever works in PowerPoint and carefully scripted demos. Time for another picture from that same blog post.

Long story short: while I see plenty of use cases for VMware SDDC on AWS (assuming the pricing is not extravagant) there are no silver bullets. If you want true high availability, you have to design it at the application layer.

Latest blog posts in High Availability in Private and Public Clouds series

More blog posts in this series

Recent posts in the same categories

7 comments:

  1. Frank Denneman 07 September 2017 15:29
    Hi Ivan, thanks for sharing your thoughts on this service. Your ending comment " If you want true high availability, you have to design it at the application layer." is the holy grail for many (external) IT consultants. Many internal IT organisation shy away from rebuilding their entire application portfolio due to the risk involved or compliancy reasons. Hence the beauty of this service. Remember back in the 90's when we used wolfpack to cluster SQL or Exchange, which apps used to go down during patching? Exactly, those who were made to complex. I don't want to pigeonhole the existence of this service for this sole reason, but "old-timers", like you and me still can remember the long hours of rebuilding and restoring. This service offer both, allowing cloud infrastructure consumption without retooling or refactoring the application, but also allow for new application landscape due to the native integration with cloud native services. With initial availability VMware Cloud on AWS allows to connect to S3 and EC2 instances directly. This permits new landscapes to appear and does not restrict organizations to move to cloud-native applications. What always strikes me as odd is the black and white attitude of most IT people. Always seeking for the technology that replaces the existing one. In the last 20 years of technology there hasn't been a technology, except one, that totally replaced its predecessor. Think Vinyl, still here, think cassettes, it's becoming hip again. The only thing that is replaced is the vcr tape. People play vinyl as it provides this extra dimension, but there isn't a sole alive who rather watch Star Wars on VHS instead of Blue-ray. Same thing with most datacenter technology, the mainframe still rules L0 and L1 computing, virtualization and hybrid data center models will be present for a long time. Heck, with Edge computing on the rise, cloud computing and precision-purpose data centers will live in a symbiotic state.
    Replies
    1. Ivan Pepelnjak 07 September 2017 18:24
      Hi Frank,

      I'm guessing we're more in agreement than it seems to you. As I wrote, VMware Cloud on AWS makes perfect sense (more so when you'll add multi-region support), just don't oversell it. Unfortunately I'm always reminded of the #facepalm moment when a VP of whatever started selling VXLAN as the ultimate DCI technology in a VMware keynote literally minutes after it was announced.

      As for holy grails and consultants - there is the right way of doing things, and a zillion other ways of doing things. Solving things the wrong way can get you pretty far, but you're always pushing the complexity around, and every now and then the hidden complexity explodes in your face when you least expect it. I've seen too many DC meltdowns caused by "high availability solved in the infrastructure" to budge on this one ;)
    2. Frank Denneman 21 September 2017 12:56
      Hi Ivan, I understand you POV. We are not overselling particular parts of this service. But beauty is in the eye of the beholder. Typically when providing 60 minutes of data points, it's the technical advanced bits that get stuck in most people minds, which are worthy for another conversation within their own team
  2. James Box 08 September 2017 09:54
    The voice in my head keeps telling me that once VMware customers engage in this service on AWS, and get a taste of how well done AWS is on its own, might start thinking "Why am I paying two vendors more money when I can pay one vendor and achieve the same?" I grok that the the initial attraction is that you don't have to change your well known vCenter operational model and yet still benefit from cloud options. As a VMware customer, license costs, and the fact that NSX is being forced everywhere in the Vmware ecosystem, makes me more nervous by the day.
    Replies
    1. Frank Denneman 21 September 2017 12:52
      Hi James, I can understand that you are nervous, but there are is more to it than the location of the resource consumption. In order to achieve the same service on AWS as you are experiencing now with a vSphere VM, you need to redesign or refactor your application. You need to move the app and data to AWS service and you have to ensure that the app can consume the AWS native services. This is not a small feat to do. Now I won't ignore the fact that some applications can benefit from this new architecture, but reality is, a lot of apps do not need refactoring or redesigning. It provides the service the business needs. You do not want to spend a lot of time and resources to end up with the same level of functionality as before. All the testing that is involved to verify whether the app performs the same, most IT teams will thankfully decline such an invite to that party. Again, it's not a black and white world, it's more nuanced. Same as the app and service inventory of IT orgs. Not all require a cloud native approach. Yet, if you want to include cloud native services from AWS, we got you covered, allowing you to connect your VMs to the AWS services while using AWS networking services, avoiding expensive egress costs
  3. Unknown 08 September 2017 14:41
    There are some applications ( like Cisco UC portfolio CUCM/CUC/IMP) that still require native ESXi support. You may play around with convertation to AMI and make it work on native AWS, but it won't get TAC support.
    There might be some other apps as well. This is to the point why paying two vendors
    But in total i do agree that solution is too keen to be a candidate for massive production rollout, but it has great perspective. Once they add multi AZ support and make it available across multiple regions, probably after that we may seriously consider it.
  4. Dmitri Kalintsev 10 September 2017 00:21
    Some additional not-so-obvious considerations: https://www.cloudphysics.com/blog/vmware-cloud-aws-long-road-hybrid-cloud/
Add comment
Home
Sidebar