This is a re-post of my article, originally published on The Ravello Blog.

The advent of the cloud has brought with it major changes in the size and nature of networks. These changes pose new challenges for network management. Software-defined networks (SDN) have the potential for helping network managers cope with their ever increasing workloads.

In the public cloud, the network could be very different from what it is in the datacenter. By enabling the automation of network configuration, Software-Defined Networks make it possible to manage network interfaces in the same way as software.

SDN presents the network administrator with the option of handing some or all aspects of network provisioning and management to a third party. The configuration of the network, which includes things such as host names, IP address and firewall rules, is an essential part of an application’s configuration. The configuration can be performed on-demand through the same interface or using an API.

This approach is particularly relevant for large-scale enterprise deployments, where large workloads necessitate automatic on-the-fly configuration, and sometimes even multiple replicas of identical networks, maintaining complete segregation.

The SDN Market

The main players in today’s SDN market are Cisco and VMware. With the acquisition of NSX, VMware is currently promoting its SDN offering as the next step in the evolution of virtualization. NSX lays down an “overlay” network on top of your existing network with the aim of saving time on configuration, improving performances, and lower costs. Cisco, on the other hand, offers a solution that combines SDN and infrastructure. It enables you to define and enforce policies through application-centric infrastructure.

Unfortunately, SDN implementation is not easy – it is not compatible with default networks, and requires a lot of work on infrastructure.

Prospects for SDN Adoption

Despite the optimism of SDN proponents, it is likely to take time before the adoption of SDNs truly catches on. When the concept of server virtualization was first introduced, it was difficult to convince the enterprise that it was reliable to virtualize their workloads – to recognize their potential and make the necessary adjustments to enable their adoption. Similarly, the spread of SDN adoption will probably be gradual. SDN faces the challenge of overcoming decision-makers’ fears of losing control. It takes time to establish trust in any new technology and changes in organization culture rarely occur overnight. Ongoing developments in network virtualization and SDNs definitely merit monitoring and consideration.

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).

Another 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…

… 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..

Yesterday I read an article titled Martin Casado on VMware's 2014 Roadmap, the Competition, and SDN and the part on which I would like elaborate is the following

On the tactical level, meanwhile, Casado said that VMware's biggest market hurdle isn't any particular competitor or technology,
but rather "the traditional way of doing things" in IT. "Inertia in IT is surprisingly strong," he said. To overcome it, VMware and their ilk must convince enterprises that if they adopt network virtualization, it will not simply be just as secure as the traditional model, but even more secure; not just as easy to manage, but in fact easier.

"We need to convince people that flying is safer than driving," he said.

This sparked a conversation on Twitter 

Of course IT is the biggest obstacle to adopting SDN.

It was the same when server virtualization started out. Remember this slide?

It took 5 years (yep 5 long years) for virtualization to become default platform on which we deploy workloads, and this is of course is growing…

Why did it take five years? well there is a number of reasons for that and to name a few, product maturity, trust and of course "the traditional way of doing things" in IT. You have to learn to trust the technology, understand it, build a proper ecosystem around it - and educate, educate, educate!!

So VMware - with NSX and Cisco with ACI are in for a long haul. SDN is the natural and logical evolution in the ever growing and changing technology landscape.

• Do you really think that Network Admins are ready to give up control of the network to their Virtual team?
• Just give them a range of IP's and let them do what they want?
• What about firewalls?
• Who will ensure that what they do does not affect the rest of the network?

It will take time, I sincerely hope it does not take the same 5 years. Until that new evolution occurs, organizations change and the technology becomes well adopted and trusted, until then SDN will have a very long climb, up a very, very steep cliff.

I would also like to address the second part of the Twitter conversation.

It is not uncommon that the development part of the organization is the one that leads the way technology and their demands/requirements from IT.

• virtual machines for testing
• virtual machine for continuous development/integration

They do not have the patience/time/tolerance to wait for IT to provide the resources they need. That is how
Rogue IT came about.

The last time I saw someone bring up a DHCP server on the corporate network - it lit up so many red lights in the helpdesk that you might have thought it was a certain place in Amsterdam.

There are limitations (rightfully so or not, that is the question) on what you can do in the corporate network. You cannot do what you would like. Of course this brings a number of limitations to what your developers are trying to accomplish. And a good amount of these things they can get with a public cloud provider today, all they need a small piece of plastic.

A good amount of NSX is going to provide already exists in Openstack, and all in software. Routers, DHCP servers, load balancers, firewalls - it is all there, built-in.

One of the observations I had in the Openstack Israel 2013 conference - is that the adoption of Openstack is being led by developers, and IT is trying to play catch-up.

Developers will not wait for IT to implement an SDN solution - they will go out and do it on their own.

They already are!

Please feel free to leave your thoughts and comments below.

P.S. Flying is statistically safer than driving - but only a few of us know how to fly a plane and even fewer own one.

Almost everyone owns and drives a car.

The conversation continued in an additional post.