In Part 1 of these series on VMware Cloud strategy we covered the VMware Cloud on AWS offering, this article will focus on the Cross-Cloud Architecture. For the sake of briefness I’ll use the CCA acronym later on (note: this is not an official VMware acronym). I strongly recommend you to read Part 1 to better understand the context.
First of all, CCA is a different beast than VMware Cloud on AWS is – it is not a tool to extend your business-as-usual vSphere environment in the cloud, or at least I don’t see it that way. At this stage both products are in Tech Preview so the final result and eventual level of integration between both products (if any) may vary.
A pillow of clouds
This VMware offering aims to bind different clouds together and allow mobility of workloads across different cloud service providers (CSPs) while also providing a common framework for securing these workloads through the use of NSX as the transport (and eventually encryption) layer.
Currently, there is no real offering in this space and most generally cloud consumers are bound to the platform they have decided to use. Moving workloads out is difficult, not only because of the format but because of the unique underlying services proposed by each provider.
VMware CCA provides a fantastic opportunity not only to abstract workloads and make them portable but also offers a single pane of glass view (or at least seemed to in the demo I’ve seen). That “view” should be theoretically delivered by a new product for cloud management based on the VMware vRealize platform. Thanks to this, it is now possible to have and end-to-end monitoring of all workloads across all cloud platforms.
Finally we should not leave aside the operational aspects that VMware CCA resolves, such as different teams with different skill sets and lack of interoperability between cloud solutions. These challenges are solved thanks to the abstraction model proposed here. Obviously, there is a point where skilled people will be needed to integrate the environments with VMware CCA. But beyond this, it should be a walk in the park.
Why Cross-Cloud Architecture Matters
Selecting a cloud provider is sometimes done on a totally eclectic basis. In some companies, someone first thought of trying AWS, then started using it more and more, and the old paradigm of “this test/dev system is a now core critical asset for the company” is true even in a cloud-operated environment.
The more apps and systems are deployed at a cloud provider, the more vendor-specific technologies are used and the more difficult it becomes to disengage, thus customers are left at the mercy and good will of each given purveyor of cloud services.
With Cross-Cloud Architecture, VMware gives a new meaning to “multiple vendor strategy”. Before CCA, you could indeed have a multiple vendor strategy and host some workloads in AWS while having others in Azure and another subset in Google Cloud, but there was no real mobility nor would you have a single management interface. The same would apply for billing costs, you would get a fragmented view of each of your cloud shards. VMware CCA management interface will allow to have a comprehensive view of the incurred costs without having to jump from vendor to vendor.
Security also matters. As hinted above, VMware NSX is integrated in the Cross-Cloud Architecture offering, allowing end-to-end, cross-cloud encryption of data flows. VMware CTO Guido Appenzeller provided an awesome demo during Day 1 Keynote where he showed how this solution analyzes traffic flows between components of a multi-tiered cloud application, not only showing allowed traffic but also highlighting unwanted inbound traffic coming on ports that were inadvertently left opened. The network flow visualisation tool included in CCA’s “cloud management platform” is essential to understand whether flows travel through the proper route and a key helper in tracking down and closing unwanted or forgotten open ports.
I personally see VMware CCA as an abstraction layer above the existing cloud solutions. It’s hard to say if it qualifies to be called a “cloud hypervisor” but it certainly checks the marks for management and orchestration of workloads.
VMware ESX abstracted hardware, separated workloads from the underlying hardware platform, and allowed workloads to move between different hardware platforms, thus empowering the customer in their platform and vendor choice.
VMware CCA does something similar with CSPs. Customers will be able to decide where their workloads run and will be back in control of the economics behind using one or another cloud provider, without having to care about vendor lock-in and bonds to a given technology.
It’s too early to say if VMware CCA will “commoditize the cloud”. But by binding all cloud offerings under its control, VMware did a master move here.
I will probably cover VMware cloud strategy and market dynamics in a third and last post, so stay tuned!
I received a blogger pass from VMware, which allows me to access the entire event at no cost. I did cover all my expenses here including travel, airplane fare, taxi and hotel. Yes, taxi because I hate metro. I am blogging out of my own will, without any obligation, and without any request from VMware. This article is independently written and represents only my personal opinions.