Are you stuck in the middle of a battle to choose VMware NSX or Cisco ACI? In this post I’ll attempt to bring some clarity and strategic guidance in first choosing the right path, then propose how the two technologies can co-exist. I’ll start with the message below from a reader asking for my opinion on the matter:

Hi Brad,

I’m involved in a new Data Center networking project where Cisco is proposing the Cisco ACI solution. I am starting to dig-in to the technology, but my immediate “gut reaction” is to use Cisco for a standard Clos-type Leaf and Spine switch network and use NSX for providing Layer 3 to Layer 7 services.

I am interested in hearing your opinion about Cisco ACI versus VMware NSX, since you have worked for both companies. If you have time, it would be great to share your views on this subject.

As you can imagine, this is a highly political discussion and our network team are Cisco-centric and resisting my ideas. We are a VMware/Cisco shop and I want the best fit for our SDDC strategy.

For the sake of discussion, lets assume that your IT organization wants to optimize for better efficiency across all areas, and embark on a journey to “the promised land”. More specifically, you want to obtain template driven self-service automation for application delivery, as well as configuration automation for the physical switches and servers. Let’s also assume that you would like to preserve the familiar model of buying your hardware from Cisco, and your software from VMware. E.g. “We are a VMware/Cisco shop”.

Before I begin, it should be obvious that I’ll approach this with a bias for VMware NSX; the result of a thoughtful decision I made two years ago to join the VMware NSX team instead of the other hardware switch vendor opportunities available at the time. The choice was easy for the simple reason that VMware is the most capable pure software company in the networking business. It was apparent to me then (and still is now), that in the new world of hybrid cloud and self-service IT, the winners will be the ones who can produce the best software.

Choosing a path forward rooted in software

Any way you slice it, your virtual machines will be connected to a software virtual switch. This is the domain of a fluid virtual environment that will exist whether or not you decide to use VMware NSX, or go all-in with Cisco ACI. Either direction will require that you do something special with the software virtual switch before you can proceed down the chosen path to the promised land. This isn’t opinion or theory, it’s a universally accepted fact. If the solution isn’t able to gain programmatic control of the fluid network within the software-centric virtual environment, it’s a total non-starter – like buying a fancy television without a remote control. It’s not optional or even a matter that’s up for discussion. Everybody agrees this is a necessary function. Well then, what does that tell us?

To explore that thought a bit further, let’s consider the hardware-centric point of view. Any way you slice it, your hypervisors and non-virtual machines will be connected to a hardware physical switch. This is the domain of a static environment that will exist whether or not you decide to use VMware NSX or Cisco ACI. One of the two directions requires that you also do something special with hardware switches before you can even proceed with the (above) unanimous requirement for special software virtual switches (e.g. Cisco’s software virtual switch for ACI doesn’t even function without special hardware switches). However, nothing special needs to be done with hardware in the NSX direction. You’re already well down the path of VMware NSX when (above) you did something special with software virtual switches.

I can proceed to argue that nothing special with hardware will ever need to be done. The moment you gained programmatic control over the fluid software environment you’ve done everything necessary, and then pose the question; “Why do you need programmatic control over this static non-virtual environment anyway?” The point here is not to have the debate, but that the debate is there to be had. This is still a matter of opinion and theory. Suppose you bought an adjustable TV stand to go with that fancy new television; does it need a remote control too?

For the sake of argument, let’s presume you accept the theory that there needs to be some programmatic control over the static environment. Hey, it sounds nice, so why not? Maybe you do want a remote control to adjust your TV stand, “just in case”. For the Cisco ACI path to make sense, the next argument you need to make is that the fancy television should only function when it’s placed on an adjustable TV stand; and only if the TV stand can be adjusted by the same remote control that operates the television. And finally, you’ll need to convince people that your fancy television and adjustable stand must be designed by the same company – one that specializes in building television stands. Otherwise, they’d better wait and stick with the same old worn-out TV.

In contrast, for the VMware NSX path to make sense, you’ll need to make the argument that a fancy television should be able to work on any stand you can rest it on. If you can place it on an adjustable stand, well that would be nice. And if the adjustable stand came with a remote control, Wow, even better. You’ll also need to convince people that it makes more sense to buy televisions from an electronics company; and television stands should be bought from a television stand company.

