2 ms·

> That said, we aren't what you'd call an uber sophisticated upstart using cutting edge tech. Right now, whatever systems we have are all mostly boringly simple

by ctvo 6y ago

> That said, we aren't what you'd call an uber sophisticated upstart using cutting edge tech. Right now, whatever systems we have are all mostly boringly simple and probably won't scale. You acknowledge here that the systems you have may not scale. I assume you're still trying to find market fit, and may end up heavily augmenting or redesigning these systems when you do. With that said, why did you prioritize spending your limited resources solving for multi-cloud? I'm curious if the cost savings of optimizing cross clouds was worthwhile vs. the engineering effort / constraints you introduced into your systems at your scale.

ignoramous 6y ago
> With that said, why did you prioritize spending your limited resources solving for multi-cloud? We keep asking ourselves the same too. We initially wandered down the "mutli-cloud" path because it made a lot of sense in terms of cost (like somewhere in the region of 10x lower costs)... but as we chipped away at code, it became quite obvious that the inherent complexities could have been avoided especially since we're so early and barely have a user-base. > I'm curious if the cost savings of optimizing cross clouds was worthwhile vs. the engineering effort / constraints you introduced into your systems at your scale. The uber low-cost setup allowed us to offer our services for free to gauge overall interest (given we're a consumer product). My assumption is that free customers are free publicity (in that they help spread the word) and that around 1% would convert to paying customers eventually. We also biased towards "serverless" offerings to avoid DevOps and SRE, and that has worked quite well: In the three months our alpha has been been live taking ~30M requests a month (ignoring the occasional DDoS), we haven't had a single outage or even bothered to look at the error logs (there aren't any errors). So to answer your question, yes I believe it was worthwhile since the cost difference is 10x and we were able to offer a free-tier because of that (we're not an enterprise business). Obviously, it sucks that engineering time had to be sacrificed for it, but hey, no pain no gain.

by ctvo 6y ago

ignoramous 6y ago

> With that said, why did you prioritize spending your limited resources solving for multi-cloud? We keep asking ourselves the same too. We initially wandered down the "mutli-cloud" path because it made a lot of sense in terms of cost (like somewhere in the region of 10x lower costs)... but as we chipped away at code, it became quite obvious that the inherent complexities could have been avoided especially since we're so early and barely have a user-base. > I'm curious if the cost savings of optimizing cross clouds was worthwhile vs. the engineering effort / constraints you introduced into your systems at your scale. The uber low-cost setup allowed us to offer our services for free to gauge overall interest (given we're a consumer product). My assumption is that free customers are free publicity (in that they help spread the word) and that around 1% would convert to paying customers eventually. We also biased towards "serverless" offerings to avoid DevOps and SRE, and that has worked quite well: In the three months our alpha has been been live taking ~30M requests a month (ignoring the occasional DDoS), we haven't had a single outage or even bothered to look at the error logs (there aren't any errors). So to answer your question, yes I believe it was worthwhile since the cost difference is 10x and we were able to offer a free-tier because of that (we're not an enterprise business). Obviously, it sucks that engineering time had to be sacrificed for it, but hey, no pain no gain.