Multi tenant Architecture for a SaaS Application on AWS

Most businesses, large and small, are already embracing multi-tenant architecture to host their SaaS applications on the cloud. There are several reasons for this, but the most basic and obvious ones are cost and scalability. Multiple tenants share one instance of a software programme in a multi-tenant architecture (clients). These tenants share a variety of resources, including databases, web servers, computer resources, and so on, making the best multi-tenant architecture cost-effective while maintaining scalability.

Single-tenant vs. multi-tenant architecture

SaaS (Software as a Service) is a cloud-based distribution paradigm that allows customers to access programmes from anywhere in the world. You may be familiar with the terms single-tenant and multi-tenant SaaS architecture. What does tenancy have to do with software services, one would wonder?

It’s simple. Tenancy in a software environment is analogous to exchanging computer resources, with renters representing neighbours living either in the apartment building or in the neighbourhood (or a private household). What are the distinctions between single-tenant and multi-tenant databases for SaaS?

A tenant owns an application in a single-tenant architecture. Each client has its own database, storage system, and webserver. Larger businesses that desire maximum customization and security solutions prefer single-tenant design. The app is frequently hosted by the consumer. As a result, they are responsible for developing, hosting, and maintaining the cloud infrastructure.

Clients can use multi-tenant SaaS providers to deploy sophisticated apps and massive databases right away while saving money. It’s an excellent choice for startups, small businesses, and enterprises with limited IT resources.

Benefits of multi-tenant architecture

Let’s have a look at the advantages of multi-tenancy in SaaS for businesses:

Efficient distribution of resources: Businesses are not required to spend money on the development, delivery, and support. As a result, they won’t have to upgrade their gear or network capacity as their business expands.

Maintenance-free. The maintenance is handled by the service provider, which allows businesses to save money and focus on other objectives.
Integration with a third party: A single-tenant arrangement does allow for additional customization. Multi-tenant SaaS programmes with rich APIs, on the other hand, can interact with third-party software with ease.

Scalable rapidly: Although the majority of SaaS products are subscription-based, each vendor has its price structure. Access to the service is available to smaller teams for a normal monthly fee. The per-user model, on the other hand, is advantageous to larger businesses (where they pay only for active users). This enables businesses to easily change expenses in accordance with their requirements.

Here sum up the benefits of single-tenant and multi-tenant solutions. Single-tenancy consumes more resources but provides superior security and customizability. The vendor owns and maintains the infrastructure in the multi-tenant model, which makes it a cost-effective and scalable option for most enterprises.

How to develop a multi-tenant architecture for a SaaS application

The tenancy model will have an impact on the core features of your SaaS. Instead of making random assumptions, you should design the service around your business needs.

The following are some multi-tenant models to consider about:

Database-per-tenant: A separate database is created for each tenant. The app tiers can be scaled vertically (adding resources per node) or horizontally (adding resources per node) (adding more nodes). The databases in the same resource groups, on the other hand, are divided into elastic pools. To improve resource management, vendors can shift tenant datasets between these pools.

A single database with multiple tenants: The storage and compute resources are shared by all users in a multi-tenant database, which has numerous tenant identity fields. As a result, per-tenant costs are reduced. The burden of a single-tenant, on the other hand, may have an impact on how the service operates for others.
Databases with sharded tenants: Sharding is a technology that allows you to store tenant data in many databases. You’ll be able to partition densely packed shards into numerous less densely populated nodes as your workload develops (or merge them back just as easily). Furthermore, sharded databases can be placed in elastic pools to improve operational administration and scalability even further.

Multi-tenant databases with sharded hybrid sharding: You can switch between dedicated and shared databases for a single tenant or entire groups. When you have numerous distinct tenant groups with different resource requirements, this strategy works best (free trial tiers and premium subscribers).

Consider the number of tenants and their isolation, onboarding, and policy management techniques when creating multi-tenant systems.

Tenant usage analytics

For a SaaS business, resource usage data are critical. You can understand what microservices and subscription types bring the most benefit if you have a clear picture of your complete infrastructure.

Keep track of the following metrics:

• For each subscription tier, the number of active clients and active users.
• Costs of infrastructure and subscriptions by tenancy
• Indicators for memory and storage usage
• Profits per tenant and tier based on user involvement.

