The Future of IT Infrastructure: Controllers of Controllers?

One of the central tenets of software-defined networking (SDN) is the notion of separated control and forwarding planes. Architecturally, this separation manifests itself in most solutions through an SDN controller. Accordingly, as companies work through their SDN product strategies, they have to determine what role the SDN controller plays in their solution. There are three primary schools of thought here:

• We will own the controller market. If the SDN controller plays such a central role in the future of networking, then owning the controller puts you at the center of the SDN universe. The core strategy of those who would own the controller space is that the point of control can be monetized. By offering software that can serve as the control plane, these companies hope to ride the ‘S’ in SDN all the way to a lucrative business. The size of the opportunity will be directly related to the install base over which the controller can preside. It becomes paramount then to offer a generalized controller with standard interfaces so that the opportunity includes as many vendor deployments as possible.
• We will interoperate with any controller. Some companies believe that the controller will be difficult to either execute against or monetize, or maybe it is just outside their core competence. Whatever the reason, they have selected a product strategy that acknowledges but does not include the SDN controller. Rather they will build a portfolio that interoperates with multiple controllers. Whatever the control plane the customer chooses, their devices will interoperate through standard protocols. Fundamentally, this strategy assumes that the monetization of the network is still primarily through hardware and services.
• We believe in solutions. Still other companies treat the SDN controller as part of their overall solution. The controller is not necessarily a point product that is sold as a standalone entity but rather a constituent element of a broader solution. These companies have no ambition to provide a controller capable of driving other-vendor gear.

The question is how do these strategies come together in a heterogeneous environment?

For medium and large-scale environments, it seems unlikely that customers will create a single maintenance or failure domain. In other words, there is unlikely to be any sizable deployment dependent on a single controller. The more likely scenario is a set of smaller domains, each managed by one or more controllers. In this environment, the meaningful architectural dilemma to be solved is whether these controllers act as standalone control planes or a federated set of related control planes. The architectures become even more challenging when you consider that there might be service or application-specific controllers as well.

Basically, how are controllers going to interoperate with each other? When an application workload requires coordination across multiple control domains, what is the mechanism by which the controllers collaborate?

It could be that controllers simply do not collaborate. In heterogeneous environments today, orchestration is difficult without fairly complex management systems (think: OSS/BSS). Perhaps this will always be true. Of course this seems like an unnecessarily limiting future, and it is likely mostly the cynics – those who believe the problem is unsolvable – that see this as the future.

Other believe in more of a Tolkien-esque future – One Controller to Rule Them All. This implies some inherent controller hierarchy. In this scenario, what company will willingly subordinate their product to someone else’s? It would seem that the master controller would be the easiest to monetize and drive the most product pull-through. It is hard to imagine any company willfully submitting to this type of architecture. And even then, there are practical considerations around controller communications that would need to be worked out.

This leaves the most likely scenario being a loose federation of controllers. But even then, how do the controllers cooperate? What control mechanisms will emerge?

Here, I think our collective reliance on protocols has bred some bad behavior. While the industry is certainly capable of developing new protocols (or extending existing ones), is this really necessary?

The notion of coordinated control is not necessarily protocol dependent. The currency for this type of orchestration is actually data. It could be that a realtime exchange of state information is sufficient to handle most types of workflows. If this is the case, the real solution is less about subordination and more about data relay. In a model where the data is elevated rather than the controller, the onus is put on individual controller vendors (standalone or solution-oriented) to publish and consume data.

This approach has the added advantage of decoupling controller work, allowing individual vendors to move forward at their own pace. It also reduces the burden of industry consensus, which might never fully emerge. And even if rough consensus is achieved, the data set is forever changing, which means that there will never be a complete and fully-converged data model.

Instead, it is more pragmatic to product a common data engine and allow publishers and subscribers to its contents to normalize the data as they need to. This encourages disparate access, authentication, formats, and even data sets. Of course, something so central to an entire industry would need to reside outside any single vendor’s control.

Taking this to the extreme though, the future of controller-controller interoperability is not only an SDN phenomenon. While SDN has been advancing controller-based architectures (which are not new to SDN either, by the way), other industries like storage have been pursuing similar control models. Whatever solution is ultimately settled on for the networking industry will quickly be required to extend to orchestrate workloads beyond just the network. If it is difficult to see a controller of controllers in the network, imagine how fierce the battle will be over the whole of the data center.

Forgetting even the product implications, the vendor dynamics are enough to ensure that a controller-of-controllers architecture does not one to fruition.

Read more:

• Setting Up a Development Infrastructure on a Shoestring