Routing: How DevOps Bridges IT Gaps and Enables Software-Defined Something

#devops #sdn #sddc I apologize sincerely for that pun. Really, I do.

One of the most common phrases heard when new technology is introduced is that it's going to "bridge the gap" between X and Y. X and Y are almost always one of three IT groups: development, operations and networking. And while that goal is admirable (and indeed there are techno-cultural issues that have and continue to cause friction between these groups) one of the biggest obstacles standing in the way of rainbow-and-unicorn harmony between these groups is terminology.

It's not just a case of difference of opinions on pronunciation, a la "you say toh-mah-toh I say tah-may-toh", it's the use of the same word to mean very different (and yet very similar) things.

Let's take "routing", for example. There are three very similar yet distinct uses of "routing" across the primary groups within IT:

The core concept is the same: I just received "X" and need to know where to send (route) it. It's a map, if you will, in all cases. But each of the groups "routes" differently. Networking routes packets from node to node, operations routes requests from users to applications, and development routes requests from one method (function) to another.

It's the difference between a map from home to the office (network), the elevator that gets to you to the right floor (operations), and a map that gets you around on the office floor (development).

This simple demonstration clearly shows why there are "gaps" that need to be bridged in the first place. The networking definition of routing from the perspective of how it's implemented is very different from that of development. The definition from an operations (devops) perspective, however, is at least somewhat aligned with both sides of the equation.

From a networking perspective, operations needs to move packets associated with an application request to a specific host. Therefore it has a need to understand network topology and naming, and may even need to interact with SDN controllers to inform it of changes to the application topology.

From a development perspective, operations may be making that decision based on application-driven meta-data such as a URI or an API version or key.  Thus, operations needs a good understanding of application topology and the meta-data that drives application architecture.

(Dev)Ops Will Enable Software-Defined Something

Operations, unlike either of the other groups, has a need to know and care about both sides of the equation because it's got its feet standing squarely in both camps. It is the "thing" that bridges the gap between networking and development, and provides application-driven, network-aware architecture that address very real challenges.

SDN - or at least the idea of an agile network that it brings to the fore - will drive the importance of devops in organizations even higher as the use of integration, automation, scripting and orchestration to accelerate service velocity becomes more common and in demand. As IDC's Brad Casemore pointed out in "Where SDN and Devops Tools Meet"

Even if companies see the value in network virtualization, automation and orchestration, "they ask, 'How are we going to do this, because it requires us to all work together, and that's not how we're constructed right now,'" IDC's Casemore said.

The core differences between development and networking will indeed pose significant cultural and practical obstacles to moving forward on an "agile network" whether through SDN or some other software-defined model because they don't, today, work together. They're in two different worlds with two different perspectives and two different dictionaries.

But devops, with its focus on applying development methodologies to operations and using very developer-oriented tools to do so while maintaining a good understanding of the network will better enable organizations to bridge those gaps and get them all working together toward a common, software-defined goal.