Just After Midnight’s nice and SaaS-y guide to SaaS architecture 

by Ned Hallett
Published on December 2021

In this piece, we’re getting into all things SaaS. 

And as cloud experts extraordinaire, we’ll be paying particular attention to infrastructure and architecture.

Putting all our cards on the table, we’ll be diving into:

  • What is SaaS?
  • SaaS vs. PaaS vs. IaaS
  • Horizontal vs. vertical SaaS
  • SaaS architecture – multi-tenant vs. single-tenant SaaS 
  • SaaS and data security 
  • Cloud-native and SaaS: microservices, containers, serverless and more 
  • A cheeky bonus 
  • How we can help 

What is SaaS? (a remedial lesson; feel free to skip, cloud heads)

This is an easy one.

SaaS stands for Software-as-a-Service: a software licencing model wherein software is centrally hosted and accessed via a subscription.

Any bits of software you access via the web are likely SaaS. 

Think Netflix, Google, Spotify – all SaaS.

SaaS vs. IaaS vs. PaaS – where does the as-a-Service in SaaS come from?

These as-a-Service acronyms are all variations on a theme.

They refer to an endpoint browser console or similar (like Netflix’s home screen) through which a user (that’s you) may access software, infrastructure or platform – whatever’s as-a-Service.

So it really just means ‘a thing,’ you access over the web.

In cloud computing, perhaps the most common example of IaaS is Amazon’s EC2 – which is a virtual piece of infrastructure (putting the ‘I’ in ‘I’aaS) offered as-a-Service via the AWS Management Console –  that’s the endpoint browser console.

For an example of a SaaS offering, we have AWS Textract, which reads and extracts text from documents.

The difference between Textract and EC2 is that one is a complete application and one is a VM on which a complete application can be run – though both are delivered as-a-Service. 

That’s a-as-Service conceptually.

For details, see below:

SaaS PaaS diagram

credit: medium.com

Horizontal vs. vertical SaaS

This one doesn’t relate too much to SaaS architecture (or at all, to be frank).

But it sounds like it does, and it crops up frequently enough that we thought we’d just get it out the way.

These terms actually only refer to the business targeting of the SaaS product.

  • Vertical SaaS is a SaaS that performs a function within a vertical, i.e a legal document reader
  • And horizontal SaaS is a SaaS that performs a function across verticals, i.e a payroll solution

Now we’ll hear no more about it!

Why SaaS?

Now that we’ve explained what SaaS is, before we dive into the architecture, it’s worth asking why SaaS is the show stopper that it is. After all, SaaS

  • Is the fastest-growing of the public cloud models
  • Is  predicted to capture more than half of cloud spending between 2019 and 2023
  • had a global market estimate of 225 billion in 2020

And is increasingly the go-to deployment model as well as and how most customers want to consume their software.

So, why all the fuss?

The benefits of SaaS 

Accessibility for users 

Users can easily sign up to a SaaS product without needing to download, install or configure. Plus, the service can be accessed from any device.

Ease of management 

The application is managed from one central code base, allowing the fast rollout of new features for all users, simultaneously.

Flexible pricing 

Instead of a costly licence, the pay-as-you-go nature of SaaS opens it up to low-barrier pricing models like pay-for-what-you-use or a monthly or yearly subscription.

Takes the pressure off internal IT teams 

SaaS products are managed by the provider, which is a major draw for many companies, and especially start-ups and scale-ups – who need their IT teams to be focussed on core business issues.

The long and short of it

There’s a lot more, we could say, but the long and short of it is that the centrally managed, as-a-Service model fits today’s culture of constant change, flexible adoption and fast scaling perfectly.

And so for the moment, SaaS is the delivery model du jour.

The good bit – How are SaaS apps architected? 

This is what we came for!

The word on the street is that the current gold standard is a multi-tenant microservices, containerised and/or serverless build. 

This is ideal for a global, hyperscale app. But there are still conditions under which ye olde’ single-tenant architectures are preferred.

And there’s no one-size-fits-all solution.

Multi-tenant vs. single-tenant SaaS 

Single-tenant 

Single tenancy was the first iteration of the SaaS model. In this setup, every tenant has their own infrastructure. Meaning every single customer has their own instance of the app, database, etc.

Although there are ways to streamline the deployment of all these resources, it certainly is costly, and this is the major reason that single tenancy is considered old hat.

However, there are still some niche cases where it’s preferable – which we’ll get to below.

Pros 

  • There are a few technical advantages to single tenancy, but these are pretty niche – there’s more scope for individual customisation of app features and infrastructure, but this is rarely gonna be a deal maker 
  • The main benefit of single-tenancy is security, which is the single biggest problem with multi-tenancy. Not sharing a database means data is truly isolated, which can be a make-or-break decision in certain situations and verticals (legal, healthcare, etc)

Cons 

  • The major con of single tenancy is the vast doubling (or how-ever-many-customers-you-have-abling) of resources – everything from databases to maintenance rises in proportion
  • There’s also no easily managed central code base, so updates are a cumbersome task indeed

Multi-tenant

In a multi-tenant architecture, customers share a single instance of the application and a single database. This is, in general, vastly preferable. But there are a few cons, also. 

And the issue of data isolation is one that needs to be taken seriously.

Pros

  • Multi-tenant architectures scale much more effectively than single-tenant architectures, since there is only one app and often only one database to scale.
  • For the same reason, multi-tenant architectures are also much easier to maintain and update
  • Multi-tenant architectures are much more resource-efficient since you’re essentially doing more with less. 

Cons 

  • There is some loss of customisation, since the app is shared by all customers – however, this is only a real problem in niche cases.
  • The real issue is the security concerns presented by shared databases – which, again, can be a deal-breaker in certain verticals (legal, healthcare etc). In fact, because this is so important, we’ve given it its own section:

Data isolation strategies in a multi-tenant SaaS architecture  

There are multiple ways to isolate customer data within a shared database, which is usually preferable to running a shared instance of the application with multiple databases (a sort of Hovis worst-of-both scenario).

However, these approaches have their own strengths and weaknesses – as do we all.

Row-level security 

Row-level security, supported by SQL Server and PostgreSQL is top dog when it comes to data isolation.

The reason for this is that it separates at the data level, which means it keeps data within an individual table separated. 

Other solutions separate between tables, meaning each customer requires their own table within a database.

If that’s confusing, just think of row-level security as walls within a building. 

Typically, row-level security is achieved by tying each login to a field restriction, I.E tenant X can only see Y fields.

Schema security 

Schema separation is a logical separation practice in which each client has one schema which separates their tables from each other table.

This is separation at table-level, and tends to be more complicated, as table-level separation means, unsurprisingly, more tables.

Going back to the previous analogy, this means building new buildings, not new walls.

One particular disadvantage of schema data isolation for customer data is that schemas are often used in microservices architectures to separate data between services – so if you’re using schemas to separate per service and per customer…things can get complicated pretty fast. 

A final word 

There are of course other ways to separate data in a multi-tenancy SaaS product – but that’s a whole ‘nother post for a whole ‘nother day. 

The above are two of the most common methods for shared databases, which is itself the most common method. 

Cloud-native SaaS – other elements of SaaS architecture

In terms of SaaS, cloud-native refers to a few technologies or practices that are used to build better SaaS apps that could be knocked up using last-gen cloud.

In no particular order, these technologies and practices are:

  • Microservices/containers/orchestration (the three are often grouped) 
  • Serverless 
  • DevOps /Automation/IaC 

Microservices-based, containerised SaaS architectures managed via an orchestration tool 

A microservices-based, containerised application has a number of benefits.

For a full breakdown of these technologies, read here for microservices and here for containers and orchestration. 

For a TL;DR:

Microservices 

Microservice architecture means an application’s processes have been decomposed into separate, you guessed it, “micro” services. The advantages of this are:

  • Each service can be scaled independently, E.G if you’re running an e-commerce app 

each service can be swapped out or changed up without causing problems for the others: 

  • Better fault isolation
  • More technology and language agnostic 

Containers 

Containers are a ‘lighter’ type of VM. They lack a virtual OS, meaning:

  • They’re lighter, meaning they consume less resource 
  • They can be scaled more cheaply 
  • More technologically agnostic 

When deploying a SaaS app as microservices and containers, the goal often is to deploy one service per container.

Orchestration 

Step 1: split your SaaS app into microservices.

Step 2: package each microservice in a container.

Step 3: devout hundreds of man-hours to manage each individual container and go bust.

Alternative step 3: orchestration.

Orchestration tools like Kubernetes and Amazon EKS manage and automate deployment and ops work, security and container lifecycle management.

Essentially, they’re essential – especially if you’re running a microservice SaaS app with one service per container.

Serverless SaaS apps 

The above build can be deployed as serverless – but it’s not as much of a done deal.

A serverless app means that the infrastructure the app runs in is created per request

Again – definitive statement here.

TL;DR:

In a serverless architecture, the business logic (that’s the part of the app that codes what it actually does, i.e. play song if user does action X) calls up the infra needed only as and when a request is run.

Think of it like Uber for infrastructure, there when you need it, gone when you don’t.

The advantages for this are:

  • Lower TCO, since your infrastructure literally doesn’t exist most of the time
  • Free up devs to focus and perfect business logic 
  • Scales more effectively 

If you wanted a SaaS app built as a serverless, containerised microservices architecture, you can!

There are orchestration platforms like AWS Fargate, purpose-built for serverless containers – i.e containers that pop into existence as and when.

Or you could have a serverless SaaS app zapping in EC2s.

The last point on serverless and SaaS is that a serverless approach can weaken the security of a multi-tenant environment.

DevOps, automation, IaC and SaaS

A mix of practices and tech, these three things are all geared toward faster, more robust deployments.

Again – here for the long read.

Or TL;DR:

DevOps comes from the joining of development and operations. And the focus of any DevOps team will be to work toward CI/CD, continuous integration and continuous deployment.

This means that new code is tested, corrected and deployed automatically, which has the obvious advantages of:

  • Less room for human error 
  • More frequent updates 
  • More robust updates 

DevOps and SaaS go hand in hand for many reasons. But the two most SaaS-full are that

  1. The easy adopt-and-drop nature of SaaS makes users fickle, so shaky deployments or bugs can kill a great product dead in the water.
  2. For the same reason, SaaS apps are expected to launch new features in-line with users’ developing needs (the competition sure will be) hence DevOps.

A cheeky bonus 

Remember when we said there was no one-size-fits-all solution? 

Well If you want a deeper look at some example SaaS architectures and explore that issue in-depth, we’ve got just the report for you.

Our guide to the ideal SaaS architecture on AWS contains diagrams and commentary from our expert engineers, covering:

  • Serverless SaaS
  • Containerised SaaS and orchestration 
  • Answers to key architecture problems facing SaaS companies 
  • The answer to why there is no one-size-fits-all approach

And because it’s you (i.e. anyone), it’s absolutely free.

How we can help 

As a leading next-gen managed service provider, we’ve architected and supported cloud-native SaaS architectures for companies in LegalTech, Insurtech and digital HR.

From UK national fitness icon Joe Wicks’ The Body Coach app to LineTen’s journey planning app serving the likes of Five Guys and Taco Bell – we’re the technology partner for cloud-native infrastructure, 24/7 tech-enabled support and a friendly face.

So to talk about your SaaS application, or anything else, just get in touch!

SHARE