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

101–110 of 189 posts

Re: Migrating from AWS to Fly.io

#101

Post by dehrmann »

garganzol wrote: post #79
atonse wrote: post #70

Earlier quoted context omitted.

The lack of “managed” Postgres is the only reason we haven’t moved 100% to fly. The idea of having to do my own upgrades by updating the docker container scares me. I have literally never run a stateful service off docker and don’t see the point, thanks to AWS. RDS has been extremely stable and boring. Maybe it’s out together by similar duct tape under the hood but it’s been incredibly solid for nearly a decade acros…

What stops you from using a managed database from a provider who specializes in it? If Fly builds it, it will create another Goliath who tries to eat everything.

I wonder if we're moving to an unbundling phase of the cloud.

The only reason I think we might not be is the selling point is less vendor lock-in, not something managed significantly better. For the most part, the major cloud providers have mature, feature rich product offerings for common use cases like DB, distributed queues, running services, load balancers, etc.

Re: Migrating from AWS to Fly.io

#102

Post by mrkurt »

dehrmann wrote: post #101
garganzol wrote: post #79

Earlier quoted context omitted.

What stops you from using a managed database from a provider who specializes in it? If Fly builds it, it will create another Goliath who tries to eat everything.

I wonder if we're moving to an unbundling phase of the cloud. The only reason I think we might not be is the selling point is less vendor lock-in, not something managed significantly better. For the most part, the major cloud providers have mature, feature rich product offerings for common use cases like DB, distributed queues, running services, load balancers, etc.

I hope we're unbundling! RDS is fine, but it doesn't really offer me (as an app dev ... sometimes) much. PlanetScale is a better MySQL: https://planetscale.com/blog/introducing-planetscale-boost

Re: Migrating from AWS to Fly.io

#103

Post by mrkurt »

memset wrote: post #93

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.

You can probably hack together with machines, though we're not a great fit for big bursts of compute. "fly machine run" is fun.

Re: Migrating from AWS to Fly.io

#104

Post by jesuspiece »

> Fly.io is not a support-first company. If this bothers you, then Fly.io is probably not for you.

> When emailing support, and email is the only option, it can take from hours to days to get a response. Sometimes they don't follow up. It does not feel like their level of support is on par with other cloud providers.

This enough to keep me on AWS. You can say a lot about AWS but their support is great

Re: Migrating from AWS to Fly.io

#105

Post by tptacek »

mostly_lurks wrote: post #95
tptacek wrote: post #88

Earlier quoted context omitted.

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 rig…

Usually, when I'm debugging a container, I start with a `tail -f /dev/null` entrypoint, or something like that, and then just shell into it to run the real entrypoint to see if it's working.

Re: Migrating from AWS to Fly.io

#106

Post by Aeolun »

jesuspiece wrote: post #104

> Fly.io is not a support-first company. If this bothers you, then Fly.io is probably not for you. > When emailing support, and email is the only option, it can take from hours to days to get a response. Sometimes they don't follow up. It does not feel like their level of support is on par with other cloud providers. This enough to keep me on AWS. You can say a lot about AWS but their support is great

Responsive at least. They’re very quick to inform you that x is a known issue with their service, and the request has been dispatched to the dev team.

Re: Migrating from AWS to Fly.io

#107

Post by rendaw »

DAlperin wrote: post #100
rendaw wrote: post #98

Earlier quoted context omitted.

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.

Thanks! Is there any documentation on the stable API? The link I posted has some normal REST stuff for machines, but nothing on other resources. I can't find any central API reference/etc in your docs.

Looking at the code, it uses GraphQL? I can't find any documentation on your GraphQL API either though, aside from a web editor that doesn't appear to be linked anywhere official.

Re: Migrating from AWS to Fly.io

#108

Post by Aeolun »

Octabrain wrote: post #16
mike_d wrote: post #11

Earlier quoted context omitted.

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." I think this is a terrible oversimplification and something tells me that you haven't had to deal with a complex database setup from an operations perspective. RDS reduces a huge overhead in terms of operations (ha, backups, upgrades and clustering being the first ones that come to my mind). Be…

> you don't know how to run a database.

Hah, I wish you didn’t need to know how to run a database to use RDS. So much is dependent on settings/parameter groups.

Re: Migrating from AWS to Fly.io

#109

Post by [deleted] »

jesuspiece wrote: post #104

> Fly.io is not a support-first company. If this bothers you, then Fly.io is probably not for you. > When emailing support, and email is the only option, it can take from hours to days to get a response. Sometimes they don't follow up. It does not feel like their level of support is on par with other cloud providers. This enough to keep me on AWS. You can say a lot about AWS but their support is great

[deleted]

Re: Migrating from AWS to Fly.io

#110

Post by [deleted] »

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…

[deleted]
Post reply on HN