SaaS Design: Are you Single, a Schema, or in the Mix?

Introduction

As CTO’s and technology heads, when we are thinking of designing a new system in a SaaS environment there are a number of factors to consider.

But first and foremost, rule #1 is to think big.

The decisions we take now will be in place for many years to come – and they are exceptionally difficult to unwind. If you reflect on the key considerations from the get-go, you will spare yourself the agony of redesigning or refactoring in the future.

In this situation, we won’t be able to redesign without incurring significant costs – which is the complete opposite of my recent article on user interface design “Ditch the Aging UI, not the Aging App”.?

As for the overall design, let’s assume that you need a web/application server and a database server in its simplest form – with the caveat that it will be powerful to meet your needs now, and in the future.

Let’s Talk Architecture

This is a vast subject, so let’s consider a couple of common scenarios:

• a company undergoing a SaaS transformation - from a single tenant on-premise or cloud enterprise solution to a SaaS offering.
• an initiative to build a product from scratch.

All facets remain the same, just the approach is slightly different in the addition of tenant provisions in the databases.

We will be discussing other critical considerations, such as separation of user information, data security, data security compliance and other compliance items, in future posts. For now, let’s keep our discussion confined to the realm of architecture.

Note that the terms tenant/client are used interchangeably and refer to a logical collection of users, who need to be completely private and protected from other users.

Scaling Up – Unlimited Resources?

It sometimes appears that cloud providers have an unlimited supply of hardware and configurations. However, in reality they offer a collection of multi-processing nodes, with high speed storage arrays on the back, which provide the storage space.

The great alure of the cloud is that you can start small to keep costs low and as the business grows, scale up the processing and storage requirements. This is typically no more complicated than allocating RAM, virtual CPU’s and storage space via a console on the cloud provider. It is worthwhile noting that at the time of writing, Amazon Web Services can offer a system with 448 Virtual CPU’s, 12TB Ram and 16TB storage space for USD 730,000/year. This is exceptionally cost effective and would typically far exceed the requirements of many other cloud service providers.

Scaling Out – Scaling all Resource Aspects:

Since Cloud Providers have a virtually unlimited supply of hardware and configurations, they can provision many small units to provide many processing servers. This is the nature of scaling out.

Each server has its own bandwidth, connectivity, storage and memory, distributing the need to a power house of processing capabilities. As your service grows, simply bring more servers and processing power online.

Cloud Service providers have mechanisms to scale out website and web servers but a solid scale out strategy requires correct technologies, design and implementation of systems with correct development of software. It is not as simple as going to a console and changing the number of CPU’s. However, the benefits are many, given the system is virtually unlimited in terms of storage and processing power.

It's Question Time:

Scale up or scale out?

If it is difficult to know your requirements, how do you take a call on this?

If you know the extent of the system, then you could possibly say that scaling up is all you need – and keep it simple. But what if you don’t know just how astronomical your growth will be?

The Easy Bit - Application Servers

Application or web servers via network load balancers can address the load from the browser on the client machine or the application running on the desktop, as they handle atomic units within the request.

Using modern technologies and development tools, this is almost boilerplate coding. Application servers therefore scale up and out without any great problem - but they all need to connect to the database.

So now, let’s look at the database configuration and architecture.

Database - Three Plus One Designs

There are 3+1 different mechanisms for the design of a multi-tenant SaaS database system. Each has its pros and cons, and requires careful consideration depending on the type of SaaS customer using the SaaS offering.

Option 1 - Separate database per tenant/client:

In this approach, each client has its own database. This means they have their own set of data, which will remain isolated from other data, which other clients own – logically, the database will be isolated.

Pros

• High security and can be customized according to the tenant’s needs.
• Tenant leakage cannot occur because there is only 1 tenant on the server.

Cons

• High maintenance and hardware costs.
• This only really works if you have a large user base under each tenant that merits a database server for each tenant.

Option 2 - Shared database with a different table grouped by schema per tenant/client:

Here, all the tenants will be configured under the same database. However, their tables will be grouped by a schema, until a certain threshold is met, and then they will move to the next server. Isolation will be at the table level.

Pros

• Lower in cost
• Address security concerns, to a certain extent.
• Potential tenant leakage is only in the schema. Provided this is set up correctly, for example a different SQL server login for each tenant, then the database by design protects itself.

Cons

• Data restoration of a single-tenant is difficult.
• This may be overkill for small user bases. Consider there is effectively a complete database for a tenant taking up requisite disk space accordingly. If that tenant has 5 users, it is significantly overengineered for the purpose.

Option 3 - All are shared – database, table, and schema:

In this case, the database and the tables are shared. Here, the tables are the same and will be storing multiple tenant’s data in any order. They are identified by a column that indicates the source i.e. tenant information. This would be validated when any tenant places a call request. Here, the isolation will be at a row level.

Pros

• Lowest cost.
• This handles tenants from a single user to a large client easily.

This is certainly the most cost effective solution as it will allow movement of information accordingly to different servers by a simple movement query, as each row in the database will have a tenant id column.

Cons

• Data security needs to be addressed appropriately. There is a real risk of data leakage with this model, as there is no database isolation.
• Development costs and testing costs are potentially higher than other options, as the data leakage is a real reputational risk, and so requires solid testing and development.

Option 4 – My preferred approach – Option 3 + Option 1

Option 4 adopts the model of Option 3, where we cater for small tenants as well as large. In the case of large (tier 1 account) or at the SaaS Customer request (for additional fees), a single tenant can be setup accordingly (Option 1).

However, to provide additional flexibility, the initial tenant maybe in a shared server environment with a move later to a single database server.

Connection Flows

The web/application servers need to connect to the correct database server (unless you are planning to have 1 monolithic server or a database cluster).

We employ a simple identifier server lookup in our token whenever we make calls from the client browser or application. The token is created when the user gets a successful logon. A simple flow chart shows the approach.

The Icing On The Cake

By adopting this approach, we can cater to the very small, the very large and the companies that start small and ramp up.

We limit any potential problems with security, and we limit potential database corruption, thanks to the distributed nature of the system. In addition, should you want to bring a new database server into the environment, you simply introduce the information to the authentication server (in the above example) and if the application server handling the request does not know the server mentioned, it simply performs step 1 and 2 to auto refresh the list. This allows new database servers to be created on the fly.

Conclusion

Remember, you have to pick your approach and stick with it.

I hope this has been helpful in removing the opacity behind SaaS database architectural design.

With Option 4 you get all the benefits and can handle the real-world use cases of people trialing with, for example 5 people and then setting up to handle 1,000 users. The SaaS architecture you choose today needs to serve you for years to come.

Choose wisely.