In this blog, I’d like to come at Practical SDN from a different point of view. Thanks to all those who slogged through the previous blogs in the series. I suspect those either had too much or too little information in them, depending on your point of view. Anyway, I’ve been mulling over my reactions to #SDN blogs, and especially some recent blogs about cross vendor abstraction. There have recently also been discussions about the idea that networking people need to learn to program, or do programming plus something. I had fun in a tweeting marathon one recent morning with @colinmcnamara and others. And Greg Ferro (@etherealmind) wrote a good blog about the topic.
Prior blogs in this series:
- Practical SDN: Security in NSX, DFA, and ACI
- Practical SDN: L3 Forwarding in NSX, DFA, and ACI
- Practical SDN: L2 Forwarding in NSX, DFA, and ACI
- Practical SDN: NSX, DFA, and ACI, The All-Seeing Eye. See this first blog for a general disclaimer.
Recent blogs about an Abstraction Layer by Ethan Banks (@ecbanks) and Jason Edelman (@jedelman8):
- http://ethancbanks.com/2014/02/10/abstract-all-the-things-or-why-clis-are-in-my-way/
- http://www.jedelman.com/1/post/2014/02/common-programmable-abstraction-layer.html
- http://www.jedelman.com/1/post/2014/02/the-power-of-a-programmable-abstraction-layer.html
And networking people doing programming (among many other blogs):
About Programming
Concerning learning to program, I think a consensus is forming. Some programming skills can be helpful. Python in particular. I’ve been playing with Python, it feels like the PERL I used to do, maybe more readable, maybe with some C++-like classes thrown in. Some powerful capabilities, some syntax gotchas. Been there, done that before. I’ve been resistant to programming since (a) I enjoy it way too much (really!) (b) I’ve done some pretty solid chunks of code, like a PERL-based compliance tool, and (c) it doesn’t pay the bills. On the other hand, if you haven’t programmed, python seems to have a good bunch of resources, and may be quite useful going forward.
I’m going to disagree with the claim that everyone needs to learn to program. I’ve seen this before with various scripting admin tools. Some learn to do it, the other maybe 80% don’t. Those that can, if sufficiently motivated, can produce power tools and get more done with automation. Those who can’t, do a lot of typing or make do.
Some of that also applies to network management tools. Most have them, some actually use them and get good at them.
Why does this happen? There’s a cost to learning to code well, or to use a network management tool. In addition, programs need maintenance when you find bugs or want to generalize them, and net management tools need care and feeding. It comes down to PROI: Personal Return on (Time) Invested.
What I see is that the ROI improves if you can leverage your efforts across many devices, or even better, across many devices at many customers or sites. (That’s why products get born?)
Now to kick it up a notch, part of the concept about learning to program may tie into being able to integrate components, deal with APIs and bugs, use GitHub, … fill in the blank.
About Size
Isn’t network size a factor here, product cost also?
I like looking at things in a range from manual/easy to automated/hard. (Prior exposure to all too many network management tools may be causing cynicism here.) Is there a range of complexity lurking here, perhaps something like:
- CLI
- PERL or Python automation of commands / configuration across multiple devices, monitoring, etc.
- NSX — virtual networking for a mostly VMware shop (private / public cloud)
- DFA (Dynamic Fabric Automation) — using a fairly “canned” datacenter automation solution to automate and scale
- ACI (Application Centric Infrastructure) –new hardware + innovative large datacenter automation
- Open Source applications — some integration and learning curve (various with the capabilities of the Open Whatever that you choose)
If you work for a any size shop, and if you have the spare time (evenings?) to fiddle with programming, then writing some small CLI automation tools (I’m thinking python version of RANCID here) might make some sense. If you deal with devices from multiple vendors, perhaps in a consulting role, then automating some common actions and abstracting syntax (a la the blogs above) could be a good entry point.
If you’re balancing pain vs. gain, and risk, the ratio might depend on what size shop you’re in, and which of the items above you’re considering.
I’ve seen some blogs recently about factors to weigh when shopping for an SDN solution.
What are We Trying to Do?
Like many things, doesn’t it all come down to what you’re trying to accomplish?
If you want to build skills and step up to a better job, go for it. Then you probably want to focus on enough programming but also on the package installation and automation side of things.
If you want more limited automation, in which case a tighter focus on programming may be in order. Or if you haven’t programmed, done some Linux scripting, and installed or compiled open source software of some form, you might want to start with some programming.
How Do I Get Started?
Terry Slattery made a good point in email to me. My version of it is “do something”. Pick one of the above based on some mix of your interest level, complexity, risk, needs. Then find a way to do something small, and gradually expand what you’re doing.
Thinking Differently: Learn VMware?
I like to spot check I’m not stuck in a rut. I’m wondering if at the small to medium end of the scale, networking people need to increase their familiarity with hypervisors, especially VMware and perhaps the VMware NSX platform. As virtual appliances arrive in increasing numbers, with performance up to 1 Gbps, some shops may opt to run virtual routers, firewalls, load balancers, etc. We have to get out of defining networking (servers, storage, security) as “I own these boxes here” and more as the role. We need to be prepared to communicate with server / application / development teams trying to deploy new applications using virtual versions of what used to be network hardware — and to be able to explain where a virtual router or switch may suffice and where a physical router or switch is advantageous. Oh, and who administers the virtual routers? If they’re a VMware NSX distributed router? Or a Cisco CSR or Brocade Vyatta?
I’ve put some of this into the CMUG presentation I’ve been preparing. I feel validated in that Ivan Pepelnjak (@ioshints) covered what a virtual appliance-based design might look like in a fresh blog, “Going All Virtual with Virtual WAN Edge Routers”.
Other Relevant Prior Blogs
- Thinking About NSX, DFA, and ACI
- Application Centric Networking After-Thoughts
- The Cisco ACI Launch, Part 2
- The Cisco / Insieme ACI Launch, Part 1
Twitter: @pjwelcher
