Tenancy models for a multi-tenant app

We frequently hear about the importance of creating a multi-tenant application, especially in the context of developing a Software as a Service (SaaS) application.

There is some confusion about the concept of a “multi-tenant app” and the various models used to develop one. In this article, we took a closer look at those terms in a more practical way.

Understand different tenancy models from a technical point of view

Single-tenant architecture

Single-tenant architecture is a software or cloud computing model where each customer or tenant has a dedicated instance of an application or service. If we look at the origin of the B2B business model, it starts with each instance of the software serving only one customer or organization.

Characteristics

• Isolation: Each customer or tenant operates in an isolated environment with dedicated resources, databases, and configurations.
• Customization: Single-tenant architectures often allow for greater customization and flexibility to meet specific customer needs.
• Security: Enhanced security and data privacy, as customer data is not co-mingled with that of other tenants.
• Scalability: Scaling resources and capacity can be more straightforward, as each tenant's instance can be adjusted independently.
• Maintenance: Independent maintenance and updates, as changes made to one tenant's environment do not affect others.
• Cost: Typically higher infrastructure and operational costs due to the need to maintain separate instances for each tenant.

Examples

• Dedicated hosting: Traditional web hosting providers offer single-tenant architectures, where each client gets its own resources, databases, or configurations.
• On-premises software: Some enterprise-level software applications, such as customer relationship management (CRM) or human resource management systems (HRMS), offer single-tenant deployment options for organizations with strict data security and customization requirements.
• SaaS with premium tiers: In some Software as a Service (SaaS) offerings, premium or enterprise tiers provide single-tenant options for customers requiring enhanced security, compliance, or customization.

Single-tenant architecture is commonly used in scenarios where compliance is paramount or needs tailored security requirements. For example, industries like finance, healthcare, and government, which have strict regulatory requirements, often favor single-tenant solutions to ensure compliance.

However, it's important to note that single-tenant architectures can be more resource-intensive and complex to manage compared to multi-tenant architectures, as each customer's instance requires its own infrastructure and maintenance. As a result, they may be more suitable for applications with fewer but larger customers or where customization and isolation are critical.

Multi-tenant architecture

Software multi-tenancy is a software architecture in which a single instance of software runs on a server and serves multiple tenants. Systems designed in such a manner are "shared" (rather than "dedicated" or "isolated"). A tenant is a group of users who share common access with specific privileges to the software instance. With a multi-tenant architecture, a software application is designed to provide every tenant with a dedicated share of the instance - including its data, configuration, user management, tenant individual functionality, and non-functional properties. -- Wikipedia

Characteristics

• Shared resources: Multiple tenants share the same infrastructure, including servers, databases, and network resources, to optimize resource utilization.
• Isolation: Tenants' data and configurations are logically segregated, ensuring data privacy and security.
• Economies of scale: Multi-tenancy can be cost-effective as the overhead is distributed among multiple users, reducing operational and infrastructure costs.
• Scalability: The architecture can scale horizontally or vertically to accommodate growing numbers of tenants and users.
• Maintenance: Updates and maintenance are streamlined, as changes apply uniformly to all tenants, simplifying management.
• Customization: While some customization is possible, it is typically more limited compared to single-tenant architectures to maintain system-wide consistency.

Examples

• Cloud-based SaaS: Most Software as a Service (SaaS) applications, such as Google Workspace and Salesforce, employ multi-tenancy to serve multiple organizations or users on a shared platform.
• Shared hosting: In web hosting, shared hosting services host multiple websites on the same server, each belonging to a different customer or organization.
• Public cloud services: Public cloud providers, such as AWS and Azure, use multi-tenancy to serve diverse clients with isolated virtualized resources within shared data centers.
• Enterprise-wide infrastructure solutions: Such as a shared Kubernetes cluster that's used by multiple business units within an organization.

Redefining multi-tenant apps in the real world

We provided definitions from an architectural perspective, making it straightforward to distinguish between multi-tenant and single-tenant designs. However, this leans more toward the technical definition. If we use these definitions in our real-world development environment when designing tenancy models, this way of thinking assumes that a multi-tenant app must have a purely shared, multi-tenant infrastructure.

However, business and product vary a lot and have lots of case-by-case requirements so there's no one-size-fits-all solution.

Imagine a scenario where a tenant is using resources from a shared infrastructure, but due to specific business needs, they require one or two parts of the system to be exclusively dedicated to them. These dedicated parts could be the database, instances, or a combination of other components, all while sharing the overall infrastructure. This is where the mixed-tenant architecture comes into play.

In practical SaaS product development, it's common to meet a scenario where a product is primarily designed with a generic multi-tenancy model. However, certain aspects of the architecture or resources may be toward a "single-tenancy" approach.

AWS used the following case as an example to communicate this concept: multi-tenancy is a broad concept, and it is case-by-case to combine and choose the right strategy to define what you want to achieve the shared resources and data isolation.

In other words, sometimes people still call this model “Multi-tenancy”, so in the broader definition of multi-tenancy, it doesn't imply that every component in a solution is shared. Rather, it implies that at least some components of a solution are reused across multiple tenants.

Understanding this term broadly can better help you empathize with your client's needs and where they come from.

Rather than fixating on a single architectural model, multi-tenancy reflects the practicality of a SaaS product's architecture in the real world. When we refer to a multi-tenant app, it doesn't necessarily mean the app adheres to one architectural model; it might utilize various tenancy strategies, indicating that at least some of its components are shared.

Key considerations to determine your tenancy model strategy

Here comes the question, how do I propose the tenancy strategy for my product? Here are some important questions to think about:

• What are your business goals?
• Can a single-tenant solution support your future growth plans?
• How big is your operations team, and how much of your infrastructure management can be automated? Do you care about agility and cost efficiency?
• Are your customers comfortable with various multi-tenancy options?
• How does each option impact compliance, both yours and your customers?
• Are you expected to meet service-level agreements (SLAs) or aim for specific service-level objectives (SLOs)?
• Have you considered security, cost, performance, reliability, and responsiveness to individual tenant needs as a whole?

Remember that there isn't a rigid division in your product where you must opt for either a purely multi-tenant or solely single-tenant model. Your decision should be based on how you divide your product's architectural components and the specific isolation levels needed by your customers or business. You can then apply different approaches accordingly.

Next

We talked about the “new” definition of a multi-tenant app, however, how about tenant isolation, identities, and how to determine whether your identities should be isolated or not? What does it mean for identities to be "isolated"?

The confusion often arises when dealing with situations where one real-world user has two different identities. Is it appropriate to label this situation as - “identities isolated”?

We'll address these questions in our upcoming series of articles. Stay tuned!