Contentious Issue: When Does a SaaS Offering Qualify As a Cloud SaaS Offering?
I made a comment on Twitter a couple of days ago reacting to how some were positioning McAfee’s purchase of MX Logic as the latter representing a “Cloud Security provider.”
The link above has the article’s author referring to the deal as one focused on the expansion of McAfee’s “Cloud portfolio” whilst all the McAfee quotes refer to it as bolstering their “security-as-a-service” offerings.
I read many articles referring to this deal as “Cloud” in nature and in a fit of frustration I said:
I’m sorry, but MX Logic is not a “Cloud Security Provider”
That caught the eye of Erik Boles (@ErikBoles) who suggested that because MX Logic is a SaaS provider, they are a Cloud provider and have been since their start in 2002. MX Logic’s website advertises them as a SaaS provider, but not a Cloud provider. McAfee refers to them as security-as-a-service. I thought it was pretty clear. Then Erik kept pushing. I’m glad he did.
We tussled with this and I made mention of the fact that the notions of SaaS and Cloud are mutually exclusive; certainly you can have a company utilize SaaS as a delivery model for their offering, but certain other deployment model and essential characteristics must be met to be considered “Cloud.”
I referred to NIST’s definitions for Cloud service so as to work through this dissonance.
Erik suggested that MX Logic meets the NIST requirements. I have my doubts.
However, I had to take a step back and admit that because I didn’t know what MX Logic’s operational and infrastructure blueprints looked like, I may be hasty and presumptuous in my ability to dispute Erik’s claims.
Further, I had to come to terms with the fact that I may be looking through a lens that is inappropriate, limiting or unfair simply because I’m overwhelmed with the marketing shuffle occurring with so many services being branded as “Cloud.”
I decided to sit back and think a little.
So, here’s the issue as I see it:
I think in exploring NIST’s definitions of Cloud, when assessing a SaaS offering’s characteristics against them, the sorts of services that are less focused on a direct coupling of interactivity between the user and the application in the traditional “desktop” sense, but rather replace what would previously be an on-premise network-based infrastructure function, do not fit well in these buckets.
Examples are things like security services: Email/web content filtering, Anti-Spam, Anti-Virus, etc.
Even though they are packaged as SaaS to allow for administration, they replace what are generally considered as infrastructure service functions traditionally-supplied via on-premises hardware/software solutions. These offerings provide a way for the consumer to manage certain elements of the service while the rest is operationally obscured.
I have to admit that when I strap on the goggles, it “sounds” like Cloud, but there’s a profound difference.
While we’ve traditionally modeled that PaaS and SaaS are built upon the foundations of IaaS, many of the now-branded “Cloud” services don’t rely at all on the oft-compared Amazon EC2-like IaaS model at all and rather than scale elastically with a “self-service” capability that the consumer has any interaction with, instead rely on good old-fashioned capacity planning and load balancing using the scale out model ala Google. They used to be called managed services and now they are Cloud.
So if a SaaS offering meets all the NIST Cloud characteristics, like Google Docs or GMail, where a user directly interacts with the “service” to perform a function that would otherwise be done locally on their desktop, that seems easy for people to understand and qualify as “Cloud,” at least given how everyone talks about SaaS today. When we talk about those infrastructure-like services offered up as SaaS, not so much — at least not for people like me — even if it can be shown that they meet the NIST requirements.
So perhaps we’ve got this backwards. Perhaps it’s the SaaS offerings that have nothing to do with replacing infrastructure that should not be considered as Cloud services, especially when you consider that many of them are built on traditional infrastructure models. Then again, we see other offerings like Pixily and Animoto that are SaaS offerings built DIRECTLY upon IaaS offerings that also meet the NIST definitions.
To stimulate debate, let’s take a well-accepted “Cloud” SaaS offering such as Salesforce.com and look through the lens above. Is it really a Cloud SaaS offering? Is multi-tenancy over the Internet enough? Will those SaaS providers who also have PaaS offerings blur the issue even further, especially those who have evolved from the days before “Cloud” was an available marketing term? Is this what Larry Ellison was getting at when he asked “What the hell is Cloud Computing?”
Just to add some color to the conversation check out a previous post on the topic titled: Re-branding Managed Services and SaaS For Security In the Cloud…1995 Never Looked So Shiny It will likely show up in the “related-posts” section below this one, anyway.
So I think I’ve closed in on one of the biggest confusing issues surrounding Cloud service branding perception:
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?
Do we need to adjust the definition or just re-focus the lens?
What say ye?
/Hoff
This is going to sound a bit, I don't know, simplistic but I think that (in the end) that the market will determine what "cloud" is… (We've talked about this before I think in the context of what the standards will be).
I think that right now the marketing folks – right, wrong, indifferent – are driving this train. The marketing organizations are competing to ensure that their message of cloud gets in front of the right decision maker first. Once that happens and consensus of what cloud "should be" develops then that consensus will drive what cloud "is".
But, more to the point your raised, I think we do need to be open to expanding the idea of what cloud is because the marketing folks are doing it as we speak. NIST documentation – while interesting – isn't going to make the choices. People who write checks for implementations will….
Cheers!
…and quite honestly, despite how I might describe myself, I *am* one of those marketing people — one way or another.
I think Erik's challenge of my assertion really helped unearth a bit of a definitional quandary. There is an inconsistency in the SaaS definition as it relates to the rest of the stack. It was clear in my taxonomy diagram when the service was a SaaS replacement for IaaS, but actually contradicts many of the traditional SaaS folks who are branding themselves as Cloud.
I always thought the problem I had with the definition was the other way 'round.
/Hoff
For me this is a pay the piper kind of moment for "cloud". The phenomena as a marketing and market term got so huge so fast because it was a big-tent. Loosely, it meant something you used to have to worry about customizing and scaling yourself coming from a networkish service. The rightful 'red herring' cloud is hype argument therefore is "bah, this is ASP part 2."
If we aren't careful we are going to have to keep talking about definitions to pay the big tent rent…..
I actually took a little stand against IaaS this week for this reason, I don't love the association with SaaS.. http://bit.ly/4R6Rc ….but I'm probably spitting into the wind.
…Oh btw, original salesforce and much of what remains was built on traditional Oracle DB and big Iron, Its what they call a "transitional fossil" 🙂
<blockquote cite="#commentbody-10582">
James Watters :
…Oh btw, original salesforce and much of what remains was built on traditional Oracle DB and big Iron, Its what they call a “transitional fossil” <img src="http://www.rationalsurvivability.com/blog/wp-includes/images/smilies/icon_smile.gif" alt=":)" class="wp-smiley">
Right, that's what I was referring to when I mentioned about the association of the EC2-like assumptions of IaaS delivering SaaS versus the reality that many SaaS offerings (that have been in place for some time) are monolithic in nature given their evolution.
@beaker
Hoff,
I see you more as an architect than a marketer…
The difference is that you are looking to fit or design solutions into a definition. Marketers are looking to fit the definition on their existing solutions. That's, I suspect, the rub here. You (and a lot of other folks) are putting a lot of thought into trying to figure out what cloud is/should be/can be and the marketing folks are latching onto a buzzword in order to close deals as fast as they can no matter what it is they are actually selling.
I think that the "cloud" term is already so amorphous and "polluted" that it's going to mean whatever people want it to mean. Seriously, from my perspective most of the dialog I see on "cloud" is about esoteric definition – not pragmatic solution. Executives, who write the checks, do not have the attention span to discuss/understand/care about esoterica – they want cost-effective solutions to problems *now*…and if they can tell the Board that it's "Cloud Technology" so much the better. That, my friend, is a marketing guys wet dream.
Personally, I think I'd rather see people talk in simpler terms about the solutions they are building and the use cases they support. I'd rather talk about the assumptions, risks, and capabilities of a solution set than what it should be labeled. Perhaps I am being naive but I suspect the solutions that provide the best perceived value will be the ones that win – no matter what we call them.
OK, take a breath. Drink a Hoffachino. Then, let's sort it all out… 🙂
<blockquote cite="#commentbody-10584">
Armorguy :
@beaker
Personally, I think I’d rather see people talk in simpler terms about the solutions they are building and the use cases they support. I’d rather talk about the assumptions, risks, and capabilities of a solution set than what it should be labeled. Perhaps I am being naive but I suspect the solutions that provide the best perceived value will be the ones that win – no matter what we call them.
I'm with you on that. I think this issue has been rattling around in my head for long enough and it finally dawned on me as to why.
I have the clarity I need. The rest of you — you're on your own. 😉
/Hoff
@beaker:
Scalability of cloud solutions in both directions is essential IMO – that is, I can sign up a single user at 3am on a Sunday by "self service" and start consuming immediately, then roll it out to squillions of users on Monday morning. My electricity provider doesn't tell me I have to consume at least X kWh, and I can consume as much as I like (within reason) provided I've got a fat enough pipe.
The provider can use an army of monkeys (SpinVox?) if they want but I don't [need to] care, so it is of no concern to me whatsoever. Thus it's a poor metric for what is/is not cloud.
Sam
@Sam Johnston
In this rare occasion I agree with Sam ;o) Yep, internal details are irrelevant. My thoughts at my blog http://doubleclix.wordpress.com/2009/08/02/when-i…
Our company has been providing hosted solutions since 2001. "cloud" is really loose because while we started as traditional managed host, we have evolved to a mix of single tennant, multi tenant, saas and iaas offerings. So is our service brand cloud? By NIST probably not, but I can tell you neatly every new customer is looking for cloud and when we ask what that means, it is exactly what we offer. They don't want responsibility for anything but maybe owning licenses. To make it even more difficult, if you offer a solution that does not include support, as in help desk, then they don't think it's cloud. So if I had to define cloud, based on the market, I'd say use of IT services without owning anything, including people on payroll.
I think you need to look at economics to get a good idea of what "cloud" is because, at the end of the day, its a business term even if the technology guys are abusing it.
Basically, you have two type of expenses – CAPEX and OPEX. CAPEX is Capital expenses which are (in IT) servers, cables, racks, routers, aircon, etc etc. OPEX is operational expenses – electricity, people, repairs etc.
When you buy equipment then there is a large outlay of money but this is a once off cost. It is also rather wasted because you will always add in some "cover" for future growth. Capex is traditionally done in advance too. Capex is always horrible because it is a large amount of money at once.
Opex is also difficult to determine upfront – how many IT staff will we need? How do we predict this?
So, cloud computing comes along and delivers a per usage price. No capex, no opex. No predictions, no mess, no fuss. You pay per user or per email, or per gigabyte, or something. Its easy to calculate and the accountants are happy.
Cloud is a benefit – not a technology.
Now, try fit your technology into that definition – does SaaS take away the need for Capex (and traditional Opex) and replace it with pure Opex? I believe it does.
Does it matter what technology is used underneath the SaaS "layer"? No, I don't believe so, as long as you (and your accountants) don't have to worry when your SaaS provider needs a new server.