Welcome!

@DevOpsSummit Authors: Yeshim Deniz, Liz McMillan, Dalibor Siroky, Tim Hinds, Dana Gardner

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
The use of containers by developers -- and now increasingly IT operators -- has grown from infatuation to deep and abiding love. But as with any long-term affair, the honeymoon soon leads to needing to live well together ... and maybe even getting some relationship help along the way. And so it goes with container orchestration and automation solutions, which are rapidly emerging as the means to maintain the bliss between rapid container adoption and broad container use among multiple cloud hosts. This BriefingsDirect cloud services maturity discussion focuses on new ways to gain container orchestration, to better use serverless computing models, and employ inclusive management to keep the container love alive.
"Since we launched LinuxONE we learned a lot from our customers. More than anything what they responded to were some very unique security capabilities that we have," explained Mark Figley, Director of LinuxONE Offerings at IBM, in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.
Is advanced scheduling in Kubernetes achievable?Yes, however, how do you properly accommodate every real-life scenario that a Kubernetes user might encounter? How do you leverage advanced scheduling techniques to shape and describe each scenario in easy-to-use rules and configurations? In his session at @DevOpsSummit at 21st Cloud Expo, Oleg Chunikhin, CTO at Kublr, answered these questions and demonstrated techniques for implementing advanced scheduling. For example, using spot instances and cost-effective resources on AWS, coupled with the ability to deliver a minimum set of functionalities that cover the majority of needs – without configuration complexity.
A strange thing is happening along the way to the Internet of Things, namely far too many devices to work with and manage. It has become clear that we'll need much higher efficiency user experiences that can allow us to more easily and scalably work with the thousands of devices that will soon be in each of our lives. Enter the conversational interface revolution, combining bots we can literally talk with, gesture to, and even direct with our thoughts, with embedded artificial intelligence, which can process our conversational commands and orchestrate the outcomes we request across our personal and professional realm of connected devices.
Sanjeev Sharma Joins June 5-7, 2018 @DevOpsSummit at @Cloud Expo New York Faculty. Sanjeev Sharma is an internationally known DevOps and Cloud Transformation thought leader, technology executive, and author. Sanjeev's industry experience includes tenures as CTO, Technical Sales leader, and Cloud Architect leader. As an IBM Distinguished Engineer, Sanjeev is recognized at the highest levels of IBM's core of technical leaders.