The Classic Software Model

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 Move to Shared Infrastructure – The SaaS Mindset

Posted on by Daniel Duggins

The Move to Shared Infrastructure

By now, the basic challenges of the traditional model should be clear. While some organizations were struggling with this model, others already understood this approach would simply not scale economically or operationally. Larger business-to-consumer (B2C) software companies, for example, knew that supporting thousands or even millions of customers in a one-off model simply wouldn’t work.

These B2C organizations really represented the early days of SaaS, laying the groundwork for future SaaS evolution. Achieving scale for these organizations was, from the outset, about building systems from the ground up that could support the massive scale of the B2C universe. They thrived based on their ability to operate in a model where all customers were presented with a single, unified experience.

This shift to sharing infrastructure amongst customers opened all new opportunities for software providers. To better understand this, Figure 1-2 provides a conceptual view of how applications can share infrastructure in a SaaS model.

Figure 1-2. A shared infrastructure model

In Figure 1-2 you’ll see a simplified view of the traditional notion of SaaS. You’ll notice that we’ve completely moved away from the distributed, one-off, custom nature of the classic model we saw in Figure 1-1. In this approach, you’ll see that we have a single SaaS environment with a collection of infrastructure. In this example, I happened to show microservices and their corresponding storage. A more complete example would show all the elements of your system’s application architecture.

If we were to take a peek inside one of these microservices at run-time, we could potentially see any number of tenants (aka customers) consuming the system’s shared infrastructure. For example, if we took three snapshots of the Product microservice at three different time intervals, we might see something resembling the image in Figure 1-3.

Figure 1-3. Shared microservices

In snapshot 1, our product microservice has two tenants consuming our service (tenant1 and tenant2). Another snapshot could have another collection of tenants that are consuming our service. The point here is that the resource no longer belongs to any one consumer, it is a shared resource that is consumed by any tenant of our system.

This shift to using shared infrastructure also meant we needed a new way to describe the consumers of our software. Before, when every consumer had its own dedicated infrastructure, it was easy to continue to use the term “customer”. However, in the shared infrastructure model of SaaS, you’ll see that we describe the consumers of our environment as “tenants”.

It’s essential that you have a solid understanding of this concept since it will span almost every topic we cover in this book. The notion of tenancy maps very well to the idea of an apartment complex where you own a building and you rent it out to different tenants. In this model, the building correlates to the shared infrastructure of your solution and the tenants represent the different occupants of your apartments. These tenants of your building consume shared building resources (power, water, and so on). As the building owner, you manage and operate the overall building and different tenants will come and go.

You can see how this term better fits the SaaS model where we are building a service that runs on shared infrastructure that can accommodate any number of tenants. Yes, tenants are still customers, but the term “tenant” lets us better characterize how they land in a SaaS environment.

Re-Defining Multi-Tenancy – The SaaS Mindset

Posted on by Daniel Duggins

Re-Defining Multi-Tenancy

Up to this point, I’ve avoided introducing the idea of multi-tenancy. It’s a word that is used heavily in the SaaS space and will appear all throughout the remainder of this book. However, it’s a term that we have to wander into gracefully. The idea of multi-tenancy comes with lots of attached baggage and, before sorting it out, I wanted to create some foundation for the fundamentals that have driven companies toward the adoption of the SaaS delivery model. The other part of the challenge here is that the notion of multi-tenancy–as we’ll define it in this book–will move beyond some of the traditional definitions that are typically attached to this term.

For years, in many circles, the term multi-tenant was used to convey the idea that some resource was being shared by multiple tenants. This could apply in many contexts. We could say that some piece of cloud infrastructure, for example, could be deemed multi-tenant because it was allowing tenants to share some resource under the hood. In reality, many services running in the cloud may be running in a multi-tenant model to achieve their economies of scale. As a cloud consumer, this may be happening entirely outside of your view. Even outside the cloud, teams could build solutions where compute, databases, and other resources could be shared amongst customers. This created a very tight connection between multi-tenancy and the idea of a shared resource. In fact, in this context, this is a perfectly valid notion of multi-tenancy.

Now, as we start thinking about SaaS environments, it’s entirely natural for us to bring the mapping of multi-tenancy with us. Afterall, SaaS environments do share infrastructure and that sharing of infrastructure is certainly valid to label as being multi-tenant.

To better illustrate this point, let’s look at a sample SaaS model that brings together the concepts that we’ve been discussing in this chapter. The image in Figure 1-5 provides a view of a sample multi-tenant SaaS environment.

Figure 1-5. A sample multi-tenant environment

Here we have landed the shared infrastructure of our application services inside surrounding services that are used to introduce tenancy, manage, and operate our SaaS environment. Assuming that all of our tenants are sharing their infrastructure (compute, storage, and so on), then this would fit with the classic definition of multi-tenancy. And, to be fair, it would not be uncommon for SaaS providers to define and deliver their solution following this pattern.

