Chapter 15. SaaS Anywhere

Up to this point, I’ve presented a view of SaaS architecture that presumes that all of the system’s resources are managed and controlled by the SaaS provider. In fact, so much of the value, scale, and efficiency of SaaS is achieved by hiding away the details of the system’s underlying infrastructure. This is a cornerstone of the as-a-service mindset where tenants can only touch the surface (application, API, etc.) of your solution. Putting this wall in place allows teams to continually refine and optimize their environments, moving between technologies and designs without fear of impacting the tenants. At the same time, there are use cases where you may be required to stretch these boundaries, allowing parts of your SaaS architecture to be hosted in environments that may be controlled by your customer. This idea of having parts of your system running in multiple settings (in the cloud, on-premises, in a customer’s account) is what I have labeled as SaaS Anywhere.

In this chapter, we’ll start by looking at some of the fundamental factors that might have teams creating these SaaS Anywhere experiences. We’ll explore some of the business and technical realities that drive this need to distribute resources to other environments, looking at how the choices you make here can influence the footprint of your SaaS business. I’ll also review some of the core questions that you’ll want to be asking yourself whenever you are considering adopting this model.

Next, ...

Get Building Multi-Tenant SaaS Architectures now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.