I was recently reviewing some sales and marketing materials regarding building out Infrastructure-as-a-Service (IaaS). Part of these materials included attributes of IaaS, one of which is multi-tenancy. Having been working with some large enterprise customers lately around private cloud, this attribute really got me thinking.

In most cases for the enterprises I have been working with, the private cloud is about agility and the workloads are all owned and related to the same business line. From the macro perspective, there is effectively one tenant, yet from a micro perspective (workload) there are multiple tenants that may require some isolation for purposes of service level and resource management.

Why is this important? Multi-tenancy is expensive. It requires additional resources and overhead to manage including encryption and key management, isolation across network, compute and storage, and additional support for tenant management. Remove this overhead and those physical resources can be focused on workloads instead of overhead.

Further confusing the issue is the duality of the use of private cloud to describe physicality and consumer models. Private cloud when described through its physicality typically is represented as “on premise” either in the customer’s data center or a third-party hosting co-location facility. However, the cloud being a business consumer model, I like to describe it based on the consumption model as anything that has a single tenant (macro) is a private cloud. Hence, in order to move away from describing private cloud by its physicality requires that we establish a macro and micro representation of tenancy. That is, by recognizing at a macro level that there is only one real tenant consuming the private cloud, then many of the multi-tenancy features can be minimized in favor of greater use of resources for workloads.

For enterprises that are operating as a shared IT services provider across multiple divisions that have various legal and operational requirements for security and isolation, where the cloud exists on premise or in a co-location scenario, secure multi-tenancy will be a requirement. However, using the existing cloud computing vocabulary, it may be more effective to identify these types of clouds as community clouds instead of private cloud since all the tenants have a shared common interest. In this way, once again, we can describe the appropriateness of multi-tenancy by consumer instead of physicality.

With many of my clients looking to develop private cloud, success will be predicated on developing and delivering the right features and functions. Identifying the real consumer for the cloud service and an understanding of the relationships between the workloads can go a long way to using either using axe to kill a fly or falling prey to an inadequate service level model. By identifying private cloud as a single tenant at the macro consumer level and a community cloud as multiple related tenants at the macro consumer level, we have a model that ensures regardless of the physical infrastructure deployment we are providing the appropriate features and capabilities.