Welcome back!  In Part 1: Embrace NetDevOps, Say Goodbye to a “Culture of Fear”, I introduced my definition of NetDevOps and talked about how we need to dispel the “Culture of Fear” as we move to NetDevOps.  We also considered the two stakeholders of NetDevOps, the builders and consumers of the network.  In this post I’ll be picking up where I left off discussing the core principals of NetDevOps.  Let’s dive in!

 

The NetDevOps Pipeline

A “pipeline” simply defines the process by which an activity is completed.  The concept of a “software delivery pipeline” is well understood today in IT, but network configurations also follow a pipeline.  Today’s network configuration pipeline is a complex maze of forks, bends, off shoots, dead ends, and paths that require special timing, keys, and phases of the moon.  The current network configuration pipeline needs to go, and be completely replaced in NetDevOps.

It is in this aspect of NetDevOps where Infrastructure as Code is relevant, and it must be driven by DevOps principles of automation, testing, and verification.  In NetDevOps, it is standard to have a “Continuous Development” approach to network changes.  Proposed network changes are picked up by build servers which manage the progression from “Development” to “Test” and into “Production”.  NetDevOps will mirror what is becoming commonplace in software development teams.

There is great work being done in network automation, network automation tooling, to help make a proper NetDevOps pipeline come to life.  In fact I am spending much of my own time within DevNet in this space, and you can look for new blog posts in this space from me very soon!

Rethinking Network Monitoring for NetDevOps

Active monitoring of software performance and user experience is core to the DevOps principles and culture.  And NetDevOps needs to bring with it a strategy and technique for network monitoring.  It isn’t that we aren’t monitoring the network today, however for many networks it’s a haphazard combination of SNMP and syslog used more as a forensic research tool than as an active part of the day to day strategy of gauging the health of the network.

The networking industry is already adopting and moving to new technologies and strategies for monitoring.  “Streaming Telemetry” solutions that provide near real-time access to structured data based on standard data models are becoming quite common.  Further these new solutions are fitting into the same monitoring framework and systems that are being used by software DevOps teams.

However, replacing older protocols with newer ones isn’t a full solution.  The more critical question that we need to answer today is what to monitor.  What are the key performance indicators (KPIs) for the network?  A strategy of collecting everything available isn’t possible or practical today.  There is just too much available data, coming at too high a rate to reasonably transport, store and process it all.  As an industry, we must figure out what to gather.  And further… we can’t sit around and wait for an engineer to take a look at the data.  We must develop strategies and plans to process the data as it comes in and take action immediately.

In NetDevOps, monitoring is about continuous health and improvement, not forensics.

The NetDevOps Engineer

Networking engineers must adopt new skills for NetDevOps, but this isn’t new to us as network engineers.  We’ve had to learn new skills for IPv6, MPLS, 802.1x, and so much more.  Not to mention the list of new technologies that have flooded us in the “Software Defined Networking” era.  First and foremost, network mastery is still a critical skill.  I scoff a little bit at all the doomsday talk I see around these days about “the death of the network engineer”.  Network engineering is as strong as ever, but it is changing.  Just look at what has happened to our cousins in software development as DevOps has flourished.

NetDevOps Engineers are skilled in programmability as well as networking.  Many of us are already well on our way down the programmability path picking up familiarity with API interfaces and new scripting languages like Python.  To these we’ll need to become familiar and fluent with DevOps tooling in areas like configuration management, build servers, and testing suites and tools.  For me the biggest challenge in this space is the sheer variety and velocity in the tools that are available today and being developed for tomorrow.  Don’t let this discourage you, embrace it as an opportunity, but realize you’ll need to become comfortable with not knowing them all.. there are just way too many out there.

And lastly I turn back to an old friend of us all, the OSI Model (or Open Systems Interconnection Model).  I do not doubt that you all look nostalgically on learning the 7 layers of the OSI model, but let’s be honest with ourselves… many of us are really are only comfortable with layers 2 – 4.  Well, in order to successfully understand, troubleshoot, and test network health for applications running today and going forward, we must embrace the upper 3 layers of the OSI Model.  Session, Presentation and Application skills and understanding are going to become more and more critical.  With REST APIs becoming pervasive, you really need to know how HTTP works in detail…

For more info on the evolution of the network engineer, take a look at Carl’s journey in my post over on Learning at Cisco!

Conclusion

As a reminder of the key elements we’ve discussed about NetDevOps, here they are again:

• Organizations practicing “NetDevOps” see network changes as routine and expected.
• NetDevOps builds and manages a network that enables network services to be consumed in a DevOps approach.
• In NetDevOps, it is standard to have a “Continuous Development” approach to network changes.
• In NetDevOps, monitoring is about continuous health and improvement, not forensics.
• NetDevOps Engineers are skilled in programmability as well as networking.

This transition has me so excited that I’m re-branding myself as a “NetDevOps Evangelist” and am spending as much time as I can exploring all the topics and elements I’ve outlined in this article.  Check back often for more blogs as I dive into each area and test out new theory, technology, and ideas.  And you can be sure I’ll be building new Learning Labs, Sample Code and DevNet Sandboxes for you all to explore along with me.

And we’ve made it to the end, but the discussion on NetDevOps is far from over.  In these two posts I’ve just started exploring my own thoughts on the topic, and framing up a discussion I look forward to having with all of you.  Leave me a comment here on the post, or drop me a note over on Twitter (@hfpreston) or on LinkedIn (hpreston) and let me know your thoughts.  And as always be sure to follow #DevNet on Twitter and Instagram for all the latest adventures in coding!

Until next time!

Hank, NetDevOps Evangelist!