Guest post originally published on the Snapt blog by Armand Sultantono

Modern Application Load Balancing With A Centralized Control Plane

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:

control-plane-data-plane-diagram-integrated

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:

control-plane-data-plane-diagram-integrated-vs-decoupled

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.

control-plane-data-plane-diagram-traditional-adc-topology

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.

control-plane-data-plane-diagram-modern-adc-topology

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:

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:

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:

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. Nova can be deployed on-premises or turn-key SaaS. Nova is an any-cloud, multi-location, centralized platform for deploying, controlling, and monitoring the delivery of your applications at scale. Nova’s built-in ML-enabled automation and simple intent-based templates and profiles massively simplify agile application delivery.