The Business of Building Clouds

There is an old saying in the venture capital world that consulting doesn't scale. As an entrepreneur I'm continually walking the line between making the short term buck (consulting revenue) versus the longtail (recurring revenue on product based licensing and support). Given our platform is open source, consulting is typically a major part of our revenue model. The dilemma is a fairly straight forward one. I'm in business to make money, in our case, from as many different opportunities as possible.

Lately it seems everyone is in need of assistance with their clouds, from architecture, setup and deployment there seems to be real need for the "Cloud Consultant". For us these jobs range from your dedicated hosting firms and large telecoms looking to create EC2 like utilities to software & traditional enterprises looking to deploy their new "as a service" offerings in a scalable way. A lot of people talk about the cloud killing the traditional system administrator's job, but in my opinion there has never been a better time to be working in IT. Those who see this paradigm shift toward cloud computing will prosper.

Defining what cloud computing is in itself a tough job, the lack of common cloud methodologies and best practices is making the job even harder. Trying to find experienced people with knowledge on how to build out a 30,000 machine cloud is nearly impossible, finding someone who's deployed hundreds is proving to be almost as difficult. We the pioneers in the cloud computing space must take steps to create an open development ecosystem, one where we share our failures and successes so others can learn the trade.

One way may be to create a common cloud specification. David Young over at Joyent, attempted to do this, he has called for a common cloud specification called "Cloud Nine". In his modest proposal, he calls for an open specification based on nine core components.

1) Virtualization Layer Network Stability

2) API for Creation, Deletion, Cloning of Instances

3) Application Layer Interoperability

4) State Layer Interoperability

5) Application Services (e.g. email infrastructure, payments infrastructure)

6) Automatic Scale (deploy and forget about it)

7) Hardware Load Balancing

8) Storage as a Service

9) “Root”, If Required

Although I'm not sure about the need for root access or hardware based load balancing his post raises some interesting ideas. In particular he says "a developer should be able to move between Joyent, the Amazon Web Services, Google, Mosso, Slicehost, GoGrid, etc. by simply pointing the “deploy gun” at the cloud and go." I think he nailed it dead on with this statement.

At the end of the day our job as cloud builders is about creating simplicity and making IT easier to manage and easier to scale.