Re-Defining Multi-Tenancy

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 Natural Challenges of the Classic Model – The SaaS Mindset

Posted on by Daniel Duggins

The Natural Challenges of the Classic Model

To be completely fair, building and delivering software in the model described above is and will continue to be a perfectly valid approach for some businesses. The legacy, compliance, and business realities of any given domain might align well to this model.

However, for many, this mode of software delivery introduced a number of challenges. At its core, this approach focused more on being able to sell customers whatever they needed in exchange for trade offs around scale, agility, and cost/operational efficiency.

On the surface, these tradeoffs may not seem all that significant. If you have a limited number of customers and you’re only landing a few a year, this model could be adequate. You would still have inefficiencies, but they would be far less prominent. Consider, however, a scenario where you have a significant installed base and are looking to grow your business rapidly. In that mode, the pain points of this approach begin to represent a real problem for many software vendors.

Operational and cost efficiencies are often amongst the first areas where companies using this model start to feel the pain. The incremental overhead of supporting each new customer here begins to have real impacts on the business, eroding margins and continually adding complexity to the operational profile of the business. Each new customer could require more support teams, more infrastructure, and more effort to manage the one-off variations that accompany each customer installation. In some cases, companies actually reach a point where they’ll intentionally slow their growth because of the operational burdens of this model.

The bigger issue here, though, is how this model impacts agility, competition, growth, and innovation. By its very nature, this model is anything but nimble. Allowing customers to manage their own environments, supporting separate versions for each customer, enabling one-off customization–these are all areas that undermine speed and agility. Imagine what it would mean to roll out a new feature in these environments. The time between having the idea for a feature, iterating on its development, and getting it in front of all your customers is often a slow and deliberate process. By the time a new feature arrives, the customer and market needs may have already shifted. This also can impact the competitive footprint of these companies, limiting their ability to rapidly react to emerging solutions that are built around a lower friction model.

While the operational and development footprint were becoming harder to scale, the needs and expectations of customers were also shifting. Customers were less worried about their ability to manage/control the environment where their software was running and more interested in maximizing the value they were extracting from these solutions. They demanded lower friction experiences that would be continually innovating to meet their needs, giving them more freedom to move between solutions based on the evolving needs of their business.

Customers were also more drawn to pricing models that better aligned with their value and consumption profile. In some cases, they were looking for the flexibility of subscription and/or pay-as-you-go pricing models.

You can see the natural tension that’s at play here. For many, the classic delivery model simply didn’t align well with the shifting market and customer demands. The emergence of the cloud also played a key role here. The cloud model fundamentally altered the way companies looked at hosting, managing, and operating their software. The pay-as-you-go nature and operational model of the cloud had companies looking for ways to take advantage of the economies of scale that were baked into the cloud experience. Together, these forces were motivating software providers to consider new business and technology models.

Thinking Beyond Infrastructure – The SaaS Mindset

Posted on by Daniel Duggins

Thinking Beyond Infrastructure

While looking at SaaS through the lens of shared infrastructure makes it easier to understand the value of SaaS, the reality is that SaaS is much more than shared infrastructure. In fact, as we move forward, we’ll see that shared infrastructure is just one dimension of the SaaS story. There are economies of scale and agility can be achieved with SaaS–with or without shared infrastructure.

In reality, we’ll eventually see that there are actually many ways to deploy and implement your SaaS application architecture. The efficiencies that are attributed to SaaS can certainly be maximized by sharing infrastructure. However, efficiency starts with surrounding your application with constructs that can streamline the customer experience and the management/operational experience of your SaaS environment. It’s these constructs that–in concert with your SaaS application architecture–enable your SaaS business to realize its fundamental operational, growth, and agility goals.

To better understand this concept, let’s look at these additional SaaS constructs. The diagram in Figure 1-4 provides a highly simplified conceptual view of these common SaaS services.

Figure 1-4. Surrounding your application with shared services

