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.
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!
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.
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.
There are two concepts that are important for us to understand before starting:
A single-tenant architecture is a siloed model were an organization operates in its own isolated environment. The application is deployed on dedicated infrastructure, hardware, and software ecosystems for each client. This ensures complete data separation and allows extensive customization for individual clients.
A multi-tenant architecture allows multiple organizations to share the same application environment. Here, resources like infrastructure and software are shared, while data remains securely separated. This model is typically more cost-effective and scalable since a single environment can serve multiple clients with centralized updates and maintenance.
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.
Adopting a Multi-tenant architecture approach will bring extensive and valuable benefits to your SaaS application.
Let’s go through the next contributions:
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.
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’ll have one codebase (source of trust) and a code repository with a few branches (dev/test/prod). By following the practices covered below, you will quickly perform the deployment process in a few seconds with a single command (one-click deployment).
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.
To build a multi-tenant architecture, you must integrate the correct AWS web stack into AWS technologies, including OS, language, libraries, and services. 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.
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 technologies for building SaaS applications is Python + React + AWS.
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.
Choosing the right platform is essential for building a multi-tenant architecture that can meet the business’s and its customers’ needs.
You should consider several factors when making 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. Also, look for a pricing structure that aligns with your budget and business model. Evaluate the provider’s services and tools, geographic availability, and customer support.
As a team of DevOps experts, we’ve noticed a cloud variation in the last two years, 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, except that Azure gradually grows 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.
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.
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. It is highly recommended for startups and small and medium SaaS companies.
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 and 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.
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).
Also, 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.
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.
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.
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.
It is essential to include a caching system for your SaaS application. By storing frequently accessed data, it improves performance and reduces latency, enhancing the overall user experience.
AWS ElastiCache is a fully scalable, available, and managed caching and data storage system that 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.
Here’s an example of how our Multi-tenant SaaS Architecture would look like:
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.
This layer is an architectural design that enables tenant hosting and is primarily delivered for Software as a Service application. In this first model the application layer is commonly shared among multiple customers.
The monolithic components include EC2 instances in the web tier, app tier, and Amazon RDS with MySQL for your Database.
With monolithic architecture, you could waste 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.
Pros of SaaS Monolithic Architecture
Cons of SaaS Monolithic Architecture
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). You can use the formula of Multi-tenant architecture + AWS Services + Microservices + Amazon ECS as the container orchestrator; they can be the perfect match.
Prof of Micorservice Multitenat Architecture
Cons of Micorservice Multitenat Architecture
Provides the use of namespaces. This attribute aids in isolating every tenant and its environment within the corresponding Kubernetes cluster, so you don’t have to create different clusters per tenant.
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, as these platforms allow you to make more granular changes.
Pros of Kubernetes Multitenant Architecture
Cons of Kubernetes Multitenant Architecture
Here is a simple Kubernetes Multi-tenant architecture siloed by its respective namespaces.
A Serverless SaaS architecture enables applications to obtain more agility, resilience, and fewer development efforts, a truly NoOps ecosystem.
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.
Pros of serverless multiteant Architecture
Cons of serverless multiteant Architecture
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 easiest and cost-effective multi-tenant database architecture is the pure and real database multitenancy.
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:
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 for the architect and design.
Pros of the single database: A Table per tenant
Cons of the single database: A Table 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.
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, computing, and storage across all its tenants. As a result, it provokes noisy tenants that utilize more resources than expected.
Pros of single database: A schema per tenant
Cons of single database: A schema per tenant
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.
Pros of database server per tenant
Cons of database server per tenant
For organizations with high demands in scalability and data isolation, multiple database approaches provide a more flexible and reliable solution. These strategies involve distributing tenants across multiple databases, which can be advantageous for scaling and managing tenant-specific workloads.
In this approach, tenants are split across multiple databases, with each database hosting a subset of tenants. This method balances the need for isolation and cost efficiency. It’s ideal for situations where tenants are grouped based on characteristics like size or activity level.
The partitioning process can also be automated based on the load, ensuring better performance and data isolation. However, this method still shares database resources across multiple tenants, making it slightly less secure than fully siloed architectures.
Sharding involves distributing tenant data across multiple databases (or “shards”) based on a sharding key, such as tenant ID. This method allows horizontal scaling, where you can add more databases as the number of tenants grows, significantly improving both performance and scalability. Sharded databases can also provide better isolation compared to single database models, though they require careful management of data consistency and cross-shard operations.
A federated database system uses multiple databases that work together, presenting a unified view to the application layer. This approach enables greater scalability and flexibility, especially for large SaaS applications serving diverse tenant needs. Each database could be optimized for different types of workloads or compliance requirements, allowing more specialized management while still maintaining a centralized control structure.
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.
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:
Previous code suggestions could change depending on the architecture.
Every organization must have its 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:
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.
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.
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.
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:
Now, to emphasize automation and operational efficiency, the following best practices will help you streamline deployment processes, tenant management, and resource cleanup:
Continuous Integration and Deployment for multi-tenant architecture
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? for a multi-tenant architecture
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:
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 for Tenant Management
Note: Ensure you utilize Infrastructure as Code principles in this aspect.
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:
It refers to the allocated computational resources for each tenant in a multi-tenant application. Each tenant requires a certain amount of computing capacity to process their requests and execute tasks within the application.
What should we do with the tenants who are idle or not used anymore? 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.
In a multi-tenant SaaS architecture, securing data and maintaining tenant privacy are essential. Each tenant’s data must be isolated and protected to ensure compliance with regulations.
Key practices include:
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.
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.
This blog is also available on our DZone profile.
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.
Have you ever wondered how companies create customized AI solutions that captivate customers? The answer…
Learning how to integrate AI into an app might be one of the smartest business…
The last few years have really shown us what's possible with Artificial intelligence. If you're…
2024 is ending, and that only means one thing: ClickIT’s year in review! This year…
Have you ever wondered how businesses easily process enormous volumes of data, derive valuable insights,…
Discover the steps for developing cloud applications, from costs to cloud app deployment