Inside the Control Plane

Assessing monitoring and alerting policies – Walk-Through – Assessing Change Management, Logging, and Monitoring Policies

Posted on by Daniel Duggins

Assessing monitoring and alerting policies

As we covered in Chapter 7, Tools for Monitoring and Assessing, cloud monitoring is a method of reviewing, observing, and managing the health and security of a cloud. Using monitoring tools, organizations can proactively monitor their cloud environments to identify issues before they become security risks. AWS, Azure, and GCP offer native solutions that an IT auditor can leverage to monitor and assess cloud environments. Let us start by looking at AWS.

AWS

The first monitoring tool an IT auditor can leverage in AWS is Amazon CloudWatch.

Amazon CloudWatch

Amazon CloudWatch is an AWS native monitoring and management service that is designed for the purpose of monitoring the services and resources that are used. Amazon CloudWatch can be used to collect and track metrics, monitor log files, and set alarms, among many other functions. To review these findings, we will need to perform the following steps to launch Amazon CloudWatch, as seen in Figure 10.24:

  1. Navigate to the AWS Management Console.
  2. Select CloudWatch | Dashboards.

Figure 10.24 – Amazon CloudWatch

Under Dashboards, an IT auditor can create custom dashboards. Under Automatic dashboards, you can pick further options. In this scenario, we have picked Billing and CloudWatch Logs to add to our custom packtestdashboard dashboard, as seen in Figure 10.25:

Figure 10.25 – CloudWatch | Dashboards

You can see the dashboard displays billing information for different services as well as CloudWatch logs, as seen in Figure 10.26:

Figure 10.26 – CloudWatch | packtestdashboard

Amazon CloudWatch also has a feature named CloudWatch Alarms that an IT auditor can leverage. CloudWatch Alarms has the functionality to monitor defined metric changes that have crossed a specified threshold. To launch Alarms within Amazon CloudWatch, as seen in Figure 10.27, perform the following steps:

  1. Navigate to the AWS Management Console.
  2. Select CloudWatch | Alarms.

Figure 10.27 – CloudWatch | Alarms

An IT auditor can create an alarm that triggers when a certain metric changes. I will provide examples of two rules an IT auditor can create.

Note

For detailed instructions on creating CloudWatch alarms, go to:

In our first example, we select a metric that triggers an alarm when an AWS Simple Storage Service (S3) bucket permission changes, as seen in Figure 10.28. An IT auditor could use this rule to monitor changes in S3 buckets. They could also use this rule to look for misconfigured S3 buckets that allow public access. This is one of the most common security misconfiguration risks within AWS.

Figure 10.28 – Amazon S3 Bucket Permissions metric

In our second example, we can select the Large Number of EC2 Security Group Rules Applied to an Instance metric to trigger an alarm, as seen in Figure 10.29:

Figure 10.29 – The Large Number of EC2 Security Group Rules Applied to an Instance metric An IT auditor could use this rule to monitor for malicious activity or insider threat activity where a user would add security groups to an EC2 instance, bypassing the regular process.

Now that we have looked at monitoring tools in AWS, let us look at tools we can leverage in Azure.

Azure

One of the tools an IT auditor can leverage for monitoring in Azure is Azure Monitor.

Azure Monitor

As we mentioned earlier, Azure Monitor aggregates and correlates data across Azure cloud resources. Within Azure Monitor, there is a useful feature named Change Analysis. Change Analysis detects and helps monitor various types of changes, from the infrastructure layer through application deployment, as seen in Figure 10.30:

To launch Change Analysis within Azure Monitor, perform the following steps:

  1. Navigate to the Microsoft Azure portal.
  2. Select Monitor | Change Analysis.

Figure 10.30 – Azure Monitor | Change Analysis

Azure Monitor also has the ability to trigger alerts. This can be done through the configuration of alert rules. Perform the following steps to launch Alerts within Azure Monitor, as seen in Figure 10.31:

  1. Navigate to the Microsoft Azure portal.
  2. Select Monitor | Alerts.

An IT auditor can set up alerts for various conditions. In this example, we are setting up alerts for All Administrative Operations over the last week, as seen in Figure 10.31:

Figure 10.31 – Azure Monitor | Alert rules

This type of rulecan be useful to an IT auditor to monitor administrative operations and ensure they are authorized.

For illustration, we went ahead and performed some administrative operations. The alerts were triggered, as seen in Figure 10.32. The IT auditor can perform further investigations on the alerts:

Figure 10.32 – Azure Monitor | Alerts

In addition, an IT auditor can create an activity log alert rule from the Activity log plane. The Activity log plane contains information about Azure resource changes. Use the following steps to launch Activity log within Azure Monitor, as seen in Figure 10.33:

  1. Navigate to the Microsoft Azure portal.
  2. Select Monitor | Activity log.

Figure 10.33 – Azure Monitor | Activity log

To create an alert, select any activity within Activity log. In this example, I selected one of the events,

Create or Update Network Security Group, as seen in Figure 10.34:

Figure 10.34 – Alert Rule: Create or Update Network Security Group

Now that we have looked at monitoring tools in Azure, let us look at tools we can leverage in GCP.

The Classic Software Model – The SaaS Mindset

Posted on by Daniel Duggins

The Classic Software Model

Before we can dig into the defining SaaS, we need to first understand where this journey started and the factors that have driven the momentum of the SaaS delivery model. Let’s start by looking at how software was traditionally built, operated, and managed. These pre-SaaS systems were typically delivered in an “installed software” model where companies were hyper-focused on the features and functions of their offerings.

In this model, software was sold to a customer and that customer often assumed responsibility for installing the system. They might install it in some vendor-provided environment or they might install it on self-hosted infrastructure. The acquisition of these offerings would, in some cases, be packaged with professional services teams that could oversee the installation, customization, and configuration of the customer’s environment.

Figure 1-1 provides a conceptual view of the footprint of the traditional software delivery model.

Figure 1-1. The installed software model

Here, you’ll see a representation of multiple customer environments. We have Customers 1 and 2 that have installed and are running specific versions of the software provider’s product. As part of their onboarding, they also required one-off customizations to the product that were addressed by the provider’s professional services team. We also have other customers that may be running different versions of our product that may or may not have any customizations.

As each new customer is onboarded here, the provider’s operations organization may need to create focused teams that can support the day-to-day needs of these customer installed and customized environments. These teams might be dedicated to an individual customer or support a cross-section of customers.

This classic mode of software delivery is a much more sales driven model where the business focuses on acquiring customers and hands them off to technology teams to address the specific needs of each incoming customer. Here, landing the deal often takes precedence over the need for agility, scale, and operational efficiency. These solutions are also frequently sold with long-term contracts that limit a customer’s ability to easily move to any other vendor’s offering.

The distributed and varying nature of these customer environments often slowed the release and adoption of new features. Customers tend to have control in these settings, often dictating how and when they might upgrade to a new version. The complexity of testing and deploying these environments could also become unwieldy, pushing vendors toward quarterly or semi-annual releases.

The Advantage of Shared Infrastructure – The SaaS Mindset

Posted on by Daniel Duggins

The Advantage of Shared Infrastructure

So, we can see how SaaS moves us more toward a unified infrastructure footprint. If we contrast this with the one-off, installed software model we covered above, you can see how this approach enables us to overcome a number of challenges.

Now that we have a single environment for all customers, we can manage, operate, and deploy all of our customers through a single pane of glass. Imagine, for example, what it would look like to deploy an update in the shared infrastructure model. We would simply deploy our new version to our unified SaaS environment and all of our tenants would immediately have access to our new features. Gone is the idea of separately managed and operated versions. With SaaS, every customer is running the same version of your application. Yes, there may be customizations within that experience that are enabled/disabled for different personas, but they are all part of a single application experience.

Note

This notion of having all tenants running the same version of your offering represents a common litmus test for SaaS environments. It is foundational to enabling many of the business benefits that are at the core of adopting a SaaS delivery model.

