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!
To keep this discussion simple, let’s just consider the two main layers of the middleware environment stack: the operating system layer and the middleware layer. What does it mean to be able to equip users with the ability to effectively customize these layers? Most importantly, the cloud management device must be cognizant of the fact that often times different people within the organization are responsible for customizing each of these layers. The team responsible for installing additional software on the OS (i.e. firewalls, diagnostic tools, monitoring agents) is hardly ever the same team that configures the middleware, middleware applications, and application resources. The device must present a layered and granular access approach that accommodates these organizational silos. On the surface, this may seem a simple enough proposition, but it becomes difficult when mapping out how and when the teams need to apply these customizations and what that means to permission mappings within the device.
Further, beyond simply designing permission mappings and granular access, the cloud management device should be aware of what is typically a sequential workflow involved in these sorts of customizations. In many cases, the OS team will start by making its modifications, ‘bless’ the resultant environment, and hand it off to the middleware team to make its own set of modifications. The solution can address this either with the ability to hide resources from users until an appropriate time, or with a more elegant workflow process built around these customization steps. In either case, the solution cannot afford to blissfully ignore the sequential nature of work involved in building these environments.
So far, we pointed out some (definitely not all) of the challenges on the cloud provider side in this scenario, but how about the consumer? Well, even when the solution meets the requirements discussed above, the consumer often has the challenge of trying to figure out how to absorb this new way of doing things. It could be something as seemingly simple as getting teams comfortable with a new medium for building out their customized environments. I say seemingly because who would expect no resistance when advocating a way to build out a customized OS/middleware environment that is different than what teams have done for the past 5, 10, 15, or 20 years?? On the other hand, it could be much more difficult and subversive. For instance, consider the impact if the solution for building out these customized environments did not play well with existing workflow approval processes. At this point, the consumer has major procedural and cultural implications to deal with, and this could become a showstopper.
The above example highlights a very specific scenario, one that I happen to have a lot of experience with, but I suspect the same holds true for a wealth of different kinds of cloud services. I am not trying to make it seem impossible to build cloud solutions that effectively deliver consumability through abstraction without sacrificing customization capabilities. Rather, I simply mean to point out that it is a considerable task and one of which both providers and consumers should be aware. After all, you should be able to peel back the onion without shedding tears!