Analogies aside, what this tells us is that software is the more important choice, and the hardware is secondary. There are two primary reasons for this. First, to realize the benefits of the fluid data center with fast provisioning and low OpEx requires tight integration with the overall orchestration framework. This is a function of software. Second, the first hop any packet will see is a software virtual switch, and this is where security policy and other important functionality will reside. Hardware is still important, but overall it accounts for fewer ports and has less of the necessary intelligence.

“Networking is a software industry. To succeed in a software market, you need to be a software company.” – Guido Appenzeller

“Who do you think is going to make better software, a software company or a hardware company?” – Steve Mullaney

In other words, Cisco makes great hardware switches. And of course you still need a well-engineered physical network to construct the static environment (the television stand). There are other good choices available, but if you prefer Cisco Nexus 9000 physical switches (either in NX-OS or ACI mode) that’s perfectly fine. However, that decision does not imply that Cisco is also the best fit for the fluid virtual environment, because that is a world of pure software.

The best example of this is security. Consider the distributed firewall available in VMware NSX providing true Zero Trust micro-segmentation with per virtual machine stateful security, including full auditing via syslog, partner integration such as Palo Alto Networks, all with no choke points (because it’s built-in to the vSphere kernel). In contrast, this capability provided by VMware NSX does not exist in Cisco ACI. One problem is that switching hardware is simply not capable yet of providing granular per virtual machine stateful security. However, this can easily be accomplished in software, as it’s done today in the NSX-enabled VMware distributed virtual switch. Similarly, there’s no technical reason why this same level of security couldn’t be available in Cisco’s ACI-enabled Nexus 1000V software virtual switch (AVS), but it’s not there. The point here is that critical network services like security work best in software and virtual switches. And it’s clearly evident that a pure software company has the focus on software to execute better and faster in providing these features than a hardware company.

On the NSX path, where does ACI fit?

Let’s assume you’ve decided to follow VMware’s lead in software to the promised land, and begin utilizing NSX and the vRealize Suite for your SDDC self-service automation and policy based application delivery. In that scenario, VMware NSX and Cisco ACI are not at all mutually exclusive, because they’re each fulfilling different roles. One is a network and security virtualization platform for your SDDC (NSX), the other is a well-engineered fabric (ACI). They go together, like a television and its adjustable stand (or wall-mount, whichever you prefer).

Your well-engineered fabric can certainly have its own automation interfaces for the purposes of constructing the static environment in way that’s, well, automated. The presence of NSX doesn’t prevent that. If you want to deploy Cisco Nexus 9K physical switches – great. The fabric can be deployed in NX-OS mode with a familiar Cisco CLI, and automation through either the NX-API or Python API. Or the fabric can be deployed in ACI mode (with no CLI), and automation available through the ACI-API. Either way, automation is obtainable. Your Cisco fabric APIs manage the static environment (connections for hypervisors and non-virtual hosts), while the NSX API manages the fluid virtual environment (network services and security for virtual machines).

For example, when it’s time to establish network connectivity for a new rack of hypervisor hosts, you’ll use the Cisco APIs for that. In the case of ACI-API, one example would be an application network profile, where the “application” in question is the vSphere hosts running NSX. This ACI profile would contain End Point Groups that establish connectivity policy for the various hypervisor vmkernel interfaces supporting vMotion, Management, vSAN, and NSX. The workflow to provision a new rack of hypervisors would include an API call to Cisco APIC requesting that it assign this profile to the appropriate physical switch ports.

Now it’s time to provision applications in minutes from a self-service portal, complete with network and security services. That’s when your vRealize Suite (or maybe VMware Integrated OpenStack) will call upon the VMware NSX API. You simply point vRealize orchestration software at your vCenter and NSX Manager as its API end points; and from there you proceed to create full application blueprints complete with templates for compute, storage, security, and full L2-L7 network services. You can do all of this today with NSX, vRealize, and your Cisco Nexus 9K fabric.

Later, if Cisco provides integration for ACI with the vRealize Suite, you might decide to create some application blueprints using the NSX networking services model, others using the ACI model – just for the fun of it – and then compare the two side by side. “Which model provides better security, better performance, etc?” But we’ll have to wait for that, which brings me back to my original point on the winners producing the best software in a timely manner.

In the meantime, I hope to see you in your awesome new SDDC sometime soon donning your new VMware NSX certifications!

Cheers, Brad