This information has the potential to change your entire business strategy. You’ll be able to focus on features that make the most income while using fewer resources, for example. In addition, if tenants consistently violate consumption limitations, you’ll be able to set an appropriate threshold for them.

The general version is that you should create a multi-tenant application that includes a way for accurately collecting a variety of resource consumption indicators.

Tenant Configuration

You must transform the way you answer the needs of your tenants as your product evolves. How? Implementing a centralised tenant configuration tool for policy management can help you achieve this.

Let’s look at how SLAs in multi-tenant cloud services should be approached.

SLAs adherence in a multi-tenant architecture

A contract between a SaaS provider and a customer is known as a Service Level Agreement (SLA). It specifies what features, security, and availability time clients should anticipate from your app. To put it another way, this paper lays out the user experience.

Strategies for SLA

The SLA is more than just a legal agreement. It’s a tool that allows you to assess how well your service fits the needs of your tenants.

As a result, you need to modify your SLA to accommodate SaaS. How are you going to do it?

Let’s take a look at some examples:

Service tiering is a method of categorising services. A portion of your user base is willing to pay for more advanced features. SLAs enable you to determine the worth of your product independently of the rest of the market. As a general rule, the more you provide, the more you may expect from your tenants.

Framework. A SaaS framework will assist you in determining client needs and determining your value. We suggest developing a dashboard to track the tenant’s progress against the SLA’s goals over time. You’ll know what tiers and features to alter as you examine stats to improve your service.

Business Impact: Various user groups utilise different amounts of resources in a multi-tenant SaaS design. As a result, some of them may exceed the limits, resulting in income loss. To balance cost and operational effectiveness for each tenant, tier, and feature, you should use SLAs to monitor tenant traffic patterns.

Impact on the Business. Various user groups utilise different amounts of resources in a multi-tenant SaaS design. As a result, some of them may exceed the limits, resulting in income loss. To balance cost and operational effectiveness for each tenant, tier, and feature, you should use SLAs to monitor tenant traffic patterns.

Reports. So you’ve set up a system to track tenant and application usage in terms of SLAs. Now is the time to develop a reporting tool to assist management teams in analysing the data and making educated decisions.

Multi tenant Architecture for a SaaS Application on AWS

Amazon EKS is one of AWS’s most popular container orchestration platforms, and it’s commonly used to host multi-tenant SaaS apps. However, it is vital to consider the issues that may arise as a result of cluster resource sharing when implementing a multi-tenancy system.

We’ll examine the best practices for multi-tenant SaaS applications using AWS in this article.

Each tenant has the same namespace

Separate namespaces are still important to consider when establishing a multi-tenant SaaS service since they effectively partition a single cluster resource across numerous clients. In Kubernetes, namespaces are the primary unit of isolation in a multi-tenant Saas architecture. Amazon EKS enables you to build a different namespace for each tenant running the SaaS application as one of its primary features. This characteristic helps to isolate each tenant and its environment within the appropriate Kubernetes cluster, ensuring data privacy by eliminating the need to construct separate clusters for each tenant. This feature will eventually result in significant cost savings in compute resources and AWS hosting.

Setting a ResourceQuota for Consumption of Resources

A multi-tenant SaaS application caters to multiple users, each of whom has accessibility to the same Kubernetes cluster capabilities at the same time. There are many circumstances in which a single-tenant consumes disproportionately large amounts of resources, exhausting all cluster resources on its own while leaving resources available for other tenants. To minimise capacity outages, the ResourceQuota idea comes to the rescue, allowing you to limit the resources that containers can utilise.

Here is an example:

apiVersion: v1

kind: ResourceQuota

metadata:

  name: resourceQuotaSetting

  namespace: tenant1

spec:

  hard:

    requests.cpu: "2"

    requests.memory: "1Gi"

    limits.cpu: "4"

    limits.memory: "2Gi"

To put this in context, once you’ve set up the above resource quota setup on Amazon EKS, a container can only request 2 CPUs at a time, with a total of just 4 CPUs available. It can also request 1 Gigabyte of RAM at a moment, with a maximum memory limit of 2 Gigabytes. This effectively limits resource utilisation while ensuring that a single tenant does not consume all available resources.

