Table of content
- What is a Multi tenant Architecture?
- Types of Multi tenant SaaS architectures
- Application Code Changes
SaaS applications are the new normal nowadays, and software providers are looking to transform their web applications into a Software As a Service application. For this, the only solution is to build a Multi tenant architecture SaaS application. 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. If this is you, you might have assumed that they have a repeatable process to run thousands of apps across all their customers. Well, definitely No. And the real solution is a Multi tenant architecture on AWS for a SaaS application.
Let’s start with this impressive fact: 70% of all web applications are considered SaaS applications according to IDC Research. So, if you know about SaaS architecture and multi-tenant, you are probably covering 70% of the web application architecture landscape that would be available in the future.
“70% of all Web Apps are SaaS, but only a few of them are multi-tenant”
This research is intended to showcase an overview of the strategies, challenges and constraints that DevOps and Software Developers are likely to face when architecting a SaaS multi-tenant application.
There are two concepts that are important for us to understand before starting
The next points are what we will explore in a Multi tenant architecture for your SaaS application, and my contributions will be:
What is Multi tenant Architecture?
First of all, you need to understand what a single tenant architecture and a Multi tenant architecture is. Single Tenant vs Multi Tenant: SaaS Architecture.
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 would 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.
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 totally transparent to the end-user.
Bear in mind that in this paper, we will discuss two Multi tenant architecture models, one for the application layer and one for the database layer. Visit this text in order to extend knowledge around Single Tenant vs Multi Tenant.
The adoption of a Multi tenant architecture approach will bring extensive valuable benefits for your SaaS application.
Let’s go through the next contributions:
a) A reduction of 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, imagine how many code repositories you would have per customer? At least 3-4 branches per customer, which would be a lot of overhead and misaligned code releases. Even worse, visualize the process of 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 below practices, –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 application environment, a multi-tenant database architecture, a centralized storage, APIs, and following The Twelve-Factor Methodology; all of them will allow you to reduce development labor costs, time-to-market, and operational efficiencies.
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 to AWS technologies. This is just the first step towards creating a next-generation multi tenant architecture.
In case you haven’t chosen your web stack, hereafter, I’ll suggest you The Perfect AWS SaaS Tech 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:
It doesn’t really matter which language platform you select. What is vital is that your application can scale, able to utilize multi-tenant architecture best practices, cloud-native principles, and a well-known language by the open-source community. The latest trends to build SaaS applications are 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, I’ll say you should go for Python.
On the other hand, if you are using modern technologies like real-time chats, mini feeds, streaming, etc.; then go for Node.js. If you want to learn more about it, I recommend 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 that is leveraging Java, but that’s for established enterprises. Any new SaaS application better goes with the mentioned web stack. Again, this is just what I’ve noticed as a trend, and what the community is demanding.
Note: This data comes from a survey that we performed a few months ago for Financial Services and SaaS companies.
Python – Node.js – Java – React – Go
As a team of DevOps experts, I’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. Those are not only my words but also ideas supported by multiple DevOps Partners. So, I strongly recommend deploying your SaaS application under AWS. It has a number of benefits; every day there is a new service available for you, and a new feature that facilitates your development and deployment. Totally recommended to deploy your SaaS on AWS.
Why Build SaaS on AWS multi-tenancy?
Because the AWS Cloud is essential to perform the digital transformation. Over here, you’ll be able to find more details about Why Build SaaS on AWS.
If you are planning to leverage the cloud, you must leverage cloud-native principles. One of these principles is to incorporate microservices with Docker. Make sure that your SaaS application is under microservices, which brings multiple benefits, including flexibility and standardization, easier to troubleshoot, problems isolation, and portability. Just like the cloud, Docker and microservices have transformed the IT ecosystem and will stay for a long 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. But before the explanation, I want to recommend you this article about Amazon ECS vs EKS that will help you make the right decision!
Amazon ECS. It is the natural Amazon container orchestration system in the AWS ecosystem. (Highly recommended for startups, small SaaS, and medium SaaS).
Amazon Fargate. Almost Serverless, price, and management is per task. Minimal operational effort vs. ECS. There are some studies conducted by our DevOps team; in terms of performance. Fargate can be slower than ECS, so for this particular case, I would recommend Amazon ECS, instead of 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. Use Amazon EKS instead of deploying a Kubernetes cluster on an EC2 instance, set up the Kubernetes networking, and worker nodes. (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 EK.
Which is the best? What shall you use? In this blog, I explain the main differences, pros, and cons of Kubernetes vs Amazon ECS; which is the best container orchestration?
Looking for a hint? In the end, we chose Amazon ECS
The inherent database will be PostgreSQL with Amazon RDS. However, I strongly recommend that if you have a senior development team, and are projecting a high-traffic for your SaaS application, –or even hundreds of tenants–, you’d better architect your database with MongoDB. In addition to this, utilize the best practices that will be mentioned below about Multi tenant Database. In this case, I would go for Amazon RDS with PostgreSQL or DynamoDB (Mongodb).
“If you are projecting a high-traffic for your SaaS application, you’d better architect your database with 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 among 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: I didn’t include this service in the AWS SaaS architecture diagram, because it is implemented in multiple ways, and it would require an in-depth explanation on this topic.
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 inside your environment, database, and business logic? You need an automated process to launch new tenants; this is called Infrastructure as Code (IaC). This script/procedure should live within a git/bitbucket repository, one of the fundamental DevOps principles. A strong argument to leverage Automation and IaC is that you need a mechanism to automate your SaaS application for your code deployments. In the same lines, automate the provisioning of new Infrastructure for your Dev/Test environments.
Infrastructure As Code and Automation Tools
It doesn’t matter which Infrastructure as Code Tool to use, they are both useful (Terraform and CloudFormation); they do the same job, and are highly known by the DevOps community. I don’t have a winner, they are both good. 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. It is easier to find DevOps with this skill.
Amazon CloudFormation. It is easier to integrate with Amazon Web Services, AWS built-in Automation tool. Whenever there is a new Amazon technology just released, the compatibility with AWS and CloudFormation is released sooner than Terraform. Trust on an AWS CloudFormation expert to automate and release in a secure manner.
Message Queue System (MQS)
The common MQS are Amazon SQS, RabbitMQ, or Celery. What I suggest here is to utilize the service that requires you less operation, in this case, is Amazon SQS. There are multiple times that you 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).
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. It is essential to include a caching system for your SaaS application.
Cloud Storage System
Amazon S3 and Amazon CloudFront CDN for your static content. All static content, including images, media and HTML, will 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 architectures
One of the most important questions among the multitenant adoption would be which Multi tenant architecture suits better for your SaaS Application on AWS. We will explore the two layers needed to enable your application to act as a real SaaS application since it is paramount to decide which multi-tenant architecture you’ll incorporate in your SaaS application from the application and database layer. These two types of multi-tenant architectures are the Application layer Multi-tenancy and the Database layer Multi-tenancy.
The Application Layer Multi-tenancy
The application layer is an architectural design that enables hosting for tenants and is primarily delivered for Software as a Service applications (SaaS apps). In this first model the application layer is commonly shared among multiple customers.
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–, I’m sure you 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. The monolithic architecture is not a bad approach, with the exception that you are 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
MicroservicesArchitecture for SaaS with containers and Amazon ECS
Microservices are a recommended type of architecture since they provide a balance between 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, I’ll recommend you to utilize 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 gives fewer efforts to configure your cluster and more NoOps for your DevOps team.
By 2022, 90% of all new apps will feature microservices architectures that improve the ability to design, debug, update, and leverage third-party code; 35% of all production apps will be cloud-native.
With a talented team, the best Multi-tenant SaaS architecture approach would be this use case scenario. 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.
The perfect match
Multi tenant architecture + AWS Services + microservices + Amazon ECS (as the container orchestrator).
Microservices Architecture Diagram
Kubernetes Architecture for SaaS with Amazon EKS
What about Kubernetes or Amazon EKS?… you might be wondering. Well, Kubernetes is another alternative of microservice architecture which adds an extra layer of complexity in the SaaS equation. However, you can overcome this complexity by leveraging Amazon EKS, –Amazon Elastic Container Service for Kubernetes; the managed Kubernetes service from Amazon–, which is a de facto service by the Kubernetes community.
What highlights of this component from the rest of the architectures is that it provides the use of namespaces. This attribute aids to isolate every tenant and its own environment within the corresponding Kubernetes cluster. In this sense, you don’t have to create different clusters per each tenant (you could, but in order to satisfy 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 would like to isolate your namespaces, you need to include Kubernetes Network policies because by default the networking is open, and can communicate across namespaces and containers.
Here is a comparison of Amazon ECS vs Kubernetes. You can also visit our youtube channel and watch a video that compares and declares which is the Best Container. Alternatively, –if you have a SaaS enterprise–, I’ll recommend better to control your microservice via Amazon EKS or Kubernetes since it allows you to have more granular changes.
So, how would a Kubernetes Multi tenant architecture look like? Here is a simple Kubernetes Multi-tenant architecture and siloed by its respective namespaces.
Kubernetes Architecture Diagram
A simple Multi-tenant architecture with Kubernetes and siloed by Kubernetes Namespaces.
Serverless Architecture for SaaS on AWS
The dream of any AWS architect is to create a Multi tenant SaaS architecture with a Serverless approach. That’s a dream that can come true as a DevOps or SaaS architect, but it especially adds a fair amount of complexity as a tradeoff. Additionally, it requires a reasonable amount of collaboration time with your dev team, extensive changes of code application, and a transformative Serverless mindset. Given said that, anyhow in a few years, it will be the ultimate 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. Now that you have decoupled every logical service, the authentication and authorization module needs to be handled by a third-party service like Amazon Cognito, which will be the one in charge to identify the tenant, user, tier, IAM tenant role, and bring back an STS token with these aspects. Particularly, the API Gateway will route all the tenant functions to the correct Lambda functions matching the STS Token.
Here is a diagram of a multi tenant architecture example for AWS SaaS Applications that are using serverless.
Serverless Architecture Diagram
The Database Layer Multi-tenancy
The multi-tenancy concept comes with different architecture 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, which is 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 right 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 criterias 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. There are specific trade-offs for this architecture, including the sacrifice of data isolation, noise among tenants, and performance degradation –meaning that one tenant can overuse compute and ram resources from another. Lastly, every table name has its own tenantID, which is very straightforward to design and architect.
In regard to 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 never expose information from more than one tenant. That’s why compliant SaaS applications, this architecture model is not recommended, however, is used widely because of its cost-effectiveness.
Alternative single-tenant database architecture: a Shared table in a single schema in a single schema in a single database. Perfect for DynamoDB. (We didn’t cover this approach – FYI)
Single Database: A schema per tenant
A schema per tenant single database, also known as the bridge model, is a multi-tenant database approach which 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 to notice 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 call 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; the best for performance, scalability, and data isolation. This pattern uses one database server per tenant, it means that if the SaaS app has 100 tenants, therefore there will be100 database servers, 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 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 in every layer, let’s start considering what is needed to change in the code level, in terms of code changes. If you have decided to adopt Django (from Python) for your SaaS application. Then you need a few tweak changes to align your current application with your Multi-tenant architecture from the database and application layer.
Fortunately, web application languages and frameworks are able to capture the URL or subdomain that is coming from the request. The ability to obtain 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 –or in any other framework–, but at least I’ll let you know what items should be considered in this section.
Python Django Multi-tenancy in a nutshell*
- 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 application
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 the identification, authentication, and authorization of every tenant. However, another workaround is called 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 in place 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 18.104.22.168 OR app.saas.com A (alias) balancer.us-east-1.elb.amazonaws.co
Note: An (A) Alias record is when you are 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 need to 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 would need to add them either in the Cloudfront CDN, Load balancer, or in your web server.
Note: This solution can be accomplished using the Apache webserver.
Follow the 12-factor methodology framework or die trying!
Following the 12-factor methodology represents the pure DevOps and cloud-native principles, including immutable infrastructure, dev/test and prod parity with Docker, CI/CD principles, stateless SaaS application, and more.
Willing to know more about the 12-factor methodology? This article deeply explains how to adopt the 12-factor methodology for any SaaS application on AWS.
Multi-tenant SaaS Architecture Best Practices
How is your SaaS Application going to scale? Consider following a strategy on how to scale your SaaS application, here is a good one:
- 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.
More details here on how to scale a SaaS Application.
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 my previous best practices, it won’t be difficult. The CI/CD practice is another world that your DevOps team needs to get familiar with, but with a team like ClickIT. CI/CD is just one of the five principles of DevOps practices, and it is pretty lean for us to adopt it into your SaaS application.
What tools to embrace CI/CD?
CI/CD tools: Jenkins, CircleCi, or AWS Code pipelines (along with Codebuild and CodeDeploy).
My 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… then go for AWS Code pipelines. But if you’re looking for compliance, banks, or regulated environments, go for Gitlab.
DevOps Automation: Automate your new tenant creation process
How are you creating new tenants per each 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, meaning to automate the setup of new tenants. Consider that it can be after your customer gets registered in your onboarding page, or you need to trigger the script manually.
Amazon CloudFormation (Trust on an AWS CloudFormation certified team) 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 is touching 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
Have you considered how many SaaS tenants can it 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? You have a particular customer that wants an isolated Tenant environment for its SaaS application. How would you support an extra Tenant environment that is separated from the rest of the multi-tenant architecture? Would you do it? What are the implications? Just consider a scenario for this aspect.
What are you doing with the tenants that are idle or not used anymore? Perhaps a clean-up process for any tenant that has been inactive for a prolonged period, or remove unused resources and tenants by hand… but you need a process or automation script.
Multi tenant architecture and SaaS applications under AWS… What a topic that 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 falls more on what you need, 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, include cloud-native principles, and finally, adopt the multi-tenant architecture best practices and considerations described in this article. That being said, brainstorm your AWS SaaS architecture firstly by thinking on how to gain agility, cost-efficiency, IT labor costs, and leveraging a nearshore collaboration model (which adds another layer of cost-savings).
If you ever need a hand on how to architect your SaaS application, execute the whole AWS/DevOps projects and follow these principles, or just hire a DevOps engineer to fulfill your DevOps needs, just contact us. We help enterprises run successfully their DevOps embracement. Read more about the voice of our customers.
ClickIT is an AWS Select Partner with multiple AWS Certifications. Every engineer on ClickIT loads more than 10 DevOps projects based on SaaS architectures and cloud-native applications including PHP Laravel, React, Angular, NodeJS, Python, Go, Ruby, and Java. In the DevOps space, we work with any cloud provider (Azure, AWS, Digital Ocean, and Google Cloud), with any CI/CD, including Jenkins, CircleCI, bitbucket, and more.
In regard, Automation with Terraform and CloudFormation is our best choice. And even better, most of our AWS/DevOps projects are following PCI, HIPAA, and SOC2 regulations. If you are a fintech, healthcare, or SaaS company, well, you know this type of requirement should be included in your processes. In case you’re looking to learn more about DevOps practices and SaaS applications, don’t hesitate and visit our YouTube Channel to learn more through videos.
FAQs (Frequently Asked Questions)
Single tenant is an architecture where a single instance serves a single 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 mode of operation of software 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 that 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 and has the advantage of not managing the installation or the infrastructure that supports the application hosted at 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.