A small introduction
I’m visiting VMworld for quite some years now, and every year there is a fully booked session about “Deploying NSX Datacenter on a Cisco Infrastructure” (in this case NET1945BE). Each year this is a session full of discussions about whether or not it’s a good idea to run NSX AND/OR Cisco ACI from the audience perspective.
The audience is divided into either the “NSX”-camp or the “Cisco ACI”-camp, but from my perspective this should not be the case when it comes to business alignment.
I’m experienced with both solutions (CCNP-Datacenter and VCIX-NV) and know the pros and cons of both solutions, which a want to layout in this blog.
Who has to work with the SDN solution?
A thing I hear frequently is that network administrators do not like NSX (at all) and that server administrators do not like Cisco ACI, which creates a huge gap from an operational standpoint.
To put some more oil on the ACI vs NSX fire: From a network admin perspective, NSX is:
- not mature enough (it’s more of a gizmo/toy).
- not optimized for low-latency connectivity.
- a software-only solutions and you still need hardware, so why not choose a hardware-based SDN?
From a server admin perspective, ACI is:
- blurry (the policy model is too complex so they do not understand it)
- not integrating well with VMware, for example it’s not offering VM Security Tagging.
- lacking some essential L4-L7 services, for instance: DHCP-, VPN-, Load-balancing-services.
- not innovative enough: it’s just a pack of network protocols and switches with a SDN shell around it.
I’m not saying that theses arguments are true or false, i’m just mentioning the things I hear and want to bring some perspective on these standpoints.
So let’s put that fire out FOR ONCE AND FOR ALL.
I always ask network administrators/engineers if they are capable of scripting? Usually i get the answer that they have no scripting-experience and have to work on that part.
This put’s a pink glass on the perspective from those network engineers. Because Why to choose a Software Defined Network solution if you are not able to use the solution where it was build for in the first place?
Network administrators like to work with a CLI, which gives them full control over the solution. With a SDN solution the control moves to the management plane (out of direct hands of the network admin), which can be daunting and scary the same time for someone who was always in full control.
You may say that network admins have some cold feet when it comes to disrupting network solutions: It has nothing to do with the technology itself, it has solely to do with a people mindset being afraid for change (and being scared of losing their jobs).
And yes, I think that cloud network admins who can not script within the near future lost their jobs to the people who can script.
Okay, but what about the server admins? what is wrong with them?
Well. ask a random server admin something about dynamic routing and they are lost. They simply do not have the necessary networking knowledge.
As with most disputes it comes down to communication: Server admins rely on network admins, but they talk a foreign language for each other.
SDN from Business perspective
Both camps share a common: They work for the same company, which has its own (business) requirements and which apply for both camps.
Agility, security and efficiency has to improve, as the sluggish and insecure infrastructure costs the business a lot of money. The server- and network admins are forced to work together to create a cloud-ish environment! What you see instead is that they are talking dirty about each others solutions (again, this has nothing to do with the technology itself) as they fear change (or their job).
From my opinion it is not possible that one solutions can solve the requirements for both camps. The picture below is taken from one of the slide during the “Deploying NSX Datacenter on a Cisco infrastructure” session and it clearly states some of the different requirements for both camps:
Again, both camps have their own requirements and should respects each others requirements!
Okay now the requirements are set, let’s move on:
Comparing NSX and ACI
YES, NSX and ACI do offer some of the same functionalities! They even share technologies, like (for instance) a Restful API, VXLAN, etc.
Both are a Software Defined Networking (SDN) solution, so it’s not rare that they offer the same functionality through the same technologies. Whatever solution you choose depends on the differences they offer! Not their similarities.
But why buying two solutions which offer the same functionality you may ask? The answer is quite simple: You’re choosing either a SDN solution optimized for the virtual Network Infrastructure OR the Physical Network Infrastructure OR for them both!
NSX offers optimized functionality for virtualized workloads and Cisco ACI offers optimized functionality for physical infrastructure. When you have requirement for both, it’s best to choose both solutions and let them work together.
for example: https://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-740124.html
What didn’t helped in this discussing is that during the beginning of the SDN-era, Cisco and VMware were fighting each other. Now, both parties have changed their vision and have laid down the hatch.
Silo’s are still present these days: the gap between network- and server admins still exist which is not beneficial for the business. From a technical perspective: both solutions can work with each other, fulfilling all necessary requirements.
It comes down to People, Process and Technology: Companies have to provide a safe environment for both camps to allow fluid communication between the network- and server admins, which as a result dissolves the different perspectives and the business goal can be fulfilled.