Explore our platform and learn how it can help your application shine.
Learn about modern authentication techniques and best practices.
Understand multi-tenancy, a foundation of shared computing.
Learn to manage user accounts and access at scale.
Learn how to design and build successful SaaS applications.
Understand what is required to provide an enterprise-ready product.
Understand the uses and benefits of Attribute-Based Access Control.
Learn how Single Sign On (SSO) can improve security and UX.
Learn about OpenID Connect, an open authentication protocol.
Learn about SAML, a popular SSO protocol.
Learn about our history, our team, and our mission.
Imagine that you want to create a SaaS application and structure it so that several users can use it; how would you implement such a project? One option is that you could take your application’s codebase and copy it entirely for each user. But then, you would need to support multiple instances of your application separately. That is not the best solution. Your development team would have to manage the infrastructure of the servers, updates, and incorporation of new functionalities separately for each instance. If your application had even a dozen users, and you want to deploy a new version to update all applications, your development team would have to do the same deployment a dozen times!
There is a much better solution. You can use a multi-tenant architecture for the SaaS application. Let’s see what it is and how it is implemented!
A multi-tenant architecture is a cloud-oriented application architecture that involves a single instance of the application but serves multiple clients or organizations. The basic idea of this SaaS architecture design is simple: have a single codebase that runs for all clients with the same data structure, but the data layer is separated into different workspaces by each organization.
With a SaaS application that uses a multi-tenant architecture, the software and web development teams will need to implement and support a single codebase and not multiple mutations. In this way, we can update the SaaS application simultaneously for all organizations, and it will be easier to manage the server infrastructure.
Some classic examples of the use of multi-tenant architecture are Salesforce, an industry standard in providing CRM services; Netflix, a popular streaming service; Slack, a business communication software; and other giants like Hubspot, Office 365, Box, Zoho, and Zendesk.
Using multi-tenant architectures for SaaS applications comes with tons of benefits that can help you grow unlimitedly and without worries. We have briefly mentioned the most significant benefits below:
One of the most significant benefits of using a multi-tenant application architecture is updating the application platform for all the clients at once. In the past, updates had to be installed on every client’s computer on which the application was installed. It is now possible to do this for all users at the same time. Customers also prefer softwares that provides frequent and streamlined updates because it makes the process less cumbersome while ensuring the service is updated.
Another great benefit of investing in multi-tenant architectures is the possibility of maintaining the application’s agility and good performance. As updates are frequent and automatic, the software is continually optimized for new technologies.
In addition, users can access such applications from any device with the internet—tablets, cell phones, notebooks, and computers. Thus, its use becomes much more practical, agile, and easy for customers who don’t work from a single workstation.
Using the multi-tenant architecture, the company can develop a fully automatic customer adhesion process—the user registers, makes the payment, and receives an automated email with their access data.
Multi-tenant architectures help reduce costs in several ways. First, the number of employees needed during the entire attraction, adhesion, and customer relationship is less. The number of calls for support also decreases, and usage becomes much more practical.
Second, the ability to perform updates on all user accesses at once helps reduce costs. Finally, when the business has unlimited possibilities for expansion, all the costs involved become smaller in scale as you expand. This way, the more customers you have, the more investment you can make in marketing, promotion, and improving customer relations.
On the other hand, since customer data can get mixed, an application needs to be developed to logically separate customer data. We will see later that the technologies integrated into AWS allow this difficulty to be quickly resolved. However, before that, we will look at the problem of data isolation and the different approaches to solve it.
We have a single instance of software that brings a problem: how will we separate the data between the different tenants of our application? We can use three different strategies to solve this problem: foreign key, segregated schema, and segregated database.
This is the simplest and most primitive way to separate data from our different tenants. Each table involved in the application has a foreign key to a tenant’s control table with this strategy. Thus, all data from all the tenants is kept in the same database, segregated by this foreign key. When a user accesses the application, the application checks the tenant linked to the user and shows data from tables whose rows had the foreign key linked to the user’s tenant.
The advantage of this strategy is that its implementation is straightforward and cheap—it only involves foreign keys and filters. However, this strategy has two downsides. One is that performance can be severely compromised if there are vast amounts of data or a very large amount of tenants. The other point is that the database is unique for all tenants—if one of the tenants performs a cumbersome operation on the database, all the other tenants will suffer from the slowdown or even the crash of the database. Therefore, this strategy is not recommended for applications with a very large volume of data or tenants.
The database instance is still shared among all the tenants in this strategy. But here, each tenant has its own schema. The bank instance is the same for everyone, but that instance has multiple sets of isolated application tables for each tenant.
The main advantage of this strategy is the isolation of data from different tenants, which reduces the possible impact that a tenant can have on other tenants of the application. For example, accidental deletions would be restricted to the tenant/schema that caused it due to the use of different schemas. This method is an inexpensive strategy as it is based on a single database instance. However, it has a slightly more complex implementation strategy, making adopting this strategy a little more expensive.
Each tenant has a dedicated database instance in this strategy—the application can simultaneously connect to multiple databases.
The main advantage of this model is that isolation is now “physical”, assuming that each tenant has their own unique database instance. This further mitigates the chances of one tenant’s operations impacting the experience of other tenants. The performance gain in this strategy is also noticeable since we are talking about isolated and different database instances for each tenant. However, this strategy is significantly more complicated to implement from a technical point of view: the application will have to connect to multiple databases simultaneously according to the user accessing the application. In addition, you will need to provision a database instance for each tenant, which makes this the most expensive strategy among the three strategies discussed.
When creating a multi-tenant architecture, the crucial issue is to secure the data so that it is not accessible by everyone. SaaS application developers must identify a user, link data to its tenant and a user to its tenant, and know what rights have been granted to a particular user.
To create a multi-tenant architecture on the AWS cloud, we recommend combining the Amazon DynamoDB, Cognito, and IAM services.
The first step for implementing multi-tent architecture in AWS is setting up and organizing the DynamoDB database.
In DynamoDB, each table present in your database must have a column allowing you to store a reference to the tenant. Typically, this is a customer identifier (organizationId).
In addition to this table management, Amazon Cognito allows you to add users to your SaaS applications. This service lists the different customers (and therefore their users and groups) and their identifiers in a multi-tenant infrastructure. In addition, it associates personalized attributes with each user according to the tenant to which they are linked to secure their authentication and manage their authorizations.
In addition, AWS manages all the security and connections for you. All the latest standards, including multi-factor authentication, are available without further development on your part.
Each user is a member of a group. You can thus manage data access finely according to groups.
Finally, with IAM (identity and access management), you will define each group’s security rules (policies). Thanks to these rules, filters (LeadingKey) are created in the DynamoDB database. Thus, users have exclusive access to the data linked to the filter. They are unable to see the rest.
In this example, the rules restrict access to data with the customer’s code acting as access key to members of the group.
To ensure that the SaaS application works like a charm and is commercially beneficial, you must follow some time-tested best practices.
Now you don’t have to spend months thinking about what should go into the admin panel. All you have to do is to prepare the launch of your next great SaaS application as FrontEgg provides you an easy to integrate and completely self-service multitenant admin protocol which is all that you need.
A multi-tenant SaaS architecture provides long-term benefits in building SaaS applications in terms of maintenance, development, and investment. However, its always challenging to identify which approach is most appropriate. Thanks to the three AWS services (DynamoDB, Cognito, and IAM), we can build a SaaS application securely and efficiently.