TNS
VOXPOP
Do You Resent AI?
If you’re a developer, do you resent generative AI’s ability to write code?
Yes, because I spent a lot of time learning how to code.
0%
Yes, because I fear that employers will replace me and/or my peers with it.
0%
Yes, because too much investment is going to AI at the expense of other needs.
0%
No, because it makes too many programming mistakes.
0%
No, because it can’t replace what I do.
0%
No, because it is a tool that will help me be more productive.
0%
No, I am a highly evolved being and resent nothing.
0%
I don’t think much about AI.
0%
DevOps / Kubernetes / Networking / Operations

Thwart Ops Sprawl With a Unified Data Plane 

A unified data plane built on the principles inspired by Kubernetes Gateway API offers a path to break down silos.
May 15th, 2024 12:00pm by
Featued image for: Thwart Ops Sprawl With a Unified Data Plane 
Image from Lightspring on Shutterstock.

When updating a critical infrastructure element for application teams takes weeks due to coordination between NetOps, SecOps, PlatformOps and FinOps, you have a problem: ops sprawl.

First was the technology ops team. Then came network operations and security operations. Then, arising from the site reliability engineering (SRE) movement and the goal of pushing more ops decisions into the development environment, came DevOps. Not to be deterred, that gave way to DevSecOps with a security focus. As cloud native landed, PlatformOps arose to curate and deploy toolchains for proper shifting leftward.

Now there is even a discipline marrying PlatformOps with financial operations — logically, it’s called FinOps, and it’s about making sense of chaotic cloud computing costs. The end result of this ops-plosion is, naturally, “ops sprawl” that leads to “ops crawl” — fragmented teams with their own dashboards and tribal knowledge, which creates bottlenecks.

The Data Plane as the Antidote to Ops Sprawl

There is a single thread that ties all of these together: the data plane. At both Layer 4 and Layer 7, the data plane is the workhorse that does the heavy lifting. It takes instructions from the control plane and moves the data. It forwards packets, applies security rules and performs tasks like load balancing. To use biological framing, the data plane is the blood and muscles of modern applications and networking. The control plane is the nervous system. And, like the human brain, the control plane can have multiple modules for specific functionalities.

Making sure that all ops functions are first-class citizens on the data plane is the key to breaking down silos between ops teams and alleviating the scourge of ops sprawl. The challenge? Most organizations have not deployed a unified data plane and remain unaware of the concept. As we move toward a world where most applications are composed of APIs, and even monolithic applications need to be able to communicate with other systems, the concept of a unified data plane becomes ever more relevant.

The data plane originally emerged from networking constructs as a response to the theory of “separation of concerns.” This fundamental design principle involves breaking down a complex system into smaller, distinct sections, where each section focuses on a specific aspect or “concern” of the program’s functionality. In networking, operators wanted to separate functionality into a data plane, where data was passed and rules governing data movements were applied, and a “control plane” that managed the data plane and related policies.

The theory was later applied to software through concepts like the model–view–controller. In networking, the separation of concerns was dutifully copied from larger core routers and backhaul systems down into smaller systems like application delivery controllers and reverse proxies. Even as more and more elements from technology stacks followed this convention, different functions tended to keep their data planes siloed, either as a physical separation or de facto with incompatible or disconnected tools. And then came Kubernetes.

Lessons From the Kubernetes Gateway API

Kubernetes was designed to be API-first and loosely coupled, mapping to cloud native architectures. More recently, the Kubernetes Gateway API more cleanly separates the data and control planes. It gives different teams clear roles (who handles basic infrastructure, who manages the cluster, who develops apps), lets you define network setups in more detail and makes it easy to add new features.

This means teams can work better together, you have more control over how your network traffic flows without things getting too tangled and it’s easier to plug in specialized networking tools when you need them. In fact, the new Gateway API will likely become the data plane for all operational teams and the critical connective fabric that not only improves security and scalability, but also enables faster deployments, easier platform iterations and better cost controls.

Five Principles for Reducing Ops Sprawl With a Unified Data Plane

Not every organization will go all-in on Kubernetes, nor should it. That said, it is possible to extract architectural principles from the Gateway API to lay out a plan for putting all ops teams on the same data plane page and cutting the Gordian knot of ops sprawl.

Principle 1: Standardization Through APIs

The Gateway API, with its focus on standardized object definitions, paves the way for seamless integration. A unified data plane should embrace similar standards, enabling disparate tools to communicate, and ultimately reducing reliance on bespoke solutions that increase siloes. The APIs should at a minimum be able to communicate. Ideally, a single API structure for managing operational data should be designed and deployed.

Principle 2: Visibility as a Unifier

A centralized data plane must offer table-stakes visibility into network traffic, application performance and latency, resource and container-type usage, and security metrics. To truly remediate ops sprawl, costs (of infrastructure and bandwidth) should also be visible to help teams understand the impact of their design choices. Every ops team benefits from a shared, real-time understanding of the system’s health, eliminating tribal knowledge and fostering proactive problem resolution.

Principle 3: Empowerment Through Abstraction

The data plane should present the right level of abstraction for each ops role. Network engineers need fine-grained control of Layer 4 with some insights into Layer 7 for application delivery and security purposes. FinOps teams will need a view of what is being spent on each cloud provider and the projected spend. Allow them to dive in as needed, but design for comfortable abstraction.

Principle 4: Policy-Driven Configuration

Establishing a unified data plane provides the opportunity to move away from manual and error-prone configuration. Instead, adopt a declarative, policy-based approach applicable across NetOps, SecOps, PlatformOps, FinOps and others. This promotes consistency and eases change management. It also makes it possible to manage by exception rather than by repetition.

Principle 5: Observability as a Foundation

True insights come from more than just visibility. Design your unified data plane with comprehensive observability in mind — structured logs, metrics and tracing that spans all operational functions. With this capability, ops teams can rapidly pinpoint issues, identify bottlenecks and optimize overall performance.

Ops sprawl creates a drag on innovation and efficiency. A unified data plane built on the principles inspired by Kubernetes Gateway API offers a path to break down silos. This empowers ops teams to collaborate seamlessly, ultimately leading to faster delivery and better operational health for your organization.

Group Created with Sketch.
TNS owner Insight Partners is an investor in: Kubernetes.
TNS DAILY NEWSLETTER Receive a free roundup of the most recent TNS articles in your inbox each day.