SDN Adoption Is Not As Easy As You Think–Take #2

Kendrick Coleman wrote a post today titled SDN on the Horizon, get ready – where amongst other things he stated:

If I were a betting man (and I am, considering I am avid horse racing fan), VMware's NSX is going to get a pretty good stronghold on its existing customer base. It's VMware for Pete's sake. If it has the brand and the label, then a majority of customers are going to buy into it for their needs because having that single vendor relationship makes sense.

This sparked a interesting change of opinions and discussion on Twitter.

I would to elaborate on the 4 points I mentioned in my tweet.

1. Silos

In most enterprise environments today – there is a separate network team, perhaps a separate storage team, and a separate server team. They work together on a daily basis – and probably get along very well with each other – they need to for their day-to-day functions.

But.. they each have their own area of responsibility. Storage admins will not have administrative access to the network switches or VMware environment, Network admins will not have administrative access to the storage array or the Vmware environment and the Server admins will be able to configure the storage arrays or the network switches. These are the separation of duties that many organizations need to have due to regulatory compliance requirements. From a security perspective these are sometimes essential.

Virtualization Admins today have to request storage resources from the storage team – and network ports, subnets and sometimes even IP addresses from the network team in order to make their virtual environment operational. Of course some of this can be offloaded – i.e. allocating subnets and IP addresses to the server team up front, and the same goes for storage space as well. But inevitably the teams are separated and each has their area of responsibility. This is cumbersome, it takes time, and is often a cause for major frustration.

In an utopian world – the Server/Network/Storage team would be one and the same – but that is not how it is today.

Each of these teams have been accustomed to working in a certain way – they have over the years, come to accept delegation of some of the responsibilities to other teams but there are certain things that are still managed solely by a single team.

It is a question of politics, ego, and trust – all of course can be overcome but that does not happen in a day (even Rome wasn’t built in a day).

2. Price

This is something that irks me (and possibly other as well). NSX went GA last year at VMworld.

  • Since then – not a single piece of software has been generally made available.
  • Not a word has been revealed about pricing – except the fact that it will probably be priced at a per VM model (with is something VMware customers DO NOT LIKE!!) (
  • An engagement with VMware PSO is mandatory (at least currently) for an NSX deployment – that could mean additional cost – training.

Of course this all depends on your environment and for some people the price of a product is negligible to the added benefit it brings to the company, your mileage may vary.

One last thing. Your company has already invested in your physical network infrastructure, paid from the budget, and continues to pay for maintenance and support every year, and equipment refresh every X amount of years. If my understanding is correct (and if not – please feel free to correct me) NSX is not a replacement for your physical Network infrastructure – it goes on top – meaning you will still need the physical network components – and in addition the new SDN components
(and I will not use the word tax)

3. Complexity

Introducing a new technology into your datacenter has a price. Be it time, be it $$$, be it training, be it changes that need to be implemented (such as an upgrade to vSphere 5.5 which is mandatory).

blackboxAnother thought I had here was the issue of the concept of a “black box” – and I would like to explain here what I mean.

VMware are looking to sell NSX to the virtualization / server teams – at least this is what I am hearing. They are not pitching (at least not yet) to the Networking teams nor to the Operations teams. (perhaps for obvious reasons)

The way I envision NSX is as follows – give the Virtualization people a segment of the network that they can manage as they like. NSX takes control of that block and does all the work internally. Which is a wonderful thing for these Admins. No more dependency on the networking guys to deploy ports, networks, configure VLANS, setup Load Balancers, Firewalls – it will all be controlled with the virtualization team. But for the Network Admins (and I will play devils advocate here for a moment) this could be a potential nightmare. A significant piece of equipment/technology (and yes it is significant – because no-one will deploy NSX for 100 VM’s) has just been placed in my topology – and I have absolutely a different level of knowledge of what is happening within this black box (I was going to use the word absolutely – but that would not totally true).

A few examples come to mind

  • QoS on the traffic in the box – how will that be implemented?
  • Traffic monitoring with current tools – will not be possible – because the insight into the network is not at the same level as current infrastructure. So now I need two tools. (single pain of glass)
  • Troubleshooting – who does the troubleshooting inside? Network team – they do not have access/control. Virtualization team – they most probably do not have enough in-depth networking knowledge to do this.
  • Who says that the internal traffic will not have any effect on the external network?
  • The blame game. Virtual admins are accustomed to hearing that it is the hypervisor’s fault, they are accustomed also to blaming the storage team for disk bottlenecks. Guess where the fingers are going to be pointed next?
  • Does NSX have any insight into the physical network – if for example there is a problem in one of my core switches – will NSX know anything about it – will it be able alert on such issues – so that I can point the networking team to the problem? Today ESXi can tell you when a physical cable is down – I am not aware if this is true or not with an NSX solution.
  • What happens if something gets compromised inside the NSX environment and proposes a security issue for the rest of the network – will the network team be able to identify the source with the same ease as they do for the physical environment – will there be an IDS/IPS solution that will work for both the physical and the virtual – or will again two different solution be needed?

4. Maturity

NSX went GA less 160 days ago (August 26th, 2013). Yes, there are some customers that have jumped feet first into NSX, even some really big ones. Not many enterprises will deploy a first version of a software product. There are many risks, many unknowns – many question marks and things that “will be fixed in the next release”. We never deploy x.0 releases at time of GA, NEVER! - why you may ask, because there are always bugs, always. And in this case replacing the complete network will is one heck of a major change. It could be that the reason that the years before 2005 were not even mentioned on this slide…

Number of VM's

… was because until version 2.5 (2005) the product was not mature enough? People did not trust it? Was it justified? I am not saying yes or no – but the numbers are there.

Today, when you say virtualization to someone VMware is seen as the leader, the visionary, and rightfully so! It took a LONG time to get there.

I would like summarize and make something clear.

SDN is the natural next step, be it ACI, NSX or whatever. To manage our networks the way we are doing today will not work in the future – just the number of devices that are connected – and will continue to climb with the IoE – it will have to change. The same goes for storage that is why the SDDC is the correct vision, the right direction and we will get there, eventually.

2014 will not be “The year of NSX”. SDN is right technology, but there are many obstacles that block technology (Self driving cars is a wonderful example). Some of these obstacles are easier to overcome than others, but there is one thing for sure.

It will take time.

Your thoughts and comments are very welcome..