Whether you’re a software provider or customer, it can be difficult to know what kind of setup you want to use. Do you go for a single tenant isolated setup, or do you take the increasingly popular other option?

Multi-tenant architecture is only growing more popular with the rising popularity of SaaS products. It’s a fantastic way to cater to as many customers as possible, with only a few downsides that you need to be careful of.

That’s why we’re here - to tell you everything you need to know about this architecture option and help you to make the best choice for how to structure your software.

This post will cover:

• What multi-tenant architecture is
• Pros and cons of multi-tenant architecture
• Single-tenancy vs multitenancy
• Cost optimization opportunities for a multi-tenant architecture

Let’s get started.

What multi-tenant architecture is

Multi-tenant architecture is a setup by which a single instance of software is running across one or more servers for use by more than one customer. The application provides a single instance experience for multiple users within a customer, who can never see or access the data of other customers.

The use of multi-tenant architecture is also commonly referred to as “multitenancy”, so know that these terms both refer to the same thing.

In practice, multitenancy means that the server’s CPU and memory is shared between users, so it’s important to have multi-server architecture built to handle peak load. It’s pretty standard practice, but failing to have this set up will result in greater online user numbers causing worse server performance for all of them (as resources are equally shared between them).

This does, however, allow for greater flexibility in some ways than single-tenant architecture. We will lay out the details of this in the following section, but know that multitenancy has the potential to serve users in a much more cost-effective manner that still prioritizes performance and security.

Another way to think about it is as if your server is a large building.

In a single-tenant setup, the building (server) could be a company office that spans every room. The entire thing is dedicated to solving the problems of the single institution that rents it. Any security measures put in place are (largely) that of the company and not the building (server) itself.

Contrast that to multi-tenant architecture. Instead of containing one company’s office, the rooms inside are divided amongst two or more companies (customers). Because there are multiple companies in there that do not have ultimate control over the room setup (software running on the server), the building (server) itself needs to have measures to keep its residents (users) separate in order to protect their data and usage.

You don’t want companies and users to be able to snoop on each others’ data, usage, and private information. Buildings with more than one company’s offices in them don’t allow for them to freely access each other - they have different locks on the doors to make sure that they can work separately, even though they’re using the same room layout (software) to do so.

So, when multiple customers are accessing the same software (from one or more servers), they need to have an almost siloed experience from each other. This is true in brick-and-mortar offices, and in multi-tenant architecture.

This analogy falls apart a little when it comes to separating physical spaces, as multi-tenancies often handle workloads from distinct customers through the same pathways, with only a unique customer identifier indicating which customer for whom the workload is being performed. Additionally, in a multi-tenant environment, the software functionality is identical across customers, so think of the rooms in the building being more like a WeWork installation with identical furniture and layout rather than a rough commercial space ready for custom build-out.           

Pros and cons of multi-tenant architecture

Multi-tenant architecture has many advantages and disadvantages that make it a powerful option for you to use. In the right hands, it can serve as the foundation for a successful business, but also provides unique security and performance risks that need to be addressed.

In terms of benefits, multitenancy:

• Has relatively low costs
• Allows for easier maintenance
• Makes onboarding new users easier

Multitenancy is relatively cheap, as server architecture goes.

Since you aren’t requiring a copy of the software being used on multiple, siloed and dedicated environments, you can consolidate usage down into fewer resources. 

You’re only ever paying for what you’re using, rather than with single-tenancy, where you pay for the entire environment no matter the usage. This is where you can start to see the true flexibility of multi-tenant architecture - you’re not being forced to use all of the resources at your disposal because you’ve reserved a lump sum. Instead, your resources can be adjusted and fine-tuned based on your needs to optimize costs as much as possible.

Maintenance is also easy when you’re running on multi-tenant architecture, as all updates can be pushed to all customers automatically, at once. While each customer needs to be siloed in their usage, the software being provided to each is the same, and since they can all work on the same infrastructure resources, updates to that software can be pushed to all of them at the same time.

In other words, it’s easy for software providers to make sure that their customers are all using the most up-to-date version of their software, and it’s better for the customers since they don’t have to worry about manually updating the software. All updates can be pushed to customers simultaneously, so there is a low chance of any issues arising due to users working from different versions of the same software.

Finally (for the positive points), multi-tenant architecture lends itself to having an effective, standardized onboarding procedure for new users, whether those users are part of a new or existing customer overall.

