VCDX-NV and the Missing Bit
As probably many of you already know, I’ve been part of the early NSX Ninjas program, leading to the obtention of both VCDX-NV and VCIX-NV. This was a great experience, however I wanted to take the opportunity to give my opinion about what I think is currently wrong with those two certifications today.
A Lack of Networking Skill Set Validation
From a background perspective, the first statement from VMware was that NSX should not be put in the hands of people without knowledge of the product and that was indeed a very good approach. The risk with NSX is that as it’s very easy to install and configure, you don’t necessarily have to know what you’re doing or have the ability to measure the impact of your actions. As a result, one could just complain about the solution not working or not being relevant. Before playing with NSX you have to be aware of the different constructs inherent to the technology. This of course includes NSX components such as DLR, ESG, transport zones and more importantly VXLAN concepts. The official NSX training does a very good job teaching how they articulate, but in my opinion VMware is missing a critical point: how do you verify the network skills of the candidates?
I mean knowing NSX concepts and what NSX does is one thing, but knowing what it does to your network is something else. Does any of the VMware certification guarantee that a VCDX-NV, VCIX-NV or VCP-NV holder who may effectively talk to customers knows what a NSSA area is, knows the difference between OSPF point-to-point and broadcast network, or have any clue about OSPF LSA types? Ok, you could argue who cares… but the network team does as you’re going to mess up with their toy!
For the time I’ve been in IT, I’ve noticed that there is a gold rule which says that when a problem occurs it’s always the network fault! So network engineers are generally very careful about what you plan to attach to their network and you’d better be prepared to justify your design choices, including considerations around L3 control protocols, such as BGP, OSPF or even IS-IS. If you fail to understand those protocols and the impact of adding NSX to the network, then you probably can’t argue in front of a decent network team. To me it simply means that the expected “VCDX level” can’t currently be reached without the verification of this knowledge. To prove what I’m saying, do me a favor and download the VCDX-NV blueprint. Then look for the words “OSPF” or “BGP”.
The Fear of the Network Engineer
And here is another problem, because of the lack of verification of network skills, a large amount of partners will end up selling NSX to the Server teams. If you ONLY do that, you will lose. Why? Because SDN is also about the ability for the server AND network teams to understand each other needs and requirements and how the solution will meet those. This means that if you’re not fluent in both languages you’ll have to adopt a weird attitude which translates into “running away as soon as you see a network guy trying to talk to you”. That being said, it may have a good impact on your lifestyle as you would also have to go to the gym more regularly to practice…
Undoubtedly the only solution for VMware to become credible in the networking world would be to depend on other vendor certifications and define them as a prerequisite for their high end certifications. This was somehow the case when they proposed current CCIE holders to take the VCIX exam without other NSX training requirement. But this is just not enough…
Networking is not about Cisco
Also why only CCIE? There are other high end accreditations that are as valuable, such as JNCIE or HP Master ASE Network Infrastructure. But either way, the strategy that consists in ignoring the network you’re peering with on the pretext that your software is going to save the world is not consistent. The wire is still there and you have to deal with the underlay, but not in the same way as current VCDX-DCV have to deal with storage for example. You can still choose your storage, go for NFS or FC, even local drives if you want. The thing that makes NSX unique in terms of where it fits is that you don’t have the choice, this is a constraint, the underlay is there and it can’t just stay as an opaque component. Maybe it will change the day someone creates Software Defined Fiber or Software Defined Copper, but in the meantime you have to get it right.
Alternatively, an other consistent, end-to-end software/hardware strategy is the one currently adopted by Juniper or HP, which consists in leveraging white boxes along with a very specialised NOS (Network OS), designed for SDN, such as Cumulus or Big Switch. Of course I didn’t mention Cisco ACI because it does solve so many other DC challenges that considering it only as a SDN technology would be too simplistic!