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

171–180 of 189 posts

Re: Migrating from AWS to Fly.io

#171

Post by benbjohnson »

H12 wrote: post #164

With all the talk of PostgreSQL, I'm curious if anyone has tried the offerings Fly.io has been pushing with SQLite (Litestream & LiteFS) in any serious capacity, and can comment on the experience. Wondering whether they would be a viable alternative to Postgres in the typical "Database + Docker Container" architecture.

Litestream & LiteFS author here. Tailscale has been using Litestream in production for a while and blogged about it in April 2022[1]. I've had a number of folks contact me out-of-band and tell me they're using in production at a surprising scale.

As for LiteFS, it's still early beta stage so I don't know of many people using it in a production capacity. I would expect it to be another six months or year before confidence builds enough to see more regular usage.

[1]: https://tailscale.com/blog/database-for-2022/

Re: Migrating from AWS to Fly.io

#172

Post by belmont_sup »

nikita wrote: post #116
belmont_sup wrote: post #113

Earlier quoted context omitted.

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

Fantastic, nikita! Hope all goes well.

Re: Migrating from AWS to Fly.io

#173

Post by atonse »

csunbird wrote: post #161
arianvanp wrote: post #147

Earlier quoted context omitted.

what makes a network private?

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 right?

Not saying public/private IPs don't matter – since almost all the servers would still only have private IPs.

In a sense this is more like VPC peering.

Re: Migrating from AWS to Fly.io

#174

Post by atonse »

mrkurt wrote: post #102
dehrmann wrote: post #101

Earlier quoted context omitted.

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

Are you guys looking at a partner program where a lot of the managed postgres companies could also provide managed postgres but on top of your infra? (like they do with GCP/AWS/etc)

Re: Migrating from AWS to Fly.io

#175

Post by speedgoose »

mi_lk wrote: post #160
speedgoose wrote: post #155

Earlier quoted context omitted.

Oracle. There is a reason why they need to have this offer to attract a few flies. Personally I would stay as far away as I can from Oracle's products.

say more for us uninitiated?

There are several reasons why Oracle has a poor reputation and should be avoided in business:

High licensing fees: Oracle is known for its high licensing fees, which can be very expensive for businesses. This can lead to a financial burden on companies, especially smaller businesses.

Poor customer support: Oracle has a reputation for poor customer support, with many users complaining about long wait times, unhelpful responses, and a lack of follow-through.

Complex software: Oracle's software can be difficult to use and understand, which can lead to delays and frustration for businesses.

Compatibility issues: Oracle's software is not always compatible with other systems and can cause problems with integration.

Poor security: Oracle has had a number of security breaches in the past, which can lead to concerns about data privacy and security.

Overall, Oracle's high costs, poor customer support, complex software, compatibility issues, and security concerns make it a risky choice for businesses.

Moreover, Oracle has a history of suing companies that it believes are using its software without proper licensing or permission. This includes sending out lawyer letters to companies that it believes are infringing on its intellectual property rights. Oracle has been criticized for its aggressive tactics, which some believe are designed to intimidate and bully companies into compliance.

I wrote this answer with the help of ChatGPT. I think the AI did learn Oracle’s bad side pretty well.

I will just add a link to an archive of the famous blog post that was thankfully deleted but that show that the reputation is not completely inaccurate: https://web.archive.org/web/20150811052336/https://blogs.ora...

Re: Migrating from AWS to Fly.io

#176

Post by ec109685 »

garganzol wrote: post #162
ec109685 wrote: post #136

Earlier quoted context omitted.

This is an advantage of the big public clouds. Any SaaS you could want is deployed into the same region as your application, so it's essentially co-located and on the same playing field as one of the native public cloud services. With Fly.io (at least today), this isn't as straightforward given your favorite database is likely not deployed there.

Even at the minimal scale, one is going to have quite a few app instances all over the world sooner or later. In such setting, a notion of regional proximity of any kind quickly becomes irrelevant. Higher database round-trip times are fixed by using database stored procedures instead of making multitudes of tiny compound SQL queries.

Not everything can be represented by a single database query. Often there is mixing involved using multiple sources, which break down the one query for all results pattern, and thus encourage co-locating the database near the tier making the db requests.

Re: Migrating from AWS to Fly.io

#177

Post by sieabahlpark »

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…

[dead]

Re: Migrating from AWS to Fly.io

#178

Post by mike_d »

tshaddox wrote: post #40
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." In the same way that a RDBMS is ultimately a solution for people who look in the mirror and confidently say “you don’t know how to directly write to disc while guaranteeing the validity of relational data in spite of concurrent writes, power failures, etc.”

Absolutely spot on comparison. For some people, RDS is the corner stone of their business. For others even a failed database can be rebuilt from logs within hours and it isn't business impacting.

Use the tools that make sense, but don't be afraid to pick the right tool.

Re: Migrating from AWS to Fly.io

#179

Post by paddim8 »

arcanemachiner wrote: post #140
dist1ll wrote: post #134

Earlier quoted context omitted.

You can get 1vCPU + 2GB RAM for 3.92 Euro/month at Hetzner. Those prices are hard to beat.

Yeah but the latency on a shared vCPU has been very noticeable in my experience. For anything serious you would want to run a dedicated vCPU which is several times more expensive (though still quite affordable)

Netcup has cheap plans with that. 10€/month

Re: Migrating from AWS to Fly.io

#180

Post by afandian »

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...
Post reply on HN