At the center of this diagram you’ll see a placeholder for application services. This is where the various components of your SaaS application are deployed. Around these services, though, are a set of services that are needed to support the needs of our overall SaaS environment. At the top, I’ve highlighted the onboarding and identity services, which provide all the functionality to introduce a new tenant into your system. On the left, you’ll see the placeholders for the common SaaS deployment and management functionality. And, on the right, you’ll see fundamental concepts like billing, metering, metrics, and analytics.

Now, for many SaaS builders, it’s tempting to view these additional services as secondary components that are needed by your application. In fact, I have seen teams that will defer the introduction of these services, putting all their initial energy into supporting tenancy in their application services.

In reality, while getting the application services right is certainly an important part of your SaaS model, the success of your SaaS business will be heavily influenced by the capabilities of these surrounding services. These services are at the core of enabling much of the operational efficiency, growth, innovation, and agility goals that are motivating companies to adopt a SaaS model. So, these components–which are common to all SaaS environments–must be put front and center when you are building your SaaS solution. This is why I have always encouraged SaaS teams to start their SaaS development at this outer edge, defining how they will automate the introduction of tenants, how they’ll connect tenants to users, how they’ll manage your tenant infrastructure, and a host of other considerations that we’ll be covering throughout this book. It’s these building blocks–which have nothing to do with the functionality of your application–that are going to have a significant influence on the SaaS footprint of your architecture, design, code, and business.

So, if we turn our attention back to the diagram in Figure 1-4, we can see this big hole in the middle that represents where we’ll ultimately place our application services. The key takeaway here is that, no matter how we design and build what lands in that space, you’ll still need some flavor of these core shared services as part of every SaaS architecture you build.

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

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.

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 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.

Defining SaaS – The SaaS Mindset

Posted on by Daniel Duggins

Defining SaaS

I’ve devoted the bulk of this chapter to bringing more clarity to the boundaries, scope, and nature of what it means to be SaaS. It only seems fair to take all the information we discussed here and attempt to provide an explicit definition of SaaS that, ideally, incorporates the concepts and principles that we have covered here. Here’s the definition I think best summarizes the view of SaaS I’ll be using across the rest of this book:

SaaS is a business and software delivery model that enables organizations to offer their solutions in a low-friction, service-centric model that maximizes value for customers and providers. It relies on agility and operational efficiency as pillars of a business strategy that promotes growth, reach, and innovation.

You’ll see here that this definition sticks to the theme of SaaS being a business model. There’s no mention here of any technologies or architecture considerations. It’s your job as a SaaS architect and builder to create the underlying patterns and strategies that enable the business to realize its objectives. While that may seem like the job of any architect, it should be clear that the unique blend of business and technology demands for SaaS environments will be infused directly into the design, architecture, and implementation of your SaaS solution.

Conclusion

This chapter was all about establishing the foundational elements of the SaaS mindset, providing you with a clearer view of what I mean when I talk about multi-tenancy and the core terms I use to describe a SaaS model. It should also make it clear that your job as a SaaS architect and builder goes well beyond the technology domain. Before you can choose any architecture for your SaaS system, you’ll need to have a firm grasp on the nature of key insights from your business to know which strategies and patterns are going to best align with the realities of your business. This reality will become clearer as we get into the details of how you architect and design SaaS systems. The challenges and needs of SaaS architecture will require you to add all new dimensions to your toolbag. In some cases, you may actually need to be the evangelist of these concepts, driving the teams around you to think differently about how they approach their jobs.

While having a clear view of the SaaS mindset is essential, our goal in this book is to dig into the technical dimensions of SaaS. In the next chapter, we’ll start to look at the various architectural constructs and concepts that are used when designing SaaS environments. Having a firm grip on these constructs will provide you with a foundation of terminology and concepts that will be essential as we move into more detailed architecture models and implementation strategies. It will also expose you to the range of fundamental considerations that are part of every SaaS architecture.