Multi-tenancy encompasses the management of heterogeneous business, technical, delivery, and security models.

Last week, during what was certainly an invigorating if not agonizingly redundant debate regarding the value of public versus private cloud computing , it was suggested that perhaps if we’d just refer to “private cloud” computing as “single-tenant cloud” all would be well.

I could point out that we’ve been over this before, and that the value proposition of shared infrastructure internal to an “organization” is the sharing of resources across projects, departments, and lines of business all of which are endowed with their very own budgets. There are “customer” level distinctions to be made internal to an organization, particularly a large one, that may perhaps be lost on those who’ve never been (un)fortunate enough to work within the trenches of an actual enterprise IT organization.

The problem is larger than that, however, and goes far beyond the simplistic equating of “line of business” with “company”. Both still assume that tenant is analogous to business (customer in the eyes of a public cloud provider) and that’s simply not always the case.

THE TYPE of CLOUD DETERMINES the NATURE of the TENANT 

Certainly in certain types of clouds, specifically a SaaS (Software as a Service) offering, the heterogeneity of the tenancy is at the customer level. But as you dive down the cloud “stack” from SaaS –> PaaS –> IaaS you’ll find that the “tenant” being managed changes. In a SaaS, of course, the analogy holds true – to an extent. It is business unit and financial obligation that defines a “tenant”, but primarily because SaaS focuses on delivering one application and “customer” at that point becomes the only real way to distinguish one from another. An organization that is deploying a similar on-premise SaaS may in fact be multi-tenant simply by virtue of supporting multiple lines of business, all of whom have individual financial responsibility and in many cases may be financially independent from the “mothership.”

Tenancy becomes more granular and, at the very bottom layer, at IaaS, you’ll find that the tenant is actually an application and that each one has its own unique set of operational and infrastructure needs. Two applications, even though deployed by the same organization, may have a completely different – and sometimes conflicting – set of parameters under which it must be deployed, secured, delivered, and managed.

A truly “multi-tenant” cloud (or any other multi-tenant architecture) recognizes this. Any such implementation must be able to differentiate between applications either by applying the appropriate policy or by routing through the appropriate infrastructure such that the appropriate policies are automatically applied by virtue of having traversed the component. The underlying implementation is not what defines an architecture as multi-tenant or not, it’s how it behaves.

When you consider a high-level architectural view of a public cloud versus an on-premise cloud, it should be fairly clear that the only thing that really changes between the two is who is getting billed. The same requirements regarding isolation, services, and delivery on a per-application basis remain.

THE FUTURE VALUE of CLOUD is in RECOGNIZING APPLICATIONS as INDIVIDUAL ENTITIES

This will become infinitely more important as infrastructure services begin to provide differentiation for cloud providers. As different services are able to be leveraged in a public cloud computing environment, each application will become more and more its own entity with its own infrastructure and thus metering and ultimately billing. This is ultimately the way cloud providers will be able to grow their offerings and differentiate from their competitors – their value-added services in the infrastructure that delivers applications powered by on-demand compute capacity.

The tenants are the applications, not necessarily the organization, because the infrastructure itself must support the ability to isolate each application from every other application. Certainly a centralized management and billing framework may allow customers to manage all their applications from one console, but in execution the infrastructure – from the servers to the network to the application delivery network – must be able to differentiate and treat each individual application as its own, unique “customer”. And there’s no reason an organization with multiple internal “customers” can’t – or won’t – build out an infrastructure that is ultimately a smaller version of a public cloud computing environment that supports such a business model. In fact, they will – and they’ll likely be able to travel the path to maturity faster because they have a smaller set of “customers” for which they are responsible.

And this, ultimately, is why the application of the term “single-tenant” to an enterprise deployed cloud computing environment is simply wrong. It ignores that differentiation in a public IaaS cloud is (or should be) at the same level of the hierarchy as an internal IaaS cloud.

CLOUD COMPUTING is ULTIMATELY a DEPLOYMENT and DELIVERY MODEL

Dismissing on-premise cloud as somehow less sophisticated because its customers (who are billed in most organizations) are more granular is naive or ignorant, perhaps both. It misses the fact that public cloud only bills by customer, its actual delivery model is per-application, just as it would be in the enterprise. And it is certainly insulting to presume that organizations building out their own on-premise cloud don’t face the same challenges and obstacles as cloud providers. In most cases the challenges are the same, simply on a smaller scale. For the largest of enterprises – the Fortune 50, for example – the challenges are actually more demanding because they, unlike public cloud providers, have myriad regulations with which they must comply while simultaneously building out essentially the same architecture.

Anyone who has worked inside a large enterprise IT shop knows that most inter-organizational challenges are also intra-organizational challenges. IT even talks in terms of customers; their customers may be internal to the organization but they are treated much the same as any provider-customer relationship. And when it comes to technology, if you think IT doesn’t have the same supply-chain management issues, the same integration challenges, the same management and reporting issues as a provider then you haven’t been paying attention.

Dividing up a cloud by people makes little sense because the reality is that the architectural model divides resources up by application. Ultimately that’s because cloud computing is used by applications, not people or businesses.