I also think an attempt at a specification is better then nothing at all. At the very least it give us something to discuss.
ruv
On Thu, Jun 5, 2008 at 11:11 AM, Mike Culver <mculver@extencia.com> wrote:
James is on the money, IMHO. Building a spec is about like building a standardized spec for intergalactic space travel. You don't even know what life form will appear in front of you when coming out of hyperdrive, so how can you build a spec before travel is required?
________________________________
From: cloud-computing@googlegroups.com on behalf of James Urquhart
Sent: Wed 6/4/2008 10:15 PM
Subject: Re: The Business of Building Clouds
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 <http://www.joyeur.com/2008/05/08/cloud-nine-specification-for-a-cloud-computer-a-call-to-action> ". In his modest proposal, he calls for an open specification based on nine core components.
Reuven,
I'm not sure I agree with you or David. Here is my problem: different platforms fill different needs in different spaces. Google AppEngine is intentionally a completely different animal than Amazon EC2/S3. So "pointing the deploy gun" makes no sense whatsoever *unless* you build a AppEngine clone on EC2/S3. But then you are just building a new stack. Do we say everyone must develop to the lowest common denominator? In that case, SmugMug, et. al. are wildly out of compliance, as it is clear you need to develop in python to Google's libraries to make the "point and deploy" scenario work between these two providers.
Look, that kind of compatibility between any two vendors serving the same layer of David's model makes some sense to me. However, what we have today is a primordial ooze of technologies, target markets and business models. I think we need a lot more time before the dominant complex life forms evolve, and the kind of portability mentioned here is "boil the ocean" complex. Let's focus on getting portability within platform "solar systems" and worry about connecting those systems once we conquered that.
James
----- Original Message ----
From: Reuven Cohen <ruv@enomaly.com>
To: cloud-computing <cloud-computing@googlegroups.com>
Sent: Wednesday, June 4, 2008 2:54:06 PM
Subject: 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 long-tail (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 working in IT. Those so 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.
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 <http://finance.google.com/finance?q=amzn> , Google <http://finance.google.com/finance?q=goog> , 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.
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
www.enomaly.com <http://www.enomaly.com/> :: 416 848 6036 x 1
At the end of the day our job as cloud builders is about creating simplicity and making IT easier to manage and faster to scale.
--------
(Original Post: http://elasticvapor.com/2008/06/business-of-building-clouds.html)
Cloud Nine: Specification for a Cloud Computer. A Call to Action.
http://www.joyeur.com/2008/05/08/cloud-nine-specification-for-a-cloud-computer-a-call-to-action
--
--
Reuven Cohen
Founder & Chief Technologist, Enomaly Inc.
skype: ruv.net <http://ruv.net/> // aol: ruv6
blog > www.elasticvapor.com <http://www.elasticvapor.com/>
--
--
Reuven Cohen
Founder & Chief Technologist, Enomaly Inc.
www.enomaly.com :: 416 848 6036 x 1
skype: ruv.net // aol: ruv6
blog > www.elasticvapor.com
-
Get Linked in> http://linkedin.com/pub/0/b72/7b4
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cloud Computing" group.
To post to this group, send email to cloud-computing@googlegroups.com
To unsubscribe from this group, send email to cloud-computing-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.ca/group/cloud-computing?hl=en
-~----------~----~----~----~------~----~------~--~---
Posts
No comments:
Post a Comment