Public cloud companies use accounts to create operational and security firewalls between the code and data of different users. SaaS companies gain cost efficiency by multi-tenanting the code and data of many end users. Is it possible to have our cake and eat it to? Turns out the answer is “yes.”
Say hello to the STAMTI architecture!
Single-tenanted accounts: The gold standard for security and isolation
Once upon a time, “public cloud” meant renting servers, and the rules were pretty simple: The servers in one account could only be accessed by someone with that account’s credentials, typically a developer who worked for the company paying the account’s bills. And between accounts? A firewall with all the security separation and operational isolation (aka “brownout protection”) the cloud service provider could muster.
Even today, in a world with a complex range of cloud services that include massively multi-tenanted offerings, account boundaries are still the gold standard for separation. They impact everything from cloud vendor limits to operational isolation to resource visibility.
While account boundaries a confer a lot of benefits to the resources inside them, they also have a big disadvantage when it comes to the rental model: By design, you can’t easily share a rented resource across account boundaries. A server either belongs to account A or account B, but not 50% to each of them. That has some serious downsides…like needing to scale to peak capacity, even when that means leaving servers or other resources underutilized much (perhaps even most) of the time.
Multi-tenanted SaaS: The standard for low-cost, easy-to-consume services
SaaS offerings are rapidly replacing packaged software, and it’s easy to see why: Customers always hated the error-prone deployments, endlessly time-consuming upgrades, and scaling challenges inherent in deploying packaged offerings. With nothing to deploy, manage, operate, or scale in house, SaaS is orders of magnitude easier to consume than old-school software. Need sales tracking, talent management, employee payroll, compliance programs, or expense tracking? You’re mere hours away from a robust, cost-effective SaaS solution for these and a host of other business needs. What’s not to love?
SaaS works well in part because it enables fine-grained multi-tenanting. Want to build a SaaS-based system to help customers do X? Just create a database in your account, add a column to track the customer and one or more columns to track X, and you’re off to the races. Yes, there’s a lot more to building a sustainable business, but the point is that the cloud infrastructure needed to power “classic SaaS” is straightforward.
COMPANY | SKU | PRODUCT |
Acme | 00001 | Anvil |
Coyote | 00002 | Clever_Trap |
Acme | 00003 | Chemistry_Set |
This approach works great as long as you’ve got a reasonable incoming request rate and what you’re reading and writing for each customer are a few pieces of scalar business data. But what happens if you want to sell someone infrastructure – like a database – rather than, say, expense tracking. Now you’re in a different ballpark: A single database in your implementation isn’t likely to scale to support the union of all data from all customers, and even if it could, those customers (and their compliance auditors) wouldn’t want their data intermingled with anyone else’s. And that need for isolation and security isn’t just at the data tier…it’s true for every part of your architecture.
Single tenanted security versus multi-tenanted cost efficiency and simplicity…do we really have to pick one of these options? Or is there another approach that provides the benefits of single tenant occupancy with the ease of implementation and deployment that SaaS enjoys?
What would Google do?
Public cloud vendors have this problem in spades. They deal with it by building fully managed services that are multi-tenanted at the infrastructure level: Services like AWS Lambda or Amazon S3 scale down to zero and up to, well if not infinity then at least “really high”. They do that by sharing physical hardware across multiple users at incredibly small levels of granularity – e.g., Lambda prices compute in single milliseconds. The same techniques that cloud service vendors like AWS, Azure, or Google use to build massively multi-tenanted offerings are available to the rest of us…but there’s a reason they’re mostly the province of the hyperscalers: Building a safe, scalable, cost-effective multi-tenanted service for millions of customers out of raw rentable units, like servers, is no easy feat. Moreover, trying to DIY it misses a critical reason that these services work: Shared economies of scale. When a public cloud vendor creates a multi-tenanted service, they can sell it to millions of customers. All those workloads don’t just amortize fixed costs, they also smooth out the peaks and valleys of usage. But operating it just for yourself? You could have the exact same codebase as an AWS Lambda, but you’d never get the same economics out of it.
Building and operating an AWS-scaled service is a challenge. But could we leverage the work that hyperscaled public cloud vendors have already done somehow?
Enter STAMTI
STAMTI stands for “Single-tenanted Accounts with Multi-tenanted Infrastructure”. The idea of this approach is to keep what’s best about each of these approaches by letting the public clouds do what they do best. The two critical elements of the approach are serverless architectures (to gain multi-tenanted advantages that allow us to create a per-request cost structure) and deploying those serverless resources to our customers using single-tenanted accounts. Let’s see why this works:
- SaaS-style deployments. Like traditional SaaS vendors, we want to create a customer experience where there is no software to install, deploy, manage, or maintain. Using serverless components helps out here because they naturally relieve us of many of these deployment and operational burdens, so there’s no chance we’ll pass that mess on to our customers in turn.
- SaaS economics. The cost to us of one additional customer or request is proportional to the resources they consume, because we’re using resources that scale linearly as we consume more.
- Per-request pricing. While we can elect to charge customers in any number of ways, the use of serverless components enables us to charge by fine-grained requests if that’s our business model.
- Single tenanted accounts. By vending an account for each of our end users, we can place the maximum security and operational isolation between our customer accounts.
With this approach we get it all: Maximum security and isolation between our end users, fine-grained pricing opportunities, and low operational burden for both us and our customers. So…why isn’t everyone doing it?
Delivering on STAMTI
STAMTI offers a lot of benefits (did I mention built-in fault tolerance and scaling?) but it does require some very specific skill sets. First and foremost, the application infrastructure has to be constructed with serverless components, which isn’t in every developer’s toolbox. And these are usually more than your run-of-the-mill CRUD web app. In Vendia Share’s case, we’re delivering high throughput, consensus-driven data replication and code execution as a platform. Building that out of serverless offerings (such as AWS’s Lambda, Step Functions, SQS, and other services) isn’t something you’re going to find in a textbook.
Another challenge with STAMTI architectures is that you need to vend and manage public cloud accounts, or otherwise find a way to get customers to grant you appropriate (and secure) access to their existing accounts. Both approaches have challenges. On some cloud platforms, account management services exist that make this easier (such as AWS Organizations), but expect to build your own account tracking and recovery tools, deployment engines, and more, along with monitoring services for all of that. It’s easier than recreating a service like AWS Lambda from the ground up, but it’s still not trivial. The good news is that after you’ve done it once, you can reuse it for other SaaS-style offerings. At Vendia, we use a hosted version of the AWS CDK, among other techniques, to help make this job a little easier.
These challenges can seem like a lot to overcome, but your customers are likely to thank you for making the experience of consuming your service easier, safer, and less expensive. Ours certainly do!
What’s next for STAMTI?
Like anything, STAMTI is not a new idea…the idea of multi-tenanting hardware with account-level isolation goes back to at least the 1950’s. But it’s new enough in in this current incarnation that you won’t find an easy button for it just yet.
If you’re looking to get started, check out serverless architecture resources, programmatic deployment tools, and the account vending capabilities your CSP provides (such as those found in the root account of AWS Organizations).
At Vendia, adopting a STAMTI architecture makes our software better, and we hope this same pattern can help you serve your customers better as well. Thanks for reading!
Interested in experiencing Vendia Share for yourself? Create a developer account and explore the Vendia Share Developer Preview today.
Love building distributed applications? We’re hiring!