In my many interactions with cloud management platform (CMP) vendors, a point of extreme concern is multitenancy. Of course, most of them recognize that a basic premise of multitenancy is network isolation. However, in too many cases, vendors can suggest that, above network isolation, implementing multitenancy simply is a matter of granular role-based access control. Too many times I heard vendors stating that if one user or group represents the cloud provider, and a number of sub groups represent the different cloud tenants, you have a multitenant environment. Of course, it’s way more complex than that.
A vendor that properly supports multitenancy must implement it at all levels of its CMP*. Some examples:
- Each tenant must be able to authenticate login credentials against its directory services. So, for example, tenant A may want to authenticate against Microsoft Active Directory, while tenant B may want to authenticate against OpenLDAP.
- Each tenant must be able to customize the self-service portal to reflect its identity. So, for example, tenant A may just want show its corporate logo and color scheme, while tenant B may want to completely mask any reference to the underlying CMP solution in the UI.
- Each tenant must be able to build and expose its service catalog in an autonomous way. And the cloud provider must be able to further populate tenants’ service catalogs with catalog objects that can be equally used by all tenants.
- Each tenant must be able to define dedicated resource allocation strategies. So, for example tenant A may want to allocate resources upfront, while tenant B may want to allocate resources as needed to address provisioning requests.
- If provisioning approval is enforced, each tenant must be able to define its approval policies, with specific levels of approval (if supported by the CMP solution), dedicated approvers, approval SLAs, and default approval action if no action is taken.
- Each tenant must be billed (or just metered) against dedicated chargeback (or show back) policies, and may enforce specific currencies. So, for example, tenant A may be billed against a pay per use charging model, while tenant B may be billed against a per-allocation charging model.
- Each tenant must have isolated automation workflow libraries for its instance of the orchestration engine. Automation workflows contain sensitive information about the whole IT infrastructures.
- Each tenant must have independent connections with preferred remote cloud environments. So, for example, tenant A may need integration with AWS, while tenant B may need integration with a vCloud service provider.
- Each tenant must be able to generate a variety of reports about the different aspects of the CMP though dedicated scheduling and customization.
The list goes on and on. In a truly multitenant cloud environment, each tenant must be able to setup and maintain all aforementioned policies and integration points without the intervention of the cloud provider.
Unfortunately, most CMPs on the market don’t implement multitenancy this way because it’s really complex.
The vendors’ argument is that most clients using CMPs to build private clouds don’t need this level of sophistication. This is certainly true for many organizations at the beginning of their cloud journey. However, in my interactions, all large organizations building an on-premises cloud serve (or plan to serve) different business units and departments that have different security levels and dedicated IT infrastructures. Additionally, many of those large organizations contemplate the idea of exposing their initially-private clouds to external entities (e.g., business partners, federated agencies).
In other words, beyond the public cloud use case, there are situations where poorly implemented multitenancy is a deal breaker.
If you are an end user organization, you should really evaluate how robust multitenancy is in your CMP of choice.
If you are a vendor, you should really anticipate the need of your maturing customers and stop pretending that multitenancy is just network isolation, group hierarchies and RBAC.
*If you are curious about what are the management functions and the capabilities that Gartner recommends for an enterprise-grade CMP, I recommend you reading our research titled: Evaluation Criteria for Cloud Management Platforms
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.