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

181–189 of 189 posts

Re: Migrating from AWS to Fly.io

#181

Post by wink »

afandian wrote: post #180
wink wrote: post #157

I've been running a hobby project on their free tier for a while and it's mostly cool. Wrote up some stuff back then: https://f5n.org/blog/2022/trying-out-some-hosting-options/ but unfortunately none of my pain points/caveats seem to have been fixed * deploying (re)builds your container but doesn't even tag it locally, so if you just built one, it will build the exact same one again and on the other hand you are left…

I never got as far as running my Spring Boot application on fly.io. Killed after a few seconds. I’d love to know why. https://community.fly.io/t/java-app-is-killed-on-startup/837...

Mine's a Clojure app and I'm running it via `java -Xmx180m -Xms180m` and my fly.toml has a kill_timeout of 15 and in services.tcp_checks I now have interval 25000 and timeout 9000 - but as I wrote, it's a very basic app, anything JVM on 256MB has always (even years before fly.io) been hit or miss, sadly. Good luck!

Re: Migrating from AWS to Fly.io

#182

Post by afandian »

wink wrote: post #181
afandian wrote: post #180

Earlier quoted context omitted.

I never got as far as running my Spring Boot application on fly.io. Killed after a few seconds. I’d love to know why. https://community.fly.io/t/java-app-is-killed-on-startup/837...

Mine's a Clojure app and I'm running it via `java -Xmx180m -Xms180m` and my fly.toml has a kill_timeout of 15 and in services.tcp_checks I now have interval 25000 and timeout 9000 - but as I wrote, it's a very basic app, anything JVM on 256MB has always (even years before fly.io) been hit or miss, sadly. Good luck!

Thanks! I may give it another go.

Re: Migrating from AWS to Fly.io

#183

Post by krab »

atonse wrote: post #173
csunbird wrote: post #161

Earlier quoted context omitted.

The point the OP wanted to make was: Servers sitting less than 1km to each other tend to have lesser latency between them, compared to servers that could be anywhere on the public internet.

Ah because I am interpreting it more at the logical level and about them venturing out into unknown territories (the packets are traversing routers I do not control), rather than just latency. Since others have mentioned that latencies are very low if you locate in the same region. But if you have a zero-trust architecture and everything communicates over wireguard, then technically public or private won't matter rig…

With IPv6, you can have all public IPs (the same as early days of IPv4). However, if you have apps that are tightly coupled and often with strict latency requirements such as Web DB, then it's better to communicate only over private links. You can control latency and you have better reaction time when something breaks down. That is in addition to security concerns.

I remember a failure of one transatlantic line that was used for one direction of packets we were sending between EU and US. I spent a night on a phone trying to convince AWS and our other datacenter operator to work around the problem by changing their routing and to push the backbone operator to fix the problem - we didn't have any relationship with the backbone of course.

You don't want such disruption to happen in a core part of your app. These disruptions can also be intermittent and "random" and you have no way to fix.

Re: Migrating from AWS to Fly.io

#184

Post by vigneshravichan »

lawnchair wrote: post #125

Author here. Some folks wanted the details on pricing. Pre migration, the Terrateam AWS monthly bill was about $200/mo. With Fly.io, we're paying around $90/mo.

Can you elaborate on the problems you faced with stolon?

You mentioned there was a case where stolon didn’t failover. Have you created an issue on this for GitHub?

(Have been a user and contributor of stolon; hence curious to know)

Re: Migrating from AWS to Fly.io

#185

Post by ryanisnan »

mrkurt wrote: post #29
ryanisnan wrote: post #26

Earlier quoted context omitted.

This is cool, I'd love to know more about how you generally fix issues like these?

I usually just go complain to network folks and they figure it out. I'm good at complaining! Routing issues like this are typically the result of some weird network provider politics. The fix is typically ti change how we announce IPs to force a route to do something we want. It's a dark art.

Awesome, thanks for sharing. I am also good at complaining! We might make good friends.

Re: Migrating from AWS to Fly.io

#186

Post by TheHappyOddish »

biorach wrote: post #43
hamandcheese wrote: post #36

Earlier quoted context omitted.

Does scale to zero work with ordinary fly apps yet?

Probably. Depends. For a simple app should be straighforward. I set up a machine - a few weeks ago this involved a few direct api calls using curl - maybe `flyctl` can do it all now. Then I deployed on that machine a version of my app that gracefully shut down if no requests were received for 60s. Works great. Shuts down after a minute, boots back up in under a second when a request comes in. See the docs for details

I found the docs difficult and inconsistent when moving between flyctl and cURL when I tried playing with machines a few months ago.

I daresay they'll be wonderful once the team get the machine stuff working under flyctl fully.

Their generous free tier does make it easy to play and assess though.

Re: Migrating from AWS to Fly.io

#187

Post by sosodev »

tptacek wrote: post #74
sosodev wrote: post #56

Earlier quoted context omitted.

I really do appreciate it. Is there any way Fly could detect this? I know geo IP isn’t perfect but it seems like it could help you track this stuff by allowing you to compare edge location to the users location.

There probably is a good way to do this. Do you have thoughts on things we should do here? We have a code footprint in every region (and also in like 6 off-platform regions on other providers) for doing this kind of monitoring, and we're probably not putting it to the most effective use we can. Ideas would be most welcome.

This idea might be a bit too naive but it seems like it could help

1) Record the IP address and edge of connecting clients 2) Use an IP API to determine the rough location and ISP of clients based on their IP 3) Spatially query the edge closest to each client and graph/log serious mismatches (>x miles off) 4) Cast the spells required to route offending ISP better 5) See if the data improves :)

For example, the IAD edge would record that I connected from San Diego via Cox Communications. My closest edge geographically is LAX so that's ~2500 miles of excess travel!

Re: Migrating from AWS to Fly.io

#188

Post by danielvaughn »

atonse wrote: post #70
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.

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…

I’m planning on moving to fly.io, and I’m exploring cloud-based databases. Specifically Planetscale and CockroachDB.

Re: Migrating from AWS to Fly.io

#189

Post by samlambert »

danielvaughn wrote: post #188
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…

I’m planning on moving to fly.io, and I’m exploring cloud-based databases. Specifically Planetscale and CockroachDB.

https://fly.io/docs/app-guides/planetscale/
Post reply on HN