Scaling Impacts
Scale is another important consideration for the full stack silo deployment model. Whenever you’re provisioning separate infrastructure for each tenant, you need to think about how this model will scale as you add more tenants. While the full stack silo model can be appealing when you have 10 tenants, its value can begin to erode as you consider supporting hundreds or thousands of tenants. The full stack silo model, for example, would not be sustainable in many classic BC2 environments where the scale and number of tenants would be massive. Naturally, the nature of your architecture would also have some influence on this. If you’re running Kubernetes, for example, it might come down to how effectively the silo constructs of Kubernetes would scale here (clusters, namespaces, etc.). If you’re using separate cloud networking or account constructs for each siloed tenant, you’d have to consider any limits and constraints that might be applied by your cloud provider.
The broader theme here is that full stack siloed deployments are not for everyone. As I get into specific full stack silo architectures, you’ll see how this model can run into important scaling limits. More importantly, even if your environment can scale in a full stack silo model, you may find that there’s a point at which the full stack silo can become difficult to manage. This could undermine your broader agility and innovation goals.
Cost Considerations
Costs are also a key area to explore if you’re looking at using a full stack silo model. While there are measures you can take to limit over-provisioning of siloed environments, this model does put limits on your ability to maximize the economies of scale of your SaaS environment. Typically, these environments will require lots of dedicated infrastructure to support each tenant and, in some cases, this infrastructure may not have an idle state where it’s not incurring costs. For each tenant, then, you will have some baseline set of costs for tenants that you’ll incur–even if there is no load on the system. Also, because these environments aren’t shared, we don’t get the efficiencies that would come with distributing the load of many tenants across shared infrastructure that scales based on the load of all tenants. Compute, for example, can scale dynamically in a silo, but it will only do so based on the load and activity of a single tenant. This may lead to some over-provisioning within each silo to prepare for the spikes that may come from individual tenants.
Generally, organizations offering full stack siloed models are required to create cost models that help overcome the added infrastructure costs that come with this model. That can be a mix of consumption and some additional fixed fees. It could just be a higher subscription price. The key here is that, while the full stack silo may be the right fit for some tiers or business scenarios, you’ll still need to consider how the siloed nature of this model will influence the pricing model of your SaaS environment.
As part of the cost formulas, we must also consider how the full stack silo model impacts the operational efficiency of your organization. If you’ve built a robust control plane and you’ve automated all the bits of your onboarding, deployment, and so on, you can still surround your full stack silo model with a rich operational experience. However, there is some inherent complexity that comes with this model that will likely add some overhead to your operational experience. This might mean that you will be required to invest more in the staff and tooling that’s needed to support this model, which will add additional costs to your SaaS business.
