Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Migrating from AWS to Fly.io

terrateam.io

Post reply on HN
Print view View original

91–100 of 189 posts

Re: Migrating from AWS to Fly.io

#91

Post by memset »

joao wrote: post #75
tommoor wrote: post #59

Fly is great. I know the Fly team has an aversion to it but I really just wish they would hire some database folks and take on managed Postgres. I'm already running 8+ apps on there and it would be the peace of mind needed to move the rest across… one day.

Would love this also. The best option I could find was using Digital Ocean Managed Databases. The cheapest costs $15, but you can host multiple databases with good insights and backups. You can choose where you host it, and place it close to the region where youre Fly.io apps are, with low latency. Only caveat is there isn't an easy way to automatically update the IPs whitelist of the database, to support the Fly bui…

I recently switched to fly.io + crunchybridge. Crunchy is super easy to set up and their cheap plan ($10/month) is quite performant too.

Re: Migrating from AWS to Fly.io

#92

Post by ignoramous »

mrkurt wrote: post #69
tommoor wrote: post #59

Fly is great. I know the Fly team has an aversion to it but I really just wish they would hire some database folks and take on managed Postgres. I'm already running 8+ apps on there and it would be the peace of mind needed to move the rest across… one day.

I'm not completely averse (we've done this before!), it's just not how I think the world should work. If we hold out, and the future Fly cloud has a better-than-RDS Postgres option, it will be worth it. If we build our own managed Postgres, no one better is going to bring their stuff to our platform. Same with MySQL.

> I'm not completely averse (we've done this before!)

For those out-of-loop: https://news.ycombinator.com/item?id=7382151

Re: Migrating from AWS to Fly.io

#93

Post by memset »

Since the fly folks are here: I'd love the ability to trigger jobs as I can with aws batch. The ability to do `fly run -a journalize-batch --command="python3 upload.py"` is something I need right now and am in the process of setting up aws batch to do it.

Re: Migrating from AWS to Fly.io

#94

Post by petesergeant »

mike_d wrote: post #11
throwthere wrote: post #6

The article mentions this, but that’s strongly enough in my opinion. With fly you have no managed PostgreSQL. In my opinion, it’s not really comparable on cost to aws when Postgres is in the stack. You do read about interesting hacks where someone will set up rds in a region that may be single digit milliseconds away from a fly region. then, presumably, you could put PG bouncer on a sort of bastion host that connects…

https://fly.io/docs/postgres/ It isn't "Managed Postgres," but the differences are minimal. RDS is ultimately a solution for people who look in the mirror and confidently say "you don't know how to run a database."

> RDS is ultimately a solution for people who look in the mirror and confidently say "you don't know how to run a database."

Which is hopefully virtually everyone whose full-time job isn't DBA.

Re: Migrating from AWS to Fly.io

#95

Post by mostly_lurks »

tptacek wrote: post #88
mostly_lurks wrote: post #87

Earlier quoted context omitted.

Caveats: 1) this may not be what grandparent was trying to do and 2) I have limited experience debugging "regular" Docker, let alone firecracker or whatever Fly.io does. With that said, I succesfully deployed a simple Rust/Actix/Sqlite app with a Dockerfile to Fly.io. I then thought I'd try out litestream. For reasons I'm still not sure about, having `ENTRYPOINT ["litestream replicate … -exec myapp"]` resulted in imm…

One of my biggest UX nits with Fly (I have no excuses, I have all the access I need to go fix this myself) is that we "kernel panic" when your entrypoint command fails. Of course, our kernel is not really panicking --- we've just run out of things for our `init` to manage, so it exits, and when pid 1 exits, so does the kernel. But you get the terrifying stack dump. We can clean this up, so that you get a clearer, sim…

That all makes sense. I think context matters. Yes, when I have a service that's been up and running for some time, if that service fails, I want my service to restart.

But when I'm trying to get a service running for the first time and I'm not sure that I have the right command in the entrypoint, the right arguments to that command, or the right supporting files in place, or the right libraries installed, or the right file permissions, …, well, then I don't want things to just blindly restart, I want a handle and some information so I can figure out why it isn't working.

