In our previous post, "Centralised Control Planes for SaaS - Part 2," we discussed about the approaches to build a stateless control plane and how to handle async communication b/w the data planes and cloud provider. In this instalment we take dive into the physical and logical models in a SaaS control planes.

Introduction​

As we build a robust SaaS architecture understanding of logical and physical mappings is essential. These mappings serve as tools in aiding SaaS developers in the translation of user-facing processes into corresponding SaaS backend workflows.

Logical Model and Physical Model​

The logical model encompasses metadata pertaining to various aspects of the system:

• Organisations: Every user using the SaaS platform belongs to an organisation. Organisation is a customer for the SaaS provider.
• Tiers or Plans: The different levels of service or subscription plans offered to users.
• Workspaces: Dedicated spaces for users to collaborate and deploy applications.
• Applications: Software applications and services provided within the SaaS framework.

This metadata is stored in metadata DB. It is important to note that for each logical entity, there exists a corresponding physical entity in the system.

The physical model, deals with the tangible, real-world bindings to the underlying infrastructure that supports the SaaS architecture. These physical include:

• Customer: A customer is an organisation.
• Data Planes: Data Planes are where the software is deployed. They can be in the SaaS provider network or in the customer network.
• Tenants: Segregated sections or environments within the architecture, often employed for multi-tenancy support.
• Applications: Application denotes the SaaS provider's application.

Relationship Model​

Here we understand the relation between each of the components described within the logical and physical model.

Organisation, Workspace and Applications ( Logical )​

• Organisation onboarded is a customer for the SaaS Provider.
• Organisation can consists of a single workspace or multiple workspace.

Tiers or Plans and SaaS Types ( Logical to Physical )​

• A Tier or Plan is offered by the SaaS provider.
• Each Tier or Plan has a quota limit on the usage of the SaaS product.
• Organisation onboarded have a SaaS Tier associated with them.
• Each tier is mapped to a SaaS Type.

SaaS Types and Data Planes ( Conceptual to Physical )​

• Each SaaS Type is mapped to a data plane.
  note

  SaaS Type is a conceptual model. Each SaaS Type has a physical mapping ie data planes. Data Planes as an abstraction consist of network, storage and kubernetes.

  

End to End Mapping between Logical and Physical Models​

• The logical entities is metadata stored in the database.
• For each entity stored a physical entity is created.

Summary​

SaaS architecture relies on logical and physical models. These models aid developers in bridging user processes with backend workflows. If you are building a SaaS, and want to build a control plane, feel free to get connected with us.

For a couple of years, my journey has revolved around constructing control planes for data infrastructure startups. As an engineer I have been fortunate to gain invaluable insights into the challenges and intricacies of developing successful SaaS products. Drawing from my firsthand experiences, this series of blog post's delves into the lessons learned and shares my goals at DataInfra, where I am building a centralised control plane for SaaS infrastructure. Join me as we explore the critical aspects and key considerations of constructing effective control planes in the dynamic and competitive SaaS industry.

Introduction

Before we delve into the content, let's address the ambiguity surrounding the term "Control Plane for SaaS Infrastructure." In the context of SaaS infrastructure, the control plane refers to the centralised system that governs and orchestrates the deployment, configuration, and operation of applications and services on data planes. Data Planes can exist within the SaaS providers network or at the customer premise. By SaaS Infra, I specifically mean the service provisioning layer in a SaaS product.

SaaS Architecture Layers​

Let's discuss a high level approach of SaaS architecture layers.

In our previous post, "Centralised Control Planes for SaaS - Part 1," we delved into the world of SaaS business models and the challenges that arise when constructing a centralised control plane. In this instalment, we will take a closer look at the crucial first step in building a control plane: the design of an asynchronous event handling system. This system plays a pivotal role in creating infrastructure, managing tenants, and deploying applications within a SaaS environment. Moreover, we will explore two distinct schools of thoughts : application developer versus infrastructure developer.

Introduction​

In the realm of SaaS, the control plane serves as an orchestrator of fundamental operations. Our focus here lies specifically within the service provisioning layer. This layer enables the control plane to execute CRUD operations on various entities. Let's break down these operations:

In this article, we explore the use cases of Helm and Kubernetes operators, demystifying when to use each tool, based on DataInfra's experience in developing and maintaining Kubernetes operators, controllers, and libraries

Introduction

In the realm of software development, the principle of separation of concerns holds great significance. It emphasises the need to divide a system into distinct parts, each responsible for a specific aspect of functionality. This approach promotes modularity, maintainability, and scalability, allowing developers to focus on specific areas without unnecessary dependencies. When it comes to managing Kubernetes deployments, the Helm tool and the operator pattern play crucial roles in adhering to this principle. In this blog post, we will explore the separation of concerns in Helm and the benefits of using operators in Kubernetes deployments.

DataInfra is at the forefront of democratizing running real-time analytical workloads on Kubernetes, with a particular focus on OLAP stores and query engines. We have delved deep into the Kubernetes API and have extended the Kubernetes control plane to create a seamless user experience for running real-time analytics infrastructure on Kubernetes.

Current State of Real-Time Analytics on Kubernetes

The need for real-time analytics has never been greater than it is today. With the increase of data sources and the speed at which data is generated, organizations want to analyze and derive insights from their data in real-time.

Setting up and scaling a real-time analytics pipeline with current tooling can be challenging. Many of the available tools are complex, distributed, and not designed to run on Kubernetes. This has led to a lack of standard, scalable, and extensible ways to define distributed systems in a Kubernetes-native way.