Quite honestly, I am a little fascinated at the preponderance of focus the industry sometimes puts on the cloud attribute of elasticity. Sure, it is important, and in fact, a necessary attribute to truly consider something a cloud. It also makes for cool reading in case studies where companies have successfully harnessed elasticity in the cloud to reap business value. However, in my experience with enterprise users, many would benefit from a couple of less sexy, but equally important attributes of cloud: standardization and automation.

When I am out talking with middleware application users (administrators, developers, operators, etc.), I hardly ever pass up the opportunity to ask ‘What are your biggest pain points?' While I sometimes get answers that indicate the need to more effectively and rapidly scale systems up and down, those pale in comparison to the number of answers I get that point out the need for different requirements. IT users often tell me they have a hard time consistently deploying the same environments, are frequently burdened managing ‘one-off' environments for LOBs, and have a hard time standing up these environments in a reasonable time period.

When users express these problems to me, I am usually quick to point out that cloud can help because standardization and automation are at its core. On the other hand, users are equally quick to tell me that standardization and automation are not new concepts. While that is definitely true, I think it is quite plain to see that cloud computing is bringing both of these concepts to a new level - and I do not mean simply virtual images with dynamic configuration scripts.

From a standardization perspective, cloud computing solutions are evolving to provide a means for users to represent and share their meaning of standardized application environments. Depending on the particular solution, we may call a unit of standardization a pattern, template, or any number of other things. Regardless of the name, the purpose is similar, and it addresses a very common need across many enterprises.

Patterns and templates are really the foundation of standardization as they give users a means to define a unit of standardization (perhaps an application environment). That said, I would argue those patterns are of little value unless they are directly deployable units. In other words, if the patterns do not encapsulate the installation, configuration, and integration of the defined environment, they are little more than fancy models or diagrams. The patterns must enable automation that set the stage for a more declarative deployment style and eliminate the need for human-driven actions relating to the provisioning of a particular environment.

This convergence of standardization and automation is an interesting and valuable trend emerging from cloud computing. It certainly helps to address the pain points I mentioned above, plus a plethora of others. The ability to define and share standardized application environments through patterns allows IT to drive the standardization discussion throughout the organization. Standardization is no longer a set of documented deployment requirements. It is a discrete unit. Imagine, a LOB calls IT to setup a typical web application environment and IT responds ‘Yeah, I've got a pattern for that.' And remember, a pattern is not simply a model, it is a deployable unit. So not only can IT drive standardized environments by using the same web application pattern for all LOBs, it can also benefit from low-touch deployments because the pattern encapsulates everything necessary to get a running environment.

Now, it's not quite as simple as talking about it. The push for standardization is usually a hard one since most environment requestors tend to think their environment is unique - it usually isn't. In this regard, the push for standardization becomes as much of a cultural/political battle as anything else. What I want to point out though is that cloud computing capabilities are quickly evolving the way we think of both standardization and automation for the better.

All this is not to say that elasticity doesn't have its place. We all know that is not true. I have talked with a number of users whose usage scenarios and pain points clearly point to the need for elasticity (I would be remiss not to point out that meaningful elasticity is much more than adding or removing servers, but that's a topic for another post). My beef is that I feel elasticity gets focus that can be out of balance with the business value it provides as compared to other cloud attributes. My advice to users is always the same: do not get caught up in cloud buzz or hype. Rather, look at your pain points and understand if and how the cloud can help you solve those problems.