Fellow comrade Chris Hoff has an interesting blog post on what exactly is a Cloud SaaS. Me thinks most of his points miss the mark. Let me elaborate –
- The dominant aspect of a Cloud eco system is the interface between the Cloud Service Provider & the Cloud Service Consumer – how the system is implemented is irrelevant
- In Chris’s view “If a SaaS offering is not built upon an IaaS/PaaS offering ” then it shouldn’t be qualified as Cloud
- He quotes NIST’s definitions as one authority.
- While NIST has done a good job overall, I have a few problems with NIST’s definitions. They are not as crisp and crunchy in many places
- Second, I am not that fan of prescriptive definitions. Definitions evolve
- And finally Chris, later in the post, confuses definitions with requirements.
- NIST’s work is a set of definitions not requirements.
- Going back, the major advancement in the Cloud model is the independence from, abstraction/frangibility of the infrastructure from the offering.
- In short one cannot define a cloud in terms of the infrastructure it is running, but define in terms of the interface, usage and programming model it offers
- Even when we add other actors like Cloud Service Developers, Cloud Service Brokers and Cloud Service Aggregators, the picture does not change. In fact extending the actors make the argument (that clouds are instance agnostic) more stronger.
- For example a Cloud Service Broker can provide a Cloud Consumer Interface and under the covers wok across different implementations from different service providers
- Which brings us back to Larry Ellison’s question “What the he** is this Cloud Computing”? (Thanks Chris for the link and the question)
- I had, in an earlier post, iterated the essential traits of Cloud Computing
- In this discussion, it is the elasticity, multi-tenancy and the pay-as-you go model that make a SaaS part of the Cloud eco system
- Chris is a little concerned about re-branding “old-world” services as Cloud Offerings. I am not. The Cloud Computing is a way of doing business, a model per se. There is no temporal aspect to it – i.e. if we were doing elasticity, multi-tenancy and so forth, years ago and didn’t call it Cloud then, doesn’t mean we cannot call it cloud now !
- A Cloud by any other name …
- Cloud is a moniker, an attribute of a service offering
- Naturally the major argument is “if a Service Provider is implementing a CRM for multiple companies as separate instances (rather than a single multi-tenant instance), is it a Cloud ?
- If an offering has interfaces like a Cloud, if we can pay for usage like a Cloud, if we can expand (or contract) usage like a Cloud and if many companies use the service like a Cloud, let us then call it a Cloud (irrespective of what is under the covers …)
- Finally let us take the specific example of MX Logic and explore if their service offerings fit the Cloud moniker
- Their e-mail archiving service is elastic, multi-tenant and pay-as-you-go. FIts the Cloud moniker (An I do not care how they implement it)
- I agree that their e-mail filtering does not seem completely like any “accepted” Cloud services
- But if you read thru their solution brief, it has all the thrills and chills of a cloud offering viz. no hardware, no licenses, no dedicated management et al
- Well, it is not AWS but then the Cloud moniker is not restricted to AWS either, it is much more than that …
- In short, Yes they do (and they can ;o)) , and I rest my case (and start the hassle ;o))
I have a few more thoughts, will update as I get time … We are off to Alaska till the 17th … so need to pack …
And Of course, thanks to Chris for raising this topic – the overarching concepts are very important because they influence our view, the architectures we develop and …
Till then … Don’t trouble trouble when trouble troubles you …