The platform allows subsidiaries or regional deployments, several projects for different departments or countries, having several customers, companies, etc.
This means at series of benefits:
- To avoid redoing the same customization several times
- Shared authentication and security requirements
- Company branding integration
- Baseline workflow
- Shared maintenance
- To speed up projects deployment
There are two approaches to achieve the mentioned use cases:
The classical approach, used by several solutions, is to build a multi-tenant application: There is only one big application, which provides isolation features so each tenant of the application feels "as if it was their application".
This approach exists for a very long time and has the big advantage to provide a complete sharing of all resources which may seem to be the most economic option.
Multi-tenant isolation system allows:
- A configurable notion of tenant: By default a tenant is a domain.
- A user isolation at tenant level: Except for main administrators, users and groups and defined and managed at tenant level.
- A data isolation at tenant level: Documents are isolated a on per tenant basis using a security policy and ACLs.
- Depending on the way you define a tenant, you could also use completely separated repositories for each tenant (allowing to have physically separated Databases and BinaryStores).
The multi-tenant model has some intrinsic limits.
- All resources are shared: It is not possible to restrict one tenant to use too much CPU, memory or bandwidth.
- As long as all tenants run inside the same application, the configuration and customization must be limited.
- Concentrating the different projects/customers/tenants on the same application automatically makes it highly critical.
- All projects/companies/subsidiaries/departments need to agree on the upgrade schedule.
- Scalability limitations
- BackUp / Restore: As long as the data isolation is handled at application level, you can not rely on system-level backup restore tool, at least, not if you want to restore a data from a particular tenant without restoring the data for all tenants.
In this case, tenant isolation is enforced at system level:
- Tenant resource are really reserved and not accessible to other tenants, including CPU, Memory, I/O.
- Each tenant should use a different runtime so the configuration from a tenant can never impact another tenant.
Basically the idea is that for each client a set of dedicated containers running Nuxeo is used.
With the container based approach all the problems of a single application with multi-tenants disappear:
- Each project / client is really isolated
- At data level
- At runtime level
- At resource level
- Each project can have its own lifecycle for upgrades
- Project can be as custom as needed
Each project can have its own lifecycle for upgrades
Project can be as custom as needed
Let's consider a use case where in a large international company each region must have its own "flavor" of the corporate ECM.
Each region should have access to two repositories:
- A corporate repository, shared across all regions
- A local repository, specific to one region
The Nuxeo Platform provides the required infrastructure:
- Platform as a Service
- Multi-repositories support