Ibexlabs recommends these ten terms to understand SaaS on AWS: Source
SaaS has a language of its own and introduces new terms such as Tenant, Isolation, Noisy Neighbor and more. Having standard terms creates understanding between the multiple parties that work on SaaS together, such as an ISV working with Ibexlabs to deploy SaaS on AWS.
The list of baseline SaaS terms that help everyone communicate on the same page are:
A tenant is a paying customer/business who has one or more users. Think of your SaaS platform as an office building with multiple tenants, each tenant has many staff (users).
A tenant is not a individual user account.
“What do you get when you combine a user identity with a tenant identity? A SaaS Identity!”
After authenticating a user, we need to know who the user is as well as which tenant that user is associated with. This merging of the user identity with the tenant identity is referred to as a SaaS identity.
A SaaS identity combines a user identity with a tenant identity.
It is a foundational element of a SaaS architecture, providing the necessary context for implementing multi-tenant policies and strategies.
Tenant isolation ensures that each tenant's resources are protected from unauthorized access and workload hogs. It is crucial in shared infrastructure models to prevent tenants from accessing each other's resources.
As independent software vendors (ISVs) make the shift toward SaaS and adopt a shared infrastructure model to achieve cost and operational efficiency, they also have to take on the challenge of determining how their multi-tenant environments will ensure that each tenant is prevented from accessing another tenant’s resources.
⚠️Crossing tenant isolation boundaries in any form would represent a significant and potentially unrecoverable event for a SaaS business.
SaaS tenants expect a modern, business-to-consumer, “Apple-esque” onboarding procedure that is automated, self-service and works everytime while being as short and as simple as possible.
Tenant onboarding involves the frictionless process of introducing new tenants to a SaaS environment. It often requires orchestrating various components to provision and configure all the necessary elements for a new tenant.
💡It’s important to note that tenant onboarding can be initiated directly by tenants or as part of a provider-managed process.
SaaS solutions can offer different tiers or plans with varying features and pricing. Each tier unlocks different features within the same multi-tenant SaaS solution.
The familiar “Pricing List” image, going left-to-right from lowest cost and features to highest – or “enterprise – is an example of tenant tiers.
Understanding individual tenant activity and consumption is important for billing mechanisms, monitoring resource usage, and providing tailored services. It enables SaaS vendors to charge tenants accurately and gain insights into their usage patterns.
Seeing the overall and average health of your SaaS platform tells you nothing about individual tenants. If you have per-tenant limits – perhaps according to the tier they are on – such as “consumed storage” or “number of users” then you need a per-tenant view of their activity and consumption.
If you are charging tenants in a Pay-As-You-Go pricing model, then per-tenant activity and consumption is at the heart of your billing mechanism. If you can’t see the storage they are using individually, then you can’t charge them individually.
For SaaS on AWS, this is the metering and billing information you will be sending to AWS Marketplace if that’s the fulfilment model you are using.
SaaS vendors should be able to view a tenant's settings and analytics without breaching privacy rules. Tenant-aware operations allow vendors to see the tenant's perspective without compromising confidentiality.
It’s not professional for a SaaS vendor to ask a tenant to “share your screen” to see what the tenant can see.
A noisy neighbor refers to a resource-hogging tenant that negatively impacts the experience of other tenants. SaaS architectures need strategies to manage and minimize the potential impacts of such tenants. One such strategy is to put per-tenant limits on shared resources. Sometimes these are linked to the tenant’s tier, other times they are internal core limites not exposed to tenants.
Data partitioning is a fundamental consideration for managing tenant data in a shared SaaS system. It involves decisions such as deploying separate databases for each tenant or partitioning a large database for multiple tenants.
SaaS architectures can follow different models based on factors like regulations, cost efficiency, and market considerations.
The silo model refers to an architecture where tenants are provided dedicated resources where each tenant of your system has a fully independent infrastructure stack. Or, perhaps each tenant of your system has a separate database.
💡It’s important to note that—even though the silo has dedicated resources—a silo environment still relies on a shared identity, onboarding, and operational experience where all tenants are managed and deployed via a shared construct.
The pool model of SaaS refers to a scenario where tenants share resources. This is the more classic notion of multi-tenancy where tenants rely on shared, scalable infrastructure to achieve economies of scale, manageability, agility, and so on.
The bridge model acknowledges the reality that SaaS businesses aren’t always exclusively silo or pool. Instead, many systems have a mixed mode where some of the system is implemented in a silo model and some is in a pooled model. For example, some microservices in your architecture might be implemented with silo and others might use pool.
The regulatory profile of a service’s data and its noisy neighbor attributes might steer a microservice to a silo model. Meanwhile the agility, access patterns, and cost profile of another microservice could tip it toward a pool model.
Ibexlabs is a team of disruptive thinkers. We support businesses by building scalable, agile, and innovative infrastructure through AWS and DevOps technology. We help companies of all sizes get the most from the cloud and their applications.
