Why Developers Need a Management Plane
This the second of a three-part series. Read Part 1 and Part 3.
We wrote already about how enterprises need a management plane to more easily shift left and empower a much greater pool of users and roles to take control of infrastructure and application deployments.
No group stands to benefit more from a management plane than developers.
Here’s why yes, shifting left means greater autonomy, agility and productivity for developers. It means a faster time to market. Shifting left also means developers are increasingly expected to perform tasks previously done by more specialized teams — tasks in operations, security, networking and application architecture. This is the nature of microservices. Developers more and more own the entire application, not just pieces of the code. With greater ownership comes greater responsibility
Unfortunately, the learning curve for all those other disciplines is steep; this is why there are so many flavors of “ops” jobs today. And just saying “shift left” doesn’t make it a viable development strategy. And expecting developers to know how to set up a web application firewall, configure a load balancer or write policies for an API gateway invites errors and security risks. This is where a new construct — the management plane — becomes a necessary piece of the cloud native stack for developers, giving them meta-Ops superpowers.
Wanted: A Happy Ops Medium for Modern Apps
Developers today want and expect more control over how and where their application code runs. This control allows them to move faster and create more resilient, loosely coupled applications that are cloud agnostic and work in the cloud native deployment pattern. Having more control enables developers to configure infrastructure that best suits the needs of the application.
At the same time, developers prefer to spend the majority of their time writing code. Configuring infrastructure, securing networks or determining API rate limits are not high on their wish list of ways to spend time. Because developer time is so valuable, any way to allow them to shift left more efficiently with a shorter learning curve can deliver real business value (and makes developers happier). Platform ops teams, in particular, are striving to minimize complexity while still maintaining choice and flexibility for developers. This is where the management plane becomes critical for developers.
Why Developers Need a Management Plane
To recap, the management plane is a layer of abstraction required to handle the new levels of complexities exposed by shifting left. The data plane is the layer where networking systems — load balancers, firewalls, API gateways, ingress controllers, caching systems — read inbound or outbound packets and decide what to do with them.
The control plane is the policy layer residing above the data plane. In the control plane, the rules for how the data plane behaves are managed and configured. The two must be cleanly separated to be scalable and system and architecture agnostic; this is a long-held tenet of NGINX product design.
The management plane is a layer above the control plane that removes the need for developers to become an expert in networking, security and APIs. The management plane offers developers a quick and easy way to achieve the following:
- Granular observability of their application and the relevant infrastructure
- Governance and policy setting of multiple capabilities in a single workspace
- Out-of-the-box security and easy security tuning of application and access controls
- Configurability across all these parameters allows developers to easily modify controls and policies (for example to achieve resiliency and scalability) without breaking through guardrails
A management plane empowers line developers to accomplish all of this without having a deep understanding or mastery of how to work native data plane configuration files and policies for firewalls, networking, API management and application performance management.
With the management plane, platform ops teams can reduce the need for developers to build domain-specific knowledge outside the normal realm of developer expertise. For example, a management plane can have a menu of options or decision trees to determine what degree of availability and resilience an application requires, what volume of API calls can be issued against an app or service or where an app should be located in the cloud for data privacy or regulatory reasons.
Equally important, the management plane can improve security by providing developers smart recommendations on good security practices or putting in place specific limits on key resources or infrastructure to ensure that developers shifting left don’t inadvertently expose their organization to serious risk. For example, a management plane can recommend (or enforce) port forwarding or proxying rules to prevent exposing sensitive personally identifiable information (PII) or customer data to other services or to external IP addresses. Or PlatformOps teams can automatically add both a Kubernetes ingress controller and a WAF to all developer deployments as part of the CI/CD pipeline, ensuring that developers pushing out Kubernetes apps deploy them in a more secure fashion. (We have written about this as “making it safe to run with scissors.”)
This becomes particularly important as the total number of microservices and small applications skyrockets. Many enterprises have thousands of microservices, far more than any security team or networking operations team could sufficiently review and make recommendations for. Rather than file a ticket, a developer can go to their management plane and follow workflows that give them choices but minimize the risks. This is how management planes can become a happy ops medium that saves developers days or weeks of time wasted on configuration management, security design and more.