The challenge here is that SaaS environments don’t exclusively conform to this model. Suppose, for example, I create a SaaS environment that looks like the drawing in Figure 1-6.

Figure 1-6. Multi-tenancy with shared and 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.

Where are the boundaries of SaaS? – The SaaS Mindset

Posted on by Daniel Duggins

Where are the boundaries of SaaS?

We’ve laid a foundation here for what it means to be SaaS, but there are lots of nuances that we haven’t really talked about. For example, suppose your SaaS application requires portions of the system to be deployed in some external location. Or, imagine scenarios where your application has dependencies on other vendor’s solutions. Maybe you are using a third-party billing system or your data must reside in another environment. There are any number of different reasons why you may need to have parts of your overall SaaS environment hosted somewhere that may not be entirely under your control.

So, how would this more distributed footprint fit with the idea of having a single, unified experience for all of your tenants? Afterall, having full control over all the moving parts of your system certainly maximizes your ability to innovate and move quickly. At the same time, it’s impractical to think that some SaaS providers won’t face domain and technology realities that require them to support externally hosted components/tools/technologies.

This is where we don’t want to be too extreme with our definition of SaaS. To me, the boundary is more around how these external dependencies are configured, managed, and operated. If their presence is entirely hidden from your tenants and they are still managed and operated through your centralized experience, this is still SaaS to me. It may introduce new complexities, but it doesn’t change the spirit of the SaaS model we’re trying to build.

Where this gets more interesting is when SaaS providers have reliance on external resources that are in the direct view of their tenants. If, for example, my SaaS solution stores data in some tenant-hosted database, that’s where things get more dicey. Now, you may have a dependency on infrastructure that is not entirely under your control. Updating this database, changing its schema, managing its health–these get more complicated in this model. This is where we start to ask questions about whether this external resource is breaking the third-wall of SaaS, exposing tenants to infrastructure and creating expectations/dependencies that undermine the agility, operations, and innovation of your SaaS environment.

My general rule of thumb here (with some exceptions) is that we’re providing a service experience. In a service model, our tenant’s view is limited to the surface of our service. The tools, technologies, and resources that are used to bring that service to life should be entirely hidden from our tenants. In many respects, this is the hard barrier that prevents our system from falling back into patterns that might lead to one-off dependencies and variations.

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

Posted on by Daniel Duggins

Operational Efficiency

SaaS, in many respects, is about scale. In a multi-tenant environment, we’re highly focused on continually growing our base of customers without requiring any specialized resources or teams to support the addition of these new customers. With SaaS, you’re essentially building an operational and technology footprint that can support continual and, ideally, rapid growth. Supporting this growth means investing in building an efficient operational footprint for your entire organization. I’ll often ask SaaS companies what would happen if 1,000 new customers signed up for their service tomorrow. Some would welcome this and others cringe. This question often surfaces key questions about the operational efficiency of a SaaS company. It’s important to note that operational efficiency is also about reacting and responding to customer needs. How quickly new features are released, how fast customers onboard, how quickly issues are addressed–these are all part of the operational efficiency story. Every part of the organization may play a part in building out an operationally efficient offering.

Innovation

With classic software models, teams can feel somewhat hand-cuffed by the realities of their environment. Customers may have one-off customizations, they may have a distributed operational model–there could be any number of factors that make it difficult for them to consider making any significant shifts in their approach. In a SaaS environment, where there’s more emphasis on agility and putting customers in a unified environment, teams are freed up to consider exploring new, out-of-the-box ideas that could directly influence the growth and success of the business. In many respects, this represents the flywheel of SaaS. You invest in agility and operational efficiency and this promotes greater innovation. This is all part of the broader value proposition of the SaaS model.

Frictionless Onboarding

SaaS businesses must give careful consideration to how customers get introduced into their environments. If you are trying to remain as agile and operationally efficient as possible, you must also think about how customer onboarding can be streamlined. For some SaaS businesses, this will be achieved through a classic sign-up page where customers can complete the on-boarding process in an entirely self-service manner. In other environments, organizations may rely on an internal process that drives the onboarding process. The key here is that every SaaS business must be focused on creating an onboarding experience that removes friction and enables agility and operational efficiency. For some, this will be straightforward. For others, it may take more effort to re-think how the team builds, operates, and automates its onboarding experience.

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.

Adding Tenancy to your Architecture – Multi-tenant Architecture Fundamentals

Posted on by Daniel Duggins

Adding Tenancy to your Architecture

