Boil down information technology to its basic elements, and what do you get? Bits on a wire (or whizzing through the air, as the case may be).
While early military applications of networking date from the late 1950s, it was the semi-automatic business research environment (SABRE) connecting two mainframes back in 1960 that marks the first commercial computer network. To this day, SABRE remains at the heart of the global airline reservation system.
Networking technologies have undergone many generations of innovation since the early days of SABRE, of course. Today, all of IT depends on it – including the entire scope of cloud computing.
In fact, if the physical layout of cables, switches, and routers still determined the network topology (as it certainly did in the 1960s), then cloud – along with the rest of modern IT – would be a non-starter.
Cloud computing as we know it today wouldn’t exist if it weren’t for a fundamental networking innovation borrowed from the telephony world: the separation of concerns.
Dial 0 for Operator
As any old movie buff knows, human operators used to handle phone call routing manually. Automating the switching system required a separation of concerns between call routing control and the technology that connected the call and kept it live until someone hung up.
These two areas of concern are the control plane and data plane, respectively.
Modern computer networking takes a page out of the telephony playbook, separating the control of the network from the data passing through it.
Network operator configuration of the network takes place in the control plane, including the layout of the network topology itself. Devices on the data plane then move packets according to the policies and rules set out in the control plane.
The power these planes bring to the organization is profound. We can configure the entire network via an abstract representation of it – a model, if you will – and then expect the physical network to follow the instructions in the model automatically.
Control planes are at the heart of cloud computing. Any cloud user can log into their cloud account and configure everything about their instance of the cloud, from the networking on up. How the bits get from place to place is entirely hidden from view, as the cloud provider’s data layer takes care of all the details.
This separation of concerns is as essential to cloud-native computing as it is to the cloud itself. After all, cloud-native means extending the best practices of the cloud to all IT – including the power of the control and data planes.
But the cloud-native story doesn’t end with networking. In fact, the concept of a control plane (along with its corresponding data plane) represents a core cloud-native abstraction that unifies many of the architectural principles behind this new computing paradigm.
Beyond the Service Mesh
The most familiar cloud-native control planes appear in the architecture of service meshes. Service meshes separate the control of east-west (container to container) interactions from the networking paths that define those interactions.
The result is better management of the security considerations for such interactions, along with the configurability of the interactions themselves – even though individual microservices may be ephemeral.
Modern service mesh technologies are still immature, but the cloud-native control plane pattern is in place. The path forward is becoming clearer.
Today, service meshes generally don’t handle north-south traffic between microservices and other systems (aka ingress traffic), leaving API management technologies to handle the challenges of such traffic.
However, the writing is on the wall: there is no fundamental difference between north-south and east-west traffic – that is, no difference at the data plane. Instead, the control plane should be entirely responsible for supporting the configurations of traffic to and from all points of this virtual compass.
Tackling Integration at the Control Plane
Once we abstract all endpoint interactions with a combination service mesh/API gateway that operates at the control plane, what we have done is essentially reinvented enterprise integration.
Ever since enterprise application integration came on the scene in the 1990s, it has largely been a static, design time exercise. Define your endpoints and then figure out the protocols and transformations necessary to get data from here to there.
Dynamic integration – where the middleware responsible for the integration made the choice of a particular endpoint at runtime – was a popular idea in the early 2000s, but turned out to be nothing but a SOA pipedream. The underlying problem: unclear separation between the control and data planes.
In essence, the only way to perform integration back in the day was to include some of the controls in the data plane – a shortcoming that cemented rigidity throughout the entire architecture.
Today we’ve largely learned this lesson. By cleanly separating the control and data planes, cloud-native integration promises a new era in dynamic integration.
This separation abstracts the endpoints, allowing the data plane to resolve them – and thus, the message paths – dynamically at runtime.
At the control plane, either human operators or automated bots work entirely with such abstracted endpoints, defining and managing the policies and rules that govern interactions among them.
Dynamic integration was a nice-to-have in the SOA days, and for the most part we didn’t have it. In contrast, it’s a must-have in today’s cloud-native world, because integration endpoints are inherently ephemeral. We simply don’t have the luxury of improperly separating our control and data planes anymore.
Bringing the Control Plane to Cloud-Native Security
The challenges of securing interactions between abstracted endpoints is at the heart of cloud-native security.
Zero-trust computing, a Forrester term from 2009, considers all endpoints to be untrusted until they are intentionally granted particular privileges. Before cloud-native came computing along, however, security technologies assigned identities to endpoints as though they corresponded to human identities.
In the cloud-native world, endpoints are more likely to be both ephemeral while not associated with a particular human. After all, every smartphone, IoT sensor, microservice, or serverless function can now be an endpoint.
Cloud-native zero trust, or what I like to call trustlessness, must take a different approach. It must cleanly separate the control plane that concerns itself with defining policies for abstracted endpoints from the data plane where enforcement takes place.
Hybrid IT and Multi-Cloud also Depend upon Control Planes
While cloud computing itself depends upon the clean separation between control and data planes, cloud-native computing must extend these abstractions to multi-cloud and hybrid IT (the combination of one or more clouds plus on-premises).
This requirement is a tall order to be sure: imagine a single pane of glass for defining all policies related to the behavior of the entire enterprise hybrid IT landscape. Create or modify a policy, push a button, and an enterprisewide data plane automatically puts the policy into production.
This comprehensive control plane vision for hybrid IT is both extraordinarily ambitious and also essential to the proper working of the hybrid infrastructure. Many vendors are already implementing parts of this vision, and early adopter enterprises are on the road to deploying such cloud-native hybrid IT today.
The Intellyx Take
The cloud-native separation between control and data planes pulls together several important cloud-native principles.
The principle of immutable infrastructure, for example, calls for the configuration of any and all infrastructure in order to define its implementation. To make a change to infrastructure, change the configuration and redeploy.
This configuration takes place at the control plane. The data plane, in turn, must automatically conform to that configuration.
Intent-based computing also depends upon the separation of data and control planes. With intent-based computing, one level of policy configuration represents the business intent for the technology in question. The infrastructure then automatically translates that business intent into configurations that the data plane can automatically implement.
The final piece of intent-based computing: the infrastructure must also continually check to ensure the deployed technology hasn’t drifted from the business intent. If it has, it should bring it back into conformance automatically. Such automation depends upon the clear separation of the planes.
A final word of advice: don’t fall for vendor confusion on this topic. Some vendors are trying to define a third, separate ‘management plane’ – because they have management gear to sell. In reality, management functions are all part of the control plane. There’s no need to overcomplicate matters by adding a third plane.
Similarly, don’t fall for fake planes where control isn’t fully abstracted away from the data plane. Traditional integration software, for example, is notorious for falling into this trap. Some vendors of so-called ‘zero-trust’ software also succumb to this mistake.
Cloud-native is more than a label – yet as with all jargon, people can apply it improperly. Be sure you look more closely at the software wares on offer to be sure they cleanly separate the control and data planes. If they don’t, you can be sure they’re not following cloud-native best practices.
© Intellyx LLC. Intellyx publishes the Intellyx Cloud-Native Computing Poster and advises business leaders and technology vendors on their digital transformation strategies. Intellyx retains editorial control over the content of this document. Image credit: Robin Hutton.
