Chris Smith's Blog

Last week, I attended the "Cloud Computing and Beyond: The Web Grows Up (finally)" conference hosted by SDForum in Santa Clara. The purpose of the conference seemed to be to provide a snapshot of where the software market currently sits with respect to cloud computing right now, as well as provide some vision as to where things are going. There was a lot of great content, mostly in the format of panels, which I enjoy quite a bit compared to just presentations.

There were a couple of themes that jumped out at me during the day. First was the sentiment that cloud computing doesn't magically make your applications "run better". It takes a good deal of forethought to properly design an application to make use of the Cloud. In fact, the type of thinking that is needed to make an application run well in the cloud can equally serve an application running on your own infrastructure, since much of what makes an application cloud-ready has to do with planning for scalability and reliability (building on cloud infrastructure just makes this more explicit). As somebody who has been helping people "grid-enable" applications for a long while now, this is not new, but I was happy to hear that nobody really believe in a cloud computing "free lunch".

The second interesting point that I took away from the conference was a provocative point made by one of the panelists in the "Crawl/Walk/Run" panel. To the question of "what makes one service more cloudy than another?", Jason Hoffman from Joyent made the contentious claim that nobody's service (including their own) was "cloudy" at all! He claimed that the fundamental property of "cloudiness" emerged when services in the cloud were truly transparently accessed by the end-user. He used as an example Amazon's S3 service. Right now, S3 isn't cloudy, because I knowingly access it remotely over the internet. In order to make a service cloudy, he imagined the following scenario:

• A company wants to provide S3 service to their users, but wants to carve out their own "s3.mycompany.com" domain for the services. They arrange this with Amazon so that it looks, to company users, like the service is provided by the company itself.
• In order to enhance the performance of the system, and to exercise a little more control over their own destiny in the face of changes to Amazon's service, they deploy their own S3 internally (imagine Amazon providing an "S3 appliance" that they plug into their own data centre). This internal S3 is still provided to users as s3.mycompany.com.
• Now, in order to realize some of the benefits of Amazon's hosted S3 service, this internal S3 and Amazon S3 can communicate, such that an outage in the internal service would be picked up by the remote service, etc, etc. To the end user, it all looks the same. s3.mycompany.com is where they get their storage service, regardless of whether the requests go to an internal box, or the remote S3 service.

Once you attain this level of transparency and seamless access, you have a service that is truly "cloudy". End users consume a service, with the same ease-of-use and cost model as S3 provides, but with a mix and match infrastructure approach that can meet the needs of small, medium and large sized organizations.

To achieve this transparency you need some level of interoperability (whether through common software stacks or standards remains to be seen), but once achieved, the true vision of "cloud computing" (elastic resources provided and charged by consumption) can be realized.

So here's to cloudy days ahead!