Let’s start our exploration of SaaS architecture concepts by looking at a traditional non-SaaS application. In classic applications, the environment is constructed from the ground up with the assumption that it will be installed and run by individual customers. Each customer essentially has its own dedicated footprint. Figure 2-1 provides a conceptual view of how one of these applications might be designed and built.

Figure 2-1. Traditional non-SaaS environments

On the left here, you’ll see that we have a simplified view of a class application. Here, this application is built and then sold to individual customers. These customers might install the software in their own environment or it might run in the cloud. This approach simplifies the entire architectural model of this environment. The choices about how customers enter the environment, how they access our resources, and how they consume the services of our environment are much simpler when we know that they will be running in an environment that is dedicated to each customer. The general mindset here is that you have a piece of software and you’re just stamping out copies of it for each new customer.

Now, let’s think about what it means to deliver this same application in a multi-tenant SaaS environment. The diagram in Figure 2-2 provides a conceptual view of what this might look like. You see here that our customers, which are now tenants, are all consuming the same application.

Figure 2-2. The shift to a tenant-centric experience

This shift may seem fairly simple in the diagram. However, it has a profound impact on how we design, build, secure, and manage this environment. We’ve essentially made the transition from a per customer dedicated model to a multi-tenant architecture. Supporting this model reaches into every dimension of the underlying implementation of your system. It affects how you implement authentication, routing, scaling, performance, storage, and, in targeted areas, how you code the application logic of your system.

As a SaaS architect and builder, it becomes your job to determine how your system will support this notion of tenancy. In some cases, the influence here may be introduced as an extension of existing patterns and strategies. In other cases, it may require you to build and design all new constructs that must be added to support the needs of a multi-tenant setting.

Part of the challenge here is that there’s a wide range of parameters that will influence how this notion of tenancy ends up landing in your environment. The key, at this stage, is to understand the fundamental architecture concepts and then look at how the different dimensions of your environment might influence how these concepts are expressed in a given environment. So, for the moment at least, let’s stay up a level from these environmental considerations and focus squarely on building an SaaS architecture foundation that will give us the terminology and taxonomy of constructs that we can use to characterize the different moving parts and mechanisms that should be in the vocabulary of every SaaS architect and builder.

Inside the Control Plane – Multi-tenant Architecture Fundamentals

Posted on by Daniel Duggins

Inside the Control Plane

Now that we have a better sense of the roles of the control and application planes, let’s take a high-level pass at exploring the core concepts that commonly live within the scope of the control plane. We’ll dig into each of these topics in much greater detail later in this book, exploring real-world implementation and architecture strategies. At this stage, though, we need to start a level up and develop an understanding of the different components that are part of any control plane you might build. Having a higher level grasp of these components, the roles they play, and how they are related will allow us to explore these building blocks of multi-tenancy without getting distracted by the different nuances that show up when we pivot to the specific influences of technologies, languages, and domain considerations. Having this foundational view will allow you to see the landscape of options and begin to see the different components that span all SaaS architecture models.

The following is a breakdown of the different services and capabilities that are likely to show up in the control plane of your SaaS architecture, which covers onboarding, identity, metrics, billing, and tenant management.

Onboarding

The control plane is responsible for managing and orchestrating all the steps needed to get a new tenant introduced into your SaaS environment. On the surface, this may seem like a simple concept. However, as you’ll see in Chapter 4, there are lots of moving parts to the onboarding experience. The choices you make here, in many respects, are at the core of enabling many of the multi-tenant business and design elements of your SaaS environment.

At this stage, let’s stick with a high-level view of the key elements of the onboarding experience. In Figure 2-4 you’ll see a conceptualized representation of the components that play a role in the onboarding experience. Here we show a tenant signing up for our SaaS service and triggering the onboarding process via the control plane. After this initial request, the control plane owns the rest of the onboarding flow, creating and configuring our tenant and its corresponding identity footprint. This includes assigning a unique identifier to our tenant that will be leveraged across most of the moving parts of our multi-tenant architecture.

Figure 2-4. Onboarding tenants

You’ll also notice that we show the control plane interacting with the application plane, provisioning and configuring any application specific resources that may be needed for each tenant. When we get into more detailed views of sample onboarding principles, we’ll see how this part of the onboarding experience can get quite involved.

While there are common themes in the onboarding experience, the actual implementation of onboarding can vary significantly based on the domain you’re in, the business goals of your solution, and the footprint of your application architecture. The key here, though, is that onboarding represents a foundational concept that sits at the front door of your SaaS experience. Business teams can and should take great interest in shaping and influencing how you approach building out this aspect of your system.

The higher level takeaway here is that onboarding is at the center of creating and connecting the most basic elements of a multi-tenant environment: tenants, users, identity, and tenant application resources. Onboarding weaves these concepts together and establishes the foundation for introducing tenancy to all the moving parts of your SaaS environment.