Chris Hoff has a new post over at Rational Survivability where he attempts to make sense of when a SaaS solution should or should not be considered “cloud.”  In his analysis, Hoff atttempts to strictly apply NIST’s cloud computing definition to various types of SaaS offerings (say hosted email vs. Salesforce.com).

I think that this approach, while intellectually interesting, is perhaps a bit off the mark.  While NIST’s framework for cloud computing is generally accepted on the surface, the lower-level distinctions they make may not be so universally agreed upon.  A perfect example of this is contained in this NIST “essential characteristic” of cloud computing:

Location independent resource pooling. The provider’s computing resources are pooled to serve all consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. The customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter). Examples of resources include storage, processing, memory, network bandwidth, and virtual machines.

This is the one NIST cloud characteristic that most mixes requirements of users and providers – and applies most to IaaS and perhaps PaaS solutions.  How a SaaS provider manages their internal infrastructure to provision an on-demand, elastic, metered and internet-accessible application is irrelevant.  SaaS need not be built on IaaS foundations to be considered a cloud computing service.

NIST aside, I think that the bigger issue is whether, from a business perspective (vs. technical), the following question from Hoff has any meaning:

If a SaaS offering is not built upon an IaaS/PaaS offering that is itself characteristically qualified as Cloud per definitions like NIST, is it a Cloud SaaS offering or just a SaaS in Cloud’s clothing?

If you are a CIO, CEO or other executive tasked with choosing between solving your requirements with in-house software & systems or a SaaS solution, does how the SaaS solution is architected internally really matter?  I’m assuming that the technical requirements that do matter to the buyer – functionality, scalability, reliability, etc. – are addressed adequately, of course.  Beyond that, why do I care if the underlying technology meets NIST’s cloud definitions for IaaS?

The answer is simple – I don’t care.   If an application meets the generally accepted pre-cloud definition of SaaS (provided generally in an on-demand, elastic, metered and internet-accessible basis), then as far as I’m concerned, it’s cloud.

Under the covers it could be running on a single IBM mainframe and I’d still call it a cloud application when viewed through the lens of the business.

And ultimately, isn’t that what matters most?

Read the original blog entry...