ETA: I recognize that your link to docs about running a supervisor addresses this problem. For me this raises some interesting questions. Like, I understand why Ben would implement `litestream exec` but maybe it would be better to steer users to a proper supervisor? Separately, what if it's the supervisor that's failing? Now I'm back to seeing kernel panics and not having error messages or a shell.

Re: Migrating from AWS to Fly.io

#96

Post by boundlessdreamz »

Since the fly folks are here, do you plan to support monorepo apps in a single fly.toml. i.e define all services in a single fly.toml like docker compose or render's blueprint?

Also a way to reuse the definition but run a different command. For example for a rails app, web worker (puma) and job worker (sidekiq) differs only in the command run. In fly, I would have to duplicate those. If there is an easier way, do let us know.

Re: Migrating from AWS to Fly.io

#97

Post by mtlynch »

garganzol wrote: post #89
mtlynch wrote: post #86

Earlier quoted context omitted.

Yeah, but going from 1 to N instances is a big jump in complexity for not much more uptime. I'd rather have a host that can do around three nines and just accept that as my upper bound.

The key moment is not to have any persistent state in the app. App may use a database, that's ok, but the app itself should not store any persistent state on a hard drive. Once that simple requirement is met, the scaling becomes easy.

Right, but keeping a database externally adds a lot of complexity.

My apps are self-contained in a single Docker container. Just Go, SQLite, and Litestream:

https://mtlynch.io/litestream/

Re: Migrating from AWS to Fly.io

#98

Post by rendaw »

mrkurt wrote: post #90
rendaw wrote: post #77

Earlier quoted context omitted.

Sorry, not to use this as a support forum, but what exactly does it need? Just some provider-side bug fixes? Or are there Fly-side changes that need to be made before it will work? If it's something small I wouldn't mind poking at it.

Just provider bug fixes / developments. The APIs it use are pretty stable. The particular errors in those issues look like either badly formed API calls, or something weird with auth. It also probably needs an update to use api.machines.dev. It is currently trying to connect over wireguard to hit our private API, because we didn't have a public API endpoint when it was built. This is probably brittle. :)

What's api.machines.dev? The documentation here says you need a VPN connection still https://fly.io/docs/machines/working-with-machines/

Can I just sub `https://api.machines.dev` in for the api hostname everywhere?

Re: Migrating from AWS to Fly.io

#99

Post by mrkurt »

boundlessdreamz wrote: post #96

Since the fly folks are here, do you plan to support monorepo apps in a single fly.toml. i.e define all services in a single fly.toml like docker compose or render's blueprint? Also a way to reuse the definition but run a different command. For example for a rails app, web worker (puma) and job worker (sidekiq) differs only in the command run. In fly, I would have to duplicate those. If there is an easier way, do let…

The second case has experimental support already: https://fly.io/docs/reference/configuration/#the-processes-s...

The first, we're not completely sure about yet. Probably someday, though.

Re: Migrating from AWS to Fly.io

#100

Post by DAlperin »

rendaw wrote: post #98
mrkurt wrote: post #90

Earlier quoted context omitted.

Just provider bug fixes / developments. The APIs it use are pretty stable. The particular errors in those issues look like either badly formed API calls, or something weird with auth. It also probably needs an update to use api.machines.dev. It is currently trying to connect over wireguard to hit our private API, because we didn't have a public API endpoint when it was built. This is probably brittle. :)

What's api.machines.dev? The documentation here says you need a VPN connection still https://fly.io/docs/machines/working-with-machines/ Can I just sub ` https://api.machines.dev ` in for the api hostname everywhere?

Yeah. api.machines.dev is a public endpoint for our machines api.

EDIT: See this comment for an example on how to make the provider use the public endpoint https://github.com/fly-apps/terraform-provider-fly/issues/42...

EDIT EDIT: I pasted the wrong link, sorry about that.

Post reply on HN