Multitenancy Status Quo (August 2014)
Resources and discussion on MultiTenancy in Sling from the last months:
- Current implementation of Sling Tenant: http://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/tenant (no documentation available besides the source code currently)
- Other Wiki pages:
- Multitenancy Support (First draft Felix Meschberger from 2009)
- Multitenancy Support Integration (proposal from Andreas Schaefer from February 2014)
- Recent discussions in the Mailing list:
- RT from Carsten Ziegeler: http://apache-sling.73963.n3.nabble.com/RT-Multi-Tenancy-td4037558.html
- Proposal from Andreas Schaefer: http://apache-sling.73963.n3.nabble.com/Tenant-Implementation-in-Sling-td4031217.html
Definition of terms
Definition of terms used in this wiki page
- Multitenancy
- The generic description is found in Wikipedia: http://en.wikipedia.org/wiki/Multitenancy
- The main question is: what exactly is a "Tenant" in context of Sling, and what are the requirements for customization etc. This wiki page should help to shape the answers.
- Content
- Content accessible via Resources in the Resource Hierarchy (in most cases in a JCR content repository) which belongs to each tenant
- Is stored by convention below /content/*, but this is not mandatory
- May be associated via resource types with scripts and components globally available, or tenant-specific custom scripts
- Configuration
- Configuration that customizes the system and application behavior
- Either globally, or on a more fine-granular level (e.g. per tenant)
- OSGi configurations are part of it, but there may be other configuration as well
- Scripts
- Scripts like JSP/ESP/Sightly/Java files stored as resources in the resource hierarchy that are used by Sling to render the views of the resources
- Ca be both globally available (stored in /libs or /apps), or tenant-specifc
- Bundles
- Java bundles containing services deployed to the OSGI runtime
- Usually bundles are always global, not tenant-specific. But configuration may be needed to be tenant-specific as well, which is currently only possible if the bundle implementation supports it.
- Site
- A site is a collection/subtree of resources of the content that forms a logical unit used to publish a CMS-based site
- The root of the subtree may be the homepage, with the subnodes forming the content hierarchy of the site
- Usually there is a need for site-specific configuration
Scenarios
After reviewing the discussions in the mailing lists there seem to be two major usecases that have the need for a Multitenancy support. Although there have some shared requirements, both have a set of special requirements with some complexity to implement that are not so relevant for the other. Of course mixes of both scenarios are possible as well.
"Virtual Hosting" Scenario
In this scenario Sling is used for "virtual hosting", that means hosting multiple tenants that should be fully isolated. The main goal according to the wikipedia definition is cost saving, that means instead of a single sling instance and the corresponding infrastructure for each tenant all tenants are hosted in a shared instance. There is no need for content sharing. Usually the users of each tenant are distinct from each other.
"Massive Multi Site" Scenario
In this scenario the whole instance is used by one corporation which has the need to host a huge number of sites (e.g. 100 or 1,000 or more sites) in a single instance. Besides cost saving of having a single instance, additional goals are the support of content sharing. Although there are some users that have only access to a single site, there are plenty of users that can have access to multiple sites (read/write or only read). To structure the huge number of sites a hierarchy of regions and subregions is used.
Usecases
// TODO