Last week I started my SDN reflections on the London Gartner Data Center Conference, and I found I had quite a lot to discuss.
Last week I covered:
- Do we need SDN?
- SDN and the Gartner Hype Cycle
- SDN Deployment Models
So here is the concluding part. This week I’ll cover:
- Overlay-Based SDN — and the questionable assumptions being made by others in this area (good for Gartner for calling these out!)
- The SDN Vendor Explosion Challenge,
- The “Unspoken Costs” of SDN Deployment, and
- The “How” of SDN is still missing.
I hope you find this useful and informative and as always, feel free to debate with me around my observations!
Overlay-Based SDN
Cisco’s Padmasree Warrior has already been vocal on the challenges of taking a software-only approach to SDN. It was good to hear healthy recognition of these challenges at the Gartner conference. In particular, there is growing recognition that VMware’s NSX approach makes 2 critical assumptions (which I am sure you may find concerning):
(i) the (physical) network has plenty of bandwidth: so be prepared to “over provision your network” is what I heard wrt NSX adoption, and
(ii) the (again underlying physical) network is always working – “Is it ?!?!” I hear you say – so the reality of troubleshooting multiple network layers is indeed receiving attention. If you’re like me, you will know that networks are terrific but occasionally they do need serious troubleshooting from time to time … and concerns were raised at the conference on how NSX’s overlay approach would hinder this.
The SDN Vendor Explosion Challenge
At the conference, I heard the market landscape for SDN described in terms of 4 layers:
- Device providers
- Controller providers
- Application providers, and
- Service providers (e.g. firewall services etc)
In principle, if you decide on a multi-vendor strategy, you could envisage ending up with say 8 suppliers (2 for each of the 4 layers), giving a total of 8 vendors … compared to say the 1, 2 or 3 vendors you may have in your network today. Can you imagine the complexity? Imagine having to align roadmaps across all vendors, test that they all inter-operate and so on. Who will help you troubleshoot the interactions between multiple components and multiple layers? This unfolding market is not simply an N2 problem, it could be an N8 problem of complexity!
What I take from this, therefore, is that you should select very carefully who you partner with for your SDN needs. It may well be that “less” is indeed “more” and that the solution providers such as Cisco are much more attractive and offer lower “total cost of ownership” across the whole solution.
The “Unspoken Costs” of SDN Deployment
Everyone is saying it. I even heard it at the conference: SDN ….”Promises the ability to leverage low-cost hardware (e.g. white box switches)“. When you consider the planning, integration and troubleshooting costs that I outline in my previous point, it’s easy to project that SDN may not be the “cheaper nirvana” that some are saying. Sure, you may get additional flexibility and agility from SDN technologies, I for one am not hearing anyone say it will be cheaper. In fact the “total cost of ownership” was not raised at the conference, reflecting the “loud silence” on this we hear across the industry. So …. make sure your SDN deployment partner can help you understand these “unspoken costs”.
The “How” of SDN is Still Missing
Im my first blog on this topic, I outlined the market’s fascination on the “What” of SDN – the features, protocols and specifications. I made the case that the “Why” (“is it specifically good for me?“), and the “How” (“can we get it done“) were missing. And that’s not changing fast enough, there isn’t in my view sufficient focus across the industry on how you really can exploit the promise of SDN. There are some exciting options where Cisco ONE can help address pressing networking challenges and help you generate innovative services and solutions – so how can you get started?
This is where Cisco Services comes in. We have worked hand in hand with our Cisco R&D counterparts as the Cisco ONE and ACI technologies have been developed, and we have developed a rock solid methodology for evaluating and deploying the SDN technologies in Cisco ONE, all the way from helping you identify the key use cases for SDN that will add value to your business, right through to performance and scale testing to ensure your solution operates and performs as you specify it. Please, then, get in touch and we’ll be happy to help you find the right path to SDN success.
Thanks for an interesting write up! Since Cisco has been one of the proponents for the development of OpenFlow, do I take it that you see a promising future of OpenFlow implementation in SP environments, please? Background of OpenFlow is ability to be implementable on COTS hardware, make deployed networks configurable and also programmable and offer increased control of custom forwarding of packets. All these do point to increased adaptation of API’s, as I think is indicated above. OpenFlow has been adapted in most network gears and also in Stanford U.’s own network and GENI project and there has been some talk of adaptation of the same in MPLS based network with split-router model.
Irrespective of which models are championed by respective vendors, do you envisage effective and widespread SP adaptation of OpenFlow in WAN in near future please? This keeping in mind the issues OpenFlow currently has with GMPLS (control plane complexity, fragile distribution routing and signaling protocols etc.).
Thanks a lot!
Best regards
santanu
Santanu,
First, many apologies Santanu, for the delay in my reply – busy days indeed! Time will tell on OpenFlow – I personally can’t see major deployments in SPs *in the short term” – for 2 major reasons
(1) It takes a long time for telcos to re-engineer their networks, they are focused on resilience and scale, and proving any new technology in these environments takes time.
(2) And …. purely because this technology IMHO still has to be proven at scale and in major corporations. While I appreciate Amazon and Google have good successes and are the “poster child” case studies, their range of use cases (partic I would argue Google) are somewhat restricted compared to SPs (e.g. Google is a search company, most SPs are offering a broad range of services).
Selective use of OpenFlow could be very interesting when combined with NfV approaches and may help re-engineering of CPE-based managed services, for example.
Of course, we’ve now seeing widespread interest in Cisco’s ACI which is a game changer for re-thinking about data center networks, so look out for ACI having major successes in the data center.
Stephen
Many thanks for the clarification Stephen! Really, no need to apologise about the delay, please! As you say, busy days for us and the industry :-). I personally concur with you about OpenFlow in SP sphere. Having worked in SP space in EMEA for over a decade, I totally concur with you about adoption time for new technologies. Scalability is definitely a factor.
Cisco’s NFV vision definitely breathes energy. If allowed to be extensible and combined with OpenFlow, then that will bring in interesting times for certain block of SP based services, as you have rightly pointed out.
Thank you for another superb write-up!
Best Regards
santanu
Thanks again Santanu – much appreciate your kind comments. NfV is a key topic as you say, I’ll be writing about that in due course.
Thank you for sharing this Stephen. There is little doubt that in the era of the Software-defined Data Center, SDN is where all the action is. And SDN deployments in hybrid cloud environments ought to be one of the sweet spots for increased adopton. However, the flip side of new features and new functionalities is that there are almost always new challenges to face.
Regards
Jasdeep
Thanks Jasdeep. I like the way you call out “sweet spots for adoption”. As you have recognized, and thanks for this, I am trying to balance the SDN debate. It’s too much like rose-tinted spectacles for me at times. Consequently, I’m trying to ensure that you know about some of the adoption challenges, so that you have time to work out ways around them (and I hope you consider Cisco Services to help you navigate the challenges).
Nice summary of some of the management issues with the SDN implementations. We’ll done, Stephen.
Thanks Josh!