[tptacek]

Except for things like student accounts, which we're working on, I don't think hard limits are coming any time soon. Our expectation is that the enforcement of hard billing limits would mostly make customers furious with us. If you read to the end of the post, the direction we're going is preemptive detection of weird billing spikes, so you don't even have to notice and ask us.

If you're really only looking to spend $50, we should put our cards on table and say that we're generally not making product pricing decisions with you in mind. If your needs are pretty straightforward, there are hosting providers that will do a better job of serving that business than we will.

[hinkley]

If there is a class of people who get steered to your service by a small number of organizations, you might. Universities, trade schools, a podcaster you’re sponsoring.

You can’t scale to individualized service for $50 per month/quarter/year users, that’s true. But you can shape policy for a demographic with… shall we call it flocking behavior, for lack of a better term?

[ilaksh]

I love your service, but this erroneous take makes me think that even if I was looking to spend up to $500 with a "real" business, you don't have me in mind.

There should obviously be multiple types of caps. AWS and others have set a precedent that they can get away with "gotchas" for anyone who isn't paying attention.

It's really the primary business model. People that aren't watching costs have more and more sneak in there.

Does anyone know of a service like fly.io that has a perspective that's more friendly to bootstrapped startups?

[sanbor]

Vercel has spend management and an option to pause pro when reaching the spend amount https://vercel.com/docs/pricing/spend-management#pausing-pro...

[tptacek]

Let me know if you find them!

[donavanm]

FWIW I believe your reasoning is exactly what I saw/learned at AWS. The potential cost of losing/disappointing “real” customers greatly outweighed the notional cost of lost “scared” customers.

One interesting thought was trying to model some of this as an actual insurance method. Think of the cases where an adversary of the customer might inflate their costs through 3p usage/traffic. Providers dont want to incentivize those adversaries, deny the customer service, or charge them for unuseful service. Normally it devolved to credit/forgiveness, but then that moves the customers business model risks to the provider. What if this functioned similar to an insurance model; very cheap/baked in forgiveness for everyone (as today), then based on risk profile (porn/games/polical/gambling, or previous occurrence) the customer gets the option of buying forgiveness insurance or self funding their risk. The real sticking point is around perceived/potential conflict of interest and goodwill for the provider to say “pay us more for a thing that you cant directly control.”

[osbulbul]

yeah I am pretty sure no cloud provider thinks people who can willing to spend small money. but guess what? if one of my projects start earning money, then I will continue to what I know best :) I think that's why every cloud provider still has configs for couple of $

[tptacek]

We think all the time about people starting small projects here. I think a really good line to draw, if you want to understand how we think about this stuff, is between people who would be OK with us terminating their service because they mispredicted what their cap should be, and people who need their stuff to stay up and running and will just talk to support if they're concerned about billing. A shorter way to say this is that we making product pricing decisions for people who are doing this work professionally.

[spion]

You're selecting for people who feel they're priviledged enough to reach out to support and ask for bill forgiveness even when they may've messed up, repeatedly. This does select for something but I'm not 100% sure "people who are doing this work professionally" is that clear-cut, especially once you move past western cultural norms.

[gwbas1c]

One thing I'm really curious about is why caps are so hard? (Perhaps this would result in a more technical blog post?)

IE, you clearly don't want to terminate or shut down an account if they get too close to a cap. But what about things like a warning email, service slowdown, ect?

Likewise, the old "slashdotted" or "hug of death" might be an appropriate result when something goes beyond a reasonable safety buffer?

Anyway, just curious. It's clear that it's a complicated topic, and the real constraints and challenges are interesting.

[tptacek]

We talk about warnings in the post. We'll do that at some point. The hard part about caps is what to do when someone hits them.

If there was a way to make caps work for our core customers, we'd do it. We're open to ideas. A theme of our work this past month and these next several months is extracting maximal value from ANFWWAONW, our new billing system. The thing you have to remember though is that our belief about our core customer is that they are averse to nothing more fiercely than service disruption.

We're not in principle opposed to caps. We just don't have a product story for them that we're comfortable with. Keeping you from spending more money than you wanted to is an explicit product goal of ours (again: see post); we're just very wary of trading availability off against that goal.

[Alacart]

Configurable warnings as webhooks would be pretty cool. Then I can automate whatever needs to happen on my side.

I already automate apps, machines, etc with the machines API and GraphQL, so my big worries in this area are:

- Woops, some bad logic deployed too many machines (sounds like this policy helps) - Some kind of mistake or attack that just explodes bandwidth usage suddenly

[Aeolun]

You are comfortable scaling a service down to zero when configured to do so though.

Of course that comes up again when anyone sends a request, but that feels sort of in the same category.

