Cloud Strategy: Multi-Tenant or Multi Single-Tenant?
This blog is part of Cloud Strategy series. This talks multi-tenant architectures and the architectural complexity they bring. This blog proposes a multi single-tenant architecture built on cloud-serverless technologies that reduces architecture complexity without compromising any functional need
A typical apartment buildings are multi-tenant in a way that tenants are separated by thick walls and take advantage of shared services like cleaning, concierge, plumbing etc. As always, IT also borrowed this term to represent systems where a common infrastructure is used to host multiple businesses. Salesforce is one system that made the multi-tenant vogue. Salesforce implements multi-tenancy in the form a big common database that segregates tenant data based on a table column called OrgId.
Multi-tenant clearly brings cost and management benefits which you can pass on to the customer making your product more competitive.
Multi-tenancy Trade-offs
All the benefits multi-tenant architecture touts do come with several challenges. Accommodating all tenants in a single infrastructure has to manage multiple concerns around data security, data privacy, performance to start with. This leads to a complex architecture which can be very fragile to change and maintain.
It also makes difficult to manage tenants in different parts of the world, and releasing features for a particular tenant would reflect in architecture complexity
A new perspective for Multi-Tenant Systems
Multi-tenancy is an architectural pattern driven by the necessity of serving multiple businesses with minimal cost, faster onboarding and common infrastructure. This style was forced by the technological constraints of that time. If we could solve this problem with a different architectural style that serves all the needs of a SaaS software and reduces the challenges posed, then that could be a viable option.
Proposed Architecture
- It uses serverless compute and database like EKS, AKS, Step Functions, Lambda and DynamoDB, AWS Aurora etc
- These serverless services are billed on usage thus reducing the overall cost
- The infrastructure is created quickly with Cloudformation, Terraform when a new Tenant is onboarded
- For systems that will see sporadic usage, eg some kind of data connector; they can be built on lambda or other FaaS, and serverless DB like aurora which would need minimal management
- For system that will see heavy usage, the compute can be on Kubernetes clusters which can host thousands of nodes or they can be on separate clusters based on customer or geo segmentation
- Not all components need to be shared, eg API gateways can still be shared across tenants or some kind of segmentation
Would it not be more expensive
- The cost can be evaluate based what and how many component you wish to share among tenants
- You need to note that regular multi-tenant systems are difficult to design, change and run. The proposed option takes out that complexity and costs would need to be compared across two options for a 3–5 yr TCO
- Serverless architecture also makes it cheaper to run the software and cost savings realised against simpler design and maintenance would reduce the overall cost which can then be passed on to tenants
Summary
The new approach to build multi-tenant systems as many single-tenant systems on a cloud based serverless native architecture has its merits and it should be evaluated against the cost of design, build and run before deciding on the final architecture
