For me, Fly.io is like a seminal step forward to an imaginary OS of the future: standardized, auto-clustered, just works, dead simple to grasp. Kind of Windows 95 of its time.
[deleted]
Migrating from AWS to Fly.io
111–120 of 189 posts
Re: Migrating from AWS to Fly.io
#112Earlier 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." Which is hopefully virtually everyone whose full-time job isn't DBA.
I used to be very dba focused ages ago. Aws RDS for postgres I just love. Their RDS products must print money. Yes I could deploy myself. Yes I could use docker in various ways - I use docker for most app deploys. But but but - if you’ve been down the rabbit hole of scaling a database - or backing up, updating, securing etc its a no brainer - and aws let’s you start small
Re: Migrating from AWS to Fly.io
#113Earlier quoted context omitted.
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'd trust a first-party managed postgres built by fly more than a third-party one.
I like their strategy of outsourcing what they’re not best at to the best. They partnered with upstash, and now they’ve got a new feature almost immediately. Sure there’s a lot of vetting, but wrapping products is common.
I’d be happy if they can wrap Neon’s serverless postgres service into their networks somehow.
Re: Migrating from AWS to Fly.io
#114No where do I see mentioned how much was actually saved in dollar figures. What are we talking here—thousands, hundreds? Similarly, I'd be interested in knowing engineering effort involved in the migration. As a software consultant focusing on designing, building, and deploying software on AWS, more often than not, the infrastructure cost issues I've seen have less to do with the underlying infrastructure provider —…
The biggest $ cost I'd have on my radar WRT AWS vs Fly is complexity and need-to-know of employee time to do any given thing. Fly is way easier to navigate and use than AWS and its labyrinth of Cloud Scale™ horrors. The trade-off being you can do more given things with AWS.
I can't wait for Fly to disrupt the market of Cloud Native Eldritch Horrors™
Their SLA's a bit too iffy for my use case atm but I wish them well in this noble endeavor.
Re: Migrating from AWS to Fly.io
#115Earlier quoted context omitted.
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.
As fly apps v2 becomes more stable the docs will continue to improve. Watch this space :). As for the graphql, it's a bit of a thorny situation. The graphql exists primarily to service our needs internally and as such has no guaranteed contract. Unfortunately, however, for some things that's the only API that exists. The autogenerated docs in the playground are pretty good actually though. That said, we are working on improving our rest api so more things will be available there.
Re: Migrating from AWS to Fly.io
#116Earlier quoted context omitted.
I'd trust a first-party managed postgres built by fly more than a third-party one.
I like their strategy of outsourcing what they’re not best at to the best. They partnered with upstash, and now they’ve got a new feature almost immediately. Sure there’s a lot of vetting, but wrapping products is common. I’d be happy if they can wrap Neon’s serverless postgres service into their networks somehow.
Neon CEO here.
We are working on becoming first party service on several major problems now. We will be happy to provide this for Fly. Kurt and I have been chatting.
Fly wants cross region replication which is coming soon. Once it's there we can integrate.
With that Neon is still on AWS and can be close to Fly, but not run on Fly servers. It's relatively straightforward for us to run on Fly, but the S3 part will still be Amazon.
Re: Migrating from AWS to Fly.io
#117> 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
Yeah, I'm ok with "hours to days" of mysterious downtime for some personal projects. But for my day job? Deal killer for sure.
Re: Migrating from AWS to Fly.io
#118Earlier 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.
> What stops you from using a managed database from a provider who specializes in it?
A lack of integrated security and authorization? Should be solvable though.
The expense of external traffic? The latency to a DB in a different datacenter?
Re: Migrating from AWS to Fly.io
#119The 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…
Does Fly allow to run unmanaged Postres easily enough? Or even semi-managed, as easy-to-provision nodes without redundancy where you yourself set up pgbouncer, replication, etc? For simpler cases it could very well suffice.
Re: Migrating from AWS to Fly.io
#120The 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…
Does Fly allow to run unmanaged Postres easily enough? Or even semi-managed, as easy-to-provision nodes without redundancy where you yourself set up pgbouncer, replication, etc? For simpler cases it could very well suffice.
Fly Postgres is just a Fly.io app. You can see the source code for it right here:
https://github.com/fly-apps/postgres-ha
It has some direct `flyctl` integration (which is also open source), but it's not doing anything you can't do yourself if you want.