|By Michael Bushong||
|December 2, 2013 11:45 AM EST||
There's been a lot of hullaboo in the last few years about the current cycle of disruption in IT: Public Cloud, Private Cloud, SDN, DevOps, Everything-as-a-Service… the list goes on and on and every vertical, every field, and every niche is feeling the churn. Every day there is no shortage of opinions "for" and "against" something in tech that is emerging, in decline, or re-emerging. There is one aspect to all of it though that is largely ignored: "The Short 't'."
Every System in Summary
Let's have a look at Figure 1. It represents any given system: A car, an MP3 player, a network, or a cloud-service. Policy-Set "1" in implementation consists of some input state, configured or ephemeral, that allows the consumer of this system (be it human or another system) to express to the system some desired behavior or outcome the system should exhibit. This expression happens in the context of a policy-framework which provides some set of policy "constructs." In networking, this would be things like prefix-lists, ACLs, route-maps, affinity groups, affinity links, etc. In the case of an MP3 player, this would be some set of menu selections leading the MP3 player to play music. In the case of Amazon's cloud services, it could be a deployed CloudFormation template.
This set of constructs is then rendered (that would be the "r") by the system into some aggregate system state which exhibits the desired behavior or outcome that the consumer originally tried to express using the policy framework. This rendering consists of a process in which the total set of policy constructs is deconstructed and turned, ultimately, into system state.
So what can we say about "r" in this diagram? Well, not much actually. We have to add something to the diagram to put "r" into meaningful context. This is the something that is largely ignored in much of the discussion and, frankly, in much of the systems engineering and development work being done in IT.
Crossing your Ts
Imagine you have two devices, both providing equivalent functionality. For instance, you have two top-of-rack ethernet switches. You actually own, and have installed vendor A's switch. You have purchased vendor B's switch, and you are about to replace vendor A's switch with it. Before you can do this, you must configure vendor B's switch. You must "transform" vendor A's configuration (policy-set 0) to vendor B's configuration (policy-set 1). If "t" is very long in this process, that means a lot of work must go into deconstructing vendor A's policy, and reconstructing them using vendor B's available policy constructs. If "t" is very short, then the conversion is relatively easy (for instance, both vendors happen to use a Cisco IOS-like user interface). Following me so far? Good… now let's get a little more cerebral!
What we can say about "r" and "t" is a little clearer now. The distance between "p0" and "s" is fixed and is a measure of user experience. You can not shorten or lengthen "t" without impacting the length of "r", and vice versa. If "r" is very short, then "t" must be long. If "t" is very short, then "r" is very long. In other words, the closer the policy constructs represent the design choices of the underlying system, the more difficult it is for a consumer to express their desired intent to the system. A short "r" will manifest as many different "knobs" in the policy-framework. In complex systems, a short "r" means innumerable potential outcome states, and therefore greater fragility. A short "r" also means the level of abstraction relative to the overall system is low…. still here? Let's get even more cerebral…
What if policy-set 0 is actually what's in your mind? It's what you naturally intuit you want the system to do. Now imagine the system is actually a "system of systems" popularly known as a network. In legacy networking, "t" is very long between human intuition and the idioms native to the system. In fact, it's so long that you need to hire specialists to make the journey. What is the CCIE exam except a test of "t?" You must transform a confusing set of overlapping broken-english requirements into a set of router configs!
It would seem a natural conclusion, then, that SDN represents a new level of abstraction that shortens "t," making the network as a whole easier to interact with. However, we've learned a lot in the last couple of years. SDN, much like it's more popular sub-topic OpenFlow, isn't as practical as much as it is a great starting point for asking questions about what we really want out of the network.
It's not about the network, it's about everything surrounding the network
What we've learned about network automation is that it's impossible to automate the network, or associated network functions, without reference to the systems surrounding the network. As soon as you accept this inevitable fact, then the "system" becomes the data center. See Figure 3. In this context, the interface to the network should present network-wide behaviors in an orchestration friendly way. In fact, all constituent components of the data center should represent domain-wide behaviors that are highly automatable. In the next article, we'll go further down the rabbit hole, discussing the implication here for APIs and the data and policy constructs they represent. We'll further enhance Figure 3, as well, as we discuss the primary importance of "deconstruction" along the path from human intent to system state.
For now, the take away here is this: KEEP "T" SHORT! Burn it into your mind, customer and vendor alike. Don't expose the contours of the underlying system to the user, because user experience matters. This is true for data-center wide policy as well as for the constituent systems of the data center.