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
(I’ve done this once before, but if it was good once…)
Recent Comments