From time to time, you may hear that cloud computing and virtualization are forcing functions. Exactly what they serve as a forcing function for varies, ranging from IT security to process inefficiency. What does this mean? Quite simply, in many cases cloud computing and virtualization are forcing enterprises to address certain topics, which historically fall into the overlooked and underappreciated column. I would like to add one to the list of topics to which these movements will serve as a forcing function: service standardization.
In my opinion, it would be impossible to understate the importance of service standardization. We always talk about virtualization and cloud and the ways in which they enable faster access to services, increasingly elastic environments, more cost efficient data centers and much more. There is little doubt these are all good things, but I would throw service standardization in the same category of top-tier benefits.
Look at this in the context of standardizing the makeup of your application environments. If you are in operations, application development, or both, I bet you understand just how difficult it can be to setup your development/test/production environments in a reliable and consistent manner. I cannot begin to recall how many times users describe their provisioning process to me and it includes a week tacked on the end to “clean up”. In other words, they are not sure that what they installed and configured is what they meant to setup, and they need to verify and manually tweak a few things.
This is not an indictment on the folks setting up these environments by any stretch. In many cases, they have an organizational standard they want to achieve, so in that sense they defined a standard service offering. However, they have little technological means by which to easily achieve such a standardized offering. After all, charts, documents, and diagrams are not artifacts that one can directly translate to running application environments.
In fact, if there is blame here, it is probably on the industry. Sure, we have preached standardizing on environments and service offerings for a long time, but historically, there has been little in the way of technological tooling that makes this easy. Thanks to some of the concepts and techniques of virtualization and cloud computing, this is rapidly changing.
With virtualization and cloud solutions, we see a big emphasis put on artifacts, which one can directly convert to a running instantiation of something like an application environment. In WebSphere CloudBurst, we call these patterns. Other solutions refer to these as templates, service offerings, and virtual appliances, to name but a few.
While the exact implementation and names vary, the basic idea is that users can represent their application environments as a persistent, actionable unit. The fact that these units are persistent is not necessarily the differentiator, after all charts, documents, and diagrams can be persistent. The key difference between patterns or templates and charts or diagrams is that the former are actionable units. By this, I mean one can directly translate them into a running application environment. Ideally, users can directly deploy or activate these units with the result being a fully configured, up and running application environment. No human translation or intervention of any kind is necessary.
Think of the value of being able to build a custom unit that represents your application environment, save that to some repository, and deploy it whenever you need the environment. Once you build the pattern or template to your specifications, there is no need to account for a week of “clean up” work after each deployment. You know that each deployment gives you and others across the enterprise the same result each time.
To me, the work going on in the cloud and virtualization space with respect to things like patterns and templates is moving us closer to the ultimate in service standardization for our application environments. For a long time we have had ways (again, mostly charts and diagrams) to represent our application environments, but the missing link was in the translation. In the past, there was just too much of a chance for human error in translating a document into a running, working application environment. These relatively new concepts are eliminating the human translation stage and allowing us to build representations of our application environments that we directly translate (largely via unattended activation) into an actual, running system. These are exciting times!