Introducing the Silo and Pool Models
As we look at deployment models, we’re going to discover that these models will require the introduction of new terminology that can add precision to how we characterize SaaS architecture constructs. This relates to our earlier exploration of how the term multi-tenant had to take on a broader meaning to fit the realities of SaaS businesses. Now, as we start to look at deployment models, you’ll notice that we still need terminology that can better capture and accurately convey how the resources in our architecture are consumed by tenants.
There are two terms that I’m going to introduce here to give us a more granular way to think about classifying dedicated and shared resources. Across the rest of this book, you’ll see that I will use the term silo to refer to any model where a resource is dedicated to a given tenant. I’ll use the term pool to reference any model where a tenant resource is shared by one or more tenants.
This may seem like a subtle nuance in language. In reality, it has significant implications on how we describe multi-tenant architecture. It allows us to describe the behavior and scope of our SaaS architecture resources without the ambiguity and legacy baggage that comes with labeling resources a multi-tenant. As we look more at deployment models and the full range of SaaS architecture concepts that span this book, I will be using silo and pool as the foundational terms that characterize the usage, isolation, deployment, and consumption of the resources in our multi-tenant architecture.
To help crystallize this concept, let’s look at a conceptual architecture that includes resources that are being consumed in a combination of dedicated and shared models. Figure 3-2 provides a view of a series of microservices that have been deployed into a SaaS architecture. In this image, I’ve created a hypothetical environment where we have a series of microservices that are using different strategies for dedicating and sharing tenant resources.
Figure 3-2. Silo and pooled resource models
At the top of the diagram, you’ll see that I’ve put two tenants here to illustrate how the tenants in our environment are landing in and consuming resources. These tenants are running an ecommerce application that is implemented via Product, Order, and Invoice microservices. Now, if we follow a path through these microservices from left to right, you’ll see how we’ve applied different deployment strategies for each of these microservices.
Let’s start with the Product microservice. Here, I’ve chosen a strategy where the compute and the storage for all of our tenants will be deployed in a pooled model. For this scenario, I have decided that the isolation and performance profile of this service fits best with the values of a pooled approach. As we move to the Order microservice, you’ll see that I’ve chosen a very different model here. In this case, the service has siloed compute and storage for every tenant. Again, this was done based on the specific needs of my environment. This could have been driven by some SLA requirement or, perhaps, a compliance need.
From the Order service, you’ll then see that our system sends a message to a queue that prepares these orders for billing. This scenario is included to highlight the fact that our siloed and pooled concepts are extended beyond our microservices and applied to any resource that might be part of our environment. For this solution, I’ve opted to have a siloed queues for each tenant. Finally, I have an Invoice service on the right-hand side that pulls messages from these queues and generates invoices. To meet the requirements of our solution, I’ve used a mix of siloed and pooled models in this microservice. Here, the compute is pooled and the storage is siloed.
The key takeaway here is that the terms silo and pool are used to generally characterize the architecture footprint of one or more resources. These terms can be applied in a very granular fashion, highlighting how tenancy is mapped to very specific elements of your architecture. These same terms can also be used more broadly to describe how a collection of resources are deployed for a tenant. So, don’t try to map silo and pool to specific constructs. Instead, think of them as describing the tenancy of a single resource or a group of resources.
This caveat will be especially important as we look at deployment models throughout this chapter, allowing us to apply to silo and pool concepts and varying scopes across our multi-tenant architecture.
