Would have loved to read how much money they saved from this migration. The number's not there, unfortunately.
Migrating from AWS to Fly.io
61–70 of 189 posts
Re: Migrating from AWS to Fly.io
#62I've migrated several services from GCP to Fly.io, and I've been very happy with Fly. All of my apps are low-volume hobbyist web apps that run on a single machine, so I don't do any Terraform, k8s, or Postgres, so my use case is a little simpler than OP. My biggest complaint has been with outages,[0, 1, 2] but that's gotten better. The original architecture meant that larger servers could evict other users' running s…
To avoid outages, just scale up the number of app instances to like 2 or 3 and choose a diverse geography for them.
Outages is not something specific to Fly. For example, if you have an app on Azure and it has only one instance then... well, you asked for it to go down from time to time.
Maybe not a big deal for hobby projects, but for business critical stuff one should always consider deploying several instances of the same app when possible.
Re: Migrating from AWS to Fly.io
#63The 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…
Isn't it usually a bad idea to have the database and application server in different data centers? It is / was my understanding that both the database and application server should ideally be on the same rack.
[deleted]
Re: Migrating from AWS to Fly.io
#64Re: Migrating from AWS to Fly.io
#65Earlier quoted context omitted.
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.
Yeah, this. AWS enables you to do anything you can think of, at any scale and complexity, given enough time spent reading their documentation and crafting terraform configurations. Fly makes it really easy to do the 80% of things that most small/medium operations need to just get done now.
[deleted]
Re: Migrating from AWS to Fly.io
#66No 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.
>Fly is way easier to navigate and use than AWS and its labyrinth of Cloud Scale™ horrors
Give fly.io a couple years and it will end up forced to take on all the complexity and edge cases AWS and Azure have to deal with today.
A shiny new codebase is always nicer than an old one, because the old one has had to accommodate all those pesky customer needs.
Re: Migrating from AWS to Fly.io
#67Earlier quoted context omitted.
Isn't this just how Prometheus works alongside Grafana? I've never used fly.io but I've used that exact setup with these two services.
I believe GP is commenting on fly’s integration. Fly comes with built in Prometheus scraping and prepopulated grafana dashboards for VM resources some connection/request metrics. I believe the value is that if you simply expose a prom endpoint, they’ll scrape it and you can use their grafana (or hook your own into their Prometheus). Nothing special vs vanilla prom/grafana, but seamless “no-ops” integration vs DIY.
Correct. It's common for companies to have their own custom systems or specific agents, then build a very custom and limited dashboard on top.
Fly.io went with "you know grafana and prometheus? yeah, we'll do just that". And I think that's perfect.
Re: Migrating from AWS to Fly.io
#68For 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.
Re: Migrating from AWS to Fly.io
#69Fly 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.
Re: Migrating from AWS to Fly.io
#70Fly 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.
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 across multiple database stacks.