The Evolution of Network Operations

The Evolution of Network Operations

When I first began this post, my thinking revolved around the translation problems of a declarative approach to network operation, but having only procedural interfaces to work with. Further thought dismissed that assumption and led to thinking about how declarative models evolve to meet organizational needs.

I Declare!

Many articles have been written about how declarative models define what we want, while procedural models focus on how we want to accomplish this. Overall network policy should be declarative, while low-level device management should be procedural, especially when dealing with older platforms, right? Well, it’s almost right.

Network device configuration and management have, for the most part, been declarative for some time. We don’t tell switches how spanning tree works, nor how to put VLAN tags on Ethernet frames. We plug in the necessary parameters to tune these functions to our specific needs, but the switch already knows how to do these things. Even old-fashioned device-level configurations are declarative operations. Admittedly, they’re not high-level functions and need some tweaking and babysitting, but they’re still declarative.

Let’s explore the timeline of where we’ve been, where we are, and where we’re potentially going.

Procedural Development

Back in the primordial days of computing (okay, perhaps not that far back), when I was first learning to code, everything was procedural. We joked about the level of detail required to accomplish the simplest of things. What we really needed was the DWIT (Do What I’m Thinking) instruction. Alas, this particular directive still hasn’t made it into any current coding environments. Developers have accepted this for the most part, and the people who are making the decisions are usually happy to let them handle it rather than trying to figure out how it all works at a low level. The development team became the buffer between the desired state and the means by which it is achieved.

Device-Level Configuration

Network device management is a step up in the abstraction ladder from procedural coding, but is still seen as a detailed and arcane process to those who aren’t experienced with it. Like the developers, the networking team became the buffer, but this time it was between a high-level desired state and the detailed configuration of same. The details became a little less daunting to look at and more input came from the people making the business decisions.

More and more, the networking team had to be aware of the greater business cases for what we were doing so that we could better align with the overall goals of the business. We implemented business policy in the language of the network, even if we weren’t fully aware of it at the time.

Large-Scale Models

Now, we’re slowly beginning to move to full-scale network automation and orchestration. We can potentially address the network as a single process, allowing our organization’s policies to map directly to the ongoing operation of the network itself. It’s still pretty messy underneath the abstraction layers, but there’s a lot of potential for the various automation/orchestration tools that are being developed to clean that up.

The Whisper in the Wires

Our network architecture should line up with our business processes. We’ve always been aware of this, but delivering on it has been difficult, mostly because we had the right idea but on too small a scale. New tools and models are being developed and refined, making it possible to this point, but it’s up to us to embrace these and push them to their limits. The value of the network to our organizations depends on it. By extension, our value to our organizations depends on it.

I don’t think we’re ever going to reach a point where that old DWIT instruction is a reality, but is it too much to hope that we’re getting closer?

Network Greasemonkey, Packet Macrame Specialist, Virtual Pneumatic Tube Transport Designer, and Connectivity Nerfherder. The possible titles are too many to count, but they don’t really mean much when he's essentially a hired gun in the wild west that is modern networking. Jody Lemoine is based in the Niagara region of Ontario, Canada, and operates tishco networks, a consulting firm specializing in the wholesale provisioning of networking services to IT firms for resale to their respective clientele. Over his career, he has developed a track record designing and deploying a wide variety of successful networking solutions in areas of routing, switching, data security, unified communications, and wireless networking. These range from simple networks for small-to-medium business clients with limited budgets to large infrastructure VPN deployments with over 450 endpoints. His broad experience with converged networks throughout Canada and the world have helped answer many complex requirements with elegant, sustainable, and scalable solutions. In addition, Jody maintains current Cisco CCDP and CCIE R&S (41436) certifications. Outside of the realm of IT, he is both a husband and father. In what meagre time remains, he contributes to the community by serving as an RCAF Reserve Officer, supporting his local squadron of the Royal Canadian Air Cadets as their Commanding Officer.