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

311–320 of 320 posts

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

#311

Post by manigandham »

imtringued wrote: post #267
manigandham wrote: post #211

Earlier quoted context omitted.

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

It's very easy to solve this problem. Just let people set a cap on the things with usage billing: "I want to cap the amount of data I store to 50GB and the amount of traffic I serve to 1000GB" Of course there is an obvious problem with this, the pricing structure would become transparent and you don't want that as a cloud provider. You want your customer to just pay his bills and not even know why it costs this much.

> "an obvious problem with this, the pricing structure would become transparent "

How is the pricing structure not currently transparent? What number are you missing exactly?

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

#312

Post by manigandham »

newaccount74 wrote: post #291
manigandham wrote: post #211

Earlier quoted context omitted.

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

It's pretty simple: Ask people when signing up if they want to set a spending limit or not. If they do, return HTTP 500 as soon as the spending cap is reached. If it's for storage, return a quota exceeded error. Obviously the vendor shouldn't delete data, that would be stupid. A lot of people try to get hobby users on a platform as a form of PR -- if you don't have spending caps, you are probably going to scare a lot…

> "Obviously the vendor shouldn't delete data, that would be stupid"

Since data accrues charges over time, there is no alternative if you want a hard cap. Which is why none of this is very simple at all and requires a tremendous amount of planning and complexity just to implement, let alone all the possible new issues and mistakes it creates for customers.

Again, this is the typical "write some code in a weekend" approach that's missing all context of what it actually takes. And as I mentioned before, it's far easier to just negotiate billing then to deal with the aftereffects of whatever service and data disruption this feature would cause for the tiny fraction of customers that end up with this problem.

Waving your $5 fee is far easier and cheaper than spending millions on trying to avoid it in the first place, only to get replaced with potential complains that a production account was suspended or deleted.

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

#313

Post by newaccount74 »

manigandham wrote: post #310
newaccount74 wrote: post #307

Earlier quoted context omitted.

Can be unpredictable? How would data storage costs increase if you stopped accepting new data? SaaS companies manage to pull of ridiculously complicated things, but coming up with a billing scheme that does fuck over the customer is asking too much? The simple truth is that usage based pricing is designed to be unpredictable, and surprising customers with high bills is probably considered a feature, not a bug.

Data (and all resources) cost money per time. You don't need to add new data to an S3 bucket to get a bill every month because the existing data accrues charges. The billing scheme is very transparent and friendly by being pay-as-you-go. It doesn't "fuck over the customer". Your entire complaint isn't about the pricing scheme but about an additional feature to stop billing at some point - which I've explained is not…

> You don't need to add new data to an S3 bucket to get a bill every month because the existing data accrues charges.

Yes, but it's pretty predictable. Once there's enough data in your bucket that the monthly cost would go over the limit, just stop accepting new data.

Nobody cares if the spending limit is accurate to the cent. What people care about is not being surprised by huge invoices.

> The billing scheme is very transparent and friendly by being pay-as-you-go.

Have you looked at eg. the glacier pricing scheme, or at lambda pricing? It's almost impossible to know how much it's going to cost you ahead of time. The only thing you know is that if you happen to use it differently than anticipated, it's going to be expensive.

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

#314

Post by manigandham »

chanux wrote: post #222

I could relate to the comment on Redis. The only things I can see missing are automated Redis hosting by the platform. There have been so many times I wanted some simple key value store which I do not have to bother about setting up and taking care of. Something like "ambient Redis". It's OK not to have crazy scaling promises. You just enable an API (maybe for a small fee) and just use it. If and when you get big eno…

Anything can be a key/value store and there are dozens of managed databases with serverless pricing and public/HTTP access so you can use it anywhere with acceptable latency.

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

#315

Post by manigandham »

newaccount74 wrote: post #313
manigandham wrote: post #310

Earlier quoted context omitted.

Data (and all resources) cost money per time. You don't need to add new data to an S3 bucket to get a bill every month because the existing data accrues charges. The billing scheme is very transparent and friendly by being pay-as-you-go. It doesn't "fuck over the customer". Your entire complaint isn't about the pricing scheme but about an additional feature to stop billing at some point - which I've explained is not…

