The subtext to the cloud computing discussion is subtle, as is the wont of subtext. But it is clear that underlying all the concerns about cloud computing is a common theme: control. Whether we’re talking about reliability or security, it should be obvious if you’re reading between and beneath the lines that the biggest stumbling block to massive cloud adoption is the issue of control.

There is a very real difference between on-demand computing and on-demand infrastructure. What the cloud provides now, and is described by just about every cloud pundit as the benefit of cloud computing, is on-demand compute resource provisioning. Central to this theme is provisioning, but also relevant to the discussion of that provisioning is applications, not infrastructure. Even when we confine the discussion strictly to IaaS (Infrastructure as a Service) we aren’t really talking about on-demand infrastructure services, we’re just talking about on-demand infrastructure as a whole.

Take a look at the offerings in the IaaS demesne and you’ll quickly find that what you can provision, on-demand, is an entire infrastructure – not individual services. Even the latest announcements around plug-n-play data centers is about implementing a data center architecture using complete components, not services. These types of offerings are geared around data centers design – not infrastructure-in-the-cloud-as-a-service-design. The use of “Infrastructure 2.0” to refer to drag-n-drop components (complete solutions) as opposed to the provisioning and orchestration of drag-n-drop infrastructure services just dirties up the cloud. There is a big difference between cloud-based infrastructure and outsourced data centers. Mind you, the latter is not a bad idea, but it isn’t the same thing at all.

Right now, in the cloud, you can’t specifically build an infrastructure suited to your particular needs. You have almost no control. There is no Burger-King-have-it-your-way infrastructure offering. Yet. We’re a few years away from that, though it seems apparent that’s exactly what we need and where we’re eventually headed.

OPTIONS. WE WANT OPTIONS.

A truly on-demand infrastructure services cloud would be a la carte, more along the lines of a buffet-style dinner than the quick run through the drive-through it is today. Today’s IaaS providers are more or less offering a canned set of menu options, a complete meal that makes it easy to click a button and order a “Junior Cloud” or “a number 3, please” but with no real provision for customizing the order. You get what you get. That’s what makes fast-food and cloud services today a profitable business: no real customization for the majority of offerings.

Oh some do offer some level of configuration – add a load balancer, provision an application accelerator, but it doesn’t really go to the level necessary to be considered an on-demand infrastructure.

What customization implies and requires is control, and that is exactly what is missing from the cloud offerings of today. Control and choice in the infrastructure. While it’s generally accepted that the end-users of cloud “shouldn’t have to care” about the infrastructure, that’s just not true when we’re talking about enterprise adoption of cloud computing services. The end users (IT) has to care because it is responsible for ensuring reliability, security, and performance of the applications it may deploy in the cloud. That may require the provisioning of additional infrastructure services from a variety of network and application network components.

Ensuring business requirements around applications and their usage are met – particularly those critical to day-to-day business operations – is something with which every IT organizations needs to concern itself. That means it necessarily has a vested interest in the infrastructure through which applications are delivered – whether it be locally or cloud deployed.

Some applications are just naturally quirky. Some require coaxing at the transport and data layers to perform in a way that maintains an acceptable level of end-user productivity. That may require additional help from the infrastructure - from the application delivery infrastructure - to achieve. If that infrastructure is local then IT has control, it has choice, it has options. It can deploy new functionality or solutions designed to boost performance, or reliability, or security. But once that application is “out there in the cloud”, those options quickly disappear. It’s no longer possible to provision additional security – whether application or protocol – or acceleration – whether application or network. These infrastructure services are not currently available in the cloud; they aren’t offered, for the most part, leaving IT either holding the bag of complaints and vulnerabilities or erasing cloud as a potential alternative to the data center.

SHARED INFRASTRUCTURE, SHARED COSTS

Undoubtedly at this point someone is going to bring up the deployment of virtual appliances as a solution to the problem of control. And while that’s certainly one possibility, it isn’t the most optimal one. Deploying virtual appliances as part of an application deployment increases costs if for no other reason than the organization has to purchase the solution – the entire solution – in order to deploy it into the cloud, and they’ve got to manage it completely. That’s the beauty of multi-tenant enabled infrastructure services; you pay for what you use, not the entire solution. You share the costs, just like the compute resources, which means the costs are drastically reduced both in acquisition, management, and maintenance.

Where we really want to get to is the ability to drag-n-drop infrastructure services – not necessarily solutions - into our cloud shopping cart and have them automagically deployed in the cloud.
We want the convenience of a drive-through but the service and customization that comes from a more expensive establishment.

And that’s really where the value of “Infrastructure 2.0” comes in; where the connectivity intelligence we associate with the next evolutionary step in infrastructure comes into play. In order to get from where we are now to where we want to go, infrastructure must be first capable of being controlled and configured remotely, one hopes in a standards-based way. That infrastructure must also be capable of collaborating with all the other components in order to add the value and intelligence necessary to pull off such a complex architecture in such a simple, elegant way.

This is where standards come into play, so that the choices you have now in your own data center can be extended into the cloud. Standards around routing, switching, firewalls, and application delivery would provide the means by which cloud providers can offer choices more easily and cost-effectively to customers. Those same standards could also be leveraged in a way as to provide interoperability and portability across clouds – whether internal, external, private, or public.

The choices available today, in the cloud, are limited. You aren’t yet provisioning, for the most part, infrastructure services, you’re provisioning the whole tomale – if you even have that choice. Don’t confuse elastic compute resource provisioning with infrastructure services; they are not the same thing at all. When you have a configuration and management environment in a cloud that offers a full palette of infrastructure services – not complete components – from which you can choose a variety of options then you’ll know we’ve arrived at a fully abstracted cloud that provides not only the scalability and cost reductions you’re looking for but the control over the entire application delivery process.

Related blogs & articles:

• OVF: A few layers short of a full stack
• Private Clouds: Even A Blind Squirrel Finds A Nut Once In A While
• Control, choice, and cost: The conflict in the cloud
• Dynamic Infrastructure: The cloud within the cloud
• Interoperability between clouds requires more than just VM portability
• Infrastructure 2.0: As a matter of fact that isn't what it means
• Cloud interoperability must dig deeper than the virtualization layer

Read the original blog entry...