Taking a deeper dive into the notion of "multi-tenancy" and sharing our insights on how we perceive it.
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.
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.
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.
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
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.
Here comes the question, how do I propose the tenancy strategy for my product? Here are some important questions to think about:
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.
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!