Minimal (Network) Exposure

#SDN #DevOps #ACI A lesson from object-oriented principles that should be applied to the network

One of the primary principles of object-oriented programming (OOP) is encapsulation. Encapsulation is the way in which the state of an object is protected from manipulation in a way that is not consistent with the way the variable is intended to be manipulated. The variable (state) is made private, that is to say only the object itself can change it directly. Think of it as the difference between an automatic transmission and a standard (stick). With the latter, I can change gears whenever I see fit. The problem is that when I see fit may not be appropriate to the way in which the gears should be shifted. Which is how engines end up being redlined.

An automatic transmission, on the other hand, encapsulates the process of shifting gears (changing the state of the engine) and only major transitions - reverse, park, drive, neutral - are accessible by the driver.

In an object-oriented paradigm, this is how the state of an object is isolated and protected from manipulation in a way that may introduce instability or cause other logical errors in processing. If we modeled a car using an OOP object it might look like this:

The actual code within each of the OPERATIONS can manipulate the STATE of the car, but it does so using well-defined rules. You can't just reach in and change the state without going through the OPERATORS. Period.

What this provides is the means to do logic and error checking, ensures consistency, and means that every other part of the system that might touch that object can be assured of the integrity of its state.

So, what does all that have to do with networking and infrastructure and DevOps and SDN and... ?

Quite a bit, actually.

One of the reasons SDN and DevOps, for that matter, is so critical to the next generation of data center architectures is its ability to centralize the state of the network. Right now it's all over the place. Literally. The state of any given network is not well known because it's distributed across every router, switch and layer 4-7 service that comprises "the network." It makes troubleshooting difficult, to say the least, and there's no good way to predict how a change in the state of the network will impact, well, the network.

An object oriented approach to the network, in general, says "let's centralize state, and provide a single interface through which it can be modified." In other words, there is a single authoritative source for the state of a network.

This is the approach that Cisco has taken with its Application Centric Infrastructure (ACI). It's the approach that OpenFlow-based SDN takes, and it's generally the approach that devops is taking to treating infrastructure as code. That's the theory. To realize this in practice requires that "the network" be API-enabled, to allow the dissemination of state and telemetry necessary for the authoritative source to maintain an accurate view of the state of the network.

The danger, however, is that we end up with a bunch of infrastructure and network devices that expose state via APIs through which operators and engineers end up directly manipulating configurations. Unfortunately, it is often the case that changing one single variable on a network device can be as devastating as opening Pandora's Box. Because of the way in which different devices relate policies and ACLs and routing tables to different objects - IP addresses, VLANs, etc... - a single change can have significant repercussions.

Similarly, the order in which various objects are configured can impact the overall stability and success of a configuration. By offering up a highly granular API and leaving consumers to their own devices (ha! pun not intended, but not regretted, either) they can easily shoot themselves (or their network) in the foot.

Providing a more policy, application-focused approach to provisioning and configuration reduces the possibility of these incidents and improves the stability and therefore reliability of the network services upon which applications rely. Encouraging engineers and operators to leverage application-driven provisioning and management rather than a line by line, API call by API call functional approach reduces the API surface area required and returns to exploiting encapsulation to preserve and protect network state by ensuring consistency in how that state is changed.

This software-defined, API-driven approach is a whole new world for networking and operations because it deviates from the direct touch world in more ways than just moving from CLIs to APIs.  It's also about encapsulation; about moving from standard transmissions to automatics and trusting that the manufacturer of the car does indeed know best how and when to shift from one gear to another.

 

H/T: This article on encapsulation in code is a good read that doesn't require a lot of understanding of development that may be of interest (and helpful) to operators and network engineers http://java.dzone.com/articles/evil-getters-and-setters-where