In the last post, I talked about how Ansible could be used for various forms of network automation.  In the comments, Michael asked if Ansible could also be used for network test automation and verification.  Since I’m just starting to explore Ansible, I figured why not try it out.  The short answer is, it’s possible.  Let’s take a look at an example proving this out.

[This article is the outcome of some great conversations and exchanges I’ve had recently with Jeremy Schulman (@nwkautomaniac) around automation and Devops in the world of networking.  Thank you to Jeremy for those late tweaks before getting this posted!  Thanks to Kirk Byers (@kirkbyers) as well - he was also gracious enough to respond to clarify a few things and assisted with this post indirectly.]

There have been numerous articles written that describe the what and the why of Devops.  Reading through a few of these, you find references to CAMS --- you’ll read how “Devops is about CAMS.”  CAMS stands for Culture, Automation, Measurement, and Sharing.  Imagine working in an environment where automation is embraced?  We know most networks are not leveraging nearly any type of automation.  While we usually talk about engineers (of all types) not embracing automation, is the harsh reality most organizations are from having the right culture to embrace automation? 

You can’t listen to an interview or podcast, an industry panel, or read a Q&A about the future of networking that doesn't involve skill sets.  The biggest question of them all – what skills should network engineers focus on so they don’t become irrelevant? If you really want to know what skills make sense, why ask, when you can do an easy search to see what skills companies are looking for these days in a variety of roles.  Combine SDN with DevOps into your search criteria and the results may surprise you.  They sure surprised me.  

It’s been two weeks since I attended my 3rd consecutive Open Networking Summit (ONS) and I’m glad to say, I finally found some time to get some notes and thoughts on paper about the conference.  Here are some on SDN at Google and Microsoft, and how they compare and contrast to industry incumbents’ solutions, but also how programmable NFV can be game changing in the Enterprise.  I also include thoughts on how Embrane and Big Switch play into this.

Over the past few weeks, I’ve written about the idea behind a common programmable abstraction layer.  Previous articles are here and here.  It’s worth stating that something like a CPAL can be used with or without SDN controllers and with or without cloud management platforms.  As can be seen from the previous write ups and the video/demo below, today its primary focus is data extraction and data visibility.  It can use device APIs or controller APIs.  It’s about accessing the data you need quicker.  It’s that simple.  No more jumping from device to device and having to manage text and excel files.  

Edit 3/15/2014:
Github repo for CPAL

If there is a controller in the environment, you can still view data around particular physical and virtual switches in the environments by creating the right modules.  Same can be said if there was a CMP/CMS deployed.  While a CPAL can easily make changes to the network, it’s about taking small steps that can have a larger impact on how we use new APIs on network devices and controllers.  And if we don’t strive for a common framework now, we will end up with many more APIs than there are CLIs.  What good is that?