You can imagine the operational benefits that come with this model as well. With all tenants in one environment, we can manage, operate, and support our tenants through a common experience. Our tools can give us insights into how tenants are consuming our system and we can create policies and strategies to manage them collectively. This brings all new levels of efficiency to our operational model, reducing the complexity and overall footprint of the operational team. SaaS organizations take great pride in their ability to manage and operate a large collection of tenants with modestly sized operational teams.

This focus on operational efficiency also directly feeds the broader agility story. Freed from the burden of one-off, custom versions, SaaS teams will often embrace their agility and use it as the engine of constant innovation. These teams are continually releasing new features, gathering more immediate customer feedback, and evolving their systems in real-time. You can imagine how this model will directly impact customer loyalty and adoption.

The responsiveness and agility of this SaaS model often translates into competitive advantages. Teams will use this agility to reach new market segments, pivoting in real-time based on competitive and general market dynamics.

The shared infrastructure model of SaaS also has natural cost benefits. When you have shared infrastructure and you can scale that infrastructure based on the actual consumption patterns of your customers, this can have a significant impact on the margins of your business. In an ideal SaaS infrastructure model, your system would essentially only consume the infrastructure that is needed to support the current load of your tenants. This can represent a real game-changer for some organizations, allowing them to take on new tenants at any pace knowing that each tenant’s infrastructure costs will only expand based on their actual consumption activities. The elastic, pay-as-you-go nature of cloud infrastructure aligns nicely with this model, supporting the pricing and scaling models that fit naturally with the varying workloads and consumption profiles of SaaS environments.

Re-Defining Multi-Tenancy 2 – The SaaS Mindset

Posted on by Daniel Duggins

Here you’ll see that we’ve morphed the footprint of some of our application microservices. The Product microservice is unchanged. Its compute and storage infrastructure is still shared by all tenants. However, as we move to the Order microservice, you’ll see that we’ve mixed things up a bit. Our domain, performance, and/ or our security requirements may have required that we separate out the storage for each tenant. So, here the compute of our Order microservice is still shared, but we have separate databases for each tenant.

Finally, our Fulfillment microservice has also shifted. Here, our requirements pushed us toward a model where each tenant is running dedicated compute resources. In this case, though, the database is still shared by all tenants.

This architecture has certainly added a new wrinkle to our notion of multi-tenancy. If we’re sticking to the purest definition of multi-tenancy, we wouldn’t really be able to say everything running here conforms to the original definition of multi-tenancy. The storage of the Order service, for example, is not sharing any infrastructure between tenants. The compute of our Fulfillment microservices is also not shared here, but the database for this service is shared by all tenants.

Blurring these multi-tenant lines is common in the SaaS universe. When you’re composing your SaaS environment, you’re not sticking to any one absolute definition of multi-tenancy. You’re picking the combinations of shared and dedicated resources that best align with the business and technical requirements of your system. This is all part of optimizing the footprint of your SaaS architecture around the needs of the business.

Even though the resources here are not shared by all tenants, the fundamentals of the SaaS principles we outlined earlier are still valid. For example, this environment would not change our application deployment approach. All tenants in this environment would still be running the same version of the product. Also, the environment is still being onboarded, operated, and managed by the same set of shared services we relied on in our prior example. This means that we’re still extracting much of the operational efficiency and agility from this environment that would have been achieved in a fully shared infrastructure (with some caveats).

To drive this point home, let’s look at a more extreme example. Suppose we have a SaaS architecture that resembles the model shown in Figure 1-7. In this example, the domain, market, and/or legacy requirements have required us to have all compute and storage running in a dedicated model where each tenant has a completely separate set of infrastructure resources.

Figure 1-7. A multi-tenant environment with fully dedicated resources

Re-Defining Multi-Tenancy 3 – The SaaS Mindset

Posted on by Daniel Duggins

While our tenants aren’t sharing infrastructure in this model, you’ll see that they continue to be onboarded, managed, and operated through the same set of shared services that have spanned all of the examples we’ve outlined here. That means that all tenants are still running the same version of the software and they are still being managed and operated collectively.

