Guest post originally published on Snapt’s blog by Armand Sultantono
A centralized control plane for application delivery allows you to use a single platform for all of your application delivery needs. It unites teams involved in the application lifecycle who are usually dispersed across many systems and platforms, with improvements in between.
Application Development teams are empowered to deploy applications on their own, with a self-service approach. Platform operations (NetOps, SecOps, Site Reliability, etc.) can set highways not roadblocks, ensuring compliance with corporate security standards without stifling the velocity of development and deployment.
What is a “Plane,” and what is the Data Plane and Control Plane?
Let’s first discuss the basics.
These days, the words “plane”, “data plane”, and “control plane” are frequently used. In various technical fields, these terms may have distinct connotations, but they all adhere to the same basic model:
- A plane is an abstract representation of where certain operations take place.
- The data plane (sometimes known as the forwarding plane) is where the “workers” of a system reside. In a network, the data plane is responsible for the actual processing of communications, right down to forwarding packets from one interface to another.
- The control plane is the management layer that manages the data plane, setting the rules for the data plane “workers” and exposing a management UI to users. In a decoupled model (we’ll discuss that next), the control plane manages the fabric of your system, the distributed data plane. In a network, a control plane controls and configures a fleet of Data Plane workers to manage traffic appropriately.
Why decouple the Control Plane and Data Plane?
The idea of decoupling the data and control planes, allowing networks to be programmed, is an intriguing notion that underpins both Software-Defined Everything (SDE) and Infrastructure as Code (DevOps). This is consistent with modernizing software systems, which is all about decoupling applications from the infrastructure on which they operate.
In general, decoupling the data and control planes has the following benefits:
- Operational Efficiency – The ability to abstract the intricacies of specific components and manage an entire complex system in a way that is more efficient than managing separate and siloed systems.
- Agility – The flexibility to allocate and reallocate resources more efficiently: autoscaling infrastructure and mixing best-of-breed platforms.
- Cost Optimizations – Achieved through efficiencies and cost savings by utilizing ubiquitous connectivity that is available as commodity hardware and readily available as a service.
The problem with traditional integrated ADCs for modern applications
In application delivery, components like load balancers and web application firewalls (WAFs) traditionally have an integrated control plane and data plane – where the user interface and logic reside in the same application as the packet processing and forwarding.
Background
The traditional ADC model of load balancers at the edge of the Data Center dates back to when load balancers (and most network functions) were dedicated hardware appliances.
Traditional load balancers were monolithic deployments in high availability configurations, often an Active/Passive pair (with one sitting idle!) that could handle the entire or substantial parts of an organization’s application portfolio. Traditionally, load balancers were rather static, with their basic settings seldom requiring modification. They worked across all of the applications that ran behind them, providing security, reliability, and performance.
Load balancers today are a comprehensive platform for application delivery and so they are also called “Application Delivery Controllers” or ADCs. ADCs are responsible for a wider and deeper set of application-centric functions, which is far more dynamic and application-specific than low-level networking functions. This includes TLS/SSL offloading, application-level DDoS attack and bot mitigation, web application and API protection, access management, and web content optimization – to name a few.
Problems
In a setting where there are hundreds or even thousands of apps, the traditional ADC model becomes a workload “bottleneck” and with the potential to produce a large “blast radius” that can jeopardize your business.
Furthermore, the traditional ADC approach is a limitation on agile development methods that allow for the rapid introduction of new features. This is especially the case where applications are deployed in microservices because instead of fewer monolithic applications that need maintenance and updating like before, microservices applications are made up of smaller services that all require specific application delivery needs and updates at a higher velocity by different app development teams. With each new release of the application code, various changes in the ADCs are often required such as modifications to routing rules, security policies, and so on.
The traditional ADC model supporting modern applications can result in continuous policy changes, which might severely strain ADCs and destabilize your application delivery and security. It also puts a strain on platform operations teams forced to make service updates during designated maintenance windows because of the burden of managing the delivery of many services.
The problem with decentralized per-application ADCs
Traditional ADCs are stifling development and concentrating workloads on a single bottleneck. What can possibly be done about it? Is it possible to solve the problem by utilizing ADCs per-application or ADCs per-tenant?
Yes, it is entirely feasible to architect a model of individually managed ADCs per-application or per-tenant (customer), because we are not constrained by expensive and purpose-built hardware appliances anymore. All modern ADCs offer virtual and even containerized form-factors packing high performance and feature-rich capabilities in a small footprint (low compute and storage requirements).
Benefits
This decentralized ADC model reduces bottlenecks and blast radius. It allows “right-sizing” of ADCs for each application, as well as empowering application teams to iterate and release new code at their own speed.
For example, an ADC cluster for App A may contain more ADC instances running on more powerful Virtual Machine specifications than App B because it necessitates greater system requirements to support heavier workloads. Furthermore, the App Dev team for App B can push new features and modify their ADC policies on a daily basis without having to worry about affecting App A’s service since they are separate clusters.
Problems
When you embrace this approach to empower application teams, it’s easy for things to get horribly out of control if you’ve established a fleet of ADC instances controlled by many teams. It would not be simple to guarantee compliance, governance, and consistency in the face of distributed deployments.
For instance, App A might use an ADC from Vendor X while App B (which fails to comply with any security standards) might use the same ADC but a previous version of code that is insecure, or perhaps a totally different ADC from Vendor Y, and all of sudden you add tool sprawl to the mix too.
How a centralized Control Plane combines the benefits of integrated and decentralized ADC models
A solution for the enterprise is a centralized control plane for application delivery. A centralized control plane provides a platform that offers a “single pane of glass” that keeps an inventory of all ADC deployments and allows you to deploy, configure, and operate your entire application delivery infrastructure in one place.
In this model, the ADC instances in the data plane are decoupled from the logic and the management UI in the central control plane.
ADC deployments can be logically organized however makes sense – per-application and per-tenant if needed. We can have “the best of both worlds” with this arrangement: Platform Operations teams can pre-provision ADC instances and set “guard rails” or global policies, and enable Application Developers to manage their own per-application ADC policies.
Of course, this is possible if the control plane supports Role-Based Access Controls (RBAC) for distinct roles to use the control plane for their specific purpose. So in this model, we bring together all the groups involved in the application lifecycle: Network, Security, Application Developers, Site Reliability Engineers, and more. A single platform to also simplify the sprawl of heterogeneous tools and minimize risk and costs associated with the operating burden and risk exposure.
When might you use a centralized control plane for application delivery?
A centralized control plane is a must-have platform when you’re managing apps that are massively scalable and distributed, with many teams involved in the application lifecycle.
There are a few key scenarios where you might want to use a centralized control plane:
- You have a hybrid and microservices architecture and need an easy way to manage your application delivery across both environments.
- You have a multi-cloud strategy and want to reap the benefits of cost optimization but want to unify tooling and observability across platforms.
- You have applications distributed on edge compute and need an easy way to manage the high volume of edge nodes in a consistent manner.
- You want to speed up app deployment and empower application developers without compromising security.
- You have accumulated a lot of tools and perhaps several control plane solutions to managing subsets of tools.
- You want the flexibility of an on-premises or SaaS solution to help with the scenarios above.
What are the benefits of a centralized control plane for application delivery?
Decoupling and centralizing the control plane is a prerequisite for modernizing your application delivery. A centralized control plane platform allows you to:
- Centralize the management of application delivery on hybrid and microservices architectures, whether on-premises or in the cloud.
- Consolidate tool sprawl for application delivery with a unified platform for Load Balancing and Application Delivery Control (ADC), API management, Web application and API Protection (WAAP), Threat Intelligence, and other critical functions.
- Manage your deployment in simpler and more flexible ways, from modern web-based GUIs to open APIs allowing centralized data to be exported and imported and integrated into third-party tooling – whether it is Cloud Platform APIs for autoscaling or API-driven controls for Continous Integration and Continuous Deployment (CI/CD).
- Improve visibility and analytics across your entire application delivery infrastructure with the ability to extract aggregated insights and granular metrics.
- Provide self-service capabilities allowing delegation of control to application teams. Once guardrails are set by other teams (SecOps and NetOps, for example), Application Developers can quickly and independently provision and customize their own end-to-end application delivery infrastructure, with Infrastructure as Code (IaC) methods in most cases.
The Next-Generation Intelligent Control Plane for Modern Application Services
If your application infrastructure’s design, monitoring, and management are simplified by the control plane, the next-generation control plane adds intelligence to the equation.
It also pushes the programmability of your data plane with adaptive and automatic network controls enabled by machine learning (ML) – executing faster and more precisely than a team of human experts.
The next-generation control plane is also ready for emerging applications for edge computing, and cloud-native architectures.
What to expect from a next-generation control plane:
- API-first control plane that can function “headless” and connect to the fabric of other specialized management planes rather than serving as the end control plane.
- Advanced ML capabilities to eliminate human intervention and errors – respond to dynamic traffic patterns, anomalies, and threats with adaptive traffic rules and self-healing, self-scaling infrastructure.
- Community-driven threat intelligence to protect against future attacks ahead of time, using real-time data collected from historical and predictive traffic flows, as well as internal and external (public and private) sources.
- Intent-based policies allow users to describe their requirements in the most basic terms possible to define outcomes and high-level operational goals, without the need to enumerate conditions and actions or even be an expert over every discrete technology function. If an app developer wishes to dynamically deploy an application in the “follow the sun” model, the control plane will instantiate and configure the required number of instances across multiple cloud platforms to meet geography-specific traffic demands without requiring user intervention.
- A highly optimized communications protocol between control plane and data plane enabling remote control of millions of devices in real-time and in parallel, with near-zero latency and extremely high scale and resilience.
Conclusion
A centralized control plane for application delivery will help accelerate application deployment and simplify lifecycle management.
It’s the solution to managing tool sprawl, siloed operations, and bringing everyone involved in the application lifecycle under one roof by addressing the challenges of hybrid and multi-cloud deployments.
Check out Snapt Nova, the next-generation application delivery platform with a centralized control plane. Contact us today if you’re ready to take your application delivery infrastructure to the next level and experience truly centralized control over every aspect of managing your applications from anywhere at any time without sacrificing performance or scalability.