A Multi tenant Architecture is the key to unlocking the potential of SaaS applications, which are the new normal nowadays. Software providers are looking to transform their applications, and multi-tenancy is here to make it happen.
Have you ever wondered how Slack, Salesforce, AWS (Amazon Web Services), and Zendesk can serve multiple organizations? Does each one have its unique and custom cloud software per customer? For example, have you ever noticed that, on Slack, you have your own URL ‘yourcompanyname.slack.com’?
Most people think that in the background, they created a particular environment for each organization –application or codebase–, and believe that Slack customers have their own server/app environment. Well, the real solution is a Multi tenant architecture on AWS for a SaaS application.
Multi tenant architecture is so important that it has contributed to the success of some of the world’s largest SaaS companies. For example, Salesforce’s stock market cap is over $200 billion, and this is partly due to its Multi tenant architecture that has allowed it to serve numerous customers efficiently.
The following research is intended to showcase an overview of the strategies, challenges, and constraints that DevOps and Software Developers can face when architecting a SaaS multi-tenant application. Let’s begin!
There are two concepts that are important for us to understand before starting: Tenant and User.
Table of contents
- What is Multi tenant Architecture?
- SaaS Technology Stack for an Architecture on AWS
- Types of Multi tenant SaaS Architecture
- Application Code Changes
- Python Django Multi-tenancy in a Nutshell
- Wildcard DNS Subdomain: URL-based SaaS Platform
- Multi-tenant SaaS Architecture Best Practices
- Final Thoughts of Multi tenant SaaS Architecture
What is Multi tenant Architecture?
A Multi tenant architecture is an ecosystem or model in which a single environment can serve multiple tenants utilizing a scalable, available, and resilient architecture. The underlying infrastructure is completely shared, logically isolated, and with fully centralized services. The multi tenant architecture evolves according to the organization or subdomain (organization.saas.com) that is logged into the SaaS application and is transparent to the end user.
To go deep into what a multi tenant architecture is, it’s also important to understand what a single tenant architecture consists of.
A single-tenant architecture (siloed model) is a single architecture per organization where the application has its own infrastructure, hardware, and software ecosystem. Let’s say you have ten organizations; in this case, you need to create ten standalone environments, and your SaaS application or company will function as a single tenant architecture. Additionally, it implies more costs, more maintenance, and a level of difficulty to update across the environments.
Bear in mind that this paper will discuss two Multi tenant architecture models, one for the application layer and one for the database layer. Visit this blog to extend knowledge around Single Tenant vs Multi Tenant.
Multi-tenant Architecture Benefits
Adopting a Multi-tenant architecture approach will bring extensive and valuable benefits to your SaaS application.
Let’s go through the next contributions:
a) Reducing server Infrastructure costs utilizing a multi tenant architecture strategy.
Instead of creating a SaaS environment per customer, you include one application environment for all your customers. This enables your AWS hosting costs to be dramatically reduced from hundreds of servers to a single one.
b) One single source of trust.
Let’s say again you have a customer using your SaaS. How many code repositories would you have per customer? At least 3-4 branches per customer. Which would mean a lot of overhead and misaligned code releases. Even worse, visualize deploying your code to the entire farm of tenants; it is extremely complicated. This is unviable and time-consuming.
With a multi tenant SaaS architecture, you avoid this type of conflict, where you’ll have one codebase (source of trust) and a code repository with a few branches (dev/test/prod). By following the practices covered below – with a single command (one-click-deployment)– you will quickly perform the deployment process in a few seconds.
c) Cost reductions of development and time-to-market.
Cost reduction considers a sequence of decisions to make, such as having a single codebase, a SaaS platform environment, a multi-tenant database architecture, centralized storage, APIs, and following The Twelve-Factor Methodology. These steps will allow you to reduce development labor costs, time-to-market, and operational efficiencies.
The 12-factor methodology represents pure DevOps and cloud-native principles, including immutable infrastructure, dev/test and prod parity with Docker, CI/CD principles, stateless SaaS applications, and more.
SaaS Technology Stack for an Architecture on AWS
In order to build a multi tenant architecture, you need to integrate the correct AWS web stack, including OS, language, libraries, and services into AWS technologies. This is just the first step towards creating a next-generation multi tenant architecture.
Check out The Perfect AWS SaaS Tech Stack if you haven’t chosen your web stack. Even though we will surface a few other multi-tenant architecture best practices, this article will be primarily oriented to this AWS SaaS web stack.
Let’s dive into our SaaS Technology Stack on AWS:
Programming language
What is vital here is that your application can scale and is able to follow multi-tenant architecture best practices, cloud-native principles, and a well-known language by the open-source community. The latest trend for building SaaS applications is Python + React + AWS. Another “variant” is Node.js + React + AWS, but in the end, the common denominators are always AWS and React. If you are a financial company, ML or AI, with complex algorithms or backend work, you should go for Python.
On the other hand, if you use modern technologies like real-time chats, mini feeds, streaming, etc., Node.js is a great option. If you want to learn more about it, check out this blog about the Basics of Multi tenant Node.js and PostgreSQL, where you’ll find valuable information about this topic. There is a market in the banking sector leveraging Java, but that’s for established enterprises. Any new SaaS application might work better with the mentioned web stack. As you can see, many options adapt to each application’s unique requirements; this web stack is just a popular and trending choice.
Note: This data comes from a survey performed for Financial Services and SaaS companies.
Ideal languages:
Cloud Provider
Choosing the right platform is essential for building a multi-tenant architecture that can meet the needs of both the business and its customers.
You should consider several factors for your decision. Firstly, the provider’s infrastructure must be scalable to fit the growing number of tenants and their resource demands.
Make sure to prioritize providers with robust security measures, compliance certifications, and data encryption capabilities. With a pricing structure that aligns with your budget and business model. And evaluate its services and tools, as well as its geographic availability and customer support.
As a team of DevOps experts, we’ve noticed a cloud variation in the last two years, and which corresponds to these percentages: 70% of our DevOps implementations are based on AWS, 25% with Azure, and 5% go to GCP and Digital Ocean. Each year the trend is similar, with the exception that Azure is gradually growing with the years.
Deploying your SaaS application under AWS has several benefits; a new service is available regularly, and a new feature facilitates your development and deployment.
Microservices
If you are planning to leverage the cloud, consider incorporating microservices with Docker. Building your SaaS application under microservices brings multiple benefits, including flexibility and standardization, easier troubleshooting, problem isolation, and portability. Like the cloud, Docker and microservices benefits have transformed the IT ecosystem and will stay for a while.
Container Orchestration Platform
This is a complicated and abstract decision; there are three options in AWS to manage, orchestrate, and create a microservice cluster environment.
Amazon ECS
It is the natural container orchestration system in the AWS ecosystem. Highly recommended for startups, as well as small and medium SaaS.
Amazon Fargate
It’s considered almost serverless. Price and management are per task. Minimal operational effort compared to ECS. Some studies show that Fargate can be slower than ECS, so Amazon ECS is more recommended for this particular case than Fargate. Another thought is that if your team is pure developers and not planning to hire a DevOps engineer, perhaps Fargate is the way to go.
Amazon EKS
It is a managed service that makes Kubernetes on AWS easy to manage. You can use Amazon EKS instead of deploying a Kubernetes cluster on an EC2 instance, set up the Kubernetes networking, and worker nodes. It’s recommended for large SaaS apps and a sophisticated DevOps and web development team. For further information, read about the best practices you should consider for your Kubernetes Multi tenancy SaaS application with Amazon EKS.
Which is the best? What shall you use? This blog explains the main differences, pros, and cons of Kubernetes vs Amazon ECS; which is the best for container orchestration?
If you’re looking for a hint, Amazon ECS is a good option thanks to its efficient resource optimization, simplified infrastructure management, and improved application availability.
Database
The inherent database will be PostgreSQL with Amazon RDS. However, MongoDB is strongly recommended if you have a senior development team projecting high traffic for your SaaS application, even hundreds of tenants. In addition to this, utilize the best practices that will be mentioned below for a multi-tenant database. For this stack, I would go for Amazon RDS with PostgreSQL or DynamoDB (MongoDB).
GraphQL or Amazon AppSync
GraphQL is a query language and an alternative to a RESTful API for your database services. This new and modern ecosystem is adopted as a middleman between the client and the database server. It allows you to retrieve database data faster, mitigate the over-fetching in databases, retrieve the accurate data needed from the GraphQL Schema, and mainly the speed of development by iterating more quickly than a RESTful service.
Adopting a monolithic backend application into a Multi tenant microservice architecture is the perfect time to leverage GraphQL or AppSync. Hence, when transforming your SaaS application, don’t forget to include GraphQL.
Note: This service isn’t included in the AWS SaaS architecture diagram below because it is implemented in multiple ways.
Infrastructure as Code and Automation
You need a mechanism to trigger or launch new tenants/organizations and attach it to your multi tenant SaaS architecture. Let’s say you have a new client that just subscribed to your SaaS application. How do you include this new organization in your environment, database, and business logic? You need an automated process to launch new tenants called Infrastructure as Code (IaC). This script/procedure should live within a Git/Bitbucket repository, one of the fundamental DevOps principles. A strong argument for leveraging Automation and IaC is that you need a mechanism to automate your SaaS application for your code deployments. Along the same lines, automate the provisioning of new Infrastructure for your Dev/Test environments.
Which Infrastructure as Code Tool are you using? Two popular options are Terraform and CloudFormation. Overall, they do the same job and are well-known in the DevOps community. However, if you want to know more about the advantages and disadvantages of each of them, I recommend this blog about Terraform vs Amazon CloudFormation.
Terraform (from Hashicorp). A popular Cloud-agnostic tool. Used widely for all DevOps communities.
Amazon CloudFormation. Integrating with Amazon Web Services, AWS built-in Automation tool is easier. Whenever a new Amazon technology is released, compatibility with AWS and CloudFormation is released sooner than Terraform.
Message Queue System (MQS)
There are multiple times when you’ll need asynchronous communication, from delaying or scheduling a task to increasing reliability and persistence with critical web transactions, decoupling your monolithic or micro-service application, and, most importantly, using a Queue System to communicate Event-driven Serverless applications (Amazon Lambda functions).The common MQS are Amazon SQS, RabbitMQ, or Celery. You can choose the service that requires less operation. In this case, it is Amazon SQS.
Caching System
It is essential to include a caching system for your SaaS application, as it improves performance and reduces latency by storing frequently accessed data, enhancing the overall user experience.
AWS ElastiCache is a caching and data storage system that is fully scalable, available, and managed. It aims to improve the application performance of distributed cache data and in-memory data structure stores. It’s an in-memory key-value store for Memcached and Redis engines. With a few clicks, you can run this AWS component entirely self-managed.
Cloud Storage System
A system like Amazon S3 and Amazon CloudFront CDN ensures high availability, improves performance, and reduces latency by efficiently storing and delivering static and dynamic content to users globally. All static content, including images, media, and HTML, can be hosted on Amazon S3, –the cloud system with infinite storage and elasticity. In front of Amazon S3 we will include AWS CloudFront; integrating this pair of elements is vital, in order to cache the entire static content and reduce bandwidth costs.
SaaS Web Stack: Multi tenant SaaS Architecture Example on AWS
Types of Multi tenant SaaS Architecture
One of the most important questions regarding multitenant adoption would be which Multitenant architecture is better suited for your SaaS Application on AWS. We will explore the two layers needed to enable your application to act as a real SaaS platform. These two types of multi-tenant architectures are the Application layer Multi-tenancy and the Database layer Multi-tenancy.
The Application Layer Multi-tenancy
This layer is an architectural design that enables tenant hosting and is primarily delivered for Software as a Service applications. In this first model the application layer is commonly shared among multiple customers.
Now, we’ll cover some of the multi-tenant strategies within that layer, including approaches such as monolithic, microservices, and serverless architectures, each offering unique benefits and considerations for implementing multi-tenancy in SaaS applications.
Monolithic architecture for SaaS
Probably, if you haven’t seen this article before –or if you have already developed and architected your own SaaS application– you might have fallen into this approach. The monolithic components include EC2 instances in the web tier, app tier, and Amazon RDS with MySQL for your Database. Monolithic architecture is not a bad approach, except that you could be wasting resources massively in the mentioned tiers. At least around 50% and 70% of your CPU/RAM usage is wasted due to the nature of the monolithic (cloud) architecture.
Monolithic Architecture Diagram
Microservices Architecture for SaaS with containers and Amazon ECS
Microservices are a recommended architecture type since they balance modernization and maximum use of available cloud resources (EC2 instances and compute units). As well as it introduces a decomposed system with more granular services (microservices). We won’t touch much about the Microservice benefits since it’s widely expressed in the community. However, you can use the formula of Multi tenant architecture + AWS Services + Microservices + Amazon ECS as the container orchestrator; they can be the perfect match. Mainly, consider that Amazon ECS puts less effort into configuring your cluster and more NoOps for your DevOps team.
With a talented team, this use case scenario is the best Multi-tenant SaaS architecture approach. Along the same lines, it covers the SaaS software and architecture’s main attributes, including agility, innovation, repeatability, reduced cycle time, cost efficiency, and manageability.
Microservices Architecture Diagram
Kubernetes Architecture for SaaS with Amazon EKS
You might be wondering now, what about Kubernetes or Amazon EKS? Kubernetes is another alternative to microservice architecture that adds an extra layer of complexity to the SaaS equation. However, you can overcome this complexity by leveraging Amazon EKS, the managed Kubernetes service from Amazon, a de facto service by the Kubernetes community.
What highlights this component from the rest of the architectures is that it provides the use of namespaces. This attribute aids in isolating every tenant and its environment within the corresponding Kubernetes cluster. In this sense, you don’t have to create different clusters per tenant (you could, but to follow a different approach). By using ResourceQuota you can limit the resources used per namespace and avoid creating noise to the other tenants. Another point to consider is that if you want to isolate your namespaces, you need to include Kubernetes Network policies because the networking is open by default and can communicate across namespaces and containers.
If you have a SaaS enterprise, we recommend that you control your microservice via Amazon EKS or Kubernetes since it allows you to make more granular changes.
Kubernetes Architecture Diagram
So, what would a Kubernetes Multi tenant architecture look like? Here is a simple Kubernetes Multi-tenant architecture siloed by its respective namespaces.
Serverless Architecture for SaaS on AWS
Any AWS architect can dream about creating a multi tenant SaaS architecture with a Serverless approach, which can be achieved if there’s an understanding of how it requires a reasonable amount of collaboration time with your dev team, extensive changes of code application, and a transformative Serverless mindset. Given that, in a few years, it might be a viable solution, and it all depends on the talent, capabilities, and use case.
A Serverless SaaS architecture enables applications to obtain more agility, resilience, and fewer development efforts, a truly NoOps ecosystem. Serverless is disrupting the IT stack, and you still on-premises? Go through this paper I created a few months ago which shows more details about the serverless ecosystem.
At a high level, what are the new parts of this next-generation serverless SaaS architecture? Every call becomes an isolated tenant call, either going to a logical service (Lambda function) or going to the database data coming from the Amazon API Gateway as an entry point in the serverless SaaS application.
After decoupling every logical service, the authentication and authorization module needs to be handled by a third-party service like Amazon Cognito, which will be in charge of identifying the tenant, user, tier, and IAM tenant role and bring back an STS token with these aspects. In particular, the API Gateway will route all the tenant functions to the correct Lambda functions that match the STS Token.
Serverless Architecture Diagram
Here is a diagram of a multi tenant architecture example for AWS SaaS applications that use serverless.
Serverless vs Containers: Don’t miss the full debate.
The Database Layer Multi-tenancy
The multi-tenancy concept comes with different architectural layers. We have already advocated the multi-tenancy application layer and its variants. Now, it is time to explore multi-tenancy in the Database layer, another aspect to discover. Paradoxically, the easiest and cost-effective multi tenant database architecture is the pure and real database multitenancy.The Database layer is the opposite of the previous model, the application layer. Over here, the DB layer is kept in common among tenants, and the application layer is isolated. As a next step, you need to evaluate what Multitenant database architecture to pursue with tables, schemas, or siloed databases.
When choosing your database architecture, there are multiple criteria to assess: Scalability (number of tenants, storage per tenant, workload), tenant isolation, database costs (per tenant costs), development complexity (changes in schemas, queries, etc.), and operational complexity (database clustering, update tenant data, database administration, and maintenance).
Single database: A table per tenant
A table per tenant single database refers to a pure database multi-tenancy and pooled model. This database architecture is the common and the default solution by DevOps or software architects. It is very cost-effective when having a small startup or a few dozen organizations. It consists of leveraging a table per each organization within a database schema.
This architecture has specific trade-offs, including the sacrifice of data isolation, noise among tenants, and performance degradation, meaning that one tenant can overuse computing and RAM resources from another. Lastly, every table name has its tenantID, which is very straightforward to design and architect.
Regarding data isolation and compliance, let’s say that one of your developers makes a mistake and brings the wrong tenant information to your customer. Imagine the data breach! Please ensure that you never expose information from more than one tenant. That’s why compliant SaaS applications are crucial; this architecture model is not very recommended. However, it is used because of its cost-effectiveness.
Alternative single-tenant database architecture: a shared table in a single schema in a single database. Perfect for DynamoDB.
Single Database: A schema per tenant
A schema per tenant single database, also known as the bridge model, is a multi-tenant database approach that is still very cost-effective and more secure than the pure tenancy (DB pooled model). Since you are with a single database, with the exception of the database schema isolation per tenant. If you are concerned about data partitioning, this solution is slightly better than the previous one (a table per tenant). Similarly, it is simple to manage across multiple schemas in your application code configuration.
One important distinction is that with more than 100 schemas or tenants within a database, it can provoke a lag in your database performance. Hence, it is recommended to split the database into two (add the second database as a replica). However, the best database tool for this approach is PostgreSQL, which supports multiple schemas without much complexity. And lastly, this strategy of a schema per tenant shares resources, compute, and storage across all its tenants. As a result, it provokes noisy tenants that utilize more resources than expected.
Database Server Per Tenant
Also called the Siloed model, where you need a database instance per customer. Expensive, but the best for isolation and security compliance. This technique is significantly more costly than the rest of multi-tenant database architectures, but it complies with security regulations, which is the best for performance, scalability, and data isolation. This pattern uses one database server per tenant, meaning that if the SaaS app has 100 tenants, there will be 100 database servers, which is extremely costly.
When PCI, HIPAA, or SOC2 is needed, it is vital to utilize a database siloed model, or at least find a workaround with the correct IAM roles and the best container orchestration –either Kubernetes or Amazon ECS namespaces–, a VPC per tenant and encryption everywhere.
Multi tenant Database Architecture Tools
- Amazon RDS with PostgreSQL (best option).
- DynamoDB (a great option for a single-tenant database with a single shared table).
- Amazon RDS with MySQL.
- GraphQL. As described previously, use it in front of any of these databases to increase speed on data retrieval, speed on development, and an alternative to RESTful API, which helps to relieve requests from the backed servers to the client.
Application Code Changes
Once you have selected your multi tenant strategy for every layer, let’s start considering what is needed in terms of code changes. Suppose you have decided to adopt Django (from Python) for your SaaS application. In that case, you need a few tweaks and changes to align your current application with your multi tenant architecture from the database and application layer.
Fortunately, web application languages and frameworks can capture the URL or subdomain from the request. Obtaining this information (subdomain) at runtime is critical to handling dynamic subdomains for your Multi-tenant architecture. We won’t cover in-depth what lines of codes we need to include in your Django application, but we’ll review what items should be considered in this section.
The full insights on Django and the Python debate of the year: Flask vs Django.
Python Django Multi-tenancy in a Nutshell
Implementing multi-tenancy in a Python Django application involves creating a system where a single instance can serve multiple tenants, each with its own isolated resources and data. Here’s one common approach:
- Add an app called tenant.py, a class for tenantAwareModel with multiple pool classes.
- How to identify tenants? You need to give each tenant a subdomain; to do so, you need to modify a few DNS changes, Nginx/Apache tweaks, and add a utility method (utils.py). Now, whenever you have a request, you can use this method to get the tenant.
- Determine how to extract the tenant utilizing the host header (subdomain).
- Admin isolation.
Previous code suggestions could change depending on the architecture.
Wildcard DNS Subdomain: URL-based SaaS Platform
Basically, every organization must have its own subdomain, and they are quite useful for identifying organizations. Per tenant, it is a unique dedicated space, environment, and custom application (at least logically); for example, ‘org1.saas.com’, ‘org2.saas.com’, and so on. This URL structure will dynamically provision your SaaS multi-tenant application, and this DNS change will facilitate every tenant’s identification, authentication, and authorization. However, another workaround is path-based per tenant, which is not recommended, for example, ‘app.saas.com/org1/…’, ‘app.saas.com/org2\…’, and so on.
So, the following is required in this particular section:
- A wildcard record should be included in your DNS management records.
- This wildcard subdomain redirects all routes to your Multi-tenant architecture (either to the load balancer, application server, or cluster end-point).
- Similarly, a CNAME record labeled (*) pointing to your ‘app.saas.com’ or ‘saas.com/login’. An asterisk (*) means a wildcard to your app domain.
- As a final step, another (A) record pointing your ‘app.saas.com’ domain to your Amazon ECS cluster, ALB, or IP.
DNS Records entries
*.saas.com CNAME ‘app.saas.com
app.saas.com A 1.2.3.4 OR app.saas.com A (alias) balancer.us-east-1.elb.amazonaws.co
Note: An (A) Alias record is when utilizing an ALB/ELB (Load Balancer) from AWS.
Web Server Setup with NGINX Configuration
Let’s move down to your web server, specifically Nginx. In this stage, you will need to configure your Nginx.conf and server blocks (virtual hosts). Set up a wildcard vhost for your Nginx web server. Make sure it is an alias (ServerAlias) and a catch-all wildcard site. You don’t have to create a subdomain VirtualHost in Nginx per tenant; instead, you must set up a single wildcard VirtualHost for all your tenants. Naturally, the wildcard pattern will match your subdomains and route accordingly to the correct and unique patch of your SaaS app document root.
For further information, I highly recommend this blog that talks about how enterprises can use Apache Multi tenant and Nginx Multi tenant to support SaaS applications. You’ll find valuable information about how Nginx Multitenancy and Apache Multitenancy can be achieved along with their respective DNS wildcard records.
SSL Certificates
Just don’t forget to deal with the certificates under your tenant subdomains. You must add them either in the CloudFront CDN, load balancer, or your web server.
Note: This solution can be accomplished using the Apache webserver.
Multi-tenant SaaS Architecture Best Practices
Building a scalable app can foster a seamless and sustainable user experience as the business expands. By efficiently adjusting resources based on demand, your app can handle larger workloads without sacrificing performance or reliability.
How is your SaaS platform going to scale? Here are the best practices for a multi tenant SaaS architecture, focusing on infrastructure and resource management:
- Amazon AutoScaling, either with EC2 instances or microservices.
- Database replication with Amazon RDS, Amazon Aurora or DynamoDB.
- Application Load Balancer.
- Including a CloudFront CDN for your static content.
- Amazon S3 for all your static/media content.
- Caching system including Redis/Memcached or its equivalent in the AWS cloud – Amazon ElastiCache.
- Multi-availability zone set up for redundancy and availability.
Now, to emphasize automation and operational efficiency, the following best practices will help you streamline deployment processes, tenant management, and resource cleanup:
Code Deployments with CI/CD
Another crucial aspect to consider is how to deploy your code releases across tenants and your multiple environments (dev, test, and prod). You will need a Continuous Integration and Continuous Delivery (CI/CD) process to streamline your code releases across all environments and tenants. If you follow up on the previous best practices, it won’t be difficult.
The CI/CD practices are another world your DevOps team needs to familiarize themselves with. CI/CD is one of the five principles of DevOps practices and is crucial for a multi-tenant architecture because it enables rapid and reliable delivery of updates and enhancements to the SaaS application while maintaining the integrity and stability of the system across all tenants.
What tools to embrace CI/CD?
Jenkins, CircleCi, or AWS Code pipelines (along with Codebuild and CodeDeploy) are great, reliable, and popular CI/CD tools.
Our advice: If you want a sophisticated DevOps team and a widely known tool, go for Jenkins; otherwise, go for CircleCI. If you want to keep leveraging AWS technologies exclusively, go for AWS CodePipeline. But if you’re looking for compliance, banks, or regulated environments, go for Gitlab.
In this video, I explain the benefits of CI/CD and the importance of using a CI/CD in place:
DevOps Automation: Automate your New Tenant Creation Process
How are you creating new tenants per subscription? Identify the process of launching new tenants into your SaaS environment. You need to trigger a script to launch or attach the new Multi tenant environment to your existing Multi-tenant architecture, to automate the setup of new tenants. Consider that it can be after your customer gets registered on your onboarding page, or you need to trigger the script manually.
Popular DevOps Automation Tools
- Terraform (Recommended)
- Amazon CloudFormation
- Ansible
Note: Ensure you utilize Infrastructure As Code principles in this aspect.
Siloed Compute and Siloed Storage
How will your architecture be isolated from other tenants? You just need to identify the next: Every layer of the SaaS application needs to be isolated. The customer workflow touches multiple layers, pages, backend, networking, front-end, storage, and more bits. So, how is your isolation strategy?
Take in mind the next aspect:
- IAM Roles per function or microservices.
- Amazon S3 security policies.
- VPC isolation.
- Amazon ECS / Kubernetes Namespace isolation.
- Database isolation (tenant per table/schema/silo database)
Tenant Compute Capacity
It refers to the allocated computational resources for each tenant in a multi-tenant application. Each tenant requires a certain amount of compute capacity to process their requests and execute tasks within the application.
Have you considered how many SaaS tenants it can support per environment? Just think, you have 99 tenants, compute/database load is almost to the limits. Do you have a ready environment to support the new tenants? What about the databases?
Improving tenant compute capacity involves ensuring that each tenant has sufficient resources to operate efficiently without impacting the performance of other tenants. This may include provisioning dedicated virtual machines, containers, or serverless resources for each tenant, depending on the architecture of the application.
Tenant Clean-up
What are you doing with the tenants that are idle or not used anymore? Perhaps an automated clean-up process for any tenant that has been inactive for a prolonged period or removes unused resources and tenants by hand.
Tenant clean-up involves the process of managing and deallocating resources that are no longer in use by a tenant in a multi-tenant application. It is essential for optimizing resource utilization, reducing costs, and maintaining system hygiene in a multi tenant architecture.
Your clean-up process will involve setting up scripts or using cloud-native tools like AWS Lambda functions to monitor resource usage and automatically release resources that exceed predefined thresholds or have been inactive for a certain period. Download our slideshow to have an overview of the Best Practices of Multi-tenant SaaS Architecture.
Final Thoughts of Multi tenant SaaS Architecture
Multi tenant architecture and SaaS applications under AWS, what a topic we just discovered! Now you understand the whole Multi tenant SaaS architecture cycle from end-to-end, including server configuration, code, and what architecture pursues per every IT layer. As you can notice, there is no global solution for this ecosystem. There are multiple variants per each IT layer, either all fully multi-tenant, partially tenant, or just silo tenants. It depends more on what you need, your budget, complexity, and the expertise of your DevOps team.
I strongly recommend going for microservices (ECS/EKS), partially multi tenant SaaS in the app, and database layer. As well as include cloud-native principles. Finally, adopt the multi-tenant architecture best practices and considerations described in this article. That being said, brainstorm your AWS SaaS architecture by thinking about gaining agility, cost-efficiency, IT labor costs, and leveraging a nearshore collaboration model (which adds another layer of value).
If you ever need a hand on how to architect your SaaS platform, execute the whole AWS/DevOps projects, and follow these principles, or you’re looking for a DevOps engineer to fulfill your DevOps needs, just contact us. We help enterprises run their DevOps embracement successfully.
ClickIT is an AWS Advanced Partner with multiple AWS Certifications, expertise in building SaaS architectures and cloud-native applications, and working with technologies like PHP Laravel, React, Angular, NodeJS, Python, Go, Ruby, and Java.
This blog is also available on our DZone profile.
FAQs (Frequently Asked Questions)
A single tenant is an architecture where a single instance serves a customer. In a single tenant architecture, tenants don’t share the database or application between them because they have their own.
Multi tenancy refers to a software operation mode in which every instance serves multiple tenants in an environment that is shared but logically isolated and with fully centralized services.
Multi tenant architecture is a software architecture in which a single environment can serve multiple tenants using a scalable and resilient architecture. A Multi tenant architecture means all users share the same database, resources, and application information.
Software as a Service (SaaS) is a cloud-based distribution model that provides on-demand applications over the Internet using a web browser. It also has the advantage of not managing the installation or the infrastructure that supports the application hosted by the cloud providers.
A SaaS application is a software application hosted in the cloud rather than physically installed on the computer. It has benefits like automatic software updates, better security, and cost reduction.
In a single-tenant architecture, each customer or tenant has their own dedicated instance of the application and infrastructure, providing isolated resources and data. A multi-tenant architecture serves multiple customers or tenants from a shared instance of the application and infrastructure, enabling resource sharing and economies of scale.
