Expert Texture Home Contact me About Subscribe Digipede Connect on LinkedIn rwandering on Twitter rwandering on FriendFeed

rwandering.net

The blogged wandering of Robert W. Anderson

The Cloud Services Stack — Infrastructure

I posted Cloud Services Continuum a couple of weeks back.  In that post I articulated a simplified view of cloud services and how they fit together.  This was simple by design — others had found this view useful, so I wrote it down.  I intentionally ignored some kinds of services, greatly simplifying the Infrastructure piece.  In this post I delve deeper into infrastructure services.  I’ll move on to platform next.

BTW: Stack is a more fitting word than continuum for various reasons, so I’m using that instead.  And a shout out to Matias Wolsky — check out his SaaS Taxonomy Map.

Infrastructure as a Serviceimage

In my earlier post, I defined IaaS to include provisioning of hardware or virtual machines on which one generally has control over the OS; therefore allowing the execution of arbitrary software. This definition isn’t really enough, because there are many other kinds of infrastructure.  Take a look at the services that are out there:

  • connectivity / messaging services.  Examples: Microsoft BizTalk Labs and Connectivity Services, Gnip.
  • identity services. Countless OpenID identity providers, again the BizTalk Labs Identity Services.
  • data storage.  Examples: Amazon’s S3 and SimpleDB, Microsoft SQL Server Data Services.

One might argue that together these services create a “platform” — and they get close — but since none of these host general user-written code, they don’t quite get there.

Then, of course, there is flexible machine provisioning like Amazon EC2.  These are definitely infrastructure — where the platform is the OS, Web servers, and other software.

Calling this all IaaS is fine — it is all infrastructure — but, maybe we should further divide these:

  • Virtual Hardware Infrastructure
  • Storage Infrastructure
  • (Other) Infrastructure Services

Granted, these names need some work, but I think the categories are useful.  And I won’t make them into acronyms because I think we have enough of those.

Tags: , , , , , , , , , ,

Cloud Services Continuum

I have found myself talking about cloud services a lot recently.  We have been talking about them here — there is an obvious synergy between what we do at Digipede and cloud services.  And I’ve been talking about them externally too: at the recent CloudCamp, on the Gillmor Gang, and in all sorts of other interesting contexts. 

Note that I refer to cloud services, not to the cloud.  I am not interested in defining cloud as a term, because I don’t think it very useful.  For those of us in the distributed computing space, cloud is the latest buzzword to compete with the word grid in terms of utter ambiguity.  I think the ship has already sailed on this one and I’m not going to try to call it back.

So, everyone is talking about cloud services and much of the conversation centers on understanding them and how they are changing the landscape.  Of course, cloud services are not one thing.  I find it helpful to think about them as parts of a continuum.  This seems useful regardless of the technical level of the people with whom I’m speaking.

imageThe diagram to the right shows this continuum from infrastructure to platform to software.   Brief definitions of these parts are:

  • Infrastructure includes provisioning of hardware or virtual computers on which one generally has control over the OS; therefore allowing the execution of arbitrary software.
  • Platform indicates a higher-level environment for which developers write custom applications.  Generally the developer is accepting some restrictions on the type of software they can write in exchange for built-in application scalability. 
  • Software (as a Service) indicates special-purpose software made available through the Internet.

I have indicated several companies that play at different parts of this stack.  This list is not comprehensive nor does it attempt to represent motion across the stack.

One scenario in which I find myself talking about the continuum is when people equate Amazon EC2 with Google App Engine.  EC2 is a flexible / scalable virtual hosting platform with provisioning APIs.  It allows you to dynamically scale the number of instances of your OS (i.e., Linux).  What you do with those instances is up to you.  Google App Engine operates at a much higher level in the stack.  It is a new software platform with specific APIs.  It requires developers to build for this specific platform.  yes, they are both in the cloud, but they are very different services. 

Another scenario in which the continuum is useful is in thinking about what vendors and new entrants might be up to.  The continuum makes one thing even more clear: many vendors that operate higher in the stack are relying on their own internal lower-level infrastructure or platform.  This begs some questions: which vendors will expose lower-level interfaces?  And of course, which vendors will move up the stack? 

  • SalesForce is already moving down with their PaaS offering. 
  • Any chance Google will expose its infrastructure stack?  I doubt it, but I do expect them to move down a little. 
  • Some of the readers of this blog probably know better than I where Amazon and Microsoft are planning to go.

Yet another way it is useful is in comparing vendors inside of a particular category.  Maybe I’ll write more on that later.

Is the continuum obvious?  Using the definition of obvious from patent law, yes, but I think it a useful paradigm.

Tags: , , , , , , ,

VSLive! Pat Helland

Pat Helland, Senior Principal Engineer of Amazon, gave a talk titled Programming for Scalability. Very good speaker. He went through the evolution to his views of building highly scalable systems and is now an apostate of the ACID, distributed transactions, single serializability scope-religion.

He walked through his approach to designing databases for high scalability from the start so applications don’t need to be rewritten when data-partitioning becomes inevitable.

He didn’t speak about Amazon in particular, but these are the kinds of things he works on there.

While this talk was quite high-level and following the “SOA and messaging” mantra, it was very practical too. If you ever get a chance to hear him talk, take it.

Tags: , ,