What are the two sorts of Cloud infrastructure called?

Posted by
Posted in Commentary, For Developers / Technical, Mapumental

I’ve been doing lots of research around “cloud computing” recently, so we can change how Mapumental works and take it out of private beta.

One thing that’s struck me is that there doesn’t seem to be a proper, industry standard name to distinguish what to me are two fundamentally different sorts of “cloud computing”. I’m focusing here entirely on cloud services for programmers (let’s leave what it means to end users or businesses for another day).

Here are my own names and descriptions of them:

1) Cloud hardware server provision (Cloud HSP)
 Low level APIs for making and destroying (virtual) servers, and loading machine images onto them. e.g. Amazon Elastic Compute Cloud, Rackspace Cloud Servers, Eucalyptus’s EC2 bits. Basically, what Eucalyptus v 1.5 can do and what libcloud should do. (By analogy, this is the assembly language of cloud computing)

2) Cloud developer service provision (Cloud DSP) A service that a developer accesses with one name and a simple API, and behind the scenes it scales for him, automatically. e.g. Amazon Queue Service, Rackspace Cloud Files. (By analogy, this layer is the C programming language of cloud computing)

[as an aside, Google AppEngine is an interesting one. It is definitely in the Cloud DSP category, but I think it is larger than that – it is a whole set of APIs all in that category. Something like Google DataStore is a single Cloud DSP, albeit one apparently only accessible within AppEngine apps]

It’s possible to use a Cloud HSP (assembly language), along with a bunch of your own software or open source software, to build new Cloud DSPs (C code). Right now this is pretty hard – even quite well known open source distributed datasbases like CouchDB still need scripting to even make them replicate. The code that makes and destroys servers and gives the service one name, needs manually stringing with quite new bits of wire (things like scalr and Wackamole).

For this reason, I’m reluctant for mySociety to get into the “making our own Cloud DSP out of Cloud HSP” game. It feels to me like a suck of time, and like we wouldn’t be able to guarantee without lots of careful and expensive testing that it would scale. I’m more tempted to use the commercial Cloud DSP services where possible, even though they are proprietary. But use them via our own abstraction layer, so we can change as we need to. Of course, we have some C++ code (the public transport route finder), so will have to use the Cloud HSP API to get that going, perhaps with Amazon’s Auto Scaling. But it can jolly well use AQS and S3 to talk to other services.

So, what do you think about the names Cloud HSP/DSP? Are there already existing names for the distinction that I’m making? Is it a useful distinction for you? Can you think of better names?

7 Comments

  3. A friend says “I have no idea, but these words need to be invented if they do not already exist, and I prefer VSP to HSP, and DSP needs too be a different acronym from Digital Signal Processing, such as API.”

  5. HSP is defined as “hosting service provider” by virtuozzo, who operate in the field. And, “SP” is commonly used for Service Provider (ISP, EmailSP, etc).

  6. The people at Cloud Camp had three layers, and this is the terminology I’m going to use.

    IaaS (infrastructure as a service) – which is the virtual machine layer, and also simpler storage things like S3.

    PaaS (platform as a service) – which is developer APIs (that scale themselves), and aggregates of APIs. So Google App Engine, Amazon Simple Queue Service, Force.com etc.

    SaaS (software as a service) – end user applications, so SalesForce, GMail etc.

    So to summarise – I’d like to just use PaaS, perferably with the software all being open source as well. But unfortunately PaaS is the weakest area right now across the industry, so we’re going to have to implement a few things ourselves using the lower level IaaS level.