Last week I had the opportunity to attend the Gartner Data Center conference in London. I attended 3 different sessions on SDN-related topics. Here are some of my observations from what was a very good conference. Also, since the Gartner Data Center conference runs this week (w/c 1 December 2014) in the US, if you are going, here are some questions to think about when you attend the SDN sessions.
(1) What does “lack of visibility” in Virtual Overlays really mean?
(2) In multi-layer SDN, will SDN be cheaper than our current networking approach?
(3) Are Vendors Guilty of Using NFV for SDN “Washing”?
(4) If OpenStack is part of your SDN solution, can you help us on OpenStack?
(5) What is the best hardware server platform for NFV/virtualised workloads?
(6) How exactly does SDN deliver better network management?
I’ll cover a few questions today and some tomorrow.
(1) What does “lack of visibility” in Virtual Overlays really mean?
Or put another way … with Virtual Overlay SDN, do we receive alarms when the network breaks?
There has been some debate on “lack of visibility” when troubleshooting virtual overlay networks including VMWare’s NSX. What does “lack of visibility” really mean? In fact this is a good question to ask on its own! However let me help break this down a bit. Virtual overlay technologies make a couple of major assumptions on the underlying network, as pointed to in previous Gartner work:
(1) The underlying physical network always has sufficient capacity
(2) The underlying physical network is always working
To be fair, some virtual networking approaches have solved some or part of these problems, however what I heard at the conference last week was that VMware’s NSX has not. In particular, when for example you pull a cable out of a switch in the physical network, the NSX overlay does not know that the underlying physical network has broken. Given that cable pulls in error are a common source of data center outages, this is not an uncommon network fault. So … the question you should be asking is – can you afford a networking solution that is not aware of basic network faults? This is what “lack of visibility” means. You don’t get the full set of network alarms. So make sure you ask this question as it’s worth diving into deeper. The second question on this topic you need to ask is to your network manager – is he or she happy with lack of alarms if and when the network breaks?
(2) In multi-layer SDN, will SDN be cheaper than our current networking approach?
SDN splits the networking models into multiple layers. It’s something like that shown below, with multiple vendors offering in some cases multiple products in each layer, and with different vendors in many cases playing in different layers:
I really like this model. On one hand, it shows the choice the designer/deployer of SDN actually has. And choice is good. However to me, it also shows deployment complexity. And isn’t it complexity that SDN is supposed to solve for networking?
To illustrate … here we have 4 layers, with multiple potential vendors in each layer. Of course some will advise you on a multi-vendor strategy, and they’ll say “choose best of breed”. So … what if you pick 2 vendors like you may do today. So that is 2 vendors … in each layer (OK that may be extreme but bear with me while we discuss the consequences of best of breed in such a complex layered model). So that’s 8 vendors. I make that 8×8 – 64 potential interactions However it’s even more when you include 8 software releases, 8 roadmaps, 8 patch streams (per release of each chosen product!) – got to be at least 8×8 = 64 times the complexity! And of course what is not loudly mentioned is that you will probably need a systems integrator to pull all of this together. So it’s more like 9 vendors you have to manage. How much will that cost? Makes Cisco ACI seem like a bargain!!! (It is, of course!)
So … the questions to ask on this diagram are ….
(i) If I choose a multi-vendor strategy across the various layers of SDN, how much will it cost to integrate all the components?
(ii) Do you advise we engage a systems integrator to pull together our SDN strategy? If so how much will it cost?
(iii) Will this multi-layer approach be cheaper that our current networking approach?
I personally wonder whether this kind of multi-layer SDN could end up saving you investment dollars on one layer only to spend way more on other layers and/or on pulling it all together. Food for thought.
(3) Are Vendors Guilty of Using NFV for SDN “Washing”?
I attended one presentation which was entitled “Software Defined Networking and Network Functions Virtualization” (SDN and NFV respectively) – but it really was just a pitch for their NFV product. That said, by definition, these are very different technologies. However I do see a lot of people blurring the lines between them. Witness for example the June 2014 SDN conference in London – it was more about NFV than SDN and OpenFlow, to be honest. I heard similar feedback from colleagues about the recent SDN and OpenFlow World Congress. To be fair to this vendor, NFV – in my view at least – has rock solid problem solving credentials and benefits. Sometimes I personally think that SDN is a solution looking for a problem, as many of the SDN use cases cited are specialist (for example, applicable mainly to large scale cloud providers only) – and I’m not the only one. Therefore so I do understand companies who focus more on NFV than SDN.
This particular presentation at last week’s Gartner conference was no different: it was mainly about NFV. Maybe it was because that particular vendor doesn’t have an SDN products – they definitely have NFV products – or maybe they are applying the term “software defined” more liberally. In any case, it’s worth asking about the differences in definition between SDN and NFV, and what part of their presentation really was about SDN – they certainly muddied the waters here.
Wrapping Up
Time, then, to wrap up for today. All of a sudden SDN seems complex, doesn’t it? That’s why in Cisco Services we have expertise in each of the areas mentioned above, SDN, NFV, OpenFlow, network overlays, OpenStack and more. We can help you exploit SDN in a way that’s best for you, helping you avoid the hype. Get in touch with us if you need SDN clarity.
And I’ll return to the next 3 questions tomorrow, Tuesday 2nd December. Follow me on Twitter to hear more.
PS: (Post publication edit): You can read part 2 here and part 3 there.
CONNECT WITH US