Using Network Policies to Isolate a Network

The Kubernetes production cluster allows namespaces to communicate with each other by default. However, if your SaaS application is part of a multi-tenant design, you’ll want to avoid this to ensure that various namespaces are isolated. On Amazon EKS, you may achieve this by using tenant isolation network policy and network segmentation. Install Calico on Amazon EKS and assign network policies to pods as stated below as a best practice.

The following policy, for example, allows only traffic from the same-namespace while limiting all other traffic. The pods in the tenant-a namespace with the label app: API will only receive traffic from the same namespace. To establish network isolation, tenant-communication a’s with other tenants and vice versa is prevented.

apiVersion: projectcalico.org/v3

kind: NetworkPolicy

metadata:

  name: same-namespace

  namespace: tenant-a

spec:

  podSelector:

matchLabels:

   app: api

  Policy types:

  - ingress

  - egress

  ingress:

  - from:

- namespaceSelector:

         matchLabels:

       nsname: tenant-a

  egress:

  - to:

- namespaceSelector:

         matchLabels:

       nsname: tenant-a

PersistentVolume and PersistentVolumeClaim are used to isolate data in storage

A multi-tenant framework, in contrast to a single-tenant framework, necessitates a unique approach to application storage management. Using PersistentVolume on Amazon EKS, you can effortlessly allocate and manage storage for many tenants (PV). PersistentVolumeClaim, on the other hand, is the name given to a storage request made by a tenant (PVC). You may simply provide storage isolation across multiple tenants because PVC is a namespaced resource.

We’ve configured PVC with ReadWriteOnce access mode and 2 Gi storage capacity for tenant1 in the example below.

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

  name: pvc-storage

  namespace: tenant1

spec:

  accessModes:

- ReadWriteOnce

  resources:

requests:

   storage: 2Gi

Setting RBAC with Amazon IAM and Amazon EKS integration

EKS interfaces with AWS IAM to administer Role-Based Access Control on a Kubernetes cluster, just like any other AWS service. You can authenticate any tenant namespace to a Kubernetes cluster using the AWS IAM authenticator. You must add the tenant’s (user) IAM role to the AWS-auth config map for namespace authentication in order to use IAM with multi-tenancy. The defined Role and/or ClusterRole for a given tenant’s namespace will be implemented on the cluster once AWS IAM authentication is successful. You can implement a hardened security posture on a multi-tenant environment by provisioning ClusterRole and Role policies on the cluster.

Tenant placement on Kubernetes nodes can be managed.

Amazon EKS includes Node Affinity and Pod Affinity for controlling tenant placement on Kubernetes nodes, and you can use taint and toleration, just like the default Kubernetes service. You can choose which node to run a tenant’s pod using Node Affinity. Pod Affinity, on the other hand, allows you to choose whether tenant 1 and tenant 2 should be on the same node or separate nodes.

No pods will be planned on node 1 unless the tolerance arguments in the procedure below match, and the key-value (client) must be tenant1. This method allows you to launch pods on a specified node for a certain tenant.

kubectl taint nodes node1 client=tenant1:NoSchedule

This is how a pod configuration looks like:

apiVersion: v1

kind: Pod

metadata:

  name: ubuntu

  labels:

   env: prod

spec:

  containers:

  - name: ubuntu

image: ubuntu

imagePullPolicy: IfNotPresent

tolerations:

  - key: “client”

operator: "Equal"

value: “tenant1”

effect: "NoSchedule"

That was all about the best practices and things to think about when hosting a multi-tenant SaaS app on Amazon EKS.

Conclusion

A multi-tenant SaaS application based on EKS provides a plethora of CPU, network, and data isolation possibilities while maintaining workflow security. Please let us know how you get on with any of these methods. Because of its cost-effectiveness and scalability, multi-tenant SaaS offers numerous benefits to startups and SMBs. However, creating a multi-tenant service entails more than just architectural design.

The number of users, partition model, onboarding procedure, configuration management tools, and SLA are all important considerations to make right away.

A reputable software development firm can provide you with the necessary technology stack and a clear product roadmap.

Alternatively, please let us know if you have any additional best practices to offer. IndaPoint will assist you with information and AWS Cloud Consulting related to Multi tenant Architecture for a SaaS Application on AWS.