Today, organizations that want their software applications to reach out to a large number of customers are adopting the Software as a Service (SaaS) approach for hosting. Most organizations usually start with a single-tenant strategy, spinning up separate instances of applications per customer on either their private or public clouds. But often, with time, end up realizing that this approach is neither scalable nor cost-effective.
Multi-tenant SaaS tenancy, on the other hand, addresses these issues, making the software development lifecycle easier. In a Multi-tenant system, the data for multiple customers is stored on a single server, but the confidential data for each tenant is secured from any other occupant.
Here are some design aspects that need to be considered from the beginning of the design to build a robust application:
Partitioning Data in a Shared Multi-Tenant Database
The most important consideration for designing the multi-tenant systems is through partitioning. The partition decision can be based on different aspects, such as:
- Using a separate database per tenant –
Many times, contractual reasons necessitate this type of method for partitioning the data. Having a separate database per tenant is the safest approach and ensures the highest level of data isolation. But it comes with additional overhead in terms of performance and development efforts. - Using the same schema and database but using an identifier to separate the data –
When the number of customers is too large, but the data size per customer is smaller, this approach is preferred. It is the easiest to implement and offers better performance. - Using the same database for all tenants but using separate schema per tenant –
Considered a mid-way approach, here the data is stored in different schemas using the same database. In terms of performance, this approach is a better option as compared to a separate database.
The hosted database services, provided by many cloud providers, make it easier to hold a separate database on the cloud for different customers.
Serve Increased Load from Tenants with Scaled Out Applications
After the data is separated for tenants, thought must be given to how the application can serve the ever-increasing load from newer tenants. To make this happen, the application needs to scale out quickly, with a stateless design, preventing the maintenance of tenant data or state of local storage on application servers. Many cloud providers provide services for various ways of scaling like scheduled, dynamic and on-demand. This is important feature to be considered to onboard new tenants as well.
High Availability and Disaster Recovery
Designing for fault tolerance in enterprise application is a familiar process and there are enough proven best practices. However, when it comes to SaaS which pre-dominantly is a cloud-based architecture-specific consideration needs to be taken care for High availability. The most effective way to achieve this is to use multiple zones for applications. If a service is distributed among several zones, consumers of that service can fail over to other zones. It also important to consider the Disaster recovery from the viewpoint of SLA to be adhered to and design appropriately, There are many cloud providers who offer services for continuous data protection to achieve RPO(Recovery Point objective and through automation achieve greater Recovery time objective(RTO).
Operational Considerations
Monitoring:- Polling application components, services and infrastructure to identify failures and report them through alert/notification systems. This is also important from a scalability perspective to identify the right thresholds for autoscaling.
Metering:- It is important to track the usage, availability, number of failures and time to respond for failures from a Service level agreement aspect.
Environments:- Ensuring there are dev/testing/staging and production environments considered and automation enabled to bring up these environment would be an important aspect.
Summary
The strategy for designing the multi-tenancy is a must from the very beginning of the SaaS applications – designing it at a later stage could be sub-optimal. Join the discussion and add your comments below about any new approaches for creating multi-tenant applications.
