NetDevOps is one of many new terms coming into the IT lexicon as “DevOps” has become widely adopted and lauded as a positive and valuable approach to software development.  As the  IT industry looks to expand DevOps to other areas, NetDevOps has emerged along with other new terms such as “ChatOps”, “SecDevOps” and even “NoOps”.  It is so new a term and idea that the name “NetDevOps” hasn’t even been fully agreed upon… I’ve also seen “DevNetOps” being kicked around by some… and despite being a member of “DevNet” at Cisco, I personally prefer the moniker “NetDevOps”.

But what exactly is “NetDevOps”?  Like its “grandfather”, there seem to be as many definitions for NetDevOps as there are people asked, so here is mine.

“NetDevOps brings the culture, technical methods, strategies, and best practices of DevOps to Networking.”  

So what is DevOps?  DevOps is a term applied to a new approach to software engineering that combines the “Development” and “Operation” of software into a single unified team and mindset.  DevOps is a full lifecycle approach where “if you build it, you own it” and accountability for success is forefront in everyone’s mind.  Technical principles such as automation and monitoring are key to DevOps, but it is much more than just a “Continuous Development” practice.  DevOps is a cultural change in IT focusing on providing solutions faster, more often, more reliably, and aligned with business requirements.  There are entire books on DevOps and for a great place to start see The Phoenix Project by Gene Kim.

I’ve been seeing more and more about “NetDevOps” come up on social media, at conferences, and in discussions with peers.  The majority of these discussions focus on strategies for network automation and embracing “Infrastructure as Code” within the network.  And while I am a HUGE believer and evangelist for both of these topics, I think we are cheating ourselves in the networking industry if we simply make “NetDevOps” another word for automation.  Yes, Infrastructure as Code (IaC) should be a major part of NetDevOps… I’m actually quite fond of the term “Network as Code”  But if we are going to work to make “NetDevOps” as important to the networking industry as “DevOps” has been to software development it must be as transformative.  And it should start with culture.

NetDevOps Culture

Many organizations today have a “Culture of Fear” about the network and network changes.  The network is one of the most critical elements in IT, every other system relies on it for communications and to function properly, but it is seen as complex and fragile.  In discussions with engineers, leaders, and executives from companies of all sizes and verticals, I have heard variations of the phrase “if it ain’t broke, don’t fix it”.  Network changes are to be avoided if at all possible, and when they must occur they are subjected to rigorous, costly, and lengthy vetting.  And despite this vetting, time and time again network changes are fraught with problems and unexpected impacts.  The majority of these problems occur due to cases of human error and lack of thorough testing and validation.

The culture and approach to networking within organizations have created a reinforcing loop of fear and distrust that paralyzes networking teams from being able to deliver the agility required by “digital businesses” today.

Organizations practicing “NetDevOps” see network changes as routine and expected.  This doesn’t mean that network changes are performed without plan and structure.  It is actually the opposite.  Because network changes are so routine, there is a well defined and practiced process for designing, testing and deploying network changes.  By making them routine, network changes can be small and simple.  And because they happen so regularly, the implementation team is practiced, and the larger organization doesn’t see the change as something unusual and of high risk.

Network Stakeholders

There are two stakeholder groups for the NetDevOps movement, the Network Builders and the Network Consumers.

The Network Builders are made up of traditional networking teams.  These are the architects, engineers, administrators and analysts.  They are responsible for designing, building, and maintaining the network “utility” at an organization.  Their focus is the care and feeding of the network, making sure it’s available for the “consumers”.

The Network Consumers are the users of the network.  They simply want to consume “services” from the network.  Services such as connectivity, analytics, power and security are all of interest to the consumers.  These stakeholders are not from the “networking team”.  They come from application, server, and security teams.  They may even come from non-IT teams such as human resources and accounting!  They have a limited core networking knowledge, and expect to treat the network like a utility – it “should just work”.

In NetDevOps, the network consumers should be able to consume the “Network as a Service”.  That is through APIs, from a catalog, and in a self-service fashion.  In order to meet that demand, network builders must build and operate the network using the NetDevOps practices and principals.

NetDevOps builds and manages a network that enables network services to be consumed in a DevOps approach.

Conclusion

Whew… NetDevOps is pretty exciting and I’m just getting started.  In this first part we’ve defined NetDevOps and talked about its culture and stakeholders.  We’ve explored how NetDevOps will dispel the “Culture of Fear” that exists across the industry today, and how it will bring together the Network Builders and Consumers.  In Part 2, NetDevOps Goes Beyond Infrastructure as Code, I’ll consider “The NetDevOps Pipeline” that will control how we bring Continuous Development practices to networking, how DevOps principles of monitoring will impact NetDevOps, and lastly a look at ourselves – “The NetDevOps Engineer“.

I’m very excited to be involved in this transition and look forward to seeing it take shape and learning from all of you about your own thoughts and experiences as you embrace NetDevOps.  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!