This may seem like an unlikely scenario. However, in the wild, SaaS providers may have any number of different factors that might require them to operate in this model. Migrating SaaS providers often employ this model as a first stepping stone to SaaS. Other industries may have such extreme isolation requirements that they’re not allowed to share infrastructure. There’s a long list of factors that could legitimately land a SaaS provider in this model.

So, given this backdrop, it seems fair to ask ourselves how we want to define multi-tenancy in the context of a SaaS environment. Using the literal shared infrastructure definition of multi-tenancy doesn’t seem to map well to the various models that can be used to deploy tenant infrastructure. Instead, these variations in SaaS models seem to demand that we evolve our definition of what it means to be multi-tenant.

For the scope of this book, at least, the term multi-tenant will definitely be extended to accommodate the realities I’ve outlined here. As we move forward, multi-tenant will refer to any environment that onboards, deploys, manages, and operates tenants through a single pane of glass. The sharedness of any infrastructure will have no correlation to the term multi-tenancy.

In the ensuing chapters, we’ll introduce new terminology that will help us overcome some of the ambiguity that is attached to multi-tenancy.

Avoiding the Single-Tenant Term

Generally, whenever we refer to something as multi-tenant, there’s a natural tendency to assume there must be some corresponding notion of what it means to be single-tenant. The idea of single tenancy seems to get mapped to those environments where no infrastructure is shared by tenants.

While I follow the logic of this approach, this term doesn’t really seem to fit anywhere in the model of SaaS that I have outlined here. If you look back to Figure 1-7 where our solution had no shared infrastructure, I also noted that we would still label this a multi-tenant environment since all tenants were still running the same version and being managed/operated collectively. Labeling this a single-tenant would undermine the idea that we aren’t somehow realizing the benefits of the SaaS model.

With this in mind, you’ll find that the term single-tenant will not be used at any point beyond this chapter. Every design and architecture we discuss will still be deemed a multi-tenant architecture. Instead, we’ll attach new terms to describe the various deployment models that will still allow us to convey how/if infrastructure is being shared within a given SaaS environment. The general goal here is to disconnect the concept of multi-tenancy from the sharing of infrastructure and use it as a broader term to characterize any environment that is built, deployed, managed, and operated in a SaaS model.

This is less about what SaaS is or is not and more about establishing a vocabulary that aligns better with the concepts we’ll be exploring throughout this book.

The Managed Service Provider Model – The SaaS Mindset

Posted on by Daniel Duggins

The Managed Service Provider Model

There’s one last wrinkle that we need to address as we try to refine our view of what it means to be a multi-tenant SaaS environment. Some organizations have opted into what’s referred to as a Managed Service Provider (MSP) model. In some cases, they’ll categorize MSP as a variant of SaaS. This certainly has created some confusion in the SaaS domain. To better understand the challenges here, let’s start by looking at an MSP environment and see how/where it fits in this discussion. Figure 1-8 provides a conceptual view of an MSP environment.

Figure 1-8. A Managed Service Provider (MSP) model

This model definitely resembles the classic installed software model that we outlined earlier. At the bottom of this diagram, you’ll see a collection of customers that are running various versions of a software vendor’s product. Each one of these customers will be running in its own infrastructure/environment.

With MSP, though, we’ll try to get efficiencies and economies of scale out of moving the operations to a centralized team/entity. This is the service that these MSPs provide. They often own responsibility for installing, managing, and supporting each of these customers, attempting to extract some scale and efficiency out of tooling and mechanisms that they use to operate these customer environments.

I’ve also represented the software vendor at the top of the diagram. This is here to convey the idea that the software provider may have third-party relationships with one or more MSPs that are managing their customer environments.

You can see how some might equate the MSP model to SaaS. Afterall, it does seem to be trying to provide a unified managed and operations experience for all customers. However, if you look back at the principles that we used to describe SaaS, you can see where there are substantial gaps between MSP and SaaS. One of the biggest differences here is that customers are being allowed to run separate versions. So, while there may be some attempts to centralize management and operations, the MSP is going to have to have one-off variations in their operational experience to support the different footprints of each customer environment. This may require dedicated teams or, at a minimum, it will mean having teams that can deal with the complexities of supporting the unique needs of each customer. Again, MSP still adds lots of value here and certainly creates efficiencies, but it’s definitely different than having a single pane of glass that gets its efficiencies from having customers run a single version of a product and, in many cases, getting efficiencies from sharing some or all of their infrastructure. At some level in the MSP model, you’re likely to still inherit aspects of the pain that comes with one-off customer variations. MSPs can introduce some measures to offset some of the challenges here, but they’ll still face the operational and agility complexities that come with supporting unique, one-off needs of separate customer environments.

