3 ms·

This is an interesting point. I actually think our service makes sense from 0 requests, because we can (a) speed ssl stuff up immediately (and latency sucks at

by mrkurt 10y ago

This is an interesting point. I actually think our service makes sense from 0 requests, because we can (a) speed ssl stuff up immediately (and latency sucks at any volume) and (b) let people ship faster. If you're building a SaaS that's doing ~2.6mm pageviews per month, you've probably saved enough time using our features that $126 is nothing. The economics for a free service or media property are different, but we'll be valuable for different reasons too (and possibly even have a different pricing model for stuff like that).

pvg 10y ago
The pricing structure has similar problems at the low end. A small (2.6mm pageviews per month is tiny) SaaS would presumably have more than one request per page they want to fly-ify so once again fly becomes a big chunk of infrastructure costs. What's worse, it's linearly-really-expensive. A lot of services targeted at the low end tend to sell some sort of peace of mind - 'give us $100/mo for capacity you don't use but should you suddenly need it, we have you covered'. Whereas Fly is priced "it's expensive now but should you experience sudden growth we're really gonna ream you". And traffic growth doesn't necessarily mean revenue growth so the fact you were on the evening news or got really popular Malaysia might just mean a big bill. For a small service, Fly pricing is practically a DOS vector.
- mrkurt 10y ago
  We should clarify this, but fly is best suited for the "valuable" requests, and we've been recommending that people put their static assets on a more traditional CDN. We should _also_ document a policy on DOS stuff. We don't intend to run people out of money if they do get attacked. In fact, we have some ideas for middleware that would end requests early and not bill at all. Still, when we've done metered services in the past we were really generous with refunds / credits after bursts (which is basically what AWS et all do too).

by mrkurt 10y ago

pvg 10y ago

The pricing structure has similar problems at the low end. A small (2.6mm pageviews per month is tiny) SaaS would presumably have more than one request per page they want to fly-ify so once again fly becomes a big chunk of infrastructure costs. What's worse, it's linearly-really-expensive. A lot of services targeted at the low end tend to sell some sort of peace of mind - 'give us $100/mo for capacity you don't use but should you suddenly need it, we have you covered'. Whereas Fly is priced "it's expensive now but should you experience sudden growth we're really gonna ream you". And traffic growth doesn't necessarily mean revenue growth so the fact you were on the evening news or got really popular Malaysia might just mean a big bill. For a small service, Fly pricing is practically a DOS vector.

mrkurt 10y ago
We should clarify this, but fly is best suited for the "valuable" requests, and we've been recommending that people put their static assets on a more traditional CDN. We should _also_ document a policy on DOS stuff. We don't intend to run people out of money if they do get attacked. In fact, we have some ideas for middleware that would end requests early and not bill at all. Still, when we've done metered services in the past we were really generous with refunds / credits after bursts (which is basically what AWS et all do too).