Full Stack Silo Deployment
Now that youhave a high-level sense of the scope and role of deployment models, it’s time to dig in a bit more and start looking at defining specific types of deployment models. Let’s start by looking at what I’ll label as a full stack silo deployment model.
As its name suggests, the full stack silo model places each tenant into a fully siloed environment where all of the resources of a tenant are completely siloed. The diagram in Figure 3-3 provides an example of a full stack silo environment. Here you’ll see that we have an environment where our application plane is running workloads for two tenants. These two tenants are running in siloes where the compute, storage, and every resource that’s needed for the tenant is deployed into some logical construct that creates a clear boundary between our tenants.
Figure 3-3. Full stack silo deployment model
In this particular example, I simplified the contents of the slilo, showing a range of microservices that are running in each tenant environment. In reality, what’s in the silo and how your application is represented could be represented by any number of different technologies and design strategies. This could have been an n-tier environment with separate web, application, and storage tiers. I could have included any number of different compute models and other services here as well (queues, object storage, messaging, and so on). The emphasis, at this stage, is less about what’s in each of these tenant environments and more on the nature of how they are deployed.
Where Full Stack Silo Fits
The full stack silo model can feel like a bit of a SaaS anti-pattern. After all, so much of our discussion of SaaS is centered around agility and efficiency. Here, where we have fully siloed tenant resources, it can appear as though we’ve compromised on some of the fundamental goals of SaaS. However, if you think back to the definition of SaaS in Chapter 1, you’ll recall that SaaS isn’t exclusively about sharing infrastructure for economies of scale. SaaS is about operating in a model where all of our tenants are operated, managed, and deployed collectively. This is the key thing to keep in mind when you’re looking at the full stack silo model. Yes, it has efficiency challenges. We’ll get into those. At the same time, as long as every one of these environments is the same and as long as these are running the same version of our application, then we can still realize much of the value proposition of SaaS.
So, knowing that full stack silo meets our criteria for SaaS, the real question here is more about when it might make sense for you to employ this model. Which factors typically steer organizations toward a full stack silo experience? When might it be a fit for the business and technology realities of your environment? While, there are no absolutes here, there are common themes and environmental factors that have teams selecting the full stack silo model. Compliance and legacy considerations are two of the typical reasons teams will end up opting for full stack silo footprint. In some heavily regulated domains, teams may choose a full stack silo model to simplify their architecture and make it easier for them to address specific compliance criteria. Customers in these domains might also have some influence on the adoption of a full stack silo, insisting on having siloed resources as part of selecting a SaaS solution.
The full stack silo model can also represent a good fit for organizations that are migrating a legacy solution to SaaS. The fully siloed nature of this model allows these organizations to move their existing code into a SaaS model without major refactoring. This gets them to SaaS faster and reduces their need to more immediately take on adding tenancy to all the moving parts of their architecture. Migrating teams will still be required to retrofit your legacy environment to align with the SaaS control plane, its identity model, and a host of other multi-tenant considerations. However, the scope and reach of these impacts can be less pronounced if your solution is moving into a full stack silo environment that doesn’t need to consider scenarios where any of a tenant’s resources are pooled.
Full stack silo can also be a tiering strategy. For example, some organizations may offer a premium version of their solution that, for the right price, will offer tenants a fully dedicated experience. It’s important to note that this dedicated experience is not created as a one-off environment for these tenants. It’s still running the same version of the application and is centrally managed alongside all the other tiers of the system.
In some cases, the full stack model simply represents a lower barrier of entry for teams–especially those that may not be targeting a large number of tenants. For these organizations, full stack silo allows them to get to SaaS without tackling some of the added complexities that come with building, isolating, and operating a pooled environment. Of course, these teams also have to consider how adoption of a full stack silo model might impact their ability to rapidly scale the business. In this case, the advantages of starting with a full stack could be offset by the inefficiencies and margin impacts of being in a full stack silo model.
