Automate All the Things!

automate.png

Eric Wright (Discoprosse) talk on this topic from a server/orchestrations side in his February post Server Build Processes, Monitoring, Orchestration and Server Lifecycle Management  but I wanted to circle back around and add networking into the mix.

There is a ton of information and views on the topic of network automation and in order to keep this post short and open Im only going to graze the surface of these topics. Also Im going to speak mostly for the Data Center space but this topic could also pertain to the enterprise network as well.

Centralized Controllers and Network Automation

The big challenge with modern data centers is how to manage and deploy these massive infrastructures and their growing complexity. Imagine managing hundreds of switches, thousands of VLANS, possibly spanning multiple data centers, servicing hundreds of customers. Each customer needs their own space and must be isolated from everyone else. These customers also expect turn-up as fast as possible.

Network vendors have addressed these challenges and design shifts in multiple ways. Both Cisco and Juniper have deployed a controller based solution where access and top of rack (ToR) switches are controlled and managed by a central controller or master switch. This design reduces the number of devices administrators need to manage and also simplifies deployment of changes or add/removes. Multiple vendors are also opening up there switches allowing 3rd party software or controllers to manage their switches.

Controllers to me are the network industry dipping our toes in the orchestration/automation realm. As I'm sure most of you know there is a lot of activity right now in the network automation realm.  

Several open source projects are out leading the charge on network automation such as OpenStack, Open Daylight and I'm sure there are others. Vendors are also making a move in this realm such as Cisco's ACI. You are also starting to see new companies pop up with some really cool products such as tail-f.

Everyone sees this topic differently so I want to hear what you think. To me automation will remove the redundant manual configuration of network equipment and speed up and simplify network deployments even further. It will also give us better control and allow us to quickly adapt and alter networks with changing traffic patterns.

Anyone here been playing with these tools?

How do you see SDN and Network automation changing our day-to-day roles?

  • I like the tone of the responses:  have a great reason for making major changes--something better than just having an Application person be able to run a GUI instead of relying on a Network Analyst to run a script.

    Don't get me wrong, I appreciate a great GUI that's fast and reliable and intuitive.  In my dreams I wish Cisco'd never gone down the Network Assistant path, and had instead bought out Nortel and deployed their Device Manager and ESM technologies across all IOS.  That would've been sweet to use.  Fully intuitive and fast GUI's, while keeping the full CLI scripting path option available for massive and fast changes.

    My organization went with Nexus six years ago when we replaced our Nortel data center infrastructure, and outside of getting some faulty chips from Asian manufacturers, it's been reliable.  Complex, challenging to manage on occasion (can you say "OTV"?  I knew you could.), but much more reliable than Nortel hardware and code.

    Now we're planning to migrate to ACI, and I'll confess to being a bit intimidated.  I've not gone done the scripting path required for ACI management, so I've got some learning to do.  But the overall benefit to all IT departments should result in faster and easier and more intuitive changes, that provide improved visibility between UCS and Nexus/ACI solutions.

    I'm cautiously optimistic, for a new solution that might be fraught with Murphy's laws.

  • Good discussion.  I found it educational and informative.

  • Great write up! I'm working to try to get as much in vCenter Orchestrator as possible, but I've done Puppet also which is great for cross-platform and cross-silo (network, server, desktop) so I think it has good chances to take a strong hold out in the wild.

    The trick for many is to pick up languages. I'd say that Python is the top given it's wide use in many projects.

  • your second point is something I had not yet thought of...if all these config updates are automatically getting pushed, it could cause chaos trying to find and troubleshoot a single element in a config file and makes it look horrible emoticons_sad.png although I guess to the same point using SDN engineers shouldnt have to look at configs

  • I usually don't sleep a lot... but I can tell you, at 3 AM I am far from friendly in any circumstance.

Thwack - Symbolize TM, R, and C