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

251–260 of 320 posts

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

#251

Post by nicoburns »

nickjj wrote: post #124
nicoburns wrote: post #107

Earlier quoted context omitted.

For low-latency workers like that it might make sense to just run them on the same instance as the web servers.

Does Fly let you run multiple commands in separate Docker images? That's usually the pattern on how to run a web app + worker with Docker, as opposed to creating an init system in Docker and running (2) processes in 1 container (this goes against best practices). The Fly docs only mention the approach of using an init system inside of your image and also tries to talk you into running a separate VM[0] to keep your we…

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.

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

#252

Post by nicoburns »

tptacek wrote: post #145
nickjj wrote: post #137

Earlier quoted context omitted.

> Are you asking if you can run Docker inside a VM, and parcel that single VM out that way? You've got root in a full-fledged Linux VM, so you can do that. On a single server VPS I'd use Docker Compose and up the project to run multiple containers. On a multi-server set up I'd use Kubernetes and set up a deployment for each long running container. On Heroku I'd use a Procfile to spin up web / workers as needed. The F…

The document you cited (I wrote it!) is entirely about the different ways to run multiple processes in 1 VM. There's no reason I can see why you couldn't run a VM that itself ran Docker, and have docker-compose run at startup. I wouldn't recommend it? It's kind of a lot of mechanism for a simple problem. I'd just use a process supervisor instead. But you could do it, and maybe I'm wrong and docker-compose is good for…

I think docker-compose is pretty good at this. One advantage is that you get a development environment and a production setup in a singe config file.

I feel like this setup might make quite a lot of sense if you have a bunch of micro services that are small enough that they can share resources.

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

#253

Post by berkes »

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…

I was in the exact same spot (only on render.com), where Redis seemed overkill, but a key-value store was needed.

So I created a Postgres Key Value Ruby library. https://github.com/berkes/postgres_key_value

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

#254

Post by nik736 »

manigandham wrote: post #248

Fly has a nice DX but unfortunately the platform still has major issues with reliability and networking. There are often problems with deploys leading to stuck and unreachable instances or other networking issues. It's probably exacerbated by the new user growth but the slick deploy workflow can't override having an app that works. Render and others are interesting but K8S is still fundamentally better considering al…

What exactly makes K8s better?

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

#255

Post by jillesvangurp »

I don't get this obsession with running a lot of vendor specific tooling on a laptop. Don't people use CI/CD? The only place that will ever deploy anything to anywhere is CI in my setups. And only after the tests pass.

I see this over and over again where the first step of using something supposedly user friendly is to install a lot of command line cruft on your snow flake laptop. It only goes downhill from there. Great for amateurs but usually left as an exercise for the reader to beat some sense into bad practices like deploying things from a laptop.

IMHO it should start from the other end and actually provide you with a sane CI/CD pipeline out of the box. Google cloud run does this right. You just give it a repository url and it sets up the rest. I used that two years ago and I was up and running in about 2 minutes. Every commit to master went live. CI/CD out of the box. No magical incantations on the command-line. Just develop as you do normally. Zero fuss.

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

#256

Post by sascha_sl »

nik736 wrote: post #254
manigandham wrote: post #248

Fly has a nice DX but unfortunately the platform still has major issues with reliability and networking. There are often problems with deploys leading to stuck and unreachable instances or other networking issues. It's probably exacerbated by the new user growth but the slick deploy workflow can't override having an app that works. Render and others are interesting but K8S is still fundamentally better considering al…

What exactly makes K8s better?

Definitely not the developer experience.

But as it is often mentioend, as companies and apps grow, so do their requirements and the need for flexibility. I can't think of a more flexible deployment target that handles a lot of the PaaS concerns than Kubernetes, warts and all.

Fly is surprisingly great, volumes + containers is very close to universal for a PaaS, but it certainly can't cover everything that is running in my workplace's kubernetes.

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

#257

Post by xchaotic »

manigandham wrote: post #211
EnKopVand wrote: post #69

Earlier quoted context omitted.

I don’t want an unlimited bandwidth promise, I want a cap that I know can never be exceeded. I mean, I use Azure professionally and one of the key reasons I don’t use it to host my own stuff is exactly because it could potentially become very expensive. I’d rather have my own stuff shut down until I decide what I want to do with it. Things like alerts are fine, professionally, but not for things like running a small…

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…

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.

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

#258

Post by tailsdog »

2c2c2c wrote: post #12

There's a lot of chat about fly.io on HN. possibly just because the founders and friends are posters here. Is there any in depth comparison between them and render.com ?

They are backed by Y Combinator so that might be why they get extremely decent exposure on HN.

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

#259

Post by endorphine »

datalopers wrote: post #93
ushakov wrote: post #82

Earlier quoted context omitted.

well, maybe but, my expectation as a PaaS customer in 2022 is that you shouldn't need to pay for a SSL cert the expectation is because nobody else charges for them anymore, not even their competitors

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.

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

#260

Post by xchaotic »

crummy wrote: post #238
franciscop wrote: post #156

Earlier quoted context omitted.

This is the reason I use Heroku and would never on a personal level use some of the bigger solutions, or apparently Fly.io. As an individual and despite being generally careful, I just cannot have a tiny risk of having a $100k+ accidental bill. I'd rather my project goes down if there's a DDOS attack, or if I made a typo and created an infinite loop. If I take some of my hobby projects to the "next level", it'd be de…

Is it possible to rack up a 100k+ bill with personal projects on platforms like fly.io? Like some absolutely massive DDOS or something?

It could also be a simple user error- there’s been stories on HN on how people racked up massive bills for example because CI was running continuously etc.
Post reply on HN