“VMware Cloud on AWS” Vs. “Azure Stack”

Introduction

VMware, Amazon Web Services and Microsoft are in the middle of some interesting technology and services roll out that have the potential of moving the needle in cloud adoption (spoiler alert: whatever cloud means). VMware is coming from a very strong (almost exclusive) marketshare in the on-prem data center virtualization space. AWS is the 800-pounds cloud gorilla and Microsoft is one of the biggest contenders in the same public cloud space.

VMware just made available “VMC on AWS” (aka VMWonAWS, aka the possibility to run the entire VMware SDDC stack on the AWS infrastructure).

Microsoft is making available “Azure Stack” (aka an on-prem instantiation of the services available on the Azure public cloud).

These two announcements will generate (and are already generating) lots of interest in the respective communities. In this post, I would like to make a comparison between the different approaches VMware, AWS and Microsoft are taking when it comes to hybridity (again, whatever hybridity means).

Background

The cloud industry has been poised in the last 10+ years by the fact that, when AWS pioneered it, it changed two very different paradigms at the very same time:

• it changed the economic paradigm with a PAYGO/OPEX model (Vs. the traditional on-prem/CAPEX model).
• it also shifted the application architectural paradigm with a cloud-native/Cattle application model (Vs. the traditional enterprise/Pet application model).

I won’t bore you more with this because I have already ranted about it a couple of years ago in my “What do Cloud Native Applications have to do with Cloud?” blog post. It would be beneficial to scan through it if the topic is of your interest.

The picture below is intended to summarize visually this multi-dimensional aspect I have alluded to in the blog post linked above:

As you can see, AWS introduced both a new economic and delivery model (X axis) as well as a new application architectural paradigm (Y axis).

In the last few years the industry has witnessed a number of attempts to bridge these two worlds and dimensions. “VMC on AWS” and “Azure Stack” are two such examples of that (albeit the respective approaches couldn’t be more different).

Let’s explore them.

VMC on AWS

When VMware and AWS teamed up, it’s clear that they focused on tackling the economic and delivery model of the traditional Enterprise data center stack dimension (X axis).

The idea is to keep the VMware software stack “constant” (and hence compatible and consistent with what the majority of the Enterprise customers are running on-prem) and make it available “as-a-Service” on the AWS infrastructure. That is to say you can consume one (or more) instances of vSphere/vSAN/NSX clusters as a service, on-demand, in the public cloud.

This picture should visually convey this concept:

In other words, the strategy here is as simple as “bringing the existing data center stack into a cloud with a cloud delivery model”. AWS gets an additional workload capability (a huge one with an enormous total addressable market) while VMware (and its customers) get access to a different “infrastructure economic and delivery model” option.

Azure Stack

When Microsoft looked at the hybridity challenge they took a completely different approach. Instead of focusing on the economic and delivery model aspect of “the cloud”, they rather looked at it from the application architecture and the stack required to run pure cloud-native applications (Y axis).

The idea here is to keep the on-prem delivery model (somewhat) “constant” and focus on making available (in your own data center) services and technologies that usually are only available in “the cloud” (that is, the public cloud).

This picture should, ideally, convey this approach:

Note how the traditional on-prem “data center virtualization” stack from Microsoft HAVE to give way to the new “Azure Stack” stack (no pun intended). Azure Stack isn’t meant to run on a traditional data center stack nor is it meant to run traditional “pets” workloads.

In other words, the strategy here is about “bringing the cloud services required to build and run cloud-native applications into an on-prem data center”.

Conclusions

In conclusions, discussing and comparing “VMC on AWS” and “Azure Stack” doesn’t even make much sense given they are meant to solve completely different problems in the hybridity space. Because of this, they both have complementary holes in their respective value proposition.

“VMC on AWS” shines if you are a happy vSphere customer, you have to support “pet workloads” but you would like to do so with a different economic and delivery model (i.e. if you want to get out of the business of managing VMware clusters, if you want zero-effort global reach, if you want a “pay-per-use” infrastructure opex billing… all without touching your application stack). On the other hand, this solution doesn’t address how to run cloud-native applications on-prem (at least in a way that is compatible with the AWS services – VMware and Pivotal have their own solutions for that but this is out of scope for this blog).

“Azure Stack” shines if you are re-architecting your applications using the 12-factor application methodology (“cattle workloads”) but, for various reasons, you want to run them on-prem in your data center (i.e. you want to leverage advanced cloud services such as Azure Functions, Object Storage, CosmoDB… all without having to move your applications to the public cloud). On the other hand, this solution doesn’t address how to run traditional applications (“pets”) with a cloud(-ish) economic and delivery model.

If you have clear what your challenges are and what you need for your own organization, you have already picked the right solution for you without any further comparison.

In the end, both solutions remain spectacular projects and I am sure they will be successful in their own respective domains. There are gigantic engineering efforts that most people do not even appreciate to make these things happen.

Super kudos to the teams at AWS, Microsoft and VMware for the astonishing work.

Interesting times ahead!

Massimo.