The Two Halves of Every SaaS Architecture
If we step back from the details of SaaS, we typically find that every SaaS environment–independent of its domain or design–can be broken down into two very distinct halves. In fact, across our entire discussion of SaaS across this book, you’ll find that we’ll use these two halves as the lens through which we’ll look at how a multi-tenant system is built, deployed, and operated.
Figure 2-3 provides a conceptual representation of the two halves of SaaS. On the right-hand side of the diagram, you’ll see what is labeled as the control plane. The control plane is where we’ll place all of the cross-cutting constructs, services, and capabilities that support the foundational needs of a multi-tenant SaaS environment.
Figure 2-3. SaaS application and control planes
We often describe the control plane as the single pane of glass that is used to orchestrate and operate all the moving parts of your SaaS solution. It is at the core of enabling many of the principles that are essential to the success of your SaaS business. Concepts like tenant onboarding, billing, metrics, and a host of other services live in this control plane. You’ll also see that our control plane includes an administration application. This represents the console or administration experience that is used by a SaaS provider to configure, manage, and operate their SaaS environment.
One interesting caveat here is that the services running in the control plane are not built or designed as multi-tenant services. If you think about it, there’s actually nothing multi-tenant about the capabilities of the control plane. It doesn’t have functionality that supports the needs of individual tenants. Instead, it provides the services and functionality that spans all tenants.
While architects and builders are often tempted to start the SaaS discussion with the multi-tenant aspects of their application, the foundations of your SaaS architecture often start with the control plane. In many respects, the control plane provides a forcing function, requiring engineers to inject and support the nuances of tenancy from the outset of their development.
In contrast, the application plane is where the features and functionality of your SaaS service are brought to life. This is where we see the manifestation of all the multi-tenant principles that are classically associated with SaaS environments. It’s here that we focus more of our attention on how multi-tenancy will shape the design, functionality, security, and performance of our service and its underlying resources. Our time and energy in the application plane is focused squarely on identifying and choosing the technologies, application services, and architecture patterns that best align with the parameters of your environment, timelines, and business. This is where you pour your energy into building out an application footprint that embraces agility and enables the business to support a range of personas and consumption models.
It’s important to note that there is no single design, architecture, or blueprint for the application plane. I tend to view the application plane as a blank canvas that gets painted based on the unique composition of services and capabilities that my SaaS service requires. Yes, there are themes and patterns that we’ll see that span SaaS application architectures. In fact, by the end of this book, you’ll certainly have a healthy respect for the degree to which SaaS applications can vary from one solution to the next. Business, domain, and legacy realities are amongst a long list of factors that can influence the shape of your multi-tenant application strategy.
This view of the two halves of SaaS aligns with the mental model of multi-tenancy that we discussed in Chapter 1. Our application plane could share all tenant infrastructure or it could have completely dedicated infrastructure and it wouldn’t matter. As long as we have a control plane that manages and operates these tenant environments through a unified experience, then we’re considering this a multi-tenant environment.
This separation of concerns also influences our mental model for how the elements of our SaaS environment are updated and evolved. The services and capabilities of the control plane are versioned, updated, and deployed based on the needs of the SaaS provider, providing a range of services that reduce friction, enable centralized operations, and provide system-wide insights that are used to analyze the activity, scaling, and consumption patterns of all of your tenants. Meanwhile, our application plane is being driven more by the needs and experience of the system’s tenants. Here, updates and deployments are introduced to provide new features, enhance tenant performance, support new tiering strategies, and so on.
Together, these two halves of SaaS represent the most fundamental building blocks of any SaaS environment. Understanding the roles of these planes will have a significant influence on how you’ll approach the architecture, design, and decomposition of your SaaS offering.