Never Mind Your Suppliers.... Are YOU Ready for SDN?
In examining Cisco IOS-based networks, it is not unusual to find multiple versions of IOS at work. I'm talking tens of versions of IOS operating across the entire network. I've seen networks with more than one hundred versions deployed.
Software-defined networking (SDN) technology advancements, product developments, solution deployments, and supplier acquisitions are accelerating. As an analyst, I know I am kept very busy (and driven a bit crazy, quite frankly) tracking this acceleration. As a network operator, I am sure you, too, are also spending more and more of your precious work time sifting through an increasing number of SDN announcements and pronouncements from suppliers big and small, old and new.
While time and energy spent passing judgment on onrushing SDN solutions and suppliers is worthwhile, it is also just as valuable to evaluate your own network -- and your own network practices -- in preparation for the inevitable SDN adoption to come in the months and years to come. For help with your "passing judgment" effort, contact me and I'll send you a copy of the following document:
So how do you prepare for SDN? Well, first off, you've got to take a hard look in the mirror and examine your present networking environment and network support practices. Given the breadth and depth of the potential impact of SDN down the road, I will state up front that the following represents only the beginnings of a full and complete "look in the mirror" with respect to your SDN readiness. But it's a start...
How consistent is your networking software environment? And how solid are your software support practices?
In examining Cisco IOS-based networks, it is not unusual to find multiple versions of IOS at work. And I'm not talking about a few distinct versions operating within specific network segments and device types - e.g., branch routers, access switches, core switches, head-end routers. I'm talking tens of versions of IOS operating across the entire network. (NOTE: I've seen networks with more than one hundred versions deployed, so dont feel too bad.)
And this is not meant as a condemnation of Cisco alone, you can also find this same kind of software diversity in networks deployed by other vendors as well. Is it the vendor's fault? Yes. Is it the operator's fault? Yes. With both vendors and operators willing to look the other way when their networks are up and running, it is no wonder networking software is left mostly unchecked. Hey, if it works, don't fix it, right?
Combine this lassez-faire software support practice with the often cited statistics that point to software faults as the root cause of many, if not the majority of network slowdowns and failures and you have the makings for the software jigsaw puzzle at work within so many of today's networks. With SDN, this jigsaw approach will not be acceptable.
The level of dependency among SDN-enabled devices and controllers and applications is nothing like we've seen before in networking. The time to streamline your networking software environment and establish proactive networking software deployment, configuration, maintenance, and enhancement practices was yesterday.
Do you have the right hardware platforms in place to support a low-impact, incremental SDN rollout?
While SDN represents a sea change in networking, it's adoption lends itself to evolution - not revolution. Here, SDN solutions can be applied to specific problem areas initially -- and spread out over the network over time.
Moving to SDN does not mean a wholesale network changeout. You want to deliver SDN capabilities and returns to your data center network? You can do that. You want to deliver SDN to your branch network? You can do that. Even better, with some planning (and maybe a little luck!), you may not even need to do a wholesale hardware platform changeout even within those network segments you target for SDN deployment.
Here, a low-impact incremental SDN rollout depends on one thing... SDN-enabled devices deployed at your point of attack for SDN. Where is your first point of attack? Where will SDN have the biggest return for you? What is the SDN roadmap for the networking devices in that segment of your network? Are they ready to be upgraded to SDN-enabled control software? Are they ready to be actively directed by your selected SDN controller? What is the effect on existing services and policies and practices aimed at that network segment? Where does your vendor stand on taking the devices you have currently deployed into the brave, new world of SDN? Are your branch routers destined for OpenFlow capabilities and SDN controller support? Are your data center switches able to support the network virtualization thrust you plan to make in the new year?
You might not like the answers you hear from your suppliers, but it is important you ask the questions. Knowing where (and when) your existing hardware platforms stand with respect to future SDN functionality will have a big effect on your SDN targeting -- and even potentially your near-term network upgrades.
Are you comfortable with your level of visibility and control across your network? Do you have a good sense of your application profile (e.g., bandwidth usage, traffic flow, response, etc.) across your network? How have you leveraged policy-based management across your network?
While these would seem like elemental questions for anyone operating any network, the answers to these questions also serve as an indicator of SDN readiness - or even neediness. At its core, SDN delivers heightened control over networking and networked resources, while at the same time, reduces the necessary system and support requirements associated with exerting this greater control.
Sounds like what you've always hoped for, right? Well it is and it isn't. On the one hand, SDN will simplify and strengthen network management by consolidating, automating, and virtualizing your networking environment. This will free up networking (and computing) staff from many of the micro-management tasks associated with today's networks. On the other hand, SDN will drive a new set of network management responsibilities -- and related practices and expertise.
With SDN, the focus turns from how the network is running to how the network is being used. In-depth knowledge in such key areas as application demands, usage and access policies, and virtual machine connections will be of high value. While we would all love to see the network profile itself, generate its own self-directing policies, and adapt readily and accurately according to its own learned expertise, the reality is that you will need to not only set in motion your SDN environment, but also ensure that it stays in motion. To do this, you will need up-front and ongoing in-depth knowledge about your network -- and the traffic that traverses it.
Are your networking and computing environments linked technically, organizationally, practically...?
SDN technology will drive a tighter linkage between your networking and computing infrastructures. Here, the SDN-driven network will ebb and flow according to ever-shifting computing requirements. And by computing requirements, I mean to include both traditional business applications (e.g., CRM, ERP, etc.) and non-traditional business-critical applications that are absolutely network-dependent - web portals, IP voice and video, web conferencing, etc.
Nowhere is this networking/computing linkage more in evidence than with the new-wave network virtualization systems being offered by such companies as VMware/Nicira. These solutions are a far cry from the virtual LAN (VLAN) functionality we have grown to know and trust over the past two decades. These new-wave systems deliver the resource effectiveness and efficiency gains associated with server/storage virtualization to the network by providing a layer of abstraction between the networking and computing infrastructures.
In essence, they act as go-betweens for the networking and computing environments. They track the activity status and operating condition of both sides. They talk both languages. They know the capabilities and requirements of both environments. To do this, these systems must know both the networking and computing environments intimately. Do you have any network staff in place that can make this same claim? Do you have CCIEs on staff that know the ins and outs of VMware? Do you have VMware experts in the data center that know the ins and outs of your network? At a higher level, how are your networking and application development staffs linked? Are they in constant contact and closely aligned? Or do they only interact when a new application rollout is scheduled or a, application-specific network problem arises. As our technology linkages tighten, so too must our IT practices, systems, and staffs
Are you committed to a single vendor or multi-vendor networking environment? Is it time to re-evaulate? Or is it time to re-commit?
Many arguments are made for and against these divergent approaches to network sourcing, I myself, can argue both sides quite convincingly. That indicates to me that both approaches can be equally effective in the right circumstance. The key is you must properly manage the sourcing approach you choose. If you commit to a single vendor, are you doing everything you can to take advantage of the streamlined support structure and services delivery mechanism this presents? At the same time, are you protecting yourself from vendor lock-in and premium pricing?
If you're operating a multi-vendor network, are you working to ensure that you strike the right balance between technology effectiveness and spending/support efficiency. SDN presents increased technology/product/vendor choice and controller/device competition within the network - and even within specific segments of the network. Network choice and competition is heightened further by the increasing influence and availability of SDN "applications" that target such key areas as policy management, network virtualization, and application delivery. SDN's modular design, open exchanges, and application intelligence will serve to undercut both the multi- and single-vendor network sourcing approaches.
Owing to the interdependencies of controllers, devices, and applications, those operators that favor a multi-vendor approach will likely be forced to narrow their vendor choices. Owing to the intense demands of delivering complete and competitive controller/device/application solutions, those operators that favor a single-vendor approach will likely be forced to widen their vendor choices. The breadth and depth of SDN solutions make managing networking vendors -- one, two , or ten -- a more complex and challenging task. Are you ready for this challenge? And be honest.
As stated previously, this is just a start. But you've got to start someplace. And with SDN accelerating, it's good to start sooner rather than later. Even small hurried steps taken now will pay big dividends later.
I welcome all comments on the above views into SDN readiness. And I especially welcome other views you think are critical in filling out and completing that SDN-driven "look in the mirror."
