Where does SDN really fit in organizations? Will you be able to shrink network staff from 30 to 20 people? Does SDN change your network topology? What size organization is SDN suitable for? Just because something is possible, does it really make sense for your environment?
With all the buzz around devops the conversation has naturally progressed to the network. Since labeling everything Software Defined or Cloud is all the rage. First lets define SDN. Since there is no hard and fast RFC to define SDN, we can make a few generalizations.
- The general consensus is you need to have an API or scriptable interface.
- Additionally some people want a separation from the control plane and data plane.
Is software defining the world? Not so fast, there has always been a software component to any network switch and router. While architecturally the separation of the Control Plane and Data Plane may provide benefits. Generally it’s not anything your network administrator can configure. Which means in the end you won’t really change your day to day operations. Historically this separation stems from some of AT&T’s works in reconfiguring their networking hardware. They wanted a way to reduce complexity in reconfiguring and redeploying hardware. Later that quest created OpenFlow which has led to new management methodologies.
The other benefit of SDN is automation or orchestration with API’s. It would really be beneficial if we rebrand Software Defined Networking as Scriptable Defined Networking. But scriptable networking sounds less friendly to the marketing department. We have had scripting in Unix since the 70’s. Even Windows and MacOS support scripting. Could it be our rush to devops has clouded our judgement and lead us to the tired mantra of “Software cannibalizing the world”? Well not so fast. There are some use cases.
1) Error Reduction. It has been estimated that 30% of outages are from misconfiguration. Others estimate 80% of outages stem from some human interaction. When deploying net new infrastructure by leveraging scripts to deploy it we can ensure there is no misconfiguration, configuration drift, and reduce deployment time.
If we want to look at this from a day to day perspective the benefit could be less. Many network administrators like to double check and triple the check before committing changes. Which is why we have 100 ways to display ip and routing information. You could just as easily fat finger a script as a CLI entry so the value is less. But organizations with very mature ITIL might want adopt SDN as a way to reduce network changes by limiting it to only the script being deployed. That being said if your script causes an outage you might fall back to manually working on the network.
2) Staff Reduction. Day to day operation, you still need to create changes, deploy new services, and troubleshoot. Does adding the ability to create a script vs manually do this actually save time? It depends on the organization size. If you are a small to medium sized organization probably not. This stems from you still need to spend time planning, analyzing, creating test plan, roll back plan etc. If you have routine tasks like service providers you might gain some advantage.
Does this mean you can fire everyone? Pretty doubtful as most network teams are very busy answering false alarm triggered by the application team. Many network teams are now being tasked to support Telephony, Video, Wireless, and now Security. Those additional burdens along will probably prevent shaving any headcount.
3) SDDC. SDDC is Software Defined Data Center. This for all it’s marketing hype is really orchestration. Some SDDC visions have followed SDN by trying to separate a control path and data path. This Control Path would be for management and Self Service Portals and Service Catalogues. While the Data Path would be for Data Services (Block or file etc).
If it was possible at a high level to create a SDDC policy, then via SDN you deploy it. You could revolutionize how IT manages devices. EMC VIPR and Cloudtopia (Now Cisco UCS Director) have some interesting features. But we are a long way from SDDC managing network infrastructure.
4) Switch/Router lifecycle. If we go through the lifecycle of Network gear depending on the phase, SDN could have different uses. As mentioned above, when we initially deploy the infrastructure given enough time to plan, we might reduce human errors. If we are configuring something that takes an hour of several steps, its easy to forget or fat finger a command. Once a device is deployed we are in our day to day operational phase. If its a constant repetitive task clearly there could be a benefit. But if it’s a one time event or rare task, it might even distract from our ability to work. Applying changes is always something thats a bit interactive, we look at the config, apply changes, look at the config again, and test. By taking out some of those steps with scripting we need to ensure we have a more robust test plan. Finally for decommissioning of hardware, SDN would provide little value when your typical step is to copy the config and recycle the gear.
5) Multi-tenancy. I will admit I didn’t initially think of this. I met with a local university a few weeks back and they have a mult-tenant environment. They let other universities put workloads on their environment. The other universities would need to open tickets to change the network infrastructure. This process could take weeks. Their solution was to expose an API they could use so they change the infrastructure themselves. Essentially a self service portal into the networking infrastructure.
SDN Value Based on company size
The very scale of Service Providers could benefit from SDN. The scope of repetitive tasks is pretty immense. Additionally these organizations have many talented senior network administrators with some scripting backgrounds.
Pros: If you have very mature ITIL, in theory you could submit a script to create a change.
Cons: Many of the current SDN solutions only work for the Data Center layer. This can create multiple network architectures to manage. Additionally you may need to train your staff on the technology as well.
Small to Medium Sized Companies
If you have mixed IT staff. People who support Networking + Wintel + Storage or Virtualization. You could easily increase the complexity to where it becomes a detriment to your organization. There might be some value in consultants who help deploy network services.
The take away:
Rarely is there only one right strategy which works for every company. Most companies have very stable networks which are custom built. Every environment is different so give some feedback on your thoughts?
Robert Illing is a Field Solution Executive focused on helping organizations modernize their Data Centers.