DevOps is the latest in a long line of confusing tech industry buzzwords, one that’s shrouded in a mix of mystery, controversy and indeed apathy.

Mystery, because many IT practitioners have little idea what it actually is. A recent InformationWeek survey found that 22 percent of respondents were very familiar with the concept, while just 21 percent (probably virtually the same group) had actually implemented DevOps inside their organizations.

Controversy arises when evangelists throw around the term “engineering,” implying that DevOps is a new professional discipline distinct from network engineering, systems design, and software development. The problem here is that DevOps is more a philosophy and process than field of proscribed endeavor and can be applied to many different areas. DevOps is actually a set of skills rather than actual professional discipline. Change the context and the distinction is obvious: imagine calling someone a JavaScript engineer or network fabric engineer. Cloud architect Mike Kavis nails the dichotomy in his column, “No, You Are Not a DevOps Engineer:”

Ask five IT people what the term DevOps means, and you will likely get five completely different answers. Go to any online job board, search DevOps, and look at the job descriptions, and you will see great disparity in the desired skillsets and responsibilities, as well as job titles. Go to LinkedIn and search for people using DevOps, and you will see thousands and thousands of people calling themselves DevOps engineers. Some of them may even claim having up to ten years of experience. I find it quite amusing that nobody can define what it is; very few companies are actually doing it and doing it well, yet we are all experts at it.

Apathy is evidenced by the 58 percent of InformationWeek respondents that had no DevOps adoption plans on the near-term horizon in the next year. Of those, one-third cite no demand from their businesses for what DevOps promises.

DevOps Is About Changing Behaviors

Given persistent DevOps hype, which often focuses on qualitative benefits like flexibility, agility, and quality, along with a tendency by vendors to conflate DevOps with their latest products and services, it’s easy to understand how IT professionals can be confused.

But according to John Willis, VP of customer enablement at Stateless Networks and a DevOps pioneer, the movement is about changing behaviors more than new technologies. He captures the essence in the acronym CAMS: Culture, Automation, Measurement, and Sharing. Of these, Willis says the first is also the most important. “DevOps is about cultural and behavioral change. Just bolting on Chef or some other tool won’t help,” adding, “once you get the ‘C’ right; 70 percent of the battle is won.” Kavis agrees. Here’s his definition.

“DevOps is a culture shift or a movement that encourages great communication and collaboration (a.k.a. teamwork) to foster building better-quality software more quickly with more reliability.”

DevOps emerged from evolving software development methodologies like agile, lean, and scrum that emphasized rapid prototyping, frequent updates, and minimal project overhead. DevOps is merely the application of these principles to IT infrastructure, or according to Willis “treating operations the same way you treat software development.” As Michael Davis writes in the InformationWeek DevOps report, DevOps is “about modeling what the environment should do before you go live, and using automation to keep things running smoothly.”

DevOps concepts were initially developed, adopted, and later promoted by large cloud services managing huge server fleets and distributed applications. However, Willis describes an epiphany when he first started hearing about SDN and OpenFlow, immediately seeing the parallels between what software-controlled networks were trying to achieve and the server automation already common in the cloud world; that networks could and should be similarly managed using repeatable processes. He says using DevOps practices means being more methodical about rolling out new servers, yet he saw networks still managed with crude scripts targeting individual devices, not an entire network or category of devices.

The goal should be to systematically describe an ideal network state (this is where SDN and virtualization abstractions come in), make it reproducible and programmable (here’s where software languages and tools are important), and automate the network build, configuration, testing, and move-to-production processes. Writes Davis, “Under DevOps, we don’t rely on a single engineer who ‘knows how it was set up before.’ Instead, we get a configuration that’s documented, easily repeatable by developers running the tools in a lab, and, most important, validated by both development and IT ops.”

Great in theory, but applying DevOps to networks is more challenging than managing server and application configurations, since network devices are inherently interconnected and thus can’t be managed in a vacuum. “There needs to be much more awareness of neighbor state” when systematically describing and automating network configurations, Willis adds. But he sees much potential with new hardware from the likes of Arista, Cumulus, Pluribus and Cisco, specifically the Nexus 9000 line derived from Insieme, which feature rich APIs supporting multiple languages. When properly designed and configured, you can take a leaf-spine network and literally replace a leaf, and it will inherit the state and configuration. When programmable networks are integrated with OpenStack, Willis has seen clients “go from bare-metal to full cloud stack in less than a day.”

Relearning the Basics

Sounds great, but where do you start? Remember, DevOps isn’t about buying software tools, but about changing attitudes, processes, and team interactions. Infrastructure engineers must learn (or revisit) the general principles of good software development and delivery and apply them to networks. These include:

• Abstract the problem.
• Use source control processes and software.
• Automate the build and deployment processes.
• Use these to create an automated test environment.
• After testing, stage new releases for controlled release to production.
• Become a polyglot; learn multiple high-level languages like Python and Ruby.
• Understand one or more model-driven configuration tools like Chef, Puppet or newcomer Ansible
• Improve communication between IT teams. This blog post offers seven techniques Willis has seen applied to facilitate DevOps.

These ideas are nothing new. As Davis writes, many of DevOps’ core principles go back to Fred Brooks’ seminal software development text, The Mythical Man Month, which criticized the practice of adding people to speed software projects, instead stressing the development of reusable components by small teams with a lot of communication, revision control, and ample pilot testing. SDN and DevOps provide the impetus for network teams to relearn these same lessons.