I wholeheartedly agree with JV's points that: • Multi-tenant SaaS is by far the best way to optimize cost • Responsibilities in SaaS are much clearer than on-prem, and responsibilities in on-prem deployments are clearer still than in a BYOC deployment • The question of security in BYOC is not as simple as it seems at first.

It seems reasonable that a vendor could offer both a SaaS and a BYOC deployment model - simply architect it so the data plane can be placed in any VPC (customer or vendor owned) and the control plane stays in the vendor account. However, this is the same on-premise architecture thinking.

Well, this was my thinking exactly as CEO/CTO of LittleHorse... I have a question for the expert opiners (is that a word, derivative of "to opine"?)... is selling a subscription to a kubernetes operator considered an on-premise distribution, or a BYOC distribution, or both?

The vendor that wants to offer a fully managed SaaS service and BYOC has two choices; opt for the single stack and stay the course with the traditional ST architecture, or choose to support both ST BYOC and MT SaaS.

I don't fully agree with this. That is true if your

Foo

software is truly single-tenant, but if it supports multi-tenancy, then can't you just deploy the whole shebang in the BYOC model (and the customer creates accounts on the server), and for the SaaS model, you deploy the same exact stack and create the accounts (and pass credentials to the customer)?

Last two thoughts— What is the security checklist before being "ready" to provide a managed multi-tenant service in the cloud? All of the features mentioned in JV's piece are very nice, but are all necessary for the first MVP? And I'm quite excited and intrigued about the "upcoming announcement" regarding end-to-end encryption at Current.

but if it supports multi-tenancy, then can't you just deploy the whole shebang in the BYOC model

I'm making some assumptions about your thoughts here, but it's not actually about the actual MT or ST software being used , it's about the tooling which surrounds it that makes it a manageable service. You're not only shipping the bits of the application the customer can see, you're also shipping the shitty scripts and monitoring services and infra scaling and everything else that won't be as idiot-proof as the frontend because you expect your internal people to be better at it, and it also won't exactly match the customer infra so it needs variants, etc. etc. That leads to the decision on whether you make a separate management stack designed for customers to operate, or you harden your internal management stack to be customer-usable. I have the possibly unpopular opinion that the latter is probably how you end up with the Azure interface, and the former is how you end up with AWS. Anyway, basically I think moving from Serverless to BYOC involves exposing a bunch of your stuff that was written as internal-only to customers who will break it, and you have to decide to let them break your toys and give them separate ones.