The Myth of a Single Pane of Glass

For as long as I can remember - and I can remember a long time - the siren call of a single pane of glass through which to view and operate infrastructure has lured IT. Like the Holy Grail, it has never been discovered and a good many IT professionals have become cynics as to its existence.

Digital transformation has put the final nail in the coffin of this mythical management construct and given rise instead to a new one: a single plane of control.

The good news is that unlike the single pane of glass sought by intrepid IT explorers of the past, a single plane of control may be within our grasp. That's because it's based not on a GUI, but the API.

And not just any API, but a declarative API.

To understand why, let me take you back to 2010 when the term "Infrastructure 2.0" was in vogue.

At the very lowest layer of the architecture is Infrastructure 2.0. Infrastructure 2.0 is focused on enabling dynamism and collaboration across the network and application delivery network infrastructure. It is the way in which traditionally disconnected (from a communication and management point of view) data center foundational components are imbued with the ability to connect and collaborate. This is primarily accomplished via open, standards-based APIs that provide a granular set of operational functions that can be invoked from a variety of programmatic methods such as orchestration systems, custom applications, and via integration with traditional data center management solutions. Infrastructure 2.0 is about making the network smarter both from a management and a run-time (execution) point of view, but in the case of its relationship to cloud and IT as a Service the view is primarily focused on management.

Infrastructure 2.0 includes the service-enablement of everything from routers to switches, from load balancers to application acceleration, from firewalls to web application security components to server (physical and virtual) infrastructure. It is, distilled to its core essence, API-enabled components.

From <https://devcentral.f5.com/articles/infrastructure-20-cloud-it-as-a-service-an-architectural-parfait>

Sound familiar? We don't call it Infrastructure 2.0 anymore, we call it "continuous deployment" and "automation" and other DevOps-type terms. But the concept is the same. Embedded in this idea is the reason a "single pane of glass" has never come to fruition. Because for such a mythical construct to exist, a single solution would need to incorporate (integrate via manual methods) a vast array of network, application service, and security solutions.

That was never going to happen.

To be honest, it was never going to happen despite the API-enablement of most of that infrastructure. Why? Because all those APIs were imperative, and just as tightly coupled to the object model of each device as was their GUIs. Imperative APIs are inherently tied to device/service specific object models that impose a heavy burden of operational expertise on those who try to use them. Now imagine the jack-of-all-trades in your IT organization who you trust to operationally manage routers, switches, security devices, and five different categories of application services across multiple vendors.

Exactly. Such a creature is like Bigfoot. Often heard of, but never proven to exist.

What do I mean by that? I mean this:

The way in which we, for example, represent a pool or a VIP (Virtual IP address), or a VLAN (Virtual LAN) is not the same way Cisco or Citrix or Juniper represent the same network objects. Indeed, our terminology may even be different; we use pool, other ADC vendors use "farm" or "cluster" to represent the same concept. Add virtualization to the mix and yet another set of terms is added to the mix, often conflicting with those used by network infrastructure vendors. "Virtual server" means something completely different when used by an application delivery vendor than it does when used by a virtualization vendor like VMWare or Microsoft.

From <https://devcentral.f5.com/articles/making-infrastructure-20-reality-may-require-new-standards>

THIS is the reason we can't have nice things, like a single pane of glass. Because the industry doesn’t have a single pane of glass through which it views infrastructure.

But this post is not designed to depress you or to lead you down a path to an IT existence marred by management on a per-device basis forever. Au contraire. Declarative - truly declarative - APIs can lead to a single plane of control.

But to do that, we need to move away from the idea that declarative means encoding our device configurations in JSON or YAML. This is not truly declarative because it still relies on operational domain expertise that is tied to device specific object models - and no one else can ingest and use them.

Let me use Kubernetes Service and Endpoint resource descriptions as an example of a declarative model:

Everything I need to configure a virtual server is right here in these very concise - and implementation agnostic - definitions. The externalIP is the virtual IP address - the address the user or mobile app is going to communicate with. The name "my-Service" describes a virtual server, with the spec providing the network details like which ports to use and which pool ("MyApp"). The Endpoint resources describe each of the nodes that make up "my-service" and provide the members for the pool "MyApp". The only thing missing here is a way to select a load balancing algorithm for those services capable of doing more than round robin.  And we could easily extend the "spec" portion of the service description to include an "algorithm: RR | WRR | LC | FR" option that is universally applicable to all load balancing solutions. There. Done.

In theory, I can feed this same resource to any one of ten different load balancing solutions and each one would determine how to model and implement the intent of the description - which is to configure a virtual service located at 80.11.12.10 port 80 which scales HTTP requests across two application instances located at 1.2.3.4 and 2.3.4.5 on port 80.

Another way to think about this is the difference between "I'd like a pepperoni pizza" and the more tedious, "I'd like you to mix up some pizza dough and then roll it out into a circle with a 10-inch diameter. Cover it with tomato sauce. Cover that with mozzarella cheese, Now place pepperoni all over the top. Bake at 425 degrees for 15 minutes."

One of these things is easier and obfuscates you from the details. The other forces you to not only know what you want - pepperoni pizza - but how to make it, as well. That's operational expertise right there.

Like ordering a pizza, the Kubernetes resource description is generic. Nothing in it forces any particular object model or method of implementation on the device that ingests this resource. It describes what needs to be present, but in no way impinges on how I might implement it.

To be truly declarative means to provide the means to communicate intent and the desired end-state. At some point in the future, we will just be able to say, "configure a virtual service for 'my-app'" and voila! Using meta-data and application tags and automated, intelligent discovery, the service will configure itself from top to bottom*. 

If we're ever going to reach that nirvana of a single plane of control, we are going to have to buckle down and come up with neutral declarative specifications that eliminate the need to integrate via imperative API every device in the data center. Because device-by-device API integration is really not that different than device-by-device management.

We want nice things. We want a unified, single plane of control. But to get there, the industry is going to have to do better than head-nod toward declarative and recognize that if no one else can ingest and use your declarative interface, it isn't really declarative in the first place.

*A girl can dream, can't she?