3 ms·
The architectural decision to deploy each customer on their own segmented components to make sure that "no one user’s data to mingle with another" seems to me l
by blantonl 7y ago
The architectural decision to deploy each customer on their own segmented components to make sure that "no one user’s data to mingle with another" seems to me like a solution in search of a problem.
First, the deployment was on AWS (EC2 and RDS among other services) which was probably already co-mingled with other AWS customers.
Second, when you are selling a SAAS offering, the assumption is already there that you'll build security and multi-tenancy into the app and the underlying infrastructure shouldn't matter.
And 100K/month for a MVP SAAS offering. I'm speechless. I just, I can't even understand how this burn rate passed muster with the leadership.
But Kudos to the team for owning up to it and sharing. Lots of lessons learned here.
- Spooky23 7y agoIt could make alot of sense for alot of government, healthcare and financial use cases.
- blantonl 7y agoI agree. In those cases, sell those customer separate products and expectations and price it accordingly.
- paulstovell 7y agoThe issue here is Octopus is like a CI server - customers can run arbitrary code in the instance (not a problem most SaaS apps have). So a VM per customer was almost the bare minimum. Cloud CI platforms typically solve this by timesharing build agents, but that takes engineering effort, which is a waste of effort if there's not a lot of demand in the first place. That's why we started with the MVP.