←back to thread

Fly.io: The reclaimer of Heroku's magic

(christine.website)
528 points sealeck | 1 comments | 15 May 22 19:56 UTC | HN request time: 0.323s | source
Show context
brundolf ◴[15 May 22 21:03 UTC] No.31391105[source]▶
The only thing I don't like is their usage-based pricing. On Heroku I could pay $7 a month and know I'd never be charged more than that. I'm sure when you're scaling a service it's fine - maybe even better - to do it on a sliding scale. But for a fire-and-forget blog site, I don't want to have to worry about stuff like that.
replies(7): >>31391168 #>>31391192 #>>31391253 #>>31391362 #>>31392452 #>>31392496 #>>31395938 #
mrkurt ◴[15 May 22 21:13 UTC] No.31391192[source]▶
This is a problem. And a bit of an own goal on our part.

I hate services that don't put a price on things like bandwidth (because there's always a price!). So we priced bandwidth and made it transparent. You can put an app on Fly.io and server petabytes of data every month, if you want. We'll never complain that you're serving the wrong content type.

But the reality is – having an unlimited bandwidth promise is perfect for for a fire and forget blog site. We're not doing ourselves any favors with scary pricing for that kind of app.

replies(8): >>31391245 #>>31391399 #>>31391400 #>>31391442 #>>31393115 #>>31393823 #>>31394011 #>>31395406 #
1. phamilton ◴[16 May 22 05:58 UTC] No.31394011[source]▶
When I worked in adtech (Brightroll) we hosted a segment mapping server on heroku. All it did was look at a url query for the target url, append a value from a cookie to it, and 302 to that url. The value in adtech is that I can tell you which segment a user is in by taking the data in my cookie and appending it to your url.

We launched it on Heroku using Nodejs and sent billions of requests a day to it. The thing ran on like a few dozen dynos, but it was responsible for like 20-30% of all of Heroku's bandwidth. Fantastic value for us. Immediate headache for Heroku.