SaaS Factory (The Series) — Understanding the SaaS Factory Architecture (Part 4/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.

In the previous post, we talked about Software as a Service Operations. In today’s post, we will talk about Software as a Service Architecture.

Software as a Service Architecture

If you are diving into SaaS, it is important to understand the big picture of SaaS architecture principles and best practices. These include the agility that usually lies behind an organization’s move to a Software as a Service delivery model, the operational view of SaaS, and the core architectural elements of SaaS environments.

To help with this, AWS developed the SaaS Enablement Framework (SEF). This framework serves as an end-to-end aggregation of the common patterns and practices that are frequently used to build and deliver SaaS solutions on the AWS service stack. The framework addresses the common themes associated with adopting a more agile approach to delivering solutions with a subscription, pay-as-you-go mindset. It is important to note that the framework is not a formal set of tools or technologies. The goal is to give SaaS organizations a clearer view of the common models and value systems that should be considered when delivering SaaS solutions on AWS.

Core SaaS Components

Tenancy and business considerations introduce a layer of SaaS-specific solutions and practices that affect most dimensions of the service stack. In a SaaS context, specific components need to be addressed individually, with individual strategies proposed for each case.

The core SaaS components are:

• Tenant onboarding;
• Application;
• Identity;
• Tenant isolation;
• Data partitioning;
• Profiling and analytics;
• Management and monitoring;
• Metering and billing.

Tenant Onboarding

SaaS solutions usually support a variety of different mechanisms for accessing the SaaS environment. This process also covers the basic elements of onboarding new users, managing their accounts and provisioning the billing area.

At this stage, I see it as shaping and structuring a deeper discussion of the various models that can be leveraged to meet your business’s SaaS agility goals. It is important to note that the framework represents a range of SaaS possibilities. It intentionally avoids suggesting that there is a preferred model.

The reality of SaaS is that there is no one model that fits every environment. The key, then, is simply to put together the palette of options, weigh the trade-offs, and select the model (or hybrid of models) that best fits the current and long-term needs of your market and business dynamics.

Application Component: Identity

Certainly, the protagonist in a Software as a Service offering is the software itself. SaaS is much more focused on addressing “how” the product is delivered to end customers than on “why” that software exists or even “what” it is.

In SaaS contexts, the application component usually needs to account for at least three themes: Identity, Tenant Isolation and Data Partitioning. As far as identity is concerned, profiling involves collecting and correlating data that can inform the technical and business shape of your SaaS offering. The framework describes the different types of data that can be collected to build a robust view of the activity in your system. This profile usually includes aggregating user activity and resource consumption data.

Application Component: Tenant Isolation

As we saw earlier, 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.

Application Component: Enforcing Tenant Isolation

As Tod Golding (AWS Partner Solutions Architect) put it, developing a tenant profile involves understanding the value systems and domain forces that will influence a customer’s willingness to adopt your SaaS solution. Your ability to understand and categorize customer needs can help determine how and where you may need to support tenant variations in your underlying design and architecture.

When we address tenant isolation, it is important to identify their entire usage lifecycle, from resource allocation — such as S3 buckets, DynamoDB tables, among others — to their whole lifecycle of using the software, isolating it horizontally across each component of the software.

Even so, there will be cases in which certain components are fully shared, making it impossible to identify each tenant’s share of usage of that resource — such as an SQS queue, as shown above. In such cases, you need to consider external methods for identifying a tenant’s usage and consumption of that shared resource. In the example above, one could, for instance, account for the volume of data moved by a single tenant within a given time window.

Application Component: Data Partitioning

As you design, develop and build software as a service (SaaS) solutions on Amazon Web Services (AWS), you must think about how you want to partition the data that belongs to each of your customers, who are commonly referred to as tenants in a SaaS environment.

There are several factors (noisy neighbor and data isolation, for example) that influence how you choose to store tenant data. You can choose to store your data in separate storage constructs using a “silo” model, or you can choose to group your data in a “pool” model.

Before we dig into specific strategies, let’s start by talking about how data is usually partitioned in a pooled model. The basic idea of the pooled model is that all tenants’ data is stored in a single structure — which can be isolated at the tenant level, per database, or even by a tenant identifier within the data model, so that the data is identified through a tenant identifier such as TenantID.

There are many approaches to storing data in multi-tenant environments. SaaS architects must identify the mix of data partitioning strategies that will align with the scale, isolation, performance and compliance needs of their SaaS environment. Data partitioning is influenced by the multi-tenant model you are adopting and by the different sharding approaches available for each of the AWS storage services.

With this post, we reach the end of the first part of our series on understanding the SaaS Factory architecture. Keep following the blog for the next chapters of the series.

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

See you in the next post! =)