Fly.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
Fly.io: The reclaimer of Heroku's magic
141–150 of 320 posts
Re: Fly.io: The reclaimer of Heroku's magic
#142Earlier quoted context omitted.
> I think people misconstrue the benefits of k8s to be related to reliability or similar. Ultimately it's about the API and the consistency and productivity it offers I think this is the first time I've heard somebody say one of the benefits of kubernetes was productivity.
Really? I think it's a pretty obvious benefit. If you bundle something into a container, you can probably run it in kubernetes. This uniformity makes it incredibly easy to deploy and scale new applications.
I think what I've heard is the kubernetes end result is very often a massively overcomplicated infrastructure that nobody understands, that's a constant source of headaches and lost time due to leaky abstractions.
Disclaimer: I've never actually used it myself. That's mostly just what I've read and heard from people who use kubernetes.
Re: Fly.io: The reclaimer of Heroku's magic
#143Earlier quoted context omitted.
We actually launched with that feature: https://news.ycombinator.com/item?id=22616857 No one took us up on it. What we found is that the majority of people want their stuff to stay up, and the right UX for "shut it down so you don't get billed" is not obvious. We ended up implementing prepayment instead. If you sign up and buy $25 in credit, we'll just suspend your apps when the credit runs out. Bandwidth is weird be…
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 layers, too. When you connect to a Fly app, you hit our edge, then traffic goes to a VM that's probably in another region. When you hit a hetzner server, there are no intermediate hops.
We usually pay that three times as data moves from customer VMs to our edges to end users (out from our edge to worker vm, out from worker vm to our edge, out from our edge to end user). Or 10x, in some cases, if data moves from Virginia to Chennai to an end user.
We pay $0.005/GB in the US and $0.9/GB in Chennai. You can see how this might add up. :)
Re: Fly.io: The reclaimer of Heroku's magic
#144Earlier quoted context omitted.
I'd love to do this, if for no other reason than I hate working with cron. What would you use it for? What would the ideal version of this feature look like for you? What kind of apps would you be more easily able to ship? Is it mostly so you wouldn't need to keep a single tiny running VM sitting around running cron?
I'd like to do any one-off job, not only scheduled ones; retrieving data and transforming or storing it, scraping a web page, running a database migration. My biggest annoyance with Fly is the assumption that everything is a long running application.
Don't tell anyone, but you can try "fly machines run" (currently only in a new, empty app). Then "fly machine start " to start the thing back up after it exits. It's not released yet, though.
Re: Fly.io: The reclaimer of Heroku's magic
#145Earlier quoted context omitted.
It sounds like you're asking if we offer some alternative between running multiple processes in a VM, and running multiple VMs for multiple processes. What's the third option you're looking for? 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.
> 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 this.
What you can't do is use docker-compose to boot up a bunch of different containers in different VMs on Fly.io.
Re: Fly.io: The reclaimer of Heroku's magic
#146Fly.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
The OP isn't associated with YC and we haven't touched the post - this is all organic. Given that, I don't see how it would add transparency to put "YC" in the title.
Also, I think if we start doing that to blog titles, people will complain about the opposite sort of shenanigan.
Re: Fly.io: The reclaimer of Heroku's magic
#147Earlier 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…
It's interesting that their bash init uses fg %1. That may return only on the first process changing state, rather than either process exiting. It should probably use this instead:
#!/usr/bin/env bash
/app/server &
/app/server -bar &
wait -f -n -p app ; rc=$?
printf "%s: Application '%s' exited: status '%i'\n" "$0" "$app" "$rc"
exit $rcRe: Fly.io: The reclaimer of Heroku's magic
#148Earlier quoted context omitted.
I'd love to do this, if for no other reason than I hate working with cron. What would you use it for? What would the ideal version of this feature look like for you? What kind of apps would you be more easily able to ship? Is it mostly so you wouldn't need to keep a single tiny running VM sitting around running cron?
> What would the ideal version of this feature look like for you? I think that Render solved "Cron as a Service" beautifully: https://render.com/docs/cronjobs
I would use render but fly.io persistent storage is a killer feature. It is literally 100x simpler to just deal with files on a real file system than having to deal with remote object storage.
Re: Fly.io: The reclaimer of Heroku's magic
#149Earlier quoted context omitted.
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…
It's interesting that their bash init uses fg %1 . That may return only on the first process changing state, rather than either process exiting. It should probably use this instead: #!/usr/bin/env bash /app/server & /app/server -bar & wait -f -n -p app ; rc=$? printf "%s: Application '%s' exited: status '%i'\n" "$0" "$app" "$rc" exit $rc
That looks a million times better than the horrible hack I wrote. Do you want credit for it when I fix the doc?
Re: Fly.io: The reclaimer of Heroku's magic
#150Earlier quoted context omitted.
> What would the ideal version of this feature look like for you? I think that Render solved "Cron as a Service" beautifully: https://render.com/docs/cronjobs
I would use render but fly.io persistent storage is a killer feature. It is literally 100x simpler to just deal with files on a real file system than having to deal with remote object storage.
Render has persistent disks! https://render.com/docs/disks. We need to expose them for cron jobs though.