We need standards… and now!


Generally, I believe standards are a good thing for both technology consumers and providers. For consumers, they act as a focusing lens for the kinds of capabilities they should be looking for from a particular implementation (regardless of the technology we are talking about). From a technology provider standpoint, you may often hear the rallying cry that standards impede innovation. By and large, this is a bogus argument. When formed at the right time, standards encourage innovation by normalizing the baseline capabilities that a particular piece of technology should deliver, thus encouraging implementers to seek out those things that will differentiate their offering. In this sense, standards serve as a forcing function for innovation.

The key though, is that the development of standards should occur at the right time. Of course, the right time will vary depending on the particular technology. That discussion is worth its own post (or series of posts), and many more can give the topic its due much better than me. For this post, let’s just say that, in my opinion, the right time for the formation of standards is typically after a set of users form a critical mass of adoption around a technology for which there are multiple, competing providers. However, there is a situation brewing in cloud computing, specifically in platform services delivered via the cloud, for which I think standards formation should happen sooner (ahead of the critical mass of adoption) rather than later.

When I think about cloud-based platform services (PaaS), I immediately think about an elastic application runtime. That is, I think about an environment (I deliberately use environment to imply the application, software infrastructure, and physical infrastructure) that scales up and down based on some set of policies or service level agreements associated with my application.  It is this particular area, the policies and service level agreements associated with an application, which could benefit from some immediate standards traction.

The call for standardization around expressing runtime requirements for a cloud-based application is nothing new. In fact, James Urquhart already formalized the concept quite well in his pCard proposal (take a look at the fourth/bottom layer of the pCard). Whether it is James’ pCard proposal or another means, the bottom line is simple: we need a well-established, standardized manner to declare the kinds of qualities of service an application expects with respect to performance, availability, fault tolerance, and more.

Maybe you understand the need for a means to declare the kinds of quality of service a cloud-based application demands, but perhaps do not understand why it is important to be able to do so in a standardized manner. In my view, there are two main reasons why standards in this area are critical:

1) Enable application portability: This is the most oft-used reason for standards in any area, but I believe it has added relevance here. There are already enough existing planes for lock-in of cloud-based applications. There are platform-specific services that applications leverage through APIs and proprietary data constructs to name but two. Do we really need to introduce yet another plane for lock-in? If users deploy to one platform, and at some point attempt to use a different platform, not only will they have to possibly make code changes, they will also almost certainly have to rework the service level policies associated with the application. This just adds to the already high level of friction when attempting to move from one PaaS platform to another.

2) Encourage PaaS componentization: I have said before that I believe PaaS systems must provide a pluggable services framework that allows third-party providers to supply services to the application runtime. In general, I think pluggable, componentized PaaS platforms will end up winning in the market because I do not believe a single provider is capable of providing all the services needed for a robust PaaS system. Why shouldn’t this notion of componentization apply to the management of the application runtime as well? I believe it would encourage a unique niche market of providers that delivered application runtime management capabilities. Ultimately, this results in more choice and value for end-users. However, the only way to make this niche market viable is to provide some level of standardization around the way we express our service level policies for applications. Otherwise, potential providers in this market must write management code unique to every PaaS platform they support, and this is not a scalable model.

I am positive there are many more points in the argument for standards in the way we describe an application’s service level policies. On the flip side, I am sure there are many arguments against the needs for standards at this point. You know what I think and why, now I want to know what you think. Is now the right time for standards here? Is it too early? Don’t be shy!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: