Setting the Record Straight: Confusion about ACI on VMware Technologies

Most of my days are spent talking to customers about network automation, application segmentation, and how to transition to a multicloud world. The vast majority of those customers have both Cisco and VMware products and solutions in their environments. Recently, we’ve seen an uptick in confusing information about how Cisco ACI integrates with VMware. With that in mind, I’d like to set the record straight about the four most common technical questions our customers ask us to clarify.

#1: Do Cisco and VMware support each other’s products?

It should come as no surprise that VMware doesn’t support Cisco products, just as Cisco doesn’t support VMware products from a professional services and maintenance standpoint. That’s just how the IT industry works. For example, at Cisco, our IT team uses Cisco’s ACI VMM integration with VMware vSphere in Cisco’s data centers. Even in this environment, VMware provides support for its products deployed in the Cisco data center.

Customers should, however, hold vendors accountable for supporting their own public API’s.

Furthermore, a common question I get from customers stems from the fact there are 2 different modes in which customers can use Cisco ACI and VMware’s solutions – 1) ACI VMM and 2) Cisco AVE. The method of how/where we integrate is different across both:

Cisco ACI VMM integration: Customers leverage the public vSphere API to deliver infrastructure as code with Cisco ACI Anywhere. Cisco ACI VMM integration was available with the first shipping release of ACI in 2014 and in production with many customers, large and small. VMware states “VMware supports vSphere and all features available through the public API”.
Cisco AVE integration: AVE is a hypervisor agnostic virtual edge delivered as VM. AVE can work with or without ACI VMM integration. Cisco AVE brings the Cisco ACI policy model, security, and visibility to the virtual infrastructure with no dependency on proprietary APIs or access to vSphere kernel APIs.

#2: Can Cisco ACI only work with Cisco’s hardware platforms? Can it work in a multicloud environment?

ACI is all about a policy abstraction layer that allows customers to define application network intent once – from connectivity to segmentation and service chains – then to automatically and dynamically configure networks as needed, whether these networks are hardware-based, software-based, or even cloud API based.

Cisco introduced the concept of intent based networking back in 2013 with the launch of ACI.

In 2013, most of our customers were focused on automating their own data centers. Hence, Cisco first delivered a solution for physical and virtual networks. The choice of an integrated approach was driven by customers’ need for single point of management, simplicity, full visibility, performance, and low cost.

As multicloud gains momentum, it’s clear our vision aligns to the direction of the market and the needs of our customers.

#3: Is security functionality best delivered closest to whereever the application resides – Cloud, Data Center all the way to the edge? What about the intrinsic software virtualization space of the hypervisor?

According to Canalys, Cisco has the largest enterprise security business in the world. We know security. From the application to the data center to the edge.

Here are a few home truths to keep in mind when discussing data, user and application security:

Closest to the application is actually within the operating system. Cisco Tetration offers workload protection, which is actually much closer to detailed workload action, down to individual containers within an operating system, if that is indeed the only consideration.
Not all applications live in a virtualized world. So, the ability to enforce security at the next closest point i.e. the host has almost become a mandatory requirement with the customer environments these days.
Not all hypervisors are from one vendor. ACI offers integration with all major hypervisors including VMware vSphere, Microsoft HyperV, RedHat KVM, and Openstack. So, look out for vendor lock-ins that give preferential treatment to the proprietary hypervisors.
Most customers actually look at multiple layers of defense (defense in depth) to protect against compromised enforcement points. Cisco ACI together with Cisco Tetration provides customers the flexibility they need to secure the network and protect the application.

#4: Is hardware scaling a particular issue with ACI, requiring a frequent churn of the gear?

The laws of physics apply to every medium. All infrastructure vendors (network, compute, storage) publish scale and hardware requirements documents and update those when releasing a new software images. Modern Data Center designs are based on a scale-out principle to enable customers to add capacity as needed without impacting existing workloads. In addition, the last few years have seen a rapid innovation cycle on both the compute (CPU) and network (switch silicon) side providing customers additional choice when adding capacity.

My intent with this blog is to set the record straight to focus on what we do best – provide advice and solve customer problems. We hope this helps address some of the confusion and inaccuracies floating around.

To learn more about Cisco ACI check out our ACI eBook

To see what our customers are saying, read our case studies