191–200 of 310 posts
If I were fly I’d implement spending caps just to filter out unserious operators. My implementation of that feature would be when you turned it on fly would just kick you off. No serious operator wants a provider to turn their system off. So if you want that it’s pretty clear you are hosting a silly system. Which likely costs more to support and drives less margin.
If I were fly I’d implement spending caps just to filter out unserious operators. My implementation of that feature would be when you turned it on fly would just kick you off. No serious operator wants a provider to turn their system off. So if you want that it’s pretty clear you are hosting a silly system. Which likely costs more to support and drives less margin.
No serious operator would choose a provider with your implementation of that feature.
Earlier quoted context omitted.
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…
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 i…
Earlier quoted context omitted.
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 i…
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.
Earlier quoted context omitted.
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.
I reiterate that you are not unique in offering a service where the customer's desire for consistent billing and your willingness to provide it are at odds.
Earlier quoted context omitted.
Same but on Hetzner. Incredibly beefy machines. Unlimited traffic. No fear of any sudden changes that I explicitly didn't act upon. I do not know why people fall for the shiny marketing so easily, that too hackers? Is it all the Javascript folks? Vercel I know is propped up by them for sure.
I am never going to get tired of telling people that if they can solve their problems running on Hetzner, they should do that. It's not like a dirty secret of our industry. By all means, deploy with VPSs! Or on bare metal servers!
Earlier quoted context omitted.
I am never going to get tired of telling people that if they can solve their problems running on Hetzner, they should do that. It's not like a dirty secret of our industry. By all means, deploy with VPSs! Or on bare metal servers!
Do you have a blog post on fly's blog where you tell people that?
But I'm happy to remind people here of it!
Earlier quoted context omitted.
I reiterate that you are not unique in offering a service where the customer's desire for consistent billing and your willingness to provide it are at odds.
I don't believe you saw me say that.
i think is what gave that vibe off. I was on a read-only phone in bed and saw the quoted message. got up and logged into the PC to think about what to say. It may be time for cloud providers to dissuade small users away, instead.
Earlier quoted context omitted.
My preferred option would be to have an optional billing cap that I can enable knowing full well that if it is exceeded the service would be terminated (obviously with notifications as that cap is approached). I could then apply this to simple hobby projects and such, while not having the risk of termination apply to more serious applications (though a 'soft cap' would be nice here so that I could still receive notif…
As a certain kind of user, you probably do think that. But I also think I should be able to have a root level admin account without MFA. The consensus is that no, that should not be up to the customer. It's different here, sure, but the providers optimize for not letting customers shoot themselves in the foot, and remediation via bill forgiveness is a fine solution -- from the provider POV.
Earlier quoted context omitted.
You might be happier with a fixed-size VPS, instead of a cloud provider,
I started writing this comment by saying: Exactly - the whole point of a cloud provider is scalability. If you're doing a personal hobby project, get off big scalable clouds and get yourself one (or multiple!) fixed-price VPS or dedicated servers. But as I think of it, I think what people really want, for hobby projects, is not so much the scalability, but the managed offerings. They want zero-ops, zero-maintenance,…
offerings were published on the main page and afaik no takers. We migrated off whatever hypervisor we were using onto wok/kimchi and finally to proxmox, so my scripts still work, but proxmox has turnkey linux "quickstart" servers now as well as lxd, so there's less reason to use my scripts.