The other difference here relates more to how SaaS teams are structured and operated. Generally, in a SaaS organization, we’re attempting to avoid drawing hard lines between operations teams and the rest of the organization. We want operations, architects, product owners, and the various roles of our team working closely together to continually evaluate and refine the service experience of their offering.

This typically means that these teams are tightly connected. They’re equally invested in understanding how their tenants are consuming their systems, how their imposing load, how they’re onboarding, and a host of other key insights. SaaS businesses want and need to have their fingers on the pulse of their systems. This is core to driving the success of the business and being connected more directly to the overall tenant experience. So, while this is a less concrete boundary, it still represents an important difference between SaaS and MSP.

Now, it’s important to note that MSP is an entirely valid model. It often represents a good fit for some software providers. MSP can even be a stepping stone for some SaaS providers, providing access to some efficiencies while the team continues to push forward toward its SaaS delivery model. The key here is that we have a clear understanding of the boundaries between SaaS and MSP and avoid viewing SaaS and MSP as somehow being synonymous.

At its Core, SaaS is a Business Model – The SaaS Mindset

Posted on by Daniel Duggins

At its Core, SaaS is a Business Model

By now you should have a better sense of how we characterize what it means to be SaaS. It should be clear that SaaS is very much about creating a technology, business, and operational culture that is focused squarely on driving a distinct set of business outcomes. So, while it’s tempting to think about SaaS through the lens of technology patterns and strategies, you should really be viewing SaaS more as a business model.

To better understand this mindset, think about how adopting SaaS impacts the business of a SaaS provider. It directly influences and shapes how teams build, manage, operate, market, support, and sell their offerings. The principles of SaaS are ultimately woven into the culture of SaaS companies, blurring the line between the business and technology domains. With SaaS, the business strategy is focused on creating a service that can enable the business to react to current and emerging market needs without losing momentum or compromising growth.

Yes, features and functions are still important to SaaS companies. However, in a SaaS company, the features and functions are never introduced at the expense of agility and operational efficiency. When you’re offering a multi-tenant SaaS solution, the needs of the many should always outweigh the needs of the few. Gone are the days of chasing one-off opportunities that require dedicated, one-off support at the expense of long-term success of the service.

This shift in mindset influences almost every role in a SaaS company. The role of a product owner, for example, changes significantly. Product owners must expand their view and consider operational attributes as part of constructing their backlog. Onboarding experience, time to value, agility–these are all examples of items that must be on the radar of the product owner. They must prioritize and value these operational attributes that are essential to creating a successful SaaS business. Architects, engineers, and QA members are equally influenced by this shift. They must now think more about how the solution they’re designing, building, and testing will achieve the more dynamic needs of their service experience. How your SaaS offering is marketed, priced, sold, and supported also changes. This theme of new and overlapping responsibilities is common to most SaaS organizations.

So, the question is: what are the core principles that shape and guide the business model of SaaS companies? While there might be some debate about the answer to the question, there are some key themes that seem to drive SaaS business strategies. The following outlines these key SaaS business objectives:

Agility

This term is often overloaded in the software domain. At the same time, in the SaaS universe, it is often viewed as one of the core pillars and motivating factors of the SaaS business. So many organizations that are moving to SaaS are doing so because they’ve become operationally crippled by their current model. Adopting SaaS is about moving to a culture and mindset that puts emphasis on speed and efficiency. Releasing new versions, reacting to market dynamics, targeting new customer segments, changing pricing models–these are amongst a long list of benefits that companies expect to extract from adopting a SaaS model. How your service is designed, how it’s operated, and how it’s sold are all shaped by a desire to maximize agility. A multi-tenant offering that reduced costs without realizing agility would certainly miss the broader value proposition of what it means to be a SaaS company.

