In this piece, we’re getting into all things SaaS.
And as cloud experts extraordinaire, we’ll be paying particular attention to 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 Docs and 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.
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 X-as-a-service, conceptually.
For details, see below:
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 of the way.
These terms actually 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
- 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, and before we dive into the architecture, it’s worth asking why SaaS is such a show-stopper. 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
It’s increasingly the go-to deployment model – as well as 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 as-a-service deployment model opens up low-barrier pricing options like pay-for-what-you-use or a monthly/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.
And so, 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’s a multi-tenant microservice-based, containerised and/or serverless SaaS app. This setup is more scaleable, flexible and robust than anything that has come before. And it’s easy to maintain and support (especially if you’ve got a great SaaS application support provider in your corner; hint, hint).
This is ideal for a global, hyper-scale app. But there are still conditions under which ye olde’ single-tenant architectures are preferred.
And, as is the monotonous but true refrain of every tech article, there’s no one-size-fits-all solution.
Multi-tenant vs. single-tenant SaaS
Single-tenant SaaS
Single tenancy was the first iteration of the SaaS model. Here, 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.
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 going to seal the deal
- 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 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 SaaS
In a multi-tenant architecture, customers share a single instance of the application and database. This is, in general, much better. But there are a few cons, also.
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 as 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 issue is the security concern presented by shared databases – which, again, can be a big no-no in certain verticals. And 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 the top dog when it comes to data isolation.
The reason being that it separates at the data level, which means it keeps data within an individual table nice and separate.
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 as opposed to multiple buildings.
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 that separates their tables from each other.
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. Just don’t think about whether these buildings contain tables and you’ll be fine.
One particular disadvantage of schema security 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-tenant 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 than could be knocked up using last-gen tech.
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 microservice-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
- Each service can be swapped out or changed up without causing problems for other services
- Better fault isolation
- It’s more technology and language agnostic
Containers
Containers are a lighter type of VM. They lack a virtual OS, meaning:
- They’re lighter and consume fewer resources
- They can be scaled more cheaply
- They’re more technology agnostic
When deploying a SaaS app as microservices and containers, the goal is to deploy one service per container.
Orchestration
Step 1: split your SaaS app into microservices. Step 2: package each microservice into a container. Step 3: devote hundreds of hours to managing each individual container and go bust.
Alternative step 3: orchestration.
Orchestration tools like Kubernetes and Amazon EKS manage and automate deployment and ops work as well as 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 also 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 of this are:
- Lower TCO, since your infrastructure literally doesn’t exist most of the time
- Frees up devs to focus on business logic
- Scales more effectively
If you wanted a SaaS app built as a serverless, containerised microservices architecture, you can!
There are container 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. It all interrelates.
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 or DaaS (DevOps as a service) 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:
- 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 (for more info on how to tackle SaaS downtime see here)
- 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 to 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’s 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 solution, 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!