Data center virtualization was originally designed to improve the utilization rates of computing, networking and storage assets. As the early pioneer of such technologies, VMWare grew to become the dominant vendor of data center virtualization software. Unfortunately, cloud providers’ popularity and rapid feature expansion have not matched the limited security solutions they offer along with their data packages.
Unaware customers who migrate their assets via providers like VMWare, without a holistic inter-cloud security strategy in place, are left both insecure and financially vulnerable.
While every cloud provider should be considered an analog, in this advisory we will address VMWare specifically as both a trendsetting example and leading cloud provider. Here we provide users with five reasons to consider an inter-cloud security approach when those assets are in play.
A successful software-defined data center implementation should support scaling of computing resources
This allows for business units to add new applications rapidly and with enhanced DC security. This should be enabled in a VMWare-powered data center. But this is not a feature VMWare offers. A barely hidden secret in IT corners is that many previous loyalists have chosen to convert to AWS and prompted a rapid rise in demand for cloud computing and IaaS.
A comparison of the growth in AWS-based virtualization and VMWare’s on-premise virtual servers illustrates the movement toward AWS.
(All figures in $mil.)
*Re-statements to account for Dell acquisition
The result has been that enterprises now own two separately virtualized assets. One is in their data centers with VMWare, and the other is in AWS VPCs and/or Azure Vnets. The public cloud has delivered economic benefits for them as well as more flexible control over their resources.
VMWare’s virtual networking and security toolkit are not built to maximize security
While VMWare has robust server virtualization offerings, its security features are simply too underdeveloped for the majority of customers’ needs.
To supplement them, customers seek alternatives with Cisco ACI and a multi-vendor mix for their security needs. Meanwhile, the cumulative cost to VMWare customers keeps rising. Gartner has seen consistent adoption of these offerings over the past year, and Cisco now reports over 3,500 paying ACI customers. (Gartner MQ on Data Centers)
VMWare never quite ‘got’ public cloud standards
VMWare initially took an adversarial stance towards their competitors. Of course, these were public clouds, most notably Amazon’s AWS. Not only did VMWare downplay the compelling benefits of AWS, but more importantly they did little to match their capabilities or provide alternative, legitimate pathways for customer workload migration.
Add-ons add up
After launch when it was forced to reconsider its position, VMWare offered its cloud customers an option of deploying its virtualization toolset (VMWare cloud on AWS) on top of the already virtualized AWS cloud (functionality illustrated by VMPro).
The following table quantifies the cost of running VMWare Cloud on AWS compared to native AWS virtual servers, VMWare providing no additional benefit.
Note the additional cost requirement to heavily invest in VMWare’s private data center in order to access preferred pricing in AWS.
|VMWare on-premise license requirements||Yearly cost of 10 VMWare servers on AWS (1)||Yearly cost of 10 AWS EC2 instances without VMWare overhead (2)|
|100 CPUs of vSphere Enterprise Plus||$467,883||$193.20|
|100 CPUs of vSphere Enterprise Plus & 10 CPUs of NSX||$441,890||$193.20|
|100 CPUs of vSphere Enterprise Plus & 20 CPUs of NSX and 20 VSAN licenses||$389,903||$193.20|
(1)(VMWare data procured from their blog.)
(2)(AWS pricing is based on a reserved instance standard for a 3-year term as derived from their pricing sheet)
VMWare has not delivered on its promise of a robust security platform
When it comes to segmentation and threat prevention across the data center and public cloud, its customers are still waiting for answers. VMWare has underdeveloped inter-cloud security offerings—and they are hampering customer adoption of true multi-cloud infrastructure.
Let’s go back to the very beginning of connective security, starting with virtual servers. Virtual servers naturally gave rise to virtual network switches, which connected them within a single physical server and across their data center. The servers needed to be segmented and inter-server traffic inspected for threats.
Initially, VMWare offered the VMSafe API to allow partners to bring their expertise to bear in order to keep this virtual network safe for their customers. But after getting their partners invested in this approach, VMWare abruptly canceled their API effort in favor of internally developed techniques. The outcome was that the virtual network suffered in its security posture compared to what was delivered on the physical network. This limited security foundation is unfortunately coupled with an aging virtual network and repackaged as an “inter-cloud” offering called NSX-T. NSX-T is not lacking in bold claims.
While the NSX-T design guide claims to provide “micro-segmentation for AWS workloads,” it does not offer any threat mitigation beyond the original NSX offering, which is limited to working on top of AWS with little support for other leading clouds such as Azure and GCP.
The security offered by NSX-T is based on basic firewall functionality for N-S traffic and coupled to the segmentation built into each vNIC.
NSX-T does not begin to address the fundamental requirements of a multi-cloud security solution. The security policy must be expressed as an intention to be applied not to VMs, but to operations from application workloads. The solution must work seamlessly across all major clouds.
Customers who have integrated their assets with VMWare have been struggling to absorb and deploy this limited model as they look to mitigate inter-cloud security challenges.
Take a hint from a proprietary major utility company, which had to deploy virtual firewalls in addition to NSX to protect their virtualized data center. Operationally, these dual security frameworks were challenging to maintain.
The customer was unsure, after all their efforts, whether they had the protection they needed. When they moved their workloads to AWS, the same data center security implementation could not be deployed there. The increasing opex and capex burdens, and reduced confidence in security, set back their timeline for moving additional workloads to the cloud.
VMWare’s capitulation to AWS has resulted in a new marketing approach wherein VMs from the data center can migrate to AWS. As noted earlier, this doubles their customers’ spend and reduces their flexibility. Additionally, this migration is currently supported on AWS, but not on Azure or Google Cloud.
Meanwhile, VMWare has taken to the airwaves stating that there are too many security offerings in the marketplace. The implication is that customers should turn to VMware for a simplified and seamless security umbrella.
Enterprise customers are attuned to VMware messaging and some have absorbed its technology and marketing pitch. While VMWare has robust server virtualization offerings, its security solutions are inadequate in relation to its features.
When what is being provided does not meet their fast-changing usage needs, customers either turn to complex and costly add-on solutions, or are otherwise hampered in their search for workload security across multi-cloud platforms.
Moving forward, enterprises should consider a true SDDC strategy that offers overarching protection for cross-platform assets. Don’t put blind faith in security for your entire company as provided by one of several cloud platforms in use.