Multi-tenancy & Nuxeo

Generic use case

Building ON TOP of a Platform

Building ON TOP of a Platform

Building ON TOP of a Platform

Building ON TOP of a Platform

Customer

Customers

Multi-Tenants

Multi-tenants application

Multi-tenants Infrastructure

vs

Multi-Tenants

Multi-tenants application

All clients share the same application.
Application manages data & configuration partitionning.

Multi-tenants Infrastructure

vs

Multi-Tenants

Multi-tenants application

All clients share the same application.
Application manages data & configuration partitionning.

Multi-tenants Infrastructure

All clients share the same infrastructure.
Deploy isolated customized application on PaaS.

vs

Application LeveL Multi-tenancy

the classic way

APPLICATION LEVEL MULTI-TENANTS 

all clients share the same application

application manages data and configuration partitionning

Application level Multi-Tenancy - Data Isolation

• Data Partitioning
  • Repository
    • Security Policy
    • "Domain based"
  • Elasticseach
    • same index
  • Users/Groups
    • filtering on per tenant basis

Logical isolation

Application level Multi-Tenancy - Data Isolation

• Data Partitioning
  • Repository
    • Separated repositories
      • MongoDB
    • Separated Blob Stores
  • Elasticseach
    • per tenant index
  • Users/Groups
    • different directories

Physical isolation

Application level Multi-Tenancy - Configuration

• Share everything
  • One Application : One configuration
     
• All tenants share the same configuration
  • extension points contributions
     
• ​Tenant isolation is done via filtering
  • ​all doc types are defined for all tenants
  • UI filters access / hides part of it

Application level Multi-Tenancy - Configuration

Some Limitations

Shallow isolation

• quota management is difficult 
• customization options are constrained
   

Monolithic 

• same version, same component set
• same upgrade and maintenance policy
   

Scaling number of tenants adds complexity

• ​scale out is not that easy (i.e. move a tenant)
• per-tenant Backup/Restore is not easy
• Heterogeneous deployment units
           VM level / JVM level / App level 

But

Well adapted for lightweight customization.
 

Easy first step.

Multi-tenanTS INFRASTRUCTURE

Cloud native approach

Container Level Multi-tenants

rely on infrastructure to provide tenants isolation

application does not need to be impacted 
 

Bake custom images

Bake custom images

Bake custom images

Deploy custom images

Deploy custom images

Principles

Docker   containers !

Leverage  AWS infrastructure 

Container Level Multi-tenants

Unlimited Customization
 

Flexibility of isolated deployments

Full security Isolation & Quotas

• Could be VM based
  • AWS ECs / CloudFormation
  • vSphere
     
• Container based
  • Rancher / Docker / Kubernetes
  • OpenShift V3 / CloudFoundry

Build Your Own Application  

Infrastructure Cost

Overhead is not that significant
(Docker is lightweight, JVM ~500MB)
 

Anyway, provisioning automation is needed to scale
(DNS, DB, Backup ...)

Nuxeo & Docker

• Working on Docker deployment since 2012 !
  • Working on Docker based PaaS
    • CoreOS / Fleet
    • Swarm / Kubernetes
    • Rancher
      
       
• All existing PaaS solutions converge to this approach
  • OpenShift 3 is now Docker/Kubernetes based

Multi-Tenants ?

Choosing the right approach

Decision Points

• Per tenant customization
   
• Per tenant isolation requirements
   
• Per tenant revenue model
   
• Differences between small and large customers
   
• Number of tenants
   
• Hosting practices

Different solutions for Different clients

• Small customers with entry level offering
  • fully shared infrastructure
  • limited customization
     
• Medium customers with more security concerns
  • shared configuration
  • isolated storage
  • limited customization
     
• Platinium customers
  • infrastructure level isolation
  • full Studio power for each customer