At its Core, SaaS is a Business Model 3 – The SaaS Mindset

Posted on by Daniel Duggins

Growth

Every organization is about growth. However, SaaS organizations typically have a different notion of growth. They are investing in a model and an organizational footprint that is built to thrive on growth. Imagine building this highly efficient car factory that optimized and automated every step in the construction process. Then, imagine only asking it to produce two cars a day. Sort of pointless. With SaaS, we’re building out a business footprint that streamlines the entire process of acquiring, onboarding, supporting, and managing customers. A SaaS company makes this investment with the expectation that it will help support and fuel the growth machine that ultimately influences the margins and broader success of the business. So, when we talk about growth here, we’re talking about achieving a level of acceleration that couldn’t be achieved without the agility, operational efficiency, and innovation that ‘s part of SaaS. How much growth you’re talking here is relative. For some, growth may be adding 100 new customers and for others it could mean adding 50,000 new customers. While this nature of your scale may vary, the goal of being growth-focused is equally essential to all SaaS businesses.

The items outlined here represent some of the core SaaS business principles. These are concepts that should be driven from the top down in a SaaS company where the leadership places clear emphasis on driving a business strategy that is focused on creating growth through investment in these agility, operational efficiency, and growth goals.

Certainly, technology will end up playing a key role in this business strategy. The difference here is that SaaS is not a technology first mindset. A SaaS architect doesn’t design a multi-tenant architecture first then figure out how the business strategy layers on top of that. Instead, the business and technology work together to find the best intersection of business goals and multi-tenant strategies that will realize those strategies.

As we get further into architecture details, you’ll see this theme is laced into every dimension of our architecture. As we look at topics like tenant isolation, data partitioning, and identity, for example, you’ll see how each of these areas are directly influenced by a range of business model considerations.

Building a Service–Not a Product – The SaaS Mindset

Posted on by Daniel Duggins

Building a Service–Not a Product

Many software providers would view themselves as being in the business of creating products. And, in many respects, this aligns well with their business model. The mindset here is focused on a pattern where we build something, the customer acquires it, and it’s, for the most part, theirs to use. There are plenty of permutations and nuances within this product-centric model, but they all gravitate toward a model that is focused on creating something more static and having customers buy it.

In this product-focused mindset, the emphasis is generally on defining the features and functions that will allow a software provider to close gaps and land new opportunities. Now, with SaaS, we shift from creating a product to creating a service. So, is this just terminology or does it have a meaningful impact on how we approach building a SaaS offering? It turns out, this is certainly more than a terminology shift.

When you offer software as a service, you think differently about what success looks like. Yes, your product needs to meet the functional needs of your customers. That dimension of the problem doesn’t go away. As a service, though, you are much more focused on the broader customer experience across all dimensions of your business.

Let’s look at an example that better highlights the differences between a service and a product. A restaurant provides a good backdrop for exploring these differences. When you go out to dinner, you’re certainly looking forward to the food (the product in this example). However, the service is also a part of your experience. How fast you’re greeted at the door, how soon the waiter comes to your table, how soon you get water, and how quickly your food arrives are all measures of your service experience. No matter how good the food is, your quality of service will have a lot to do with your overall impression of the restaurant.

Now, think about this through the lens of a SaaS offering. Your SaaS tenants will have similar service expectations. How easily they can onboard your solution, how long it takes to realize value, how quickly new features are released, how easily they can provide feedback, how frequently the system is down–they are all dimensions of a service that must be front-and-center for SaaS teams. Having a great product won’t matter if the overall experience for customers does not meet their expectations.

This takes on extra meaning when software is delivered in a SaaS model, where the tenant’s only view of your system is the surface of your SaaS solution. SaaS tenants have no visibility into the underlying elements of your system. They don’t think about patches, updates, and infrastructure configuration. They only care that the service is providing the experience that lets them maximize the value of your solution.

The Two Halves of Every SaaS Architecture – Multi-tenant Architecture Fundamentals

Posted on by Daniel Duggins

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.