The Role of Layer 4-7 Services in Scaling Applications for the Cloud

The Cloud Challenge
Cloud computing is increasing demands on applications and the application-delivery infrastructure must change to meet the challenge. Virtualization does not solve the problems with applications scaling, in fact it adds complexity. Infrastructure alone does not solve the challenge either. You don’t want to oversubscribe or just add capacity on demand. The infrastructure needs to respond to user demand based on business value and maintain a favorable cost structure. This means that you need intelligent load processing to manage scale, especially given the evolution of applications, which now make numerous backend function calls, which create more traffic than at the front end.

The Need for Scale
Cloud-computing applications are characterized by stateful access, with differentiated service levels, charged to the end user using the pay-per-use pricing model. Implicit in this model is the assumption that a cloud application is always on. Scaling the cloud delivery model to an Internet scale (millions of users) is a challenge that next-generation Layer 4–7 infrastructure needs to overcome. Scaling a cloud application involves scaling three mechanisms: location (mobility), replication, and load balancing. Virtualization was an early catalyst for cloud computing because it substantially lowered the cost of replication and mobility of a prepackaged application. It does not, however, solve the load-balancing problem. Load balancing involves scaling the address, name space, transport, session, identity, and business logic of the application. Clustering enables scaling of application business logic but leaves the rest of the problem to a proxy infrastructure.

Getting Beyond Stateless
Traditional data center proxy infrastructure (Layer 4–7) is stateless and focuses on transport-level session and content management. The state management in these proxies is limited to cookies that hold bare-minimum identity of the application server. Further, this state is not shared across a network overlay of proxies to enable an application for multi–data center applications or to distribute the processing to edges. For example, a load balancer does not a play any role in user customization in a data center application such as encryption of private data in the response. Not having this function in the proxy infrastructure means the data center has to incur a higher cost of development of the core application and is not able to use existing proxy infrastructure to deploy this function.

In the cloud-computing model, waiting for the application developers to add marginal functions to a cloud application (for example, user customization) will derail the business model. Adding functions to a cloud application needs to become the focus of proxy infrastructures in a cloud data center. To play this role, a load balancer needs to extract intelligence from metadata and integrate with infrastructure in the data center at layers higher in the Open Systems Interconnection (OSI) stack than Layer 2 or Layer 3.

A New Model is Needed
The current thinking in cloud computing is to disaggregate the load-balancer function and assimilate it into the switching infrastructure, hypervisor, and the virtual machine itself. One way to assimilate this function is to extend its footprint at the edge, offload stateless functions into the upstream switching and routing infrastructure, and subsume stateful functions that are currently part of the application server. In other words, convert the proxy infrastructure into a control-plane function with a distributed data plane. The evolution and eventual integration of the control plane into a cloud manager is a topic of discussion for thought leaders in the industry today.

Data centers are evolving to adopt a cloud service model. Whether the deployment model is public or private, the challenges that face application architectures are the same. To overcome these challenges, infrastructure used by the applications needs to evolve to support the cloud service models. Of the three models—PaaS , IaaS, and SaaS—IaaS and PaaS are expected to guide the evolution of Layer 4–7 services. The critical dimension of evolution for Layer 4–7 services embodied in an SLB is the programmatic dimension. SLB will have to expose all of its functions through API’s as managed objects to an external cloud manager to enable scaling of applications in the cloud computing data center.

For a deeper read on this topic see, The Role of Layer 4-7 Services in Scaling Applications for the Cloud-Computing Data Center.

Backstory: The linked paper started life as an MRD written by a product manager for Cisco ACE. I turned it in to a white paper and got it published and wrote the blog to promote it, which is also posted on the Cisco Data Center blog site.