Hacker News Reader

Comment by Multicomp | Hacker News Reader

This reminds me of Fly.io's model off the top of my head, though its not a self-hosted firecracker as such.

I specifically complained to a fly.io staff on here about their "gotcha, b*tch" usage based pricing which they basically copied from AWS, and they stood by it and other people here backed them up. No one is giving me a pile of free money, so I can't risk that kind of thing.

Exactly what did we copy from AWS here? You could get a long way in our decisionmaking process generally by just consciously avoiding what AWS does.

The short version is it seems like a big "gotcha" that there is no way to limit bandwidth or spending on that or other resources ahead of time, and that might be a deliberate business model that is more aimed at well-funded startups or large companies that are monitoring costs much less closely than an individual or small business.

It's not necessarily too hard to just not dynamically spawn a bunch of machines, but the bandwidth one is going to sneak up on people.

Lots of people want limits. They might make sense for something like Sprites, where the end-users are often (but not always) individual developers. They're terrible for hosting fixed-function applications. The real gotcha is having limits, because that's the host effectively taking your app down for you.

I know talk is cheap, but I've been in the room for every one of these discussions over the last 6 years at Fly.io, and if we could have come up with a system to make limits workable, we would have done it. Charging for stuff you don't want is bad business, and we make our money from happy, growing customers (the open secret of hosting is that a huge chunk of usage is basically a loss leader search for a much smaller number of ultra-profitable customers).

These pricing models --- at least outside of AWS (I'm not cynical about them but their incentives are different from indies) --- are not meant to fuck you.

Why is it that you claim limits are unworkable? If you can track or enforce it (others have been for years) then couldn't you make it an optional field or checkbox?

Every limit is a commanded outage. We can refund an unexpectedly high bill. We can't refund downtime.

You’re optimizing for one class of customer by denying another class a choice they explicitly want.

That's true, in the sense that it is true of every coherent business. What would not be a true statement is that we somehow profit from the discomfort of the "disfavored" cohort of customers here. If we could serve them reasonably without making terrible compromises for everybody else, we would do so, and we would profit from that.

I guess business is all about making the right compromises

Which implies that you cannot reasonably serve the "disfavored" cohort (self-funded startup or small business). In other words, you have admitted that I was correct in that the business model is deliberately aimed at businesses that likely can absorb surprise expenses, and it's not appropriate for others.

We probably have different definitions of "small business". At any rate: my only point here is, it's not our business model to earn a premium off surprise bills. Railway does hard billing limits! Railway's great. Use them! I'm not here to sell you on Fly.io.

Sorry, I was just curious, i think i'd consider fly more after this exchange than less tho, thanks for all the info.

I'm just a message board nerd message board nerding about something I believe to be true. :)

So write "WARNING: your service will go down if you exceed this limit. We cannot provide refunds for this. To avoid outages in the event of unanticipated traffic, do not enter a spend limit."

A learning from the past 6 years: warnings do absolutely nothing. If your answer to a problem is a warning label, you have no answer for the problem.

Reply on news.ycombinator.com