Understanding Architecture Strategies for SaaS Web Applications

Table of Contents

• Introduction

• Software as a Service Overview

• SaaS Business model

• SaaS Application architecture

  • SaaS Maturity Model

• Summary

Introduction

My experience as a frontend developer mostly has me primarily focused on delivering a consistent user experience to each user of an hypothetical userbase. In extending into designing and building web applications, I quickly found the complexity of overlapping requirements multiplying when compared to delivering websites, where the requirements are much more linear.

After levelling up my understanding of deploying and managing databases, user authentication and authorisation methods such as RBAC, I soon stumbled felt the requirement to understand a multi-tenancy setup growing in weight. The learning never stops.

In researching Backend as a Service offerings to facilitate this, I landed on this supabase issue, which sent me on a path to strengthen my foundational knowledge for conceptualising application solutions and the associated core concepts.

This blog serves as the first post summarising my learning from a series of articles ^{[1] [2]} published by Microsoft in 2006 to demystify the Software as a Service (SaaS) model. This post heavily references:

• Architecture Strategies for Catching the Long Tail, April 2006, Frederick Chong and Gianpaolo Carraro Microsoft Corporation

Software as a Service Overview

Defined as:

Software deployed as a hosted service and accessed over the Internet.

While this broad stroke definition isn't immediately useful to a developer or architect, defining key attributions and two major categories help us begin to classify the SaaS model.

Key attributes are profiled as:

• configurability
• multi-tenant efficiency
• scalability

Two major categories are presented as:

• line of business services: offered to enterprises and organisations to facilitate business processes (i.e. finances, inventory control, marketing), typically sold on subscription basis
• consumer-oriented services: offered to general public as consumer service, typically sold on subscription basis, but can leverage freemium or advertising models

Three areas that require strategy synergy to accommodate the SaaS model are:

• Business model
• Application architecture
• Operational structure

SaaS Business model

A traditional IT company might have budgeted for software, hardware and professional services in approximately equal portions. However a business chiefly relying upon SaaS products to fulfil its business can expect software subscriptions to dwarf hardware and services costs.

Hardware is relegated to a "means to an end" to access mostly self-serving cloud-based SaaS platforms. Economy of Scale is therefore leveraged, as infrastructure, hardware, services and specialist staff resourcing is centralised, optimised and accommodating of new "long tail" business opportunities. ^[3]

SaaS Application architecture

A well architected SaaS application is:

• scalable: maximising concurrency and using application resources efficiently, pooling resources, caching data, and partitioning databases
• multi-tenant efficient: an application instance may accommodating hundreds of other companies, all unbeknownst to any of the users.
• configurable: given the shared codebase, customising the application is achieved through metadata, configuration and plugin patterns, limiting development and operational costs to deliver per customisation.

Multi-tenancy may be the most significant paradigm shift that an architect accustomed to designing isolated, single-tenant applications has to make.

— Bhaskardeep ^[4]

SaaS Maturity Model

There are four levels of application maturity that layer in the attributions identified above:

1. Level I: Ad Hoc/Custom: Traditional offering, with each customer receiving their own bespoke hosted and individually configured application, hosted on individual hardware. Vendors might reduce costs by leveraging Infrastructure as a Service.
2. Level II: Configurable: Vendor hosts a separate instance for each customer/tenant, but shares the same code implementation. Unique requirements are achieved through configuration patterns. Requires sufficient hardware and storage to facilitate multiple concurrent instances.
3. Level III: Configurable, Multi-Tenant-Efficient: A single instance serves every customer, with metadata providing user experience and functional variances. Authorisation and security policies ensure users don't perceive shared tenancy. Benefits include efficient computing resources, although at the cost of scalability, unless database partitioning manages storage performance.
4. Level IV: Scalable, Configurable, Multi-Tenant-Efficient: Multiple hosts share load-balanced farm of identical instances, with siloed data and configurable metadata. Scalable to an arbitrary number of users based on demand, capable of rolling out fixes, changes and features easily.

Choosing a maturity level requires consideration for the business model (costs, legal, culture), architectural model (desktop migration vs net-native) and operational model (SLAs, downtime, disaster recovery).

Summary

The key attributes of SaaS platforms include configurability, multi-tenant efficiency and scalability, and are delivered as B2B or B2C services typically commercialised by subscriptions. Hardware is relegated as a means to an end, as businesses delegate infrastructure management to the service provider, where economies of scale are introduced, opening new "long tail" market opportunities.

Four levels of application maturity are identified which layer in complexity to match business, architectural and operational models.

While application architectures are complex, categorising their complexity and modelling requirements within the business domain give shape to the type of solution we can design and build.