SaaS providers aim for economy of scale: multiple customers (tenants) must be serviced on a common infrastructure/platform or software application.
As such, application service providers (ASPs, and more recently SaaS providers) have evolved their deployment architecture from strict hardware separation between tenants towards an increasing level of sharing between tenants. This process is mainly driven by scalability and maintainability reasons.
- Shared nothing. This first deployment architecture provides separate servers per tenant and enforces strict separation between tenants throughout the whole hardware and software stack.
- Shared infrastructure. A first approach to optimize scalability and resource usage is by sharing infrastructure and to provide separate virtual machines (VMs) per tenant.
- Shared application server. The VM-per-tenant approach does not scale for larger sets of tenants. The application provider further optimizes by sharing more layers of the software stack: the application server, and possibly also the database. However, to realize tenant separation, the application is still deployed in separate application spaces or application domains on top of the application server.
- Shared everything. To further increase maintainability, the application code is shared between the tenants, and to further improve scalability, a pool of deployed application instances can be shared between tenants. Tenant separation is handled completely in the application code.
The consequence of this evolution is that the application code exposes an increasing level of complexity, for example to enable tenant-specific feature management, to deliver tenant-specific security features, etc. This first white paper in a series of blog articles on application-level multitenancy, introduces and discusses the promise and pitfalls of such shared-everything architectures. We conclude with a set of challenges that we will discuss in follow-up articles