This entry was originally published in January 2012 on the CloudSource blog.

In part 4 of this series I described how to assess applications and decide whether they should be hosted in a private cloud or a public cloud. One aspect I did not address was the one of multi-tenancy. Let me take a sidestep and address this. The entry might look a little more technical, but be assured; I want to stay at the business level. It’s actually quite important to understand what this concept means and how it may affect your decisions.

Definition of multi-tenancy

According to Wikipedia, multi-tenancy refers to a principle in software architecture where a single instance of the software runs on a server, serving multiple client organizations (tenants). Multi-tenancy is contrasted with a multi-instance architecture where separate software instances (or hardware systems) are set up for different client organizations. With a multitenant architecture, a software application is designed to virtually partition its data and configuration, and each client organization works with a customized virtual application instance.

Webopedia has a simpler definition. In cloud computing, multi-tenant is the phrase used to describe multiple customers using the same public cloud.

Multi-tenancy enables sharing of resources and costs across a large pool of users thus allowing for:

  • Centralization of infrastructure in locations with lower costs (e.g. real estate, electricity)
  • Peak-load capacity increases (users need not engineer for highest possible load-levels
  • Utilization and efficiency improvements for systems that are often only 10-20% utilized

Actually, all of this sounds nice, but why does this really matter? In trying to maximize the use of our computing assets, we are confronted by two antagonistic elements. On the one hand, we would like to have our information assets being used as much as possible to maximize utilization. This may imply people from different departments and/or companies (each being one tenant) using the same assets concurrently. But on the other, we want to ensure we are fully isolated from the others. So, multi-tenancy is all about being able to isolate multiple tenants using the same IT assets.

Multiple levels of multi-tenancy

You probably realized I was very cautious about the shared assets, not specifying them clearly. That’s because there are multiple levels of multi-tenancy. Actually, in their multi-tenancy reference architecture, Gartner recognizes seven layers. You can find the picture of this architecture on slide 11 of this slideshare. You can share nothing, share the hardware, the operating system, the database, having shared application containers, share everything or have a custom combination of the six others.

Now, what does that mean for you?

To come back to the discussion in part 4, you probably don’t want the core applications on a platform that is shared with external tenants, so you will implement those either in legacy environments or on a private (potentially hosted private) cloud. This will typically be a single tenant environment, which means you share nothing. However, one question to ask yourself is whether you should treat the departments, business units or subsidiaries of the enterprise as separate tenants. In other words, what level of isolation do you need between the different parties? If you treat the different entities as separate tenants, your private cloud (which we originally considered as a single tenant environment because we considered all members of the enterprise as part of the same tenant group) suddenly becomes a multi-tenant environment where you share everything. So, you have just moved from one extreme of the Gartner architecture to the other.

As IT increasingly becomes a service provider, it’s important to look at the potential risks you may be subject to. We typically recognize six different levels:

  1. The lowest level, although serious, would be when privacy is breached by employees of the company. It’s possible to contain the damage via standards of business conducts or data privacy policies.
  2. The second level involves contractors enrolled by the enterprise, who have been given access to the enterprise IT environment. Control and trust may address the issues.
  3. The third level involves business partners. Those probably have to be contained to a more isolated area of the IT environment, maybe only sharing infrastructure and/or operating system.
  4. Let’s now think about customers/consumers. This is where multi-tenancy plays its role fully. Some may be grouped in a consortium or a community and share the same application (with or without sharing the same database – shared everything or shared application containers).
  5. Unrelated customers require strong multi-tenancy.
  6. And then you have intruders, but here periphery tools should block their entry in the first place. It becomes a security issue more than a multi-tenancy issue.

Public cloud services implement multi-tenancy. In the case of IaaS, it’s typically a shared infrastructure/shared operating system model, in the case of PaaS, shared application containers and in case of SaaS, typically a shared everything model.


When deciding which application goes where, ask yourself the level of isolation you require for this application. Does its access, and the access to the associated data, need to be limited to a small amount of employees, to one department, one business unit, one subsidiary? If yes, you may want to start looking at developing some level of multi-tenancy within your private cloud. Keep it simple and use the shared infrastructure or shared operating system approach. That works most often and although it may not be the most efficient way, it will do the job.

If you decide to use public cloud services for your application, ensure you understand the multi-tenancy model used by the service provider. Ask how they separate between the tenants and what technologies they have in place to avoid security breaches. That will give you a good understanding of how secure your information is in the cloud.