3 ms·

> As for fly.io, well, I work there, so, they pay me. Well, that’s nice and all, but if a fly.io customer were attacked with 3.1GB/s throughput, according to t

by oefrha 5y ago

> As for fly.io, well, I work there, so, they pay me. Well, that’s nice and all, but if a fly.io customer were attacked with 3.1GB/s throughput, according to the lowest outbound bandwidth price of $0.02/GB [1] they’d be burning at least $3.72/min. 6 times that if attacked from India. That would be a lot less fun. [1] https://fly.io/docs/about/pricing/ https://fly.io/docs/about/pricing/ Edit: They mentioned they waive charges as a result of attacks: https://community.fly.io/t/about-rate-limiting/156/4 https://community.fly.io/t/about-rate-limiting/156/4

sammy811 5y ago
- kuschku 5y ago
  This sounds like you're claiming responsibility for the attack?
  - steveklabnik 5y ago
    They do so more explicitly downthread.
    - LegionMammal978 5y ago
      Do you recall what this user said downthread? They seem to have deleted their other comments.
      - bronson 5y ago
        The posts were flagged, you can see them if you turn on showdead. Here's sammy811's threadstarter: > I was the one "attacking" the video platform! I saw fly io had insane bandwidth pricing for India, so I spawned a couple of VMs in India to constantly pull the 4k video. Sad the whole ASN got blocked!
        LegionMammal978 5y ago
        Thank you, I'd checked with showdead earlier but for some reason I didn't see the comments on mobile.
- mrkurt 5y ago
  If your goal was to get us to spend more money on bandwidth, you succeeded. Well done. We documented how to do this quite a while ago, though: https://fly.io/blog/we-cut-bandwidth-prices-go-nuts/ https://fly.io/blog/we-cut-bandwidth-prices-go-nuts/
  - bronson 5y ago
    "What we've done instead is set a blended price that fits most apps running on Fly.io, and decided to just eat the extra cost from outliers. If you want to exploit that, run an app in Sydney with a whole bunch of users in India. We'll lose money on your app and you will win one round of capitalism." Impressive foreshadowing.
fasterthanlime 5y ago
Indeed. fly.io encouraged me to move projects there, but since I budget my side projects as if they were an actual business, parts of the pricing page turned me off. For the time being, I've decided that getting insights into "how well the platform worked for me" was more valuable for me, so my video platform is staying there, but I've initiated multiple discussions about pricing and I intend to keep doing so until I'm happy with the answer.
- oefrha 5y ago
  Cool, thanks for pushing this discussion from the inside.
mrkurt 5y ago
We do waive attack related charges. We're not interested in making money on bandwidth. We have a blog post with a few more details here: https://fly.io/blog/we-cut-bandwidth-prices-go-nuts/ https://fly.io/blog/we-cut-bandwidth-prices-go-nuts/ That said, bandwidth does cost money. There are three ways we could handle it: 1. Charge as little as we can get away with, be transparent about it, eat the cost when someone has a negative experience. 2. Charge for bandwidth capacity, but don't meter it (ie: give VMs unmetered 100mb interfaces). 2. Don't charge for it, call it unlimited, put a hidden cap in place, and restrict what kinds of apps can run on the platform. We opted for #1. I could give you a lot of post hoc reasoning, but the reality is that it's what I'd prefer as a customer. Companies that promise "unlimited bandwidth" feel a little slimy to me. Amos wouldn't be able to run his video hosting on one of those platforms. Unmetered interfaces with restricted throughput do seem pretty nice. I've used a bunch of services like that. The cost to get started is high, though. And in my experience, the quality is poor. I've never had worse network performance than when I was paying for an unmetered network connection. Which makes sense, because these people attract all the users who want cheap, unmetered bandwidth. And they can't really afford to build enough upstream network capacity to handle all of them. I don't love surprise expenses any more than you do. I do think we picked the least bad option, though, even though it puts some people off.

by oefrha 5y ago

sammy811 5y ago

kuschku 5y ago
This sounds like you're claiming responsibility for the attack?
- steveklabnik 5y ago
  They do so more explicitly downthread.
  - LegionMammal978 5y ago
    Do you recall what this user said downthread? They seem to have deleted their other comments.
    - bronson 5y ago
      The posts were flagged, you can see them if you turn on showdead. Here's sammy811's threadstarter: > I was the one "attacking" the video platform! I saw fly io had insane bandwidth pricing for India, so I spawned a couple of VMs in India to constantly pull the 4k video. Sad the whole ASN got blocked!
      - LegionMammal978 5y ago
        Thank you, I'd checked with showdead earlier but for some reason I didn't see the comments on mobile.
mrkurt 5y ago
If your goal was to get us to spend more money on bandwidth, you succeeded. Well done. We documented how to do this quite a while ago, though: https://fly.io/blog/we-cut-bandwidth-prices-go-nuts/ https://fly.io/blog/we-cut-bandwidth-prices-go-nuts/
- bronson 5y ago
  "What we've done instead is set a blended price that fits most apps running on Fly.io, and decided to just eat the extra cost from outliers. If you want to exploit that, run an app in Sydney with a whole bunch of users in India. We'll lose money on your app and you will win one round of capitalism." Impressive foreshadowing.

fasterthanlime 5y ago

Indeed. fly.io encouraged me to move projects there, but since I budget my side projects as if they were an actual business, parts of the pricing page turned me off. For the time being, I've decided that getting insights into "how well the platform worked for me" was more valuable for me, so my video platform is staying there, but I've initiated multiple discussions about pricing and I intend to keep doing so until I'm happy with the answer.

oefrha 5y ago
Cool, thanks for pushing this discussion from the inside.

mrkurt 5y ago

We do waive attack related charges. We're not interested in making money on bandwidth. We have a blog post with a few more details here: https://fly.io/blog/we-cut-bandwidth-prices-go-nuts/ https://fly.io/blog/we-cut-bandwidth-prices-go-nuts/ That said, bandwidth does cost money. There are three ways we could handle it: 1. Charge as little as we can get away with, be transparent about it, eat the cost when someone has a negative experience. 2. Charge for bandwidth capacity, but don't meter it (ie: give VMs unmetered 100mb interfaces). 2. Don't charge for it, call it unlimited, put a hidden cap in place, and restrict what kinds of apps can run on the platform. We opted for #1. I could give you a lot of post hoc reasoning, but the reality is that it's what I'd prefer as a customer. Companies that promise "unlimited bandwidth" feel a little slimy to me. Amos wouldn't be able to run his video hosting on one of those platforms. Unmetered interfaces with restricted throughput do seem pretty nice. I've used a bunch of services like that. The cost to get started is high, though. And in my experience, the quality is poor. I've never had worse network performance than when I was paying for an unmetered network connection. Which makes sense, because these people attract all the users who want cheap, unmetered bandwidth. And they can't really afford to build enough upstream network capacity to handle all of them. I don't love surprise expenses any more than you do. I do think we picked the least bad option, though, even though it puts some people off.