SaaS Factory (The Series) — Understanding the SaaS Factory Architecture (Part 1/4)

The goal of this post is to provide an introduction to the basic terminology, strategies and patterns applied when building SaaS products on AWS. This material presents a mental model that can be used to dive deeper into SaaS technical content.

First, we need to define what software as a service is. SaaS refers to licensing and delivering software in a centralized way, managed and hosted by a provider, making the software available to customers on a subscription or pay-as-you-go model.

When we talk about Software as a Service, we usually focus heavily on the technology aspects. As with any software solution, there is a natural focus on understanding and implementing the technical nuances needed to meet product requirements. However, hands-on experience implementing and migrating software as a service on AWS shows us that there are many practices and approaches that need to be addressed to ensure a SaaS model is being implemented in the best possible way.

Practice shows that we usually have four major pillars:

• Technology: how data is separated and partitioned, how the infrastructure is architected and provisioned, how a new tenant is onboarded into the environment;
• Operational Model: how the health of the overall environment is managed, how one tenant impacts another, how overall and per-tenant reliability is addressed;
• Delivery Model: how the software is delivered to the customer, what the sign-up and onboarding mechanisms for the environment are, how the tenant is allocated and provisioned for the customer;
• Business Strategy: how the product is delivered and how product strategies are built, which tiers are offered, what the cost and sales model is, how usage costs are billed.

The Overall Structure of Software as a Service

The overall structure of software as a service starts with identifying the tenant. The tenant is the smallest consuming unit of a SaaS product. It is the customer itself. Once the tenant is identified, the first stage of the SaaS journey is the initial onboarding process. It is essential that the subscription process be as low-cost and as “painless” as possible. In other words, there can be no barrier that makes it harder for a new customer to come in.

The second point in the overall SaaS structure concerns the level of isolation of this tenant in the infrastructure. For example: will there be environment segregation for that specific customer? Are the computing resources it uses individual or shared? Can there be, in any way, an intersection between one tenant and another?

For this tenant-level infrastructure management to be possible, it is essential to have a per-tenant operational control panel. You should plan for a subset of resources or features that make it possible to quickly see the overall context of the software as a service, but individually, per tenant.

And for this management to be possible, it is essential to produce data and information about the entire SaaS environment, each tenant, each infrastructure component, as well as about the overall usage and operation of the software.

The Multi-Tenancy Mental Model

The term “software multi-tenancy” refers to a software architecture in which a single instance of the software runs on a server (or computing resource) and serves multiple tenants.

Systems designed this way are often called shared (as opposed to dedicated or isolated). A tenant is a group of users who share common access with specific privileges to the software instance. With a multi-tenant architecture, a software application is designed to give each tenant a dedicated share of the instance — including its data, configuration, user management, individual tenant functionality and non-functional properties. Multi-tenancy contrasts with multi-instance architectures, in which separate software instances operate on behalf of different tenants.

What We See in Practice in Multi-Tenancy

Even though, in the general SaaS context, an approach based on shared infrastructure contexts is what one naturally envisions, what we see in practice is a variety of allocation and architecture approaches for SaaS.

• Silo Model: refers to an architecture in which tenants are given dedicated resources. Imagine, for example, a SaaS environment in which each tenant of your system has a fully independent infrastructure stack. Or perhaps each tenant of your system has a separate database. When some or all of a tenant’s resources are deployed in this dedicated fashion, we refer to it as a silo model. It is important to note that, although the silo has dedicated resources, a silo environment still relies on a shared identity, onboarding and operational experience in which all tenants are managed and deployed through a shared construct. This is what sets SaaS apart from a managed service model, in which customers may run separate versions of your product with separate onboarding, management and operational experiences;
• Pool Model: refers to a scenario in which tenants share resources. This is the more classic notion of multi-tenancy, in which tenants rely on scalable, shared infrastructure to achieve economies of scale, manageability, agility and so on. These shared resources can apply to some or all of the elements of your SaaS architecture, including compute, storage, messaging, etc.;
• Bridge Model: refers to the reality that SaaS businesses are not always exclusively silo or pool. Instead, many systems have a mixed mode, in which part of the system is implemented in a silo model and another part in a pooled model. For example, some microservices in your architecture may be implemented with silo and others may use pool. A service’s regulatory data profile and its noisy-neighbor attributes may push a microservice toward a silo model. Meanwhile, agility, access patterns.

In the next post, we will talk about the benefits and drawbacks of each model and about Software as a Service delivered with Agility.

SaaS Factory (The Series) — How to Build Software as a Service Solutions on AWS

See you in the next post! =)