SaaS Solutions - What is the difference between a multi-instance and a multi-tenant architecture

Reminder: What is SaaS?

Before delving into the subject, it may be interesting to recall what a SaaS solution is: SaaS stands for Software as a Service. This is a method of distributing software that typically involves a subscription model to access a product, tool, or service.

With a few exceptions, these software is hosted in the cloud and can be accessed directly from a browser or mobile device, which greatly increases accessibility.

New ways of consumption:

In order to use an application or software, it was traditionally necessary to install it on its application servers. To do this, you had to have one or more employees in your company able to manage all layers, from networking to maintaining the application itself. Above all, it was often necessary to possess the infrastructure.

Then came the concepts of IaaS hosting (Infrastructure as a Service) and, a little later, PaaS (Plateform as a Service). These new ways of consuming IT resources have provided a layer of abstraction and simplification to deploy and install our or our customers' software. It is in this line of new ways of consuming IT conveniences that SaaS was born.

The problem is then simple: Allow my client to use simply my software.

No need to install it, manage updates or maintain the infrastructure.

SaaS Architectures

SaaS solutions are mainly built on two types of architectures:
Multi-instance on one side and multi-tenant on the other.
“Tenant” refers to the team or organization of your customers.

We won't see them here, but there are also architectures such as single-instance, multi-instance with shared database or flex tenancy that are a little less common.

The purpose of this article is not to take the side of a particular architecture because each architecture meets different needs. So the idea is to be able to compare the two types of architecture so you can choose the one that best suits you based on your needs and those of your clients.

Note that the result will not be much different for the end user. However, it will vary greatly in the design of the system architecture, data and access, and in the configuration and management of users.

So let's look at the pros and cons of each of them starting with multi-instance architectures:

Multi-instance architecture

In a multi-instance architecture, several companies will run their own separate instance of the application, with their own database. Each company will therefore have access to its data separately from another.

This type of architecture provides the following benefits:

• Data Isolation:
  Each organization (or team) has its own database and infrastructure. This results in total data isolation and offers a guarantee of confidentiality for your customers. Hackers will therefore have less interest in attacking your system because they will be less interested in recovering access from a small segment of your total data.
• Simplified scalability:
  Increasing resources is easier for a customer because only its infrastructure will need to be modified. We will be able to allocate more CPU, RAM or storage according to their needs.
• Increase in overall availability:
  If an instance fails for some reason, this issue will not affect all of your customers.
• Personalisation:
  Each of your customers can receive customizations of your SaaS (dedicated features, scheduled updates, etc...) that you can easily turn into business arguments.

However, since no architecture is perfect, we will still note the following negative points:

• More complicated to deploy and maintain:
  As you understand, each of your customers has their own dedicated infrastructure, you will need to provision each infrastructure, maintain it and update it separately.
• Higher total cost:
  This choice of architecture is less cost-effective when it comes to creating and configuring each environment such as the database or application because costs are not shared.

Multi-tenant architecture

Now let's look at another type of architecture, the multi-tenant. Here several companies will use a single instance of the application (which can of course be replicated if needed), with a single database. This architecture does not give much flexibility but simplifies the process of adding features and fixing code bugs.

Major advantages:

• Better profitability.
  Using the same infrastructure and resources will cost you less because the resources will be shared between your customers.
• Simplicity related to shared infrastructure.
  Since there is only one infrastructure, it is easier to maintain.
• Save time:
  This type of architecture has the advantage of being simpler to set up than a multi-instance architecture. This makes it easier to develop your SaaS application and requires less time and resources to maintain it.
• Always up-to-date:
  Updates will only be done once so that they will benefit all of your users.

Disadvantages:

• Shared database:
  Any action affecting the database will affect all shared clients.
  So it is at the application level that data separation will have to be done and therefore the developer team will prevent data exposure from one customer to another, which will increase the complexity of the application layer.
• Any security breach has a massive effect because it will affect all users of the system.
• Less customizable:
  You will be less easily able to customize the offer you offer to your customers. It is still possible to lock some features in the code of the application but again, it may lead to complexity related to development.

Which architecture to choose?

You now have the cards in hand to understand the differences between the two types of architectures.

To summarize, for my part, if I had a “fast time-to-market” problem and need to quickly develop a SaaS solution, I would rather focus on a multi-tenant architecture because it is easier to set up. On the other hand, if I needed to develop a more robust and secure solution, I would instead opt for a multi-instance architecture and benefit from total data isolation.

To go further, build your architecture with Kubernetes

Kubernetes has the advantage of allowing you to build a multi-instance architecture as well as multi-tenant architecture. You will then be able to orchestrate your deployments, updates, replicate or even “self-scaling” your infrastructure. At Scaleway, we have developed a Kubernetes Managed offer:
Kubernetes Kapsule.

Create Kubernetes clusters in seconds:

👉 Create an account

Let's see some must-see features:

• Automatic provisioning:
  For a multi-instance architecture, end users will ultimately request application deployment in Kubernetes. To do this, you should consider integrating your application with the Kubernetes API. It's also not uncommon to pre-provision instances that will be assigned to your customers at the time of account creation. This will save you the few minutes of infrastructure provisioning and make the user journey more enjoyable.

• Customizable Hostname:
  Lately, end users attach their domain to applications. Kubernetes has put in place tools to make this process easier and even get to the point where it becomes self-service (users pressing a button to get their domain pointing to the pod assigned to them). You can use ingress controllers such as Nginx Ingress to accomplish this.
• Automatic Node Scaling:
  When your nodes get full, you'll definitely need to provision more nodes so that your applications can keep running without slowing down. Kubernetes Kapsule provides an option to allow you to automatically scaling your nodes.

• Application scaling:
  You will be able to scale your app (up or down) depending on usage. Kubernetes provides this “out of the box” feature with triggers that automatically scale deployments. For example, running this command: kubectl autoscale deployment myapp —cpu-percent=70 —min=1 —max=10
  This command will set the myapp deployment to scale up to 10 pods when the CPU percentage exceeds 70.
• Portability:
  Our offer Kubernetes Kapsule is certified by the CNCF (Cloud Native Computing Foundation). Kubernetes Kapsule therefore complies with CNCF standards to provide safety, stability and robustness. This warranty enables the design of hybrid and multi-cloud applications and infrastructures. It also gives you the guarantee that you can design an architecture with Kubernetes so that it can work with any managed Kubernetes offering on the market that is certified.

Kubernetes Kapsule is a great tool for managing your cloud infrastructure. If you're having trouble scaling your application, consider moving to a Kubernetes-based architecture. You'll see a significant increase in the productivity of your DevOps in deployments, clustering, and overall stability.

This article is taken from the Webinar (in French) “Découvrez les avantages de Kubernetes pour héberger une solution SaaS”, feel free to watch it on Youtube: