3 ms·

This article is not far off in its prediction that AWS would support multi-cloud natively eventually if that's what the market demands (See also: AWS Marketplac

This article is not far off in its prediction that AWS would support multi-cloud natively eventually if that's what the market demands (See also: AWS Marketplace). We are very early in our journey and are multi-cloud already and because we're bootstrapped, cost ultimately decides what we use. And no, I don't mean multi-cloud in a way Netflix does it, but in a way where different parts of our system are hosted wholly by different cloud providers. So, in a sense, everything supports multi-cloud already anyways? > QLDB is a recent entry to the canon. It’s easy to spot these "AWS-native" services because they’re often dogfooded by Amazon retail. Well, in some cases, it is dog-fooded by AWS themselves. In QLDB's case, the underlying tech was built for EC2 [0] whilst Kinesis Data Streams was built by the Billing team at AWS [1]. [0] https://twitter.com/colmmacc/status/1067832198059970561 https://twitter.com/colmmacc/status/1067832198059970561 [1] https://gigaom.com/2014/03/20/why-amazon-built-its-data-stream-processing-engine-kinesis/ https://gigaom.com/2014/03/20/why-amazon-built-its-data-stre...

tpetry 6y ago
How do you keep the costs down with egress pricing? If the parts of your applications are distributed through cloud providers you all the time are exporting data to egress. Thats not a cheap concept or did you build your software with this in mind?
- ignoramous 6y ago
  > How do you keep the costs down with egress pricing? The AWS components we use are mostly ingress heavy. Egress heavy components are on Cloudflare, Scaleway, and Digital Ocean. > ...did you build your software with this in mind? Yep, we designed the system keeping egress costs in-mind, and that meant some of things were a bit more time-consuming (build vs buy) than they normally would have been. 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.
  - 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.
- dilyevsky 6y ago
  If you have enough volume you can pay for partner interconnect that lower price per GB to 2c so that’s not great but not terrible either. Edit: You probably would want it for performance first though
- user5994461 6y ago
  Run the database in multiple regions and pay the egress for replication. egress cost is really not as bad as people expect. if you're willing to pay for double the instances and storage, as required to run in multiple regions/clouds, the bandwidth costs are really not that outstanding in the grand scheme of things. The usual problem is poor architecture and non-distributed systems. You're not going multi region when everything relies on a single MySQL instance somewhere.

tpetry 6y ago

How do you keep the costs down with egress pricing? If the parts of your applications are distributed through cloud providers you all the time are exporting data to egress. Thats not a cheap concept or did you build your software with this in mind?

ignoramous 6y ago
> How do you keep the costs down with egress pricing? The AWS components we use are mostly ingress heavy. Egress heavy components are on Cloudflare, Scaleway, and Digital Ocean. > ...did you build your software with this in mind? Yep, we designed the system keeping egress costs in-mind, and that meant some of things were a bit more time-consuming (build vs buy) than they normally would have been. 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.
- 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.
dilyevsky 6y ago
If you have enough volume you can pay for partner interconnect that lower price per GB to 2c so that’s not great but not terrible either. Edit: You probably would want it for performance first though
user5994461 6y ago
Run the database in multiple regions and pay the egress for replication. egress cost is really not as bad as people expect. if you're willing to pay for double the instances and storage, as required to run in multiple regions/clouds, the bandwidth costs are really not that outstanding in the grand scheme of things. The usual problem is poor architecture and non-distributed systems. You're not going multi region when everything relies on a single MySQL instance somewhere.