Six Degrees of Multi-Tenancy InverCloud > Resources > Blog – The Degrees of Multi-tenancy We’re all familiar with the concept of Six Degrees of Separation. Well, while it’s a loss less likely that there will be a movie of the same name, it turns out that there also logically six levels of multi-tenant isolation in Cloud architectures. But, enough of the frivolity! In this post, we’ll consider the Six Degrees of Multi-tenancy which which system architects should consider. Each of these stages represents an architecture which utilises varying degrees of shared resources. This ranges from complete isolation to full resource sharing. Single-Tenant On-Premises This is the default architecture for deploying .NET. It has no multi-tenancy and each of the tenants is isolated. Every tenant has their own hardware and software, all installed on their servers in their premises. For every new tenant it is your responsibility to install their Hardware, Operating System, SQL Server and your Application Software. For each tenant there must be licencing for an OS and an SQL server. With this architecture maintenance must be performed on the hardware, OS, Database and the Application Software for each tenant. Depending on the nature of your Application Software and the update you might be required to be on their premises for the update. Single-Tenant Virtual Servers This is the first step in simplifying your architecture. This architecture begins the move to Virtualisation. The use of Virtual Machines (VMs) in this architecture greatly improves the utilization of hardware. This means that your application and database no long need their own hardware they can share the resources of any existing hardware. Reducing your overhead cost; you no longer have to purchase hardware and deploy it on your tenants’ premises. This architecture also offers a minor improvement in deployment efficiency. By designing your application to run on a VM you can then use an image of that VM to deploy your application to your tenants. This reduces the installation cost as you no longer have to create custom configurations to ensure your application work with different systems. With this architecture the maintenance and support responsibilities are the same as the “Single-Tenant On-Premises” architecture. Single-Tenant Data-Centre (Mixed VM/Physical) The “Single-Tenant Data-Centre” architecture has made the transition away from the tenants’ premises. All the hardware and data is now stored in a data-centre and is accessed via a network connection. While this architecture looks like it might contain some degree of multi-tenancy it is in fact still single tenant. Each of the tenants’ data and software is stored in the same datacentre but they are stored on different hardware and running individual versions of your application. With this architecture the hardware is no longer your concern; it is the Data Centres responsibility to fix any hardware maintenance issues. This means that it is not necessary to have an in house IT department to maintain the SQL and OS servers, the hardware is all taken care of by the data centre. However, because the data centre charges a standard fee, all your tenants must pay the same rate regardless of data size or revenue raised. When provisioning a new Tenant there is still a considerable amount of setup required. A new account must be created with the Data Centre and an instance of your application must be deployed along with any databases that are required. MultiTenant – Separate Database Servers The “Separate Database Servers” is the first architecture that contains any multi-tenant features. The Application Server is now multi-tenant; all your tenants’ login via the same application but the data that they access is unique to them. This architecture means that you no longer have to provision and maintain an individual instance of your software application for each of the tenants. There is now only one instance of your application software which all of your tenants use. This greatly reduces the costs of maintaining your application. However, in this architecture the Data Layer is still separated per tenant. Each tenant requires their own SQL server and hardware to host it. This significantly reduces the potential of the multi-tenant application server. When provisioning a new server there is little or no cost related to the application layer but for each new tenant you are still required to setup a new database and SQL server. With this architecture you are only required to purchase one Operating system licence as all the tenants will be accessing the same instance of your application. But, you will still be required to obtain one SQL server licence per tenant. MultiTenant – Schema per Tenant In this architecture all the tenants’ data is stored on the same SQL server but it is stored in separate databases. The SQL server managed the Data Isolation and ensures no tenant may access another tenant’s database. Sharing the same resources greatly reduces the provisioning cost; because all the databases are hosted on the same SQL server there is now only one Operating System licence and on SQL server licence required. Provisioning new tenants is also easier and less time consuming with this architecture. Instead of setting up a new SQL server you can now run a script which will deploy a new schema for the tenant. Another area of saving is the initial cost of hardware. With previous architectures a new tenant would require a new SQL server to host their data. However, you now only have to purchase new hardware when you get a significant increase in tenants or one of your tenants expands. MultiTenant – Shared Everything “Shared Everything” is a complete multi-tenant architecture where all the tenants data is stored in the same database, on the same hardware and separated logically using metadata. This allows all the infrastructure costs to scale evenly. As you or your tenants succeed you can increase the resources you require access to from your cloud provider or have available on your private cloud. Like in previous architectures there is only one instance of your application and only one OS licence and one SQL server licence. This helps to keep overhead costs low. This architecture is ideal for supporting “Free-to-try” or introductory rates. Since the hardware and software is already in place for your current tenants there is no provisioning required when adding a new tenant, the database simply expands to accommodate the new tenants. This means you can easily add new tenants at no extra cost. In this architecture Data Isolation is one of the major concerns for new tenants signing up to your service. So it is critically important that your data isolation design is of the highest standard. Architecture Cost Comparison Cost Single Tenant On Premise Single Tenant Virtual Tenant Data Centre Separate database servers Schema Per tenant Shared Everything Operating System Licence 1 per Tenant 1 per Tenant 1 per Tenant 1 1 1 SQL Server Licence 1 per Tenant 1 per Tenant 1 per Tenant 1 per Tenant 1 1 New Tenant Installation Software Application SQL Server Database Software Application SQL Server Database Software Application SQL Server Database SQL Server Database Database None Application Upgrades 1 per tenant 1 per tenant 1 per tenant 1 1 1 Database Upgrades 1 per tenant 1 per tenant 1 per tenant 1 per tenant 1 per tenant 1 Hardware Required 1 Server per tenant Makes use of existing hardware Flat rate per SQL and Application server Flat rate per SQL server Shared rate for one SQL server Shared rate for one SQL server Hardware Maintenance Onsite IT department Onsite IT department Handled by Data Centre Handled by Data Centre Handled by Data Centre Handled by Data Centre