Why Enterprises Need a Management Plane
This is the third in a three-part series. Read Part 1 and Part 2.
Working on the control plane of cloud native infrastructure is not for the faint of heart.
Light on menus and heavy on config files, the control plane is easy to mess up, especially when an inexperienced admin tries to set traffic control, security or access-control policies.
In part, this is because the traditional control plane for applications came about when there were fewer roles and specialized products – your enterprise might have had just a handful of load balancers, a couple of application delivery controller (ADC) instances, global firewall and a web application firewall (WAF).
Today, enterprises with large cloud native applications might need tens of thousands of load balancers, each with its own WAF. These distributed networking and traffic-management elements sit in front of distributed and constantly moving containers. Managing that fleet en masse via scripts and without abstractions is a tremendous accomplishment even for the most astute DevOps, NetOps or DevSecOps teams.
But the whole point of cloud native is to empower more people to be self-sufficient and shift capabilities left. At the same time, we need to make it possible for humans to manage this constantly morphing compute kaleidoscope, and at machine speed.
In this era of mass computation and containers, a layer of abstraction is needed above the various control planes to set and enforce policy, to deliver enterprisewide observability and to provide a security layer across everything.
That new layer is the management plane, the latest essential tool in cloud ops. The management plane is key to enabling cloud native systems to deliver promised efficiencies and capabilities at scale for the entire enterprise.
What Is the Management Plane?
In networking systems and architectures for larger organizations, we have long thought about management in terms of two planes:
- Roughly speaking, the data plane is where data lives, moves and acts. It is where networking systems – load balancers, firewalls, API gateways, ingress controllers, caching systems – inspect inbound and outbound packets and decide what to do with them.
- The control plane is the policy layer residing above the data plane, where the rules controlling how the data plane behaves are managed and configured.
A long-held tenet of NGINX product design is that the two planes must be cleanly separated for your architecture to be scalable and system- and architecture-agnostic.
With the rise of cloud native, shift left and modern apps, we are seeing an emerging need for a further layer of abstraction: the management plane. The management plane is a layer above the control plane that reduces management complexity on the control plane and makes it easier for different personas inside the enterprise to manage applications, networking and compute resources.
The Platform Ops team designs and configures the management plane. Users of the management plane likely include the usual suspects: application development teams, DevOps, SecDevOps, SecOps and NetOps teams.
Beyond these core networking, application management and security teams, many other teams can use the management plane to do their jobs more easily while staying within architectural guardrails designed to safely provide scalability, security, resilience and observability.
Other beneficiaries of the management plane include IT teams, procurement teams, API management teams, infrastructure management teams and even marketing teams. In other words, the management plane becomes a broad offering that benefits users well beyond traditional networking, security and application development teams.
With Cloud Native, Everyone’s an Infrastructure Engineer
As we transition to modern apps for the cloud native era, the entire concept of centralized control and specialization of roles has been turned on its head. Consider average developers building a microservice. In the past, they primarily worried about the quality of their application code.
But with modern apps, developers have more responsibilities. To ensure their microservice runs and scales, they need to set up ideal traffic-management policies and load-balancing rules, configure firewall rules for a WAF, set API rate limits and retry policies – and that is just at the traffic level! For the most part, performing these tasks requires detailed knowledge of the control plane and data plane combined with mad scripting chops.
It’s the same story for marketing technologists, a newer but fast-growing persona. They need to scale their systems up and down for marketing efforts and are usually one layer up from application developers. But they have the same concerns and needs around guaranteeing security, resiliency and observability of the infrastructure of the marketing stack.
Take this over to the NetOps experience, where they’re now tasked with managing networking security and reliability not just for global networks using a global set of appliances, but also for numerous types of networking instances across different clouds, vendors and more.
This is not what the networking team signed up for, and it’s not sustainable. Even going from one major system to two means that complexity grows astronomically. Add Kubernetes to the mix and it gets even more complicated; networking looks and feels completely different with commingled Layer 7 and Layer 4 traffic and new data routing and control methods.
The Management Plane Reduces Complexity, Increases Control and Enables Scaling
It’s not enough simply to expose control-plane management tools to new stakeholders; that is more likely to increase the complexity and the scope of their jobs. This is why enterprises must consider embracing the management plane. Let’s look at how the management plane helps specific teams.
- Developers: The management plane presents a single interface in which microservice owners can pick from a basic list of settings and configurations for all the necessary infrastructure for their application – load balancer or ingress controller, API gateway, WAF, etc. The service owners can choose from a curated list of configurations and policies, allowing them to set parameters for their application runtime, networking and security. This enables shift left, agility and speed while minimizing cognitive load and requirements for specialized knowledge.
- NetOps teams: The management plane enables quick changes and policy checks across all networking applications without requiring NetOps teams to learn multiple coding languages, like NGINX conf scripts, YAML and Terraform’s scripting language. The management plane also allows them to export observability and telemetry data for all networking systems into centralized and customizable dashboards and reports.
- Line-of-business engineers: Use the management plane to procure instances to scale out their systems confident that the instances already have all the properly configured security, traffic and restart settings.
Across all these teams, the management plane solves one common problem: too much stuff to think about. To ensure that shift left works and that an organization can convert to cloud native and run quickly to build modern apps, all teams will need to learn to do more with more. NGINX believes that a management plane layer tuned for productivity, resilience and security removes complexity at both the control plane and the data plane.