This is because the software being provided like this is always going to be the same across customers. While the data of those customers will change the software on their end, the core will always be shared, meaning that the software provider and customers alike can take a standardized approach to training new users on its usage.

However, there are some issues with multi-tenant architecture too. Namely, it:

• Requires architecture solutions to manage heavy use
• Requires greater data security measures
• Increases the complexity of data backups
• Limits user customization
• Relies on more factors to have consistent uptime

As we’ve mentioned earlier in this post, multitenancy will naturally require the software provider to have extra measures in place in order to handle heavy usage. Since the memory, CPU and storage space of your infrastructure are shared between all users on it, this will more often than not require enough resources and monitoring to support expected peak usage. Auto scaling can be a great and easy solution for that, so it’s not a massive worry.

Security, however, is a major concern for multi-tenant architecture.

One customer’s data should never be revealed to another customer, and errors in code can sometimes cause this to occur in such a setup. That’s why the software provider needs to build rigorous checks and balances in the QA process in order to keep each customer’s data secure. This is doubly so if your company is required to be compliant with GDPR, HIPAA, PCI, or other universal standards of data protection.

The same is true for if you want to have any reasonably sized companies using your software - if you’re not secure enough for them to be compliant with the bodies that their clients require, they will look for another service which is.

Security measures need to cover preventing unauthorized user access within existing customer accounts and prevent the much more numerous avenues of attack from being vulnerable to outside sources.

Being a more complex setup also means that multitenancy can be a pain when it comes to data backups and user customization too. For backups it’s a case of the software provider being much less likely to want to offer to restore data from a backup or look up data within the backup on an ad hoc basis, as this would require the provider to have to isolate that specific customer’s data among the entire backup.

As for customization, the nature of having the same software being supplied to every customer means that there is inherently no way for users to fully customize things. They can’t implement a new feature or function that doesn’t already exist in the wider software, though configuration options are quite typical. However, the more configuration options they’re given, the more stress is put on the provider’s resources to an exponential degree. At a certain point, it becomes more viable for the customer to search for a fully customizable single-tenancy solution.

The last negative to consider is that multitenancy requires more services to work correctly in order to achieve 100% uptime. This isn’t necessarily a problem, as the software provider will want to maintain their services as much as possible anyway, but much like with security it still provides an extra factor into the equation that can mess everything up if it goes wrong.

Single-tenancy vs multitenancy

To quickly cover the discussion of single- versus multi-tenant architecture, it largely depends on what kind of setup you wish to cater to.

Software providers and customers who are aiming for more foolproof security and customization and care less about the cost of providing it are going to be better served by single-tenancy in an onsite setup. By isolating the software environment for a single customer to use, you silo their data and immediately cut out a huge point of access for malicious parties.

Providers and customers who are more focused on flexibility, scale, are on a budget, or who wish to simplify updates and maintenance would be better suited to multitenancy. This will allow them to provide services to a much wider span of customers, and to utilize a greater selection of more globally successful (and cutting-edge) software.

Cost optimization opportunities for a multi-tenant architecture

Let’s say that you’re a SaaS company running on multi-tenant architecture via AWS. You’re providing your software to as many paying clients as possible, but the costs involved with upkeep and maintenance are the highest in your business bar none.

Don’t worry. We’ll take you through some tips for optimizing your costs.

First, you should utilize AWS Auto Scaling instead of having a fixed number of servers per client. This will automatically adjust your usage and server resource allocation based on your usage goals - the more strained you are for resources, the more will be allocated and vice versa.

Second, Savings Plans are a fantastic way to save money on the computing power you use. This should allow you to save up to 72% in return for committing to 1 or 3 years of usage without the need to restrict yourself to instances with particular reservations.

Third, try deploying with containers on spot instances to save up to 90%. It’s a great way to limit your costs while keeping most of the uptime you would have otherwise, as it allows Amazon to easily adjust and reallocate resources depending on your usage and without affecting your overall performance.

Finally, you should talk to our team here at Aimably. We’re AWS experts, and our AWS Cost Reduction Assessment will highlight everything you could and should do in order to reduce your costs while maintaining performance. We’ll take you through every trick in the book, and even do all of the heavy lifting for you when it comes to searching for the best deals on things such as Savings Plans.