> You don't need to add new data to an S3 bucket to get a bill every month because the existing data accrues charges. Yes, but it's pretty predictable. Once there's enough data in your bucket that the monthly cost would go over the limit, just stop accepting new data. Nobody cares if the spending limit is accurate to the cent. What people care about is not being surprised by huge invoices. > The billing scheme is ver…

> "it's pretty predictable"

It quite literally isn't, otherwise there would be no billing surprises in the first place. Your entire argument about predictability is counter to the problem of unpredictable charges.

> "just stop accepting new data"

This is still effectively data loss and a major problem in production. Customers would rather negotiate a bill than lose data.

> "Nobody cares if the spending limit is accurate to the cent. What people care about is not being surprised by huge invoices."

Then it's a soft-cap, and if that's all you want then you already have billing alarms. Otherwise what's the buffer amount? What overage is acceptable? Is there a real hard cap? What if that's reached? You didn't actually provide any solution here.

> "the glacier pricing scheme, or at lambda pricing ... It's almost impossible to know how much it's going to cost you ahead of time."

How so? AWS is completely transparent about pricing. The calculations for it might be hard, but that's an entirely different issue. There are plenty of tools you can use if you don't want to do it yourself, however this is another logically incongruent point where you claim billing is easy enough to calculate and predict accurately for caps yet simultaneously hard enough that it's "almost impossible".

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

#316

Post by newaccount74 »

manigandham wrote: post #315
newaccount74 wrote: post #313

Earlier quoted context omitted.

> You don't need to add new data to an S3 bucket to get a bill every month because the existing data accrues charges. Yes, but it's pretty predictable. Once there's enough data in your bucket that the monthly cost would go over the limit, just stop accepting new data. Nobody cares if the spending limit is accurate to the cent. What people care about is not being surprised by huge invoices. > The billing scheme is ver…

> "it's pretty predictable" It quite literally isn't, otherwise there would be no billing surprises in the first place. Your entire argument about predictability is counter to the problem of unpredictable charges. > "just stop accepting new data" This is still effectively data loss and a major problem in production. Customers would rather negotiate a bill than lose data. > "Nobody cares if the spending limit is accur…

You are twisting my words. I said it's easy to predict storage costs, to counter your claim that you'd need to delete data to stay within budget.

The biggest problem are mainly exorbitant bandwidth costs, and those are trivial to cap -- just stop serving requests.

Also, billing alarms are not a soft cap. They don't prevent you from waking up in the morning to a 5000€ bill.

> You didn't actually provide any solution here.

I'm commenting on the internet, I don't need to come up with a way for AWS to implement billing caps, especially since they have designed their service pricing in a way that makes estimates really hard.

But for most services, billing caps really aren't that hard, especially since the company we are discussing here (fly.io) apparently already allows billing caps if you prepay (according to other comments here).

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

#317

Post by manigandham »

newaccount74 wrote: post #316
manigandham wrote: post #315

Earlier quoted context omitted.

> "it's pretty predictable" It quite literally isn't, otherwise there would be no billing surprises in the first place. Your entire argument about predictability is counter to the problem of unpredictable charges. > "just stop accepting new data" This is still effectively data loss and a major problem in production. Customers would rather negotiate a bill than lose data. > "Nobody cares if the spending limit is accur…

You are twisting my words. I said it's easy to predict storage costs, to counter your claim that you'd need to delete data to stay within budget. The biggest problem are mainly exorbitant bandwidth costs, and those are trivial to cap -- just stop serving requests. Also, billing alarms are not a soft cap. They don't prevent you from waking up in the morning to a 5000€ bill. > You didn't actually provide any solution h…

> "it's easy to predict storage costs"

You're just repeating this. Predictable is the opposite of surprise.

Even if storage use was very stable, so what? The overall bill is the problem so where the charges come from doesn't matter, only that eventually a limit is crossed. An overage is still an overage and the only way for billing to stop immediately is to delete and drop everything. This is the fundamental issue that you're not considering. It's what happens at the limit, not about how you get there.

> " billing alarms are not a soft cap"

Soft caps that don't actually stop anything are effectively nothing more than billing alarms. What else is their purpose?

> "I don't need to come up with a way for AWS to implement billing caps"

I didn't ask for implementation, I'm inquiring as to what logically is supposed to happen in the scenarios that occur based on your proposed "pretty simple" solution. If you can't answer then it's not so simple is it? You either haven't thought it through entirely to conclude that it's not actually possible to do that way.

