More interesting, what if you had the means to actually try to meet them?

On the surface, Infrastructure 2.0 seems to have very little value to the end-user. It is, after all, about collaboration at the infrastructure layer. It is under the covers, as it were, of the application blanket with which end-users actually interact. But it may end up that Infrastructure 2.0 will have a direct impact on the control the user has over the way in which applications are delivered. Which is to say they might one day have some. What this means is something along the lines of taking the “choose your download mirror” capability offered by popular download sites and cranking it up about six clicks on the dial. Yes, we’re going to turn it up to eleven. First, let’s lay out some options for these fictional (but very demanding) users:

I value speed and function equally

I value speed over function

I value function over speed

These aren’t your enterprise SLA definitions, granted, but when you’re presenting a user with options that ultimately must be translated into technical terms, you really can’t get too specific. And really, even this level of “SLA” is more than most users have ever had aside from “high bandwidth | low bandwidth” and “big pictures | no pictures”. Besides, this is my post, I’ll define my SLAs any way I want.

Now, how would you go about implementing the means by which such SLAs might be enforced?

If you said “context-aware global application delivery” you’re on the right track. If you added “enabled by Infrastructure 2.0” you get extra points. And a cookie.

There way in which you could accomplish such an implementation relies on the enabling characteristic of collaboration that comes from Infrastructure 2.0. By being able to dynamically determine speed and capabilities offered by applications deployed in multiple locations you can attempt to meet the end-user’s “SLA” when the initial request is made by directing that user to the application location that best fits their specified requirements. Obviously this requires quite a bit of collaboration, as it’s first required that you know what the conditions of the user-specified SLA in the first place. Traditional methods of accomplishing such a task are to set cookies that persist for long periods of time, and offer a “profile” or “account settings” option for the user to change them at a later time if desired. You could ask every time, but that’s a bit annoying, although this, too, could be one a part of the SLA if you extend “service level” to include “how often you ask me questions about my service level.”

Assuming that you know the conditions of the SLA you can then go about determining how best to meet it. Early on this is likely to be a configuration profile – you know which site has which capabilities, and thus you know how to interpret the SLA in terms of capabilities. In the future one hopes this aspect might become dynamic and on-demand, perhaps similar to the ideas presented by James Urquhart in his pCard proposal, but focused on end-user meta-data. Some of the capabilities you’d need to know about might the ability to apply compression or other application acceleration techniques to improve performance and of course what “functions” – which probably equate to URIs in the case of web-based applications – are enabled and which ones are not. Or perhaps the capability is simply that the location can degrade functionality if necessary to maintain response times under a specified threshold.

Assuming at this point that you know the capabilities of each location it’s now necessary to determine real-time performance and availability. That is something that’s easily enough accomplished today with global application delivery. GSLB today is capable of determining performance and status of remote application deployments as a means to load balance application requests to maintain availability and improve the end-user experience. What’s necessary to complete this scenario is the GSLB must be context-aware; it must be able to determine the end-user’s device, examine the network conditions, the client capabilities, and make a decision regarding which application deployment will best be able to meet the customer’s SLA based on those conditions as they exist at the time the request is made.

This is actually just one step forward on the application delivery path to a more dynamic infrastructure. The goal for SLA enforcement should be to essentially hand (digitally) a provider an SLA and allow the infrastructure, in real-time, to attempt to meet it. This might mean a “cloud control system” that is capable of gathering the necessary information – all the context – about a request, plugging it into a formula (its capabilities to improve performance, address bottlenecks, current response time of applications) and come up with a request-specific policy that needs to be applied in order to meet that SLA.

Yes, in real time. For each request.

What may be somewhat surprising is that we’re awfully close to being able to do this now. Most infrastructure is enabled with control-plane APIs and can provide the pieces of the context relevant to their function, and capabilities are primarily services. What’s primarily missing is the “cloud control system”, the compute resource and service overlord who oversees the creation and enforcement of a dynamically generated application delivery policy. The other missing pieces of this puzzle are the means by which disparate application deployments can communicate and of course, in this scenario, an accepted SLA meta-data definition.

These kinds of scenarios, requiring such a high-level of collaboration across infrastructure components, requires standards. Really. If you can ensure you can deploy F5 solutions across every application deployment location then you can probably implement something very close to this scenario today. But if you can’t ensure you can do that (and you can’t, because it’s not always your infrastructure to control) then we’re going to need standards to enable collaboration not just across infrastructure components but across vendors. We need the ability for an F5 Global Application Delivery Controller to collaborate with a Citrix or Cisco local application delivery solution; we need the ability for all solutions in a problem space to be able to accept, interpret, and enforce an application delivery policy regardless of which vendor’s solution generated that policy.

We need standards for that, and that’s part of the goal of Infrastructure 2.0.

Related blogs & articles:

How to Gracefully Degrade Web 2.0 Applications To Maintain Availability How FarmVille Scales to Harvest 75 Million Players a Month Payload descriptor for cloud computing: An update | The Wisdom of Clouds Clouds Are Like Onions The Context-Aware Cloud Infrastructure 2.0: Squishy Name for a Squishy Concept Users use Applications. Applications use Clouds. That Whole Concept is Broken It’s 2am: Do You Know What Algorithm Your Load Balancer is Using? Optimize Prime: The Self-Optimizing Application Delivery Network