Demystifying SaaS Architecture

Introduction

In an old post, I discussed the different cloud service models: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS).  I illustrated these models using the fitness industry.  Most of my experience at AWS has been with building IaaS, while I once built a SaaS product.  I am now working on SaaS products targeted towards businesses.  This post will focus on SaaS and the different deployment options. 

Over the last two decades, we have seen a remarkable transformation in how we access and utilize software.  I remember setting up the Wind River licensing server to manage licenses to their products.  Sometimes, we would associate the license with the computer on which the software was installed.  On-premise installations offered more control over the software but required more IT involvement and manual license management.  

The emergence of cloud providers fueled the rise of Software as a Service (SaaS).  SaaS applications, delivered via the internet with a subscription model, offered significant advantages over traditional on-premise deployments.  They were more affordable, scalable, and convenient, eliminating the need for expensive licenses and complex installations.  This shift moved software access from physical installations to cloud-based subscriptions, and services like Hotmail (a popular early SaaS offering in the late 90s) paved the way.  SaaS fundamentally transformed how businesses operate, offering on-demand functionality and flexibility.  Today, this convenience has expanded to numerous areas, even leading to the need for a SaaS to manage all the SaaS subscriptions themselves.

Control, Data, and Application Planes

Building large-scale systems requires efficient architecture.  A key concept in distributed systems design is the separation of control and data planes.  The control plane acts as the brain, making strategic decisions about data flow, like optimal routes and resource management.  Think of it as a traffic controller directing the flow.  In contrast, the data plane is the workhorse, responsible for the actual movement of data, following the control plane's instructions.  Many cloud providers utilize this pattern.

AWS separates most services into Control and Data Planes.  My first experience working on control and data planes was with the EC2 team.  Control planes provide administrative APIs to create/update, read, list, or delete resources.  The data plane provides the primary function of the service and, in the case of EC2, running the instance itself.  When my colleague and I transferred to a new team to build a new service, we took the pattern and built a control and data plane.  A competitive situation ensued with the Canadian teams regarding the ownership of the control and data planes.  Opting for a constructive approach, we focused on developing the core logic of the service.  However, this decision did not sit well with my then-manager, who had hoped we would tackle the data plane due to its complexity and the specialized skills it required.  That experience of working on control and data planes has stuck with me, I've found it valuable in designing efficient and scalable systems ever since.

With the advent of SaaS, we now have an Application plane where the backend services represent the business logic and functional elements of a SaaS solution.  This plane focuses on delivering the application logic to the end user, and it interacts with the Data Plane to send/receive data needed for its operations. 

SaaS Deployment Models

SaaS for Business (B2B SaaS) and SaaS for Individuals (B2C SaaS) are two distinct software delivery models, each serving a different target audience.  This post focuses on B2B SaaS; even with B2B SaaS, there is more than one deployment option. 

Moving to a SaaS model introduces the concept of tenancy, which refers to the method of partitioning a SaaS application to support multiple users or tenants in a way that isolates each tenant’s data and configuration from the other tenants.  There are two types of tenancy: single-tenant and Multi-tenant.

Single-tenant: Each customer gets a dedicated instance of the software and infrastructure.  This offers maximum control and security but comes at a higher cost.

Multi-tenant: Multiple customers share a single application codebase and infrastructure.  Data is isolated for each tenant, but resources are pooled for efficiency and lower costs.  This is the more common SaaS model.

Design Influences: 

Infrastructure: The underlying hardware and software resources (like servers, storage, and networking) are shared among all tenants.  This sharing enables efficient utilization of resources.  However, some clients may prefer dedicated infrastructure.

Security and Compliance: B2B SaaS deployments must prioritize security and regulatory compliance to protect sensitive data and meet industry standards like HIPAA, SOC2, and GDPR. 

Data Handling and Storage: B2B SaaS often needs to offer data handling and storage options that comply with business standards and legal requirements. 

Single-Tenant Deployment

This Single-Tenant approach segments customer data and interactions into secure containers in separate GCP Projects or AWS accounts on cloud platforms.  Each deployment operates independently, ensuring isolation beyond just applications and databases.  Control Plane or Shared Services is a centralized suite of services that supports the SaaS infrastructure.  It includes an Identity Platform for secure user authentication, Metrics & Analytics for performance monitoring, Metering & Billing for financial operations, Tenant Management for handling different customer environments, and a Key Management Service for securing sensitive data.  This architecture delivers customers a personalized and secure SaaS experience with strict compliance and security requirements.

Multi-Tenant Deployment

The Multi-Tenant Shared Infrastructure model is the dominant approach in SaaS deployments.  Unlike single-tenant models, it leverages a single application stack to handle customer requests.  This shared infrastructure optimizes resource utilization and cost-effectiveness.  However, data security remains paramount.  Each customer's data is securely isolated and accessed within the same infrastructure, ensuring privacy and compliance.  Like the previous model, a unified Control Plane manages essential services like identity verification, billing, and security for all tenants.

Secure Connect Deployment

The following diagram illustrates a Secure Connect Deployment within a cloud-based SaaS environment.  Customers access applications hosted on a shared cloud infrastructure (AWS, GCP, or Azure) through the Application Plane.  Each application securely connects to its dedicated database located in the customer account in the same region via a private link, ensuring enhanced data security and privacy.

This Secure Connect Deployment model prioritizes data security and privacy while maintaining the efficiency and shared resources essential for multi-tenant SaaS providers.  It achieves a strategic balance between isolation using the Single-Tenant Model and the Multi-Tenant Model described earlier.

On-Prem Deployment

While less common, some customers may require a private deployment due to specific security or compliance needs.  This on-premise deployment model requires a shared responsibility between the SaaS vendor and the client for infrastructure management and security updates.  However, it's important to note that private deployments often incur the highest cost compared to other deployment options.

Conclusion

B2B SaaS deployment offers several options, each with its strengths.  The multi-tenant model is highly cost-effective, making it ideal for many businesses.  However, a single outage can impact multiple customers simultaneously if not designed correctly.  Single-tenant deployments provide the ultimate isolation and control but at a premium price.  Here, issues have minimal impact on other clients.  Striking a balance is the Secure Connect option, suitable for customers with stricter security needs.  It offers some cost advantages of shared resources while maintaining a good isolation level.  While the Control Plane, managing core services like identity and security, is shared across all models, the Application Plane's implementation varies.  Depending on the cloud provider, it can be a single account (or VPC) per client or project-based.  Ultimately, the best deployment choice depends on your business needs, considering budget, security requirements, and desired control level.  You could explore a hybrid approach, combining elements from different models for a tailored solution.