What is needed to customize the cloud is a pair of data center ruby slippers called Infrastructure 2.0.

Frank Gens of IDC discussed the “New IDC IT Cloud Services Survey: Top Benefits and Challenges” in his blog and what is not surprising is that security continues to top the challenges associated with cloud services. What may be surprising to some is the increasing focus on customization. It shouldn’t be. As customers continue to push at the boundaries  of the cloud computing model they will inevitably find it unable to meet some need they have, such as customization.

See, when IT professionals said they didn’t want to worry about infrastructure that didn’t necessarily mean they didn’t care about the infrastructure. What they meant was they didn’t want to bear the operational and capital expenses associated with infrastructure if they didn’t have to. That’s a very different story than not caring about the infrastructure or about their ability to provision it, manage it, and ultimately control it. Applications are never deployed in a vacuum, after all, and part of the way in which they are secured, optimized, and made highly available is through its supporting infrastructure. Many of those options are simply no longer available in “the cloud”, and this is likely to be a bullet point in the “against cloud” column for many organizations who employ a more infrastructure inclusive strategy to delivering applications.

We could easily argue that “lack of interoperability standards” (cited higher on the challenge scale at 80.2% of respondents concerned to very concerned about standards in the survey) is directly related to this lack of customization capability (76% cited this as a concern). After all, interoperability standards across infrastructure of similar ilk would, ostensibly, make it easier for cloud computing providers to offer the infrastructure services required to customize the environment.

Infrastructure 2.0 is the means by which many of these concerns will eventually be addressed.

I will now shamelessly adopt terminology generally associated with SOA because cloud computing and “self-service” customization is, at its core, about leveraging a service-oriented architecture. That’s why we call them “services”, after all. That in the case of cloud computing the architecture is focused on infrastructure is irrelevant; the same principles embraced by composite applications built from software (business) services can be equally applied to a data center architecture built from infrastructure services.

Infrastructure 2.0 capable devices, whether virtual network appliances or physical hardware implementations, are solutions enabled with some sort of control-plane, usually REST or SOAP and accessible via an HTTP-based communication channel. These control planes provide the means by which cloud computing providers – or ISVs or regular old folks in the enterprise – can integrate infrastructure services into the application deployment and delivery chain.

This is nothing new. These capabilities have actually existed for nearly a decade now. What is new is cloud computing and virtualization and the need for automation and orchestration of the application deployment and delivery chain to enable efficiency and drive down the costs associated with delivering large-scale applications through rapid elasticity and scalability.

By exposing infrastructure services to customers it allows customization in a consistent way. The interesting thing about virtualization and cloud computing is that like SOA, the service implementation can vary without changing the interface through which the service is provisioned and managed. Some services may actually reside on physical infrastructure hardware while others might require the provisioning and deployment of a virtual network appliance (VNA). The customer may care about the implementation as it could effect cost or require specific management skills to include in their “virtual infrastructure” in the cloud environment.

For example, a cloud provider is going to provide load balancing as a means of scaling applications and, likely, virtualized infrastructure services. Using infrastructure 2.0 capabilities, the APIs and SDKs that manage and control infrastructure, the provider can offer a variety of options and billing structures based on the form factor and capabilities. One service might be a basic load balancing service, via a shared hardware Load balancer, with its only options being a choice of a few load balancing algorithms. Customers requiring more intelligent load balancing algorithms might be able to choose the same service on a shared hardware load balancer, but with more options and at higher costs. Customer desiring advanced application delivery capabilities such as network-side scripting or protocol optimization or security may be offered the choice of such services via a dedicated virtual application delivery controller, at yet a different cost rate. The reason this works is because the service interface is the same regardless of whether the form factor is hardware or virtual; it’s SOA in the network; an abstraction that allows for differences in implementation internal to an environment and, eventually, across environments.

As a customer chooses services to include in the application delivery chain it becomes essentially a composite infrastructure based on a chain of individual services. This is very similar to the way in which composite SOA applications would be composed: as individual services that combine to form a complete application.

What an infrastructure 2.0, service-based model offers both sides of the cloud equation – customer and provider – is choice. Choices in deployment form factor, choices in services offered and available; the customization cited as concerning by customers exploring cloud computing environments. This is the way in which cloud providers will be able to differentiate their offerings – by providing choices to customers in the infrastructure services available.

Remember Dorothy thought she needed the Wizard of Oz to get her home. Only after she saw that the wizard actually wasn’t, that he was just a man moving levers and pushing buttons behind the covers, was it revealed that she’d always had the power to go home on her own: those red, ruby slippers. Infrastructure 2.0 are the customers red, ruby slippers; providing the means by which they can customize their cloud-based application delivery infrastructure in the way that best suits their needs, without the help of the Wizard of Cloud.

An Infrastructure 2.0 services-based model is vital to addressing several of the challenges still raised in surveys: lack of interoperability standards, ease of integration with internal applications/infrastructure, migration back to the enterprise data center. If data center architectures are based on services, and not specific hardware or virtual implementations, it will be a lot easier to migrate that architecture between cloud computing providers and the local data center (“in house”) because the over-arching orchestration, the model, is a composite of infrastructure services. It essentially becomes an architecture built on solutions, not products.

That’s not to say there aren’t challenges associated with an infrastructure 2.0 services-based data center model. Differences in service implementation right now make it difficult to migrate services between vendor implementations, something that must be addressed before complete portability is possible. But this is the next evolutionary step in cloud computing: the abstraction and normalization of infrastructure services. Without this step customers will continue to raise the same integration, portability, and customization issues as they do today, and the growth of cloud computing will eventually slow to a crawl.

Related blogs & articles: Creating a Hybrid ADN Architecture with both Virtual and Physical ADCs [PDF] Infrastructure 2.0: Squishy Name for a Squishy Concept  All Infrastructure 2.0 Topics on DevCentral  That Whole Concept is Broken The Devil is in the Details Virtual Infrastructure in Cloud Computing Just Passes the Buck Scaling Security in the Cloud: Just Hit the Reset Button Vertical Scalability Cloud Computing Style Scaling AJAX Applications is More About Architecture than Apache The Question Shouldn’t Be Where are the Network Virtual Appliances but Where is the Architecture? You’re Asking the Wrong Question About Virtual Appliances

Check out the “New Infrastructure” track at Cloud Connect, where we’ll be discussing these topics in more depth.