That said, I do understand that building your service for people like me that’d rather be restricted to just $50/month doesn’t really make sense.

[tptacek]

I don't think anyone with a serious app running on us will use a cap. Just stay fixated on this scenario: a deploy-only token gets stolen, and the attacker (like most cloud attackers) uses it to stand up a bunch of Monero miners. As a consequence... their main app goes down? Who would be OK with that?

[donavanm]

Metering, pricing, and billing is way more complicated than you might assume. There are historical posts here with more details if you search. In short its all async, theres variable lag, theres multiple “types” or dimensions to metering, the prices vary by SKU + customer + previous metering or billing value + other SKU usage, and billing is not uniform across customers. Imagine needing to accumulate all the metering events, apply pricing plans, modify price based on accumulated value, then periodically recalculate it all to compute a bill, then apply more transforms and credits, and that gets to the billable price.

Now evaluate your “cap” rules (which will be just as complex) and feed that back to the actual admin/control plane of the service.

[naniwaduni]

No, this is motivated reasoning brainrot. It's overcomplicating the problem by hyperfocusing on a specific implementation that's already been judged infeasible to justify not doing it.

The actual problem that people want solved is "the customer wants predictable, budgetable upper bound periodic cost". You are not unique in offering a service where this is a desirable property. Realigning this sort of cost structure is the bread and butter of insurance industry, and no, as much as they'd like to, they don't actually do it by making sure to stop the earthquake before it knocks down more of your house than your price cap.

[donavanm]

I dont understand what youre on about. The post I replied to, and many others, use “caps” to refer to limits of service based on billing. This is an endless source of comments on every “cloud” topic. I provided a very brief overview of why large billing systems are more complicated than expected and have an impedance mismatch to the stated desire. But sure, tautological brain rot. Got it. Im sure you have a wealth of experience with metering, billing, and pricing for billion dollar revenue streams.

Now if you have some _other_ proposal for how billing and service limits could function Im legitimately interested. But I dont see anything at all specific or actionable in your replies. Insurance is interesting for _some_ facets. Im curious how you think that aligns with dynamic resource utilization and what happens at the boundary.

[tptacek]

No, this is a much harder problem than you think it is; it's, like, CAP-theorem problematic. I think you should do the exercise of working through how these billing systems work.

[gwbas1c]

I understand all that; and that's not really the kind of information I'm looking for. (I know deeply that metadata is often more expensive and complicated to process than the data your customer cares about.)

This response explains the problem best: https://news.ycombinator.com/item?id=41334596

> I don't think anyone with a serious app running on us will use a cap. Just stay fixated on this scenario: a deploy-only token gets stolen, and the attacker (like most cloud attackers) uses it to stand up a bunch of Monero miners. As a consequence... their main app goes down? Who would be OK with that?

Reading between the lines: If a customer's utilization suddenly spikes, the assumption is that the customer's revenue will follow. IE, if my utilization goes up 10x, my revenue will go up 10x, so I'll happily pay the bill.

What they are providing is more like an insurance policy against hacking.

And that is the answer that I was looking for.

[rincebrain]

It "seems" simple, but people have really complicated needs, and the simplest answer if you don't have the time to build and maintain something to cover enough of the state space to make enough people happy is to not support it.

Some people are going to want you to go to 1Mb/s if you blow your bandwidth limits, or cash spend. Some might want you to go to 10 connections at once. Some might want you to just disable networking entirely.

And what happens to your storage when you blow your billing? Or CPU time?

It all becomes a hairy mess of state machines and companies wanting precisely _their_ requirements met, so you try to offer as much as you need to still have a compelling offering that enough people want to use, and no more.

Probably at best you could provide an API to make it easy for customers to build their own state machine, but that's fraught because then the customer will still blame you even if their own code did the wrong thing.

[naniwaduni]

Sinclair effect in action: "It is difficult to get a man to understand something, when his salary depends on his not understanding it."

Obviously, cloud providers are capable of billing. It's not unreasonable to expect them to offer, at minimum, "Look, we're not evaluating billing continuously but we might, at our option, try to shut down your services after $X and won't bill you excess of $Y" as a (optional) hard contractual term. Having a larger, well-capitalized party absorb risk on behalf of a smaller party for a fee is a business model humans know how to price. It's just not the desired "product".

Note that this doesn't even per se require any technical artifact to implement, just very primitive metering and lush margins.

[tptacek]

Seriously question: have you thought through what billing for bandwidth, storage, compute, and services actually entails? I'm having a bit of a reaction to the word "obviously" there.

[naniwaduni]

I don't need to, the fact is manifest in your ability to send out the bills for them. This seems very obvious to me, and your incredulity is baffling.