Standards for the cloud not what you think

Coming from a technical background, when I hear the word "standards," I tend to think of things that usually go by strings of numbers (802.11), inscrutable abbreviations (USB), or at best a slightly more melodious moniker dreamed up by a marketing department (WiMAX).

They may be codified by a standards body as part of a formal de jure process. They may evolve through the efforts of one or several companies and gain wide enough usage to be considered a de facto standard. Or, as with PDF, they may start life as a de facto standard that is later ratified by a standards body.

Whatever the particulars, such technical standards allow equipment or software from a variety of different sources to work together in predictable ways.

When people talk about cloud computing, these are the sorts of standards that they're usually talking about. The main issue being addressed is portability--the canonical example being moving an application developed for Amazon Web Services to some other vendor's service.

In the Amazon case, a subset of AWS has indeed become a sort of de facto standard. Eucalyptus is one example of implementing a subset of AWS outside of Amazon. Another approach is epitomized by RightScale, which has emerged as a dominant management platform for AWS; it has efforts under way to mask the differences between different cloud infrastructure providers at the management level.

Well-established Web standards of various types also play key roles in creating and accessing cloud-computing services.

So technical standards for cloud computing are indeed moving forward. However, I find that when I talk to consumers of cloud computing, they don't really care much at this point. I noted this previously after I interviewed Tobias Klauder at Razorfish.

That's not to say that people don't care about standards in cloud computing. I led a session at the Massachusetts Technology Council unconference on The Future of Software and the Internet last week to address the question of whether we need standards for cloud computing.

The participants argued that we do indeed need standards. But they had a different sort of standards in mind--something more akin to these definitions:

• an average or normal requirement, quality, quantity, level, grade, etc.
• those morals, ethics, habits, etc., established by authority, custom, or an individual as acceptable

They were looking for more transparency in understanding data protection schemes--backup procedures, recovery point objectives, and recovery time objectives. They wanted to understand what is private and what is not and how data is secured and exported. They wanted this to be communicated in a straightforward manner and, ideally, audited by a trusted third-party in some way.

The issues raised in my session were less about finely tuned service level agreements (SLAs) and more about simply understanding the characteristics of a service. One size does not fit all. Thus, an online backup service such as EMC's Mozy has to offer a variety of options--including whether a user supplies their own encryption key (which itself must be kept secure and protected) or let the service provide one. An organization with specific archive requirements would need other types of guarantees and capabilities.

These are all standards. Some may become true standards over time in the sense of codified best practices and metrics. However, it's clear to me that what users most want in the near-term is to better understand, in plain English, some of the basic practices followed by cloud-service providers.