Multi-tenancy and ownCloud
What is Multi-tenancy? Multi-tenancy is a term referring to systems that have multiple organizations accessing the same server, each organization (or company) is considered a tenant and to each tenant the system looks custom for them. There are 2 approaches to multi-tenancy in the world: multi-tenancy through instance replication, and multi-tenancy through data segregation (this […]
What is Multi-tenancy?
Multi-tenancy is a term referring to systems that have multiple organizations accessing the same server, each organization (or company) is considered a tenant and to each tenant the system looks custom for them.
There are 2 approaches to multi-tenancy in the world: multi-tenancy through instance replication, and multi-tenancy through data segregation (this tends to be considered true multi-tenancy).
Instance replication means an admin spins up a separate virtual machine instance per organization. This is somewhat difficult to manage in large scale – imagine managing 100 organizations, meaning 100 or more virtual machines! – and also server resource intensive as each instance has a separate virtual machine consuming overhead.
ownCloud – as a Web Service allows you to make this even easier by using different data directories for each ownCloud instance. In that case you do not need to manage different virtual machines, operating systems, Apache or PHP versions but still different ownCloud instances. Management tools from 3rd parties (like RH Satellite Server or SUSE Manager) can make this even easier for you. This means that you have …/customer1, …/customer2, etc. instead of just /owncloud inside your Apache or ISS setup.
Setup with multiple data directories is the currently best setup for organizations with 20 users or more.
The even more modern, third approach is to use containers. Docker or other container technologies allow you to spin up ownCloud instances very easily and there are management utilities around that.
Multi-tenancy achieved through data segregation (true multi-tenancy), makes managing the environment even simpler as there is just one server farm, one admin interface and one instance of the software. This is how SalesForce.com works, for example. Tenants are segregated through software configurable options on the servers, and their data is physically separated on the storage backend, to meet isolation requirements. Typically, multi-tenant systems also allow customer admins to customize features for the organization’s users, modify workflows, and polish the look and feel for their users, while not impacting any other tenants on the system. Such systems need to put high focus on security and secure programming. Often XSS (Cross-side-scripting) issues do exist. In separate instances security can be easily proven!
ownCloud has seen customers asking for the following:
- Unique domain names and SSL certificates per tenant
- Unique branding per tenant
- Groups imported from Active Directory/LDAP per tenant
- Flexible storage usage per organisation per tenant
- Unique ownCloud Apps available per tenant
What ownCloud Does
ownCloud can provide multi-tenancy through instance replication very easily, and for small service providers or enterprises, this is typically a good start. This is also often good enough for large organizations or service providers.
ownCloud also provides multi-tenancy through data segregation – partly. There are 4 parts to providing multi-tenancy through data segregation in ownCloud: group isolation for sharing, physical data segregation, the tenant data construct, and customization by tenant.
– Group isolation for sharing. If you share a file with someone in ownCloud, the admin can enable a check box so that you can only see other users on the system that are members of the groups to you are a member. For small (up to approx. 20 users per account) multi-tenant situations, this means you treat tenants as groups, and you can emulate multi-tenancy.
– Physical data segregation. ownCloud can leverage a custom data path for each user of the system, and the admins can configure it to use a separate path for each tenant. This requires a directory (LDAP/AD) to function, but it can isolate user files from each other.
In result this means that for any tenant which does not need groups, typically 10 users or less – you can use one ownCloud instance.
For any larger tenant we strongly recommend to spin up unique instances in one of the ways described above. Consultancy on management of such instances can be delivered by ownCloud partners!
How this compares to ownCloud competition:
We have not been able to find a single competitor who can deliver all 5 customer requests on a per tenant basis combined.
Typically it will be only possible to have a subdomain and/or your own SSL certificate. (IDGard, Sharefile). Flexible storage usage is typically not possible, one storage system is needed for the full application (CTera with S3 or Scality).