Peeling Onions in the Cloud

From a conceptual standpoint, consumability through abstraction is arguably one of the most important benefits of cloud computing. The cloud offers up some collection of raw resources (i.e., servers, networks, storage, and applications) as a set of pre-configured, pre-integrated, and ready to use services. As a result, users typically need to know a good deal less about how those resources are setup, and can instead concentrate on consuming them to deliver their own set of services.

While the benefits offered by abstraction (namely consumability) are most certainly a good thing, abstraction can also be problematic. What do I mean? Well, while users understand the benefits they get from abstraction, sometimes they need to peel back the layers of the onion. In other words, they need to pop the hood and exercise more control over resource configuration within their cloud. While I expect this need is really news to no one, the implications on the cloud service provider, and subsequently cloud service consumer, are quite interesting to examine.

In order to provide a sense of concreteness around this discussion, I want to share the kind of discussions I have with users on a regular basis. A considerable part of my day job involves working with users implementing a cloud management device that allows them to more rapidly and consistently provision application middleware environments into an on-premise cloud. The fundamental premise of this solution is that of a patterns-based approach to middleware in the cloud. In this sense, a pattern is a representation of a particular application environment. Further, to a deployer, a pattern abstracts the inane details of the integration and configuration of the middleware supporting an application, and instead presents a simple, cloud-deployable unit. Therefore, the patterns are an abstraction of middleware resources delivered in the cloud.
While the patterns-based approach offers up a nice abstraction to the deployer, not everyone in an organization plays the role of deployer. Some within the organization are responsible for building the patterns that represent their desired middleware environments. It should come as no shock that these environments require customizations, and these customizations apply to many different layers in the software stack. Let the peeling begin!