The subtext of the ONUG spring 2015 conference was operationalizing open networking. The idea might not sound like much, but it’s indicative of an added focus in the SDN industry. For the last five years or so, the main focus has been on tools and techniques. We’ve been trying to figure out just what SDN is and how we might use it. Talking about operationalization implies enough product maturity that we can move the topic ahead to these pragmatic concerns. Let’s not confuse “enough product maturity” with complete, robust maturity. SDN has a long development cycle ahead of it in several areas — for example, group policy — but practically speaking, enough headway has been made that we have usable (and useful) products. So why not talk about operationalization? The time seems right, and it was a helpful ONUG theme to consider.
For the record, I believe operationalizing open networking is going to be hard for most organizations. It’s not that I wish it to be hard, or that I’m looking askance at a half-decade of networking technology advancement. Just the opposite is true. Networking stack disaggregation is one of the few technology trends that brings out genuine passion in me. I feel deeply — right in my gut — that the open, disaggregated approach is right. Open networking is a frontal assault on the vertically integrated networking stack, a unified charge with weapons raised in clenched fists by open source software, commodity hardware, global organizations, networking professionals, and emerging networking vendors. The battle is about choice, but it’s also about innovation. Open networking is the freedom to build new operational processes, and to integrate tightly with the rest of our IT stacks in whatever way we need. It’s the flexibility to change that process down the road with a minimum of bother. It’s a breeding ground for new ideas and new code.
Yes, open networking is still nascent, and if it’s to eventually take over as a standard approach to networking, there is much work to be done. Education to share. Vendor myths to debunk. Minds to win over. Oh, and organizational processes to change. Hmm. Even if every organization on the planet grasped the open networking value proposition and was ready to change today…operationalizing open networking is going to be hard. In my personal experience and in talking to many peers, I’ve found that the siloed approach to IT is still in full swing. Blame traditional management hierarchies. Blame ITIL. Blame the way the IT industry is fractured along technology lines. But the reality of IT operations is that, for the most part, we’re still specialists with deep knowledge in a narrow field operating in a technology silo.
One ONUG talk that addressed this problem was Adrian Cockcroft’s Creating Business Value with Cloud Infrastructure. Adrian is of Netflix fame, and currently works at Battery Ventures. Adrian talked about how to organize an IT shop for efficient operations, based on his experience with Netflix. In a nutshell, Adrian’s talk was about how to deliver new code onto infrastructure with a minimum of fuss. Accomplishing this requires IT teams that are horizontally aligned “cross teams” (tied to a product, perhaps), and not infrastructure or component aligned. When properly structured, a team can release small changes, as small as one at a time, with a minimum of risk. Everyone on a team is responsible for their own element, while at the same time working with each other to get the job done. No complex managerial hierarchy. No complex processes, which Adrian actually described as “scar tissue” typically found in larger or older organizations.
Adrian’s talk gets to the heart of why I think operationalizing open networking and SDN will be hard. Organizations just aren’t structured the way he’s describing. For example, networking has been the domain of specialists for a long time now. Networking has become so difficult to implement, and so catastrophically impactful when it fails, that organizations feel they must entrust their care and feeding to specialists. Turn over network provisioning to an automation engine? Subsume network changes into a larger set of changes that test or deploy an application to production? I can feel the wincing right now. Networks feel fragile. Networks are built on groups of layered dependencies, the failure of any one of which can bring down the rest. Entrust network changes of any kind to anything other than a specialist? Hard. (I’m focused on process in this piece, but this also speaks to the overly complex nature of our networks, a topic for another day.)
I think this issue of trust fairly describes the mindset of many, and I believe this is why disaggregation of the networking stack is going to take time. Open networking is a rebuilding process. I think it would be not quite right to think of it as a displacement process, because in fact our networks will — must — operate as they do today. We can’t simply displace them. We must rebuild them slowly over time, keeping our businesses going while we do so. Precious few of us have the luxury of greenfield deployments, and even if we did, how many of us would be brave enough to try an unproven (to us) paradigm? Some have, and some are — thus ONUG exists as a semi-annual event. But how long will it take to convince IT practitioners at large that an integrated, flexible approach to infrastructure management, including networking, is the way forward?
I believe open networking will win. The value proposition makes too much sense to lose in the marketplace of ideas. Yes, making the IT organizational and process changes required to implement it will be a difficult challenge for most organizations. But, we’ve done this before. We’ll do it again. We’re IT. Change is what we do — it’s how we keep our businesses winning.
- SD-WAN Fabrics Aren’t Interoperable. Should Organizations Care? - January 14, 2019
- The Complex Simplicity of SD-WAN - November 15, 2018
- Operationalizing Open Networking – It’s Going To Be Hard - May 20, 2015
- The Potential of Open Networking - April 8, 2015
- The Scaling Limitations of Etherchannel -Or- Why 1+1 Does Not Equal 2 - December 7, 2010
- Breaking The Network, One /24 At AÂ Time - November 3, 2010
- Coping Mechanisms For A Lying ARP Cache - October 14, 2010
- Traveling East-West Might Get A Little Easier: Highlights from the TRILLÂ RFC5556 - October 11, 2010
- Don’t Drop The Baby: Data Center Bridging Wants Storage To Trust Ethernet - October 8, 2010
- Assembly Required: A Basic Spanning-Tree Design for a Two-Tier Data Center - September 8, 2010