SDN Post-Deployment Considerations

A geek marrying a geek is a mixed blessing. She’s a Mac-head; I’m a Linux guy. It was an inter-faith marriage. Our division of home IT worked out to her getting desktops and home entertainment and me picking up the network, security, and anything that drops to a Unix shell. I definitely got the better deal until she hatched a plan to replace our DVD player with a Mac Mini way before Apple TV was an option.

The first movie we watched was "Blade Runner," which seemed apropos for our forward-looking entertainment system -- until the voice and video fell out of sync. Turned out to be some zombie process sucking up a bunch of CPU. With a kill -9 command line to terminate the program, things were working again After all this, she ditched the Mac and switched to something you could find at Circuit City.

I’m reminded of this story as I think about life after software-defined networking gets deployed. SDNs, like our Mac Mini, promise incredible programmability, flexibility, and agility. However, after we got it we realized we really needed an appliance that worked. Did that make it a failure? No; we just didn’t have a plan for what to do with it once we had it. No plan, no value. Therein lies the greatest weakness of SDN: Without a plan to exploit its capability, it is an over-complicated network switch.

So what should we be thinking about with SDN? I previously blogged about working out the problems and framing them in the context of applications. So let’s say you’ve done that and it’s day one with your new and shiny SDN. Now what?

There are three things to consider:

1. It can be programmed, but can you?

One of the greatest strengths of SDN is that it can be dynamically redefined by the administrator using little more than a few API calls. However, there is a bit of a caveat: Is your team investing in the scripting skills to take advantage of this capability?

While modern SDNs can be configured using admin-friendly user interfaces, their real strength comes from their ability to have networks’ creation, removal, and reconfiguration completely automated. If you haven’t invested in your team’s scripting skills, make it happen. It will be the difference between an over-complicated appliance and a tool that enables a far more flexible business.

2. Setting expectations and mitigating risk

The technology of SDN has matured to the level that it can reliably run networks at scale. However, our experience with the technology has not. As a result, many administrators have taken to running parallel networks: a new SDN with new procedures and new apps and their legacy n-tier network.

This allows administrators to set reasonable expectations up front and mitigate the risk of site-wide outages by transitioning one application at a time. Thus, any issues with an application, the SDN, or the automation of the network can be carefully managed without having to worry about site-wide outages.

3. Adjacencies and new values

Networks are rarely made of switches and routers alone. The menagerie of firewalls, proxy servers, and load balancers are equally critical elements of the network. As your SDN gets deployed, understanding how these adjacencies are playing nice with modern SDN and automation techniques is a critical step. Modern infrastructure elements should be first- class citizens in your SDN with integrations and native understanding of SDN design elements such as VXLANs.

The adoption of a new SDN is a great opportunity to question the incumbents in your network and examine other vendors. After all, the SDN is going to change much of the operational model your administrators follow, so if they have to learn something new, you may as well use the opportunity to test the waters. That said, there is a tendency to look strictly at new vendors or software-only vendors – you’re missing out if you do. Many existing vendors in these adjacent spaces have new offerings that are developer/application friendly products and SDN-ready. Be sure to ask; you might be surprised at your choices.