While I’ve been writing about Cisco Domain TenSM, I’ve been watching the SDN debate evolve in our industry, and I have to say, I’ve had my concerns. Don’t get me wrong – I personally see SDN as an important and very much required evolution (and note: ‘evolution’ – not ‘revolution’) of the networking industry. Being able to extract more value from the network – through, for example, a consistent and broad network API – I mean, who wouldn’t be excited about that! And especially for us in Cisco, with the largest by far networking installed base, the ability to uncover and exploit additional value for our customers from the network can only be a good thing!
As I say, over the past year or two, I’ve been perturbed about lack of discussion across the industry about the adoption and deployment challenges associated with SDN. There is – bluntly – too much “nirvana” or “marketing promises” out there, too much focus on the end result (e.g. “look at our use case, wow isn’t it great”) without discussion of steps required for a success, and too little discussion on the costs and challenges of the design and implementation of SDN solutions (e.g. “took us X man years + $M of investment”). It’s now time to change the discussion.
I was therefore delighted to see Jim Meltzer’s discussion of the issues he was seeing with his clients regarding SDN.
This discussion was music to my ears. At last someone was talking about the realities and challenges. Here are some of his key observations regarding the SDN (dare I call it) “hype”:
- “Customers are very concerned about their ability to manage [SDN devices]” … and …
- “What to do when something goes wrong …. There is very little discussion in the industry, including at the ONF .. [about this]”
- “How do I build the business case?”
- “What new security vulnerabilities will I have [in this new SDN controller]?”
- “Applications can dynamically request services from the network … how exactly does that happen?”
These are all very important points, to which I will return later. Let’s first consider the challenges of new technology adoption. Here I often think about 3 aspects – the “What, the Why and the How” -- when it comes to a new technology, as summarized in the following diagram.
Defining these ….
- The “What” – from an SDN perspective, is the industry discussion that has been on-going – about technologies, protocols, approaches, products, and standards;
- The “Why” – specifically “why” is this new technology good for me, what can it do for me, what business problems does it solve, why do the benefits help address my challenges, and so on;
- And the “How” – OK, how do I gain these benefits, how do I get this to work for me, how do I make this happen, how do I deal with problems when I get into production.
Going back to Jim Meltzer’s discussion above, he is one of the first to broach these topics. At last someone is asking on the “Why” – specifically around the need to build a business case. And he is also talking about the challenges of the “How” – especially around the support model for SDN deployments. He also implies on the need for software development of applications to “dynamically request services from the network”. Here then is one of the “secrets” of SDN, buried in the “promises” of cheaper networking devices – additional software development may well be required You don’t get this for free, and many will need to make substantial software development investments and/or purchase upgraded applications (when they are available). Hence it may be wise to consider a Return On Investment (RoI) analysis to ensure that an SDN deployment of “cheap and dumb switches” is not dwarfed by the associated software development, integration and support costs.
Of course, I’m not advocating that you use this lack of clarity as a reason for avoiding the opportunity. What I will advocate is this: to move fast into the SDN world, to ensure you evaluate all the options open to you (SDN is a lot more than the OpenFlow protocol after all, and Cisco ONE encompasses both), you’ll need professional services to help you figure out if SDN is relevant to your business, to develop the appropriate adoption strategy, to build the business case and test and validate the technology in your environment.
Additionally, since this is “Software” Defined Networking, much of the solution will be in software, not just hardware. Hence professional services to help you develop, extend and integrate SDN controllers, applications and associated management and orchestration tools will be a key customer need.
Finally – and perhaps most importantly, it’s also clear, from Jim Meltzer’s discussion above, and his observation that….“What [do you] do when something goes wrong …. There is very little discussion in the industry, including at the ONF .. [about this]” …. that Technical Support Services will be a major requirement for the majority of customers. SDN will give you a lot of power and flexibility -- you can even change control plane behavior . Perhaps someone in your team will figure out how to do just this, and make changes to your network behavior without proper impact analysis, scale and load testing. What will you do if and when it breaks, and who do you trust to be your network support partner? Indeed who is best placed to help you avoid such issues in the first place?
Which brings me to my headline, what indeed is the “Missing ‘S’ in the SDN Debate”? For me, it is the “’S’ word”: Services, that is consulting, professional and technical services, to help you “Plan, Build and Manage” this next evolution in the network. To date, there has been some, but not much, discussion around the services most customers will require to exploit the potential of SDN and Cisco ONE. Over the coming weeks and months, I’ll tell you more about our professional and technical support services around Cisco ONE, Cisco’s strategy for giving you choice in the SDN debate.
To conclude, there has been plenty discussion around the “What” of SDN. It’s now time to discuss the “Why” and the “How”. It’s now time for Services, the “Missing ‘S’” in the SDN debate, to be discussed as a central issue and a critical customer need. While others are supporting only a single path to SDN, with the choices available in Cisco ONE, it’s now time to examine which route to network evolution is right for you. And who better than Cisco Services, with our networking heritage and R&D insights into Cisco ONE, to help you evaluate these choices and lead your network evolution with Cisco ONE. Watch out for what we in Cisco Services are doing around SDN and Cisco ONE in future blogs. And if you are attending CiscoLive in Orland later this month, please do look out for our “Design Centers” where you can discuss your SDN questions with our solutions architects.