> "designed their service pricing in a way that makes estimates really hard"

How so? You also keep repeating this without evidence. How is providing numbers on exactly what they charge for make it difficult? It's as transparent as it gets. They also have a calculator on their site. What more are you expecting?

> "for most services, billing caps really aren't that hard"

The nature of the service changes everything. Fly.io doesn't have billing caps, they just stop the apps when the credits run out and eat the bandwidth cost for now. The economics of scale can change that answer drastically, however even Fly repeats what I've said before: "the majority of people want their stuff to stay up" and "shut it down so you don't get billed" is usually not the preferred solution compared to negotiating a large bill.

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

#318

Post by newaccount74 »

manigandham wrote: post #317
newaccount74 wrote: post #316

Earlier quoted context omitted.

You are twisting my words. I said it's easy to predict storage costs, to counter your claim that you'd need to delete data to stay within budget. The biggest problem are mainly exorbitant bandwidth costs, and those are trivial to cap -- just stop serving requests. Also, billing alarms are not a soft cap. They don't prevent you from waking up in the morning to a 5000€ bill. > You didn't actually provide any solution h…

> "it's easy to predict storage costs" You're just repeating this. Predictable is the opposite of surprise. Even if storage use was very stable, so what? The overall bill is the problem so where the charges come from doesn't matter, only that eventually a limit is crossed. An overage is still an overage and the only way for billing to stop immediately is to delete and drop everything. This is the fundamental issue th…

> I'm inquiring as to what logically is supposed to happen in the scenarios that occur based on your proposed "pretty simple" solution.

Here's the simplest solution: If the limit is reached, stop serving requests, stop accepting new data, but don't delete any data. Allow static storage costs to go over the limit. That is probably what 99% of people who ask for a budget cap want, and it's the most logical thing to do because typically 99% of the charges are for bandwidth/requests/processing and only 1% for storage. If I set a limit at 10€ and amazon ends up charging me 10.2€ I can live with that.

The next simplest solution would be to look at how much is currently stored, multiply that with the storage cost per hour, multiply that with the remaining hours in the month, then subtract that from the monthly budget, and stop serving requests or accepting new data as soon as this lower limit is reached. This will guarantee that you never go over the limit without having to delete data. If data in storage is deleted before the end of the month, you'll end up spending less than the limit.

Now if you consider this basic math too complicated for a software engineer making $300000 a year, you could do something even simpler: allow the customer to set a limit on each resource. Eg. let the customer say, I want to limit S3 to 100GB of storage and 5TB of bandwidth and 2 million requests (or whatever). Of course that would be a bit of a hassle for the customer, but it would be very effective at preventing surprise charges.

> the majority of people want their stuff to stay up

At any cost? That's unlikely. I'm pretty sure that every company has some limit where they'd prefer the service to be down rather than pay the bill.

But if you go back up the thread you'll see that this discussion is about hobby users and tinkerers, and people who just sign up to try out the tech. These people absolutely want a hard cap on potential charges, and if you don't offer that you might scare them away.

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

#319

Post by john_the_writer »

WJW wrote: post #247
rr808 wrote: post #209

Earlier quoted context omitted.

This is pretty common in corporates too. Shiny new project gets all the attention, funding and management focus. The poor guys left to deal with the day to day crap get screwed over then leave. If they leave too soon its an emergency, if they stay too long they get laid off.

Oh for sure. The last company I worked at did a similar thing and decreed that all Ruby projects would be maintenance-only and all new projects were to be in Golang, despite there being a single golang dev in the entire company (who did not even work in the backend dev team but rather in a "platform" team). Within five months all the Ruby devs had left, so despite not a single Golang project being released yet the co…

Yeah.. I'm seeing the same thing where I work. Moving from ruby/rails to elixir. No outages, but dev speed is at a crawl. All the legacy stuff just gets ugly patches.

There was zero need to switch because even though elixir/BEAM allows for a pile of processes, postgres does not.

If I had to guess, the switch was made because someone saw something shiny.

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

#320

Post by john_the_writer »

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…

Lets re-write it they said. It will be easier to maintain they said. It will be more use friendly they said. We're Netscape and there's nothing like us they said.
Post reply on HN