SaaS Deployment Architecture

Your SaaS application is hosted in the cloud, and you have to pay for this. That’s why subscription fees your customers pay must be higher than your cloud hosting spending. Wrong architectural decisions lead to hard-to-manage operational gaps. You may want to make provision for different negative scenarios architecturally.

Advise with a professional SaaS developer

Choosing the deployment architecture for your SaaS solution is not straightforward as you have to consider a variety of business aspects. Your tiered pricing model, customers' usage patterns, and consumption rates must all be factored into the application's architecture model. Advising with an experienced SaaS development company, you can be sure you've chosen the right path.

Selecting a tenancy model isn't just a technical decision, it's also a commercial one. 

The tenant is a purchased instance of your SaaS application or, in other words, a group of cloud resources (such as database space and many more) that each of your customers can use within the quota. You may want to use multitenancy deployment architecture to allow cloud resources, that your SaaS app consumes, to be shared between all your customers. Below are the benefits and risks of different types of deployment architecture.

Multi-Tenancy in SaaS Application Architecture

Multitenancy in SaaS for you as a SaaS owner means that you buy resources from your cloud provider to host your software and then allow your customers to share these resources. For example, potentially millions of tenants could be stored in a single database (resource costs for a single database are quite low).

In a fully multitenant deployment architecture, all components are shared.

Benefits of Fully Multitenant Deployment Architecture

1. Low cost to operate even if you need to deploy more resources globally. You may want to use this type of architecture to decrease your cloud costs when your business scales and you onboard more and more customers. 
2. Cost maintenance is simpler since you only have to update one set of resources. 
3. Do not have to migrate data between two separate deployments and just need to update tenant identifiers and keys, if a user or tenant needs to move their data to another tenant.

Risks of Fully Multitenant Deployment Architecture

1. High risk of data leaks between tenants. Separate data for each tenant carefully.
2. Cloud cost changing affect your entire customer base. Be careful. 
3. Hitting a resource quota limit affects your entire customer base. Consider deploying multiple instances of your resources (for example, multiple storage accounts).
4. Noisy Neighbor problem. Be concerned about the effects that single large tenants can have on other tenants while performing a heavy query or operation. 
5. Non-linear cost increase of scaling to keep up with the demand, especially when you have only a single, shared database.

Automated Single-Tenant Deployment Architecture

In an automated single-tenant deployment model, each tenant has a dedicated set of infrastructure.

Benefits of Automated Single-Tenant Deployment Architecture

1. Low risk of data leakage. Data for each tenant is isolated which is important to customers with high regulatory compliance. 
2. Absence of Noisy Neighbor problem. Tenants don’t affect each other's system performance. 
3. Low risk of system-wide outage due to updates and changes. Ones can be rolled out progressively across tenants.

Risks of Automated Single-Tenant Deployment Architecture

1. Low-cost efficiency. Think about the provision and use a dedicated subscription, per tenant. 
2. Time-consuming ongoing maintenance. Consider automating these processes, as well as other cross-deployment operations, like reporting and analytics across your whole SaaS solution. 

Mixed-Tenancy Deployment Architecture

Some of your customers may want to use more cloud resources your SaaS provides than others, and it’s not correct to cover their spending with the help of others. It's more thoughtful to issue invoices to each subgroup depending on consumed resources. 

SaaS philosophy is to provide the same pool of features and a shared environment. However, some of your clients will want customizations and will be ready to pay for them. Pay well. But these customizations are only be needed by them. Or they will prohibit your other customers to get access to these customizations.  

In a vertically partitioned mixed-tenancy deployment architecture there are shared deployments for some tenants and single-tenant deployments for others.

Benefits of Vertically Partitioned Mixed-Tenancy Deployment Architecture 

Cloud cost benefits because you can deploy cheaper shared resources for trial customers and provide a higher rate for customers who require higher performance or data isolation.

Risks of Vertically Partitioned Mixed-Tenancy Deployment Architecture 

More spending on the codebase because the code needs to be designed to support both multitenant and single-tenant deployments, support migrating customers from a multitenant deployment to a single-tenant one, and help you understand which of your tenants are on which deployments to communicate information about system issues or upgrades to the relevant customers.

In a horizontally partitioned mixed-tenancy deployment architecture, some components of the infrastructure are shared, while others are within single-tenant deployments  (like individual databases).

Benefits of Horizontally Partitioned Mixed-Tenancy Deployment Architecture

Absence of Noisy Neighbor problem. If you've found that some of your tenants send a large number of requests to your SaaS solution and your shared database is overloaded that negatively affects other tenants, you may provide them with separate databases.