A Note On Multitenancy As A ‘Defining’ Cloud Attribute…
Balakrishna Narasimh and I were discussing the recent hoohaa on Public and Private Clouds when he made an observation on Twitter:
Starting to think public vs private clouds is misleading terminology. more meaningful distinction is single-tenant vs multi-tenant clouds.
I suggested that multitenancy can certainly be an attribute of Cloud deployment, but that I don’t see it as being a differentiator. I responded thusly:
So different business units in an enterprise don’t represent different “tenants?” They can be governed w/ diff. SLA, policy, $
My point here was that trying to use multitenancy as a way to distinguish between Public and Private Cloud deployments ignores the reality that in many large enterprises — many of whom who are beginning to architect and deploy Private Clouds — they think of their business constituencies as individual “tenants.” Each of these “tenants” often have different business requirements, service level requirements, cost structure and chargeback rates, policies, etc.
Food for thought.
/Hoff
I made exactly the same point a month ago (which resulted in a small scrub fire as this has now):
‘”internal” and “private” #cloud both suck. it’s all about tenancy: single-tenant vs multi-tenant.’
That’s basically what it comes down to though – whether it’s on-site/internal or off-site/hosted doesn’t really matter… what is important is that much of the value of cloud derives from multi-tenancy (sharing the capex, avoiding peak load engineering, etc.).
Things are grey in the large enterprise world – they’re like their own marketplace with business units buying from each other and so on. Indeed building out a next gen datacenter and selling it back those units (possibly even from a separate wholly-owned subsidiary) is one of the models I suggest to my larger clients. However, if the right hand is selling to the left hand the enterprise is ultimately still wearing the cost.
Now, were a vendor to deliver a fully financed hardware, software and services solution and take ownership of everything on the far side of the user (web) and machine (API) interface demarcation point then I’d say that is, for all intents and purposes, what cloud’s about.
Sam
Like or Dislike:
1 
0
Despite our obvious disagreement with Private Clouds, your comment was interesting, and I had the same reaction to it as I did to Krishnan’s which is why I chose to comment on it.
People might find the following posts relevant:
The Vagaries Of Cloudcabulary:
Why Public, Private, Internal & External Definitions Don’t Work (http://www.rationalsurvivability.com/blog/?p=678)
and
Internal v. External/Private v. Public/On-Premise v. Off- Premise: It’s all Cloud But How You Get There Is Important
(http://www.rationalsurvivability.com/blog/?p=18)
/Hoff
Like or Dislike:
0 
0
I may have mentioned something along these lines when discussing where the shared resources comes from in a private cloud.
Needless to say, I agree with your assessment that both private and public clouds can be multi-tenant. There’s nothing that precludes enterprises, especially those large enough to have departmental/line of business/subsidiary lines of demarcation around both IT-oriented and business (accounting)-oriented policies.
Lori
Like or Dislike:
0 
0
Chris, I agree with you 100%. Enterprises large enough to potentially benefit from large scale internal clouds would absolutely be multi-tennant – allowing multiple business units to share the resources vs the typical siloed “server hugging” approach most often used today….
Like or Dislike:
0 
0
@Sam Johnston
“Now, were a vendor to deliver a fully financed hardware, software and services solution and take ownership of everything on the far side of the user (web) and machine (API) interface demarcation point then I’d say that is, for all intents and purposes, what cloud’s about.”
Why cannot $VENDOR be the Information Technology/Services arm of that same organization? For years we’ve had the religion of the business as client drummed into us – re-envisioning internal resources as Cloud would seem to be the logical conclusion. If done properly, reductions should happen in capex, and opex for clients is tied to usage.
Like or Dislike:
0 
0