The blogged wandering of Robert W. Anderson
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 Service
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: Amazon, AWS, cloud, Gnip, Google, IaaS, Microsoft, PaaS, SaaS, Salesforce, SSDS
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.
The 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: Amazon, cloud, Google, IaaS, Microsoft, PaaS, SaaS, Salesforce
Marc Benioff was special guest in the recent Gillmor Gang (VIdeo Gang Parts I and II). After getting through the initial discussion on SalesForce.com earnings we moved on to talk about the SaaS business and their application platform.
Mike Vizard led off the questions about ApEx with a good one: how will SalesForce get developer traction for their language / environment / form? Marc enumerated several things they are doing about that. Most of this is kind of “business as usual” for those building a developer community, though I do think that one of their strategies is pretty innovative: rent out cubicles to developers in a building devoted to ApEx development (this is happening in old offices of Siebel — this would be ironic if it weren’t intentional). These developers get everything they need to build apps on the SalesForce platform.
This may turn out to be of great value to those who are already interested in the platform. Of course, the drive for developers to build applications on ApEx will come down to one thing: is there a viable marketplace for the applications they build?
Clearly Marc and SalesForce understand this fully. They are not pushing the “build it and they will come” mantra; instead, they have built an application exchange (i.e., the AppExchange) to enable a viable marketplace.
On a slightly different tack, I asked Marc to talk a little about their hosting capabilities for third party applications sold through the AppExchange. Without getting into too much detail about the different kinds of applications that support the ApEx (native, client, hybrid, etc.) there is a class of applications that requires external hosting. These applications take advantage of the SalesForce.com APIs yet are not built on the ApEx platform. As a result, these applications are not hosted by SalesForce.com.
I grok why they choose not to post these hybrid applications. Doing so requires a different hosting model: one that is application-specific possibly supporting different hardware requirements, different OSes, different staff, etc. I can only guess that they have made the decision not to do this in favor of their “pure” ApEx strategy. Certainly the “pure” strategy is a lot cleaner, more focused, more repeatable, more like an “product sale” instead of an implementation sale . . .
However, lets go back to the earlier point of developer adoption. Wouldn’t it be easier to get developers to adopt ApEx and AppExchange and the whole concept of SaaS if you were able to provide a hybrid hosting solution?
This reminds me a little bit of .NET. One of the key features of .NET is support for COM. If users had to throw out their legacy code to begin to adopt .NET in their organization, .NET would have had a much slower adoption rate. They don’t.
It sound likes an ApEx developer who wants to take advantage of the AppExchange has to either start everything from scratch or provide their own hosting solution.
So I wonder, would SalesForce be able to ramp up developer adoption rates with a hybrid hosting strategy?
Tags: .NET, ApEx, Benioff, Gillmor, Gillmor-Gang, SaaS, Salesforce