Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fly.io: The reclaimer of Heroku's magic

christine.website

Post reply on HN
Print view View original

211–220 of 320 posts

Re: Fly.io: The reclaimer of Heroku's magic

#211

Post by manigandham »

EnKopVand wrote: post #69
mrkurt wrote: post #42

Earlier quoted context omitted.

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 perfe…

I don’t want an unlimited bandwidth promise, I want a cap that I know can never be exceeded. I mean, I use Azure professionally and one of the key reasons I don’t use it to host my own stuff is exactly because it could potentially become very expensive. I’d rather have my own stuff shut down until I decide what I want to do with it. Things like alerts are fine, professionally, but not for things like running a small…

This topic has been discussed many times. There's no easy solution to what happens after the cap is exceeded - should the vendor delete everything? - which is why so many of them don't bother.

And for customers, it's far easier to negotiate billing disputes then to try and recover from an account deletion because of spending caps (and there have been plenty of examples of companies shutting down because of such a mistake here).

Re: Fly.io: The reclaimer of Heroku's magic

#212

Post by xena »

oxff wrote: post #202

Quoted post unavailable.

Author here. I am not being paid to say this. If you don't trust me, I'm sure one of the fly.io people will chime in to confirm this. I haven't accepted paid sponsorship and everything I write on my website is my own opinion and not the opinion of my employer.

Of course, believe what you want. I am only words on a screen. I can't tell you want to think about things.

Re: Fly.io: The reclaimer of Heroku's magic

#214

Post by strken »

nosvince wrote: post #106
treeman79 wrote: post #95

Earlier quoted context omitted.

Most of the time. If heroku is having downtime. Then Amazon is having downtime. Then half the internet is down. Let customers know Amazon is down. Sit back and relax.

Wow, that's a horrible way of thinking about the user experience. And honestly, I'm not surprised. That's why companies that really care about the user experience will always steal market share from those that don't.

On the one hand, yeah it sucks. On the other hand, my local ice-cream shop was closed for 30 minutes last week because the owner was doing something and the staff member who was rostered on was out sick. If your online business is at the same level of profit and necessity as an ice-cream shop, it can probably close for 30 minutes once or twice a year.

Re: Fly.io: The reclaimer of Heroku's magic

#215

Post by oxff »

EnKopVand wrote: post #69
mrkurt wrote: post #42

Earlier quoted context omitted.

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 perfe…

I don’t want an unlimited bandwidth promise, I want a cap that I know can never be exceeded. I mean, I use Azure professionally and one of the key reasons I don’t use it to host my own stuff is exactly because it could potentially become very expensive. I’d rather have my own stuff shut down until I decide what I want to do with it. Things like alerts are fine, professionally, but not for things like running a small…

Yeah, if I'm going to be signing up with my credit card I'll just log back into my AWS account since I have already pricing monitoring setup for that stuff. I definitely don't want to worry about it (surprise costs) for scratch / hobby stuff, let alone monitor bills for it.

With Heroku it is stupidly simple to get things going, no credit cards, "fire and forget". Works great for hobby projects, and examples you want to show.

Re: Fly.io: The reclaimer of Heroku's magic

#216

Post by raytracer »

mrkurt wrote: post #76
EnKopVand wrote: post #69

Earlier quoted context omitted.

I don’t want an unlimited bandwidth promise, I want a cap that I know can never be exceeded. I mean, I use Azure professionally and one of the key reasons I don’t use it to host my own stuff is exactly because it could potentially become very expensive. I’d rather have my own stuff shut down until I decide what I want to do with it. Things like alerts are fine, professionally, but not for things like running a small…

We actually launched with that feature: https://news.ycombinator.com/item?id=22616857 No one took us up on it. What we found is that the majority of people want their stuff to stay up, and the right UX for "shut it down so you don't get billed" is not obvious. We ended up implementing prepayment instead. If you sign up and buy $25 in credit, we'll just suspend your apps when the credit runs out. Bandwidth is weird be…

Having a billing limit is important to me as I don't want to risk unbounded costs for personal projects.

> we'll just suspend your apps when the credit runs out.

This sounds great! I've looked at Fly.io before but didn't realise this was a thing so didn't go past looking. I'll definitely give Fly.io a test run now. :)

Re: Fly.io: The reclaimer of Heroku's magic

#217

Post by krallja »

ditsuke wrote: post #163
hthrowaway5 wrote: post #111

At one point (a very long time ago now) it was declared that Dogwood was the future and as a result Go would be the language of choice at Heroku and Erlang would be no more. Trouble is that Erlang ran all the important Cedar code (it might still today) and the Erlang engineers didn't particularly like the news that Erlang code was essentially deprecated so they left and nobody knew how to maintain the stack. This def…

Sorry I couldn't find a reference, what is dogwood?

It’s mentioned in the article.

Re: Fly.io: The reclaimer of Heroku's magic

#219

Post by FBISurveillance »

EnKopVand wrote: post #69
mrkurt wrote: post #42

Earlier quoted context omitted.

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 perfe…

I don’t want an unlimited bandwidth promise, I want a cap that I know can never be exceeded. I mean, I use Azure professionally and one of the key reasons I don’t use it to host my own stuff is exactly because it could potentially become very expensive. I’d rather have my own stuff shut down until I decide what I want to do with it. Things like alerts are fine, professionally, but not for things like running a small…

This. I've had a very real situation with DataDog: I've accidentally created a Synthetics test (and forgot about it) on a test account and incurred $5k+ bill at end of month. Zero notice or anything.

I ended up swallowing the bill but will not be using them again since this is plain scary.

Edit: funny thing - to add insult to injury, I've started to hear from their sales people on "my growth plans", even though I've had a support ticket hoping to resolve this to no avail.

Re: Fly.io: The reclaimer of Heroku's magic

#220

Post by glenngillen »

ditsuke wrote: post #163
hthrowaway5 wrote: post #111

At one point (a very long time ago now) it was declared that Dogwood was the future and as a result Go would be the language of choice at Heroku and Erlang would be no more. Trouble is that Erlang ran all the important Cedar code (it might still today) and the Erlang engineers didn't particularly like the news that Erlang code was essentially deprecated so they left and nobody knew how to maintain the stack. This def…

Sorry I couldn't find a reference, what is dogwood?

Heroku named all of their stacks after an alliterated color + tree convention:

- Argent Aspen

- Badious Bamboo

- Celadon Cedar

I can’t remember what to color name for the Dogwood stack was meant to be, we mostly only ever referred to them by the tree name and dropped the color. Suffice to say that Dogwood was meant to be the 4th major evolution of what Heroku was.

Post reply on HN