Can someone explain what fly.io actually is for someone with an AWS background?
[deleted]
Fly.io: The reclaimer of Heroku's magic
281–290 of 320 posts
Re: Fly.io: The reclaimer of Heroku's magic
#282I really wish more of these PaaS solutions would offer UK regions - it's a big issue for us compliance-wise and means we can't use a lot of them. Render.com seems to be one solution - and we're currently using Cloud66 with our own AWS instances as a solution, although I would prefer something lower-effort, like Heroku has historically been.
Re: Fly.io: The reclaimer of Heroku's magic
#283Earlier quoted context omitted.
the website for fly.io is extremely well written in explaining fly.io in terms of AWS
So no? I went to the site and didn't see anything nor did a google search turn up anything
Re: Fly.io: The reclaimer of Heroku's magic
#284Earlier quoted context omitted.
I'm actually very curious: why is bandwidth so much cheaper on more traditional VPS or dedicated server hosts like Hetzner ? This extends to their somewhat new-ish cloud product, where you get 20TB traffic included - even on a tiny instance. And it's 1 Euro per TB after that. [1] Do they just decide to not profit from bandwidth or are they doing something special that allows them to be so cheap? [1] https://docs.hetz…
There are three ways to manage bandwidth prices: 1. Put servers where bandwidth is cheap (not Sydney, for example) 2. Constrain throughput per server 3. Buy from cheap transit providers like Cogent Hetzner does all three. Bandwidth in the US/EU is very cheap. They meter total throughput on their services. And they use cheap providers. None of these are bad choices, just different than ours. Our product has multiple l…
$0.9 is a typo, I meant $0.09/GB in Chennai. We're not taking that much of a haircut.
Re: Fly.io: The reclaimer of Heroku's magic
#285Fly.io is backed by YCombinator In order to increase transparency on Hacker News, it would be nice it the title was changed to include the fact that's it's backed by YCombinator https://www.ycombinator.com/companies/fly-io -- I personally don't think it's better than Heroku, you have much less features, Heroku is much cheaper + they have an unbeatable free tier
Just FYI https://www.ycombinator.com/companies/heroku
Exactly, ask yourself why you keep hear about them over here, that'll answser part of the reason why they are moving away from it and are looking for a "reset" with a new "brand"
The exodus
Re: Fly.io: The reclaimer of Heroku's magic
#286Earlier quoted context omitted.
Do they? I feel like you're just uncomfortable with line-item pricing and prefer flat all-in-one pricing. What are the other competitors that offer actual PaaS instead of static-site hosting? * Render.com charges $0.60 per custom domain after the first 25 * Heroku gives you "free" custom certificates once you're on a $7/mo minimum.
Yeah but "after the first 25" may cover the majority of their customers. I myself am one of them, and at this point I don't care at all what happens after I reach 25 domains. Essentially it _is_ free.
[deleted]
Re: Fly.io: The reclaimer of Heroku's magic
#287Earlier quoted context omitted.
Do they? I feel like you're just uncomfortable with line-item pricing and prefer flat all-in-one pricing. What are the other competitors that offer actual PaaS instead of static-site hosting? * Render.com charges $0.60 per custom domain after the first 25 * Heroku gives you "free" custom certificates once you're on a $7/mo minimum.
Yeah but "after the first 25" may cover the majority of their customers. I myself am one of them, and at this point I don't care at all what happens after I reach 25 domains. Essentially it _is_ free.
I agree with you of course. I feel the same way about fly.io’s pricing. For nearly all use cases, certs are free. Which is why I found it so odd that GP was complaining about it.
Re: Fly.io: The reclaimer of Heroku's magic
#288Earlier quoted context omitted.
Great question. I want to know the answer to it. I apologize for being skeptical but the wording in the contract seems to be extremely handwavy and they don't give me any confidence that if my bill goes from $4 to $200 that month because I made it to the front page of reddit, my bandwidth will magically be waived. Right now, I feel 100% sure that my credit card would get charged.
Contractually? I doubt it. But they have refunded many, many people on their forums after they report accidental charges. Whether they continue is a different story, but I feel safe using it and certain that I won't be overcharged. To be clear a bandwidth limit would be awesome! And the pricing may not be for everyone. However there is a large amount of leeway as evidenced by the community forum posts.
Good will does not feel like a good way to scale this. For a business that might be ok, but I’m highly unlikely to recommend to a business something I haven’t personally investigated, and I’m not writing cheques whose value is dependent on the good will of a startup.
I don’t understand why cloud providers will not accommodate this basic “prepay to X and allow me to use the credit” model.
Re: Fly.io: The reclaimer of Heroku's magic
#289Earlier quoted context omitted.
Not sure how Ruby works, but can you not run the workers and the web server in the same process? In our Node.js apps, this is as simple as importing a function and calling it.
Most of the popular background workers in Ruby run as a separate process (Sidekiq, Resque, GoodJob). The same goes for using Celery with Python. I'm not sure about PHP but Laravel's docs mention running a separate command for the worker so I'm guessing that's also a 2nd process. It's common to separate them due to either language limitations or to let you individually scale your workers vs your web apps since in a lo…
Yeah, it definitely makes sense to be able to scale workers and web processes separately. It just so happens that they app I work on for my day job is:
1. Fairly low traffic (requests per minute not requests per second except very occasional bursts)
2. Has somewhat prematurely been split into 6 microservices (used to be 10, but I've managed to rein that back a bit!). Which means despite running on the smallest instances available we are rather over-provisioned. We could likely move up one instances size and run absolutely everything on the one machine rather than having 12 separate instances!
3. Is for the most part only really using queue-tasks to keep request latency low.
Probably what would make most sense for us is to merge back in to a monolith, but continue to run web and worker processes separately I guess. But in general, I there is maybe a niche for running both together for apps with very small resource requirements.
Re: Fly.io: The reclaimer of Heroku's magic
#290Earlier quoted context omitted.
Imo it’s really simple, actually. Stop the service and delete after the next billing cycle. Price that in for regular price of the service.
That's limited to free tiers that usually deactivate or delete if there's too much usage. Anything with production usage and pay-as-you-go pricing means data at rest still costs money - and requires deleting to avoid accruing new charges. Do you want your databases and volumes and object storage deleted when your app stops? And if this was offered then there would be a whole new class of mistakes leading to lost data…
> billing is easier to negotiate than deleted accounts
Maybe, but I'd still like the option. My blog site is stateless so I couldn't care less if the service got deleted