As previously promised, I am starting to post about the principles that I believe define cloud computing.  The first and to me most important principle is that cloud computing from a developers perspective no longer involves machines.  This is a much stricter principle than most people are using today.  For instance, by my approach, Amazon EC2 is not cloud computing.  I should be clear that I am a huge fan of what Amazon is doing with EC2 but I would not (yet) call it cloud computing.  On EC2 you still have to bring up instances of machines and manage those instances.  Offerings such as Right Scale greatly help with that but don’t abstract machines away entirely.  One of the few offerings currently available that does is Google App Engine (and 10gen will when the first hosted version is available later this year).

Why draw such a tight boundary?  First, because I find the looser you make the boundary for a term, the less useful it winds up being.  Cloud computing is clearly a term that’s in great vogue.  Whenever a term becomes popular quickly many vendors want to attach what they are doing to the term which can render it meaningless quickly.  By drawing a very tight boundary, I am hoping to help preserve some meaning.

Second, because for me this boundary captures the essence of cloud computing.  In many ways we are already doing a lot of cloud computing when we call the APIs of services such as flickr.  Your code that calls the API does not need to know anything about flickr’s machines.  Not how many there are.  Not whether they are DB machines, web servers or image stores.  Not even what their IP addresses are.  The API simply exists in the cloud and completely abstracts flickr’s infrastructure.  Well, the same should be true for all the code you write in a true cloud environment.

Third, post machine computing is the culmination of digging ourselves out of the hole that we went into when instead of following the path McCarthy had set out towards abstracting the hardware and the OS layers, we found ourselves with lots of code in C and other low level languages that had to be compiled and linked on a specific machine.  It will be incredibly liberating for software development to finally get past this.

As previously promised, I am starting to post about the principles that I believe define cloud computing.  The first and to me most important principle is that cloud computing from a developers perspective no longer involves machines.  This is a much stricter principle than most people are using today.  For instance, by my approach, Amazon EC2 is not cloud computing.  I should be clear that I am a huge fan of what Amazon is doing with EC2 but I would not (yet) call it cloud computing.  On EC2 you still have to bring up instances of machines and manage those instances.  Offerings such as Right Scale greatly help with that but don’t abstract machines away entirely.  One of the few offerings currently available that does is Google App Engine (and 10gen will when the first hosted version is available later this year).

Why draw such a tight boundary?  First, because I find the looser you make the boundary for a term, the less useful it winds up being.  Cloud computing is clearly a term that’s in great vogue.  Whenever a term becomes popular quickly many vendors want to attach what they are doing to the term which can render it meaningless quickly.  By drawing a very tight boundary, I am hoping to help preserve some meaning.

Second, because for me this boundary captures the essence of cloud computing.  In many ways we are already doing a lot of cloud computing when we call the APIs of services such as flickr.  Your code that calls the API does not need to know anything about flickr’s machines.  Not how many there are.  Not whether they are DB machines, web servers or image stores.  Not even what their IP addresses are.  The API simply exists in the cloud and completely abstracts flickr’s infrastructure.  Well, the same should be true for all the code you write in a true cloud environment.

Third, post machine computing is the culmination of digging ourselves out of the hole that we went into when instead of following the path McCarthy had set out towards abstracting the hardware and the OS layers, we found ourselves with lots of code in C and other low level languages that had to be compiled and linked on a specific machine.  It will be incredibly liberating for software development to finally get past this.