12 ms·

the biggest reason of I am not using aws, google cloud, vercel etc... for my personal projects is surprise bills. I am not earning anything from them so I can o

the biggest reason of I am not using aws, google cloud, vercel etc... for my personal projects is surprise bills. I am not earning anything from them so I can only put $50 but can't afford $500 or $5000. so still i will feel much more secure if I can put hard limit and absolutely sure my bill will never go above $50. (or cloud billing insurance :)) but you got my attention, i can try fly.io

tptacek 2y ago
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.
- osbulbul 2y ago
  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 2y ago
    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.
    - gwbas1c 2y ago
      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 2y ago
        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 2y ago
        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 2y ago
        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.
- hinkley 2y ago
  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 2y ago
  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?
  - tptacek 2y ago
    Let me know if you find them!
  - sanbor 2y ago
    Vercel has spend management and an option to pause pro when reaching the spend amount https://vercel.com/docs/pricing/spend-management#pausing-projects https://vercel.com/docs/pricing/spend-management#pausing-pro...
- donavanm 2y ago
  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.”
reducesuffering 2y ago
Vercel has spending caps as of about a month ago.
- tptacek 2y ago
  Vercel is pretty great.
  - reducesuffering 2y ago
    There are so many Next.js apps. Please make sure the Next.js deployment on Fly.io is smooth as you'll inevitably get a huge exodus (including me) if/when too many people pay high prices on Vercel. Proxy for popularity: https://trends.stackoverflow.co/?tags=elixir,next.js,django,ruby-on-rails,laravel,go https://trends.stackoverflow.co/?tags=elixir,next.js,django,...
    - tptacek 2y ago
      We're not looking to pull people from Vercel. I'm not kidding, I like Vercel a lot.
isoprophlex 2y ago
Hetzner. 40$/mo gets you a 10-core, 20-thread intel box, 64 gb ram, 1 TB storage, unlimited traffic.

tptacek 2y ago

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.

osbulbul 2y ago
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 2y ago
  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.
  - gwbas1c 2y ago
    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 2y ago
      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 2y ago
        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 2y ago
        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.
hinkley 2y ago
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 2y ago
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?
- tptacek 2y ago
  Let me know if you find them!
- sanbor 2y ago
  Vercel has spend management and an option to pause pro when reaching the spend amount https://vercel.com/docs/pricing/spend-management#pausing-projects https://vercel.com/docs/pricing/spend-management#pausing-pro...
donavanm 2y ago
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.”

reducesuffering 2y ago

Vercel has spending caps as of about a month ago.

tptacek 2y ago
Vercel is pretty great.
- reducesuffering 2y ago
  There are so many Next.js apps. Please make sure the Next.js deployment on Fly.io is smooth as you'll inevitably get a huge exodus (including me) if/when too many people pay high prices on Vercel. Proxy for popularity: https://trends.stackoverflow.co/?tags=elixir,next.js,django,ruby-on-rails,laravel,go https://trends.stackoverflow.co/?tags=elixir,next.js,django,...
  - tptacek 2y ago
    We're not looking to pull people from Vercel. I'm not kidding, I like Vercel a lot.

isoprophlex 2y ago

Hetzner. 40$/mo gets you a 10-core, 20-thread intel box, 64 gb ram, 1 TB storage, unlimited traffic.