4 ms·

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 dat

by 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.

by tpetry 6y ago

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.