Welcome!

@DevOpsSummit Authors: Yeshim Deniz, Liz McMillan, Pat Romanski, Elizabeth White, Flint Brenton

Related Topics: @DevOpsSummit, Microservices Expo, Containers Expo Blog, @CloudExpo, Cloud Security, @DXWorldExpo, SDN Journal

@DevOpsSummit: Blog Post

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

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 many faces of routing in 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.

Read the original blog entry...

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.

@DevOpsSummit Stories
Andi Mann, Chief Technology Advocate at Splunk, is an accomplished digital business executive with extensive global expertise as a strategist, technologist, innovator, marketer, and communicator. For over 30 years across five continents, he has built success with Fortune 500 corporations, vendors, governments, and as a leading research analyst and consultant.
In his keynote at 18th Cloud Expo, Andrew Keys, Co-Founder of ConsenSys Enterprise, provided an overview of the evolution of the Internet and the Database and the future of their combination – the Blockchain. Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereum.
For far too long technology teams have lived in siloes. Not only physical siloes, but cultural siloes pushed by competing objectives. This includes informational siloes where business users require one set of data and tech teams require different data. DevOps intends to bridge these gaps to make tech driven operations more aligned and efficient.
For organizations that have amassed large sums of software complexity, taking a microservices approach is the first step toward DevOps and continuous improvement / development. Integrating system-level analysis with microservices makes it easier to change and add functionality to applications at any time without the increase of risk. Before you start big transformation projects or a cloud migration, make sure these changes won’t take down your entire organization.
It is ironic, but perhaps not unexpected, that many organizations who want the benefits of using an Agile approach to deliver software use a waterfall approach to adopting Agile practices: they form plans, they set milestones, and they measure progress by how many teams they have engaged. Old habits die hard, but like most waterfall software projects, most waterfall-style Agile adoption efforts fail to produce the results desired. The problem is that to get the results they want, they have to change their culture and cultures are very hard to change. To paraphrase Peter Drucker, "culture eats Agile for breakfast." Successful approaches are opportunistic and leverage the power of self-organization to achieve lasting change.