Are VMware public cloud options such as VMware Cloud on AWS cloud washing? Each of the major cloud providers has released a public cloud offering loosely based on VMware Cloud Foundation. However, VMware vSphere isn’t a private cloud. vSphere is the foundation for virtual machine management in the private data center. The platform doesn’t provide cloud extensibility. VMware public cloud offers something that on-premises installations do not – stability in API. That stability in API powers simple to maintain automation, at least compared on on-premises vSphere automation.
Infrastructure as code
Extensibility is one of the things we discovered during our comparison of VMware public cloud options. I recently wrote about how automation of the data center inherits a diverse data center landscape’s challenges. The public cloud offers an excellent example of a software-defined data center (SDDC). What happens when you take an abstracted on-premises solution such as vSphere and place it into a public cloud? You get some of the best of both worlds.
I shared how an operationally diverse data center creates complexity for the automation of VMware vSphere environments. By placing VMware vSphere within a public cloud, the underlay is normalized. VMware public cloud consumers inherent the API stability of the public cloud underlay. Unlike the private data center, automation engineers have a single API to build vSphere automation.
It doesn’t matter your organization has standardized on Terraform, Ansible, Chef, or vRealize. Creating automation scripts remain consistent. For example, by using a standard underlay, automation scripts are sharable. The script to add cloud storage to a VSAN array remains fundamentally the same across customers. VMC on AWS has a limited number of ways to add storage, and customers are limited to that shortlist of API. Therefore, an automation engineer need only create a single script to provision storage across regions in a public cloud provider.
Compare the simplicity to the private data center. An automation engineer may need to create a script each for HCI, Mid-tier, Tier0 storage arrays. As the firmware of these arrays update, the scripts may require modification. As long as the public cloud provider doesn’t deprecate the underlying API or service, the API calls remain the same.
Multiple clouds do introduce complexity into automation across vSphere environments. If like the CTO Advisor, you have vSphere environments across different infrastructure, the API differs. Oracle, IBM, VMC on AWS, and Azure use different API and underlying storage capabilities. Therefore, adopting an all vSphere approach doesn’t eliminate the challenge of portable vSphere automation.
It’s a future argument to focus on one or two clouds. The more public cloud solutions you add to your infrastructure, the more involved you operations.