Welcome to Scribd. Sign in or start your free trial to enjoy unlimited e-books, audiobooks & documents.Find out more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
The Role of Layer 4-7 Services in Scaling Applications

The Role of Layer 4-7 Services in Scaling Applications

|Views: 176|Likes:
Published by Michael Leonard
Cloud computing is increasing demands on applications and the application-delivery infrastructure must change to meet the challenge.

MCL: I wrote this paper.
Cloud computing is increasing demands on applications and the application-delivery infrastructure must change to meet the challenge.

MCL: I wrote this paper.

More info:

Categories:Types, Research
Published by: Michael Leonard on Jun 06, 2011
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





 © 2011 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 20
White Paper
The Role of Layer 4-7 Services in ScalingApplications for the Cloud-Computing Data Center
Cloud computing is increasing demands on applications and the application-deliveryinfrastructure must change to meet the challenge
Cloud-computing applications are characterized by stateful access, with differentiated service levels, charged tothe end user using the pay-per-use pricing model. Implicit in this model is the assumption that a cloud application isalways
. 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 andmobility of a prepackaged application. It does not, however, solve the load-balancing problem. Load balancinginvolves 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.Traditional data center proxy infrastructure (Layer 4-7) is stateless and focuses on transport-level session andcontent management. The state management in these proxies is limited to cookies that hold bare-minimum identityof the application server. Further, this state is not shared across a network overlay of proxies to enable anapplication for multi-data center applications or to distribute the processing to edges. For example, a load balancerdoes not a play any role in user customization in a data center application such as encryption of private data in theresponse. Not having this function in the proxy infrastructure means the data center has to incur a higher cost ofdevelopment 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 cloudapplication (for example, user customization) will derail the business model. Adding functions to a cloud applicationneed to become the focus of proxy infrastructures in a cloud data center. To play this role, a load balancer needs toextract intelligence from metadata and integrate with infrastructure in the data center at layers higher in the OpenSystems Interconnection (OSI) stack than Layer 2 or Layer 3.The current thinking in cloud computing is to disaggregate the load-balancer function and assimilate it into theswitching infrastructure, hypervisor, and the virtual machine itself. One way to assimilate this function is to extendits footprint at the edge, offload stateless functions into the upstream switching and routing infrastructure, andsubsume stateful functions that are currently part of the application server. In other words, convert the proxyinfrastructure into a control-plane function with a distributed data plane. The evolution and eventual integration ofthe control plane into a cloud manager is a topic of discussion for thought leaders in the industry today.This white paper discusses the challenges in scaling a cloud application and the role Layer 4-7 services can expectto play to scale application services in a cloud data center.
 © 2011 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 2 of 20
Evolution to the Cloud
The dominant model for application delivery today, the web application model, was triggered by advancement intechnologies that enabled platform-independent representation of input and output of an application. Having aplatform-independent representation of application data enabled creation of the browser, which over time extendeditself beyond simple rendering of mark-up text to a mini-run-time interpreter for fourth-generation languages suchas JavaScript. Code migration from back-end server to the browser enabled an application to initiate multidomaindata-access connections and enhanced the application interactivity afforded by asynchronous interactions with theback-end web server. HTML 5.0, which is now supported by Internet Explorer and Firefox, enables standardbrowsers to render rich-media graphics and support models of interaction that are currently possible only withproprietary technologies such as JavaFX, Silverlight, and Flash. These technologies, which were initially greetedas a security hazard, are today looked upon as a building block to deliver fully functional applications resident on aserver cluster - in other words, cloud computing. The ultimate goal of cloud computing is having a stateless clientwith varying sizes of caches and a changeable identity accessing applications resident across WAN distances in astateful manner. This concept is not new - it has been the preferred application-delivery model since the advent ofWeb 1.0.The evolution to the cloud started with a client-server model of the late 1980s when applications were resident on aserver within a Domain Name System (DNS) domain. What has changed is that the data center is the new server,and it is located several DNS recursions and WAN hops away. The economic factors that led the industry awayfrom mainframe to client-server computing continue to be in effect and, in fact, have been catalyzed by thewidespread use of virtualization in data centers. However, simply hosting an application in virtual machines is notcloud computing. The critical difference is the application composition. Virtualization has not changed thedistribution, composition, or invocation of the application.
In other words, virtualization has not changed theusage model of the application, nor has it changed the run-time model of the application - what it has doneis changed the management model of the infrastructure of an application.
In contrast, cloud computing aimsto make the application itself the infrastructure by offering the application components as services (Platform as aService [PaaS]). The application itself transforms into coarse-grained (or lightweight) services that can resideanywhere (mobility or location), can be invoked from anywhere (Internet scale), and can reside on any device. Themanagement of these services is governed by a service-level agreement (SLA) between the cloud and the enduser, and a substantial portion of the management function is delegated to the end user.Like all disruptive innovations of the past in the data center, cloud computing too arrived unexpectedly.Virtualization - that is, a continuation of a prior trend toward server consolidation - created a bigger problem that itsolved. The ratio of administrator to (virtual) machines rose to a level such that administrators themselves startedto ask for automation. This advance to automation of a virtual data center is now serving as a catalyst to thecreation of cloud data centers and cloud applications. It is now widely accepted that the road to cloud computinggoes through a virtual data center. The debate has shifted to how best to design the next-generation data centerwhere the design center is the data and not the application. Shifting the design center has wide ramifications on thearchitecture, organization, and operational model of the data center. Table 1 lists the important differencesbetween virtual data centers and cloud data centers from an application perspective.
 © 2011 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 3 of 20
Table 1.
Differences Between Three-Tier Data Center, Virtual Data Center, and Cloud Data Center from ApplicationPerspective
ApplicationCharacteristicTraditional Three-Tier Data Center Virtual Data Center Cloud Data Center (Public orPrivate)Development model
 Structured data model with logicimplemented as componentsbundled with the executionenvironment
 Same as three-tier data center
 This unstructured data model haslogic implemented as services ontop of the data store, composedinto an end-user application by theuser
 The application is written to a PaaSthat integrates multiple disparatedata models and offers a singlelarge data table with name=valuepairs
 Logic executes on input/outputcard containers, and the end userselects the view
Deployment model
 Separate model (data) from theview (presentation) from thecontroller
 Results in a three-tier data center
 Same as three-tier, but affords co-location of three tiers on a singlephysical server (through isolation)
 Model differs by data center
 Unstructured data is stored in adata store, indexes to which arestored in Relational DatabaseManagement Systems (RDBMS),and data is exposed using batch jobs. In other words, data is thedesign center of the data centeroptimized for querying
 Applications are lightweightservices that are deployed using adeveloper portal onto a cluster, andpresentation is an end user-customized template that is fetchedupon access
Execution model
 Fine-grained distribution acrosstiers of data center with fine-grained access to data
 Application servers: Optimizeconnection management acrosstiers; are enhanced using proxies
 Same as three-tier but affordsmobility of execution environmentacross physical server boundaries(migration)
 Enables elasticity of executionenvironment modular support ofoperating system
 Users have coarse-grained accessto data in batches
 Services work off shared storage
 Application servers aredisaggregated into pools of JavaVirtual Machines (JVMs) runningPlain Old Java Objects (POJO)files
 Session management of theapplication server is separated outas a session manager
 The proxy layer queues requestsand is not in the path of responses
Access model
 Optimized for browser and desktop
 Centered on synchronous HTTPaccess to data over a portal
 Same as three-tier; however,intravirtual machine traffic needs tobe redirected for proxy functionprocessing
 This model supports asynchronousaccess and cache synchronization,in addition to portal access
 The access controller is thesession manager
 Proxy exists only to negotiatenetwork topology
Security model
 Focused on transport security,identity management, andsandboxing of executionenvironments
 Same as three-tier; however,intravirtual machine traffic is notsubject to security policies
 This model is a work in progress
 A private cloud is posturing as asecurity model, but in reality it isnot
Management model
 Separation of roles into serveradministrator, networkadministrator, and storageadministrator, each with its ownmodels
 Cross-function management doneusing workflows
 Forces a convergence ofmanagement models because ofvirtualization
 Server administrator subsumingnetwork administrator role because80 percent of the traffic staysinside a data center
 Support for a self-service model
creates the “user” as an additio

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->