Back to articles

Multi-tenancy for backup-as-a-service

In the world of IT cloud services the need for and use of multi-tenancy software solutions is growing with each passing day. Everybody speaks of the need for managing multiple tenants in their applications and IT infrastructure environments -  but what exactly does it mean when someone mentions the need for multi-tenancy? This article will give a definition of multi-tenancy and specifically address multi-tenancy in relation to data protection services (backup-as-a-service).

Defining multi-tenant software

Multi-tenant software is the concept of a software solution which can be accessed and used by users belonging to multiple tenants (e.g. individual organizations, departments, groups etc.) in a single-instance installation of the software. The tenants are separated from each other while still sharing the same single instance software solution and potentially the underlying infrastructure. Users of each tenant can only access information, reports and possible features belonging to and relevant to their said tenant and have no access to other information in the setup.

Arguments for multi-tenancy

There are obvious reasons why multi-tenant solutions are beneficial for managed service providers (MSP’s). From a software update perspective it is easier to maintain and update a single instance of a service as opposed to having to update multiple instances of software installed for each customer using the software. 

Economies of scale is another argument. Having multiple user groups using the same software and sharing the infrastructure behind the software is driving down total cost of ownership and management costs and hence generates a more profitable business for the service provider.  

Finally, the software cost (operating system, database, etc.) for the single server and system on which the multi-tenant software is running will often be way less than architectures where multiple servers are required to run multiple instances of the same software.

Managed service provider or enterprise organization

The obvious organizations which can benefit from multi-tenancy are the MSP’s who provide shared services across multiple customers. They need multi-tenant software solutions to allow each of their customers to login to their part of the service delivered. Multi-tenant software enables the service provider to segregate the customers from each other while still consolidating all customers into a shared infrastructure.

Over the past years we have seen a transformation in enterprise organizations which requires these organizations to copy delivery models from the “as-a-service” world. We are seeing IT departments of the enterprises transforming their delivery models into “as-a-service” models empowering their departmental users with self-service capabilities and departmental reporting, invoicing and everything else which is part of a managed service. The transition into an internal (private) service provider requires multi-tenancy which can separate departments and organizational units from one another and still consolidate into centralized and shared infrastructures.

Multi-tenancy in a backup-as-a-service context

In a backup-as-a-service setup, multi-tenancy can be complicated: There is a good chance that your backup-as-a-service exists in a multi-level (or multi-layer) organizational hierarchy which can be almost flat in some parts, and many levels deep in others (unless your service has a strict one-to-one relationship with the end-users), and thus your multi-tenant environment needs to enable you to create a model that reflects your real-world organizational hierarchy.

Let us give you an example: An MSP has a backup infrastructure which is used to provide backup-as-a-service across the following organizational units:

  1. MSP
    1. Internal systems
      1. Critical systems
        1. One or more server groups
      2. Other systems
        1. One or more server groups
    2. External customers
      1. On-premise customers
        1. External customer One
          1. One or more regions
            1. One or more departments
              1. One or more server groups
      2. Other customers
    3. Resellers
      1. Reseller One
        1. One or more customers
          1. One or more regions
            1. One or more departments
              1. One or more server groups

 

Elaboration:

  1. “Internal systems” which are separated into two descendant tenants “critical systems” and “other systems”. For both of these groups there are several underlying “server groups”. There are internal employees who need access to all internal systems but also employees who should only access either “critical systems” or “other systems”. They also do internal billing and have different prices on backup data in “critical systems” versus backup data in “other systems”.
  2. “External customers” which are separated into a group of customers who have a mix of on-premise backup appliances and replicated data in the MSP data center and another group of customers who are backing up directly into the MSP backup infrastructure (with no on-premise backup appliances). Some of these customers have separated their backups into different regions which again are separated into different departments. For each department, some of the customers have multiple server groups. The service provider invoices each customer for their total consumption and some of the customers make internal invoicing of their regions and departments. 
  3. Resellers who operate their own subset of customers: Some of the resellers are required to deliver the service in their own name and brand. The MSP invoices the resellers for their total consumption across their customer portfolios and the resellers invoices their individual customers. Some of the customers require to do internal billing of their regions and departments. 

As the above examples show, there may be very different needs in different parts of an organizational hierarchy for how many side-by-side tenants or how many descendant levels are required. On top of this, users need the ability to manage their own part of the hierarchy (with different privileges in regards to self-service), without them gaining access to information which doesn’t concern them, i.e. have them securely separated from business units and other resources outside of their own part of the hierarchy. Automated multi-level invoicing capabilities are a must in most as-a-service setups.

Cloutility includes built-in multi-tenancy

Cloutility from Auwau is a web-based software solution for delivering backup-as-a-service. It seamlessly plugs into your backup/data protection infrastructure and among other features the solution provides role-based self-service, custom reporting and alerting, recurring billing automation and show-back. Cloutility organizes business units in a secure multi-tenant environment reflecting the user’s real world of business units, customers and departments.

To be able to reflect most types of business organizations, Clouitility is built upon: 

  • a flexible and secure multi-tenant hierarchy in which there are no fixed/required organizational levels
  • where each business unit can be the root of a new hierarchy, while being completely separated from other hierarchical siblings or ancestral relationships (apart from intentionally shared resources), and e.g.:
    • use their own brand
    • have related users signing in and be able to administer their own business unit as well as its potential descendants
  • and with each business unit being able to be related to one or more data-sources.

In addition, as organizations change over time, being able to easily move business units including their potential hierarchies (and data-sources) around in the multi-tenant hierarchy has become an integral part of Cloutility’s backbone, in order to prevent inevitable changes inside and outside of our organization resulting in potentially huge workloads for our own organization. 

To accommodate for various sign-in and security requirements, Cloutility supports both single sign-on (SSO) via SAML 2.0, e.g. for Microsoft Active Directory Federation Services (AD FS), Google Workspace etc. and multi-factor authentication (a.k.a. 2FA/2SV/MFA/MSV) using "time-based one-time passwords" (TOTPs) which can be configured throughout the multi-tenant hierarchy.

Summary

In this article we have defined multi-tenancy and highlighted some of the possible challenges in setting up a multi-tenant model for providing backup-as-a-service. 

Regardless of whether you deliver backup-as-a-service to hundreds of end-customers as a MSP, or to regions and departments as the internal IT services provider in a large enterprise, you will benefit from being able to segregate the data-sources you manage (even though they may reside in a shared data protection infrastructure) in order to gain both a general overview as well as detailed insight into how your data protection infrastructure is used. And if your business model changes at some point, say that you decide to enable other organizations to use or resell your service, multi-tenancy can provide you with the tools you need to easily add them to your existing hierarchy and provide them with the resources and privileges they need to get going, instead of necessarily having to set up a separate environment for them.

Thank you for reading.

Back to articles

You accept the use of cookies by using this site or closing this banner

Read more about cookies
IBM ISM Library Excellence Award 2012
IBM Storage: Best Cloud Solution 2013
IBM Beacon Award 2013
Ready for IBM Storage 2017
Top 10 IBM solution provider 2021
Børsen Gazelle 2024