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…
Migrating from AWS to Fly.io
151–160 of 189 posts
Re: Migrating from AWS to Fly.io
#152Earlier quoted context omitted.
You can get 4 virtual ARM CPU + 24GB RAM + 200GB hard disk for $0/month at Oracle cloud. Nothing can beat that.
Any caveats? This sounds really great.
Re: Migrating from AWS to Fly.io
#153Earlier quoted context omitted.
You can get 4 virtual ARM CPU + 24GB RAM + 200GB hard disk for $0/month at Oracle cloud. Nothing can beat that.
Any caveats? This sounds really great.
Oh and FreeBSD runs on it (i think it's under partner-images)
Re: Migrating from AWS to Fly.io
#154Earlier quoted context omitted.
You can get 4 virtual ARM CPU + 24GB RAM + 200GB hard disk for $0/month at Oracle cloud. Nothing can beat that.
Any caveats? This sounds really great.
I also really like the dashboard much better than AWS or GCP.
Re: Migrating from AWS to Fly.io
#155Earlier quoted context omitted.
You can get 4 virtual ARM CPU + 24GB RAM + 200GB hard disk for $0/month at Oracle cloud. Nothing can beat that.
Any caveats? This sounds really great.
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.
Re: Migrating from AWS to Fly.io
#156Re: Migrating from AWS to Fly.io
#157Wrote 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 guessing which hash is the container that the tool just built.
* if you start with your own Dockerfile the mandatory options in fly.toml are not described overly well, so a bit of fiddling
* recently I redeployed and without any real change (just a new code build) it wouldn't deploy, I had to remove some of the settings in fly.toml that I had guessed at to make it work in the summer to make it work now - no changelog anywhere
* if your app is coming close to some assumed limit on the services.concurrency (which is not documented well), again you need to guess and redeploy until it works
Maybe I've run into an edge case with a JVM app where 256MB of RAM is tight, but my problem is more that all the feedback I get from the tooling is a little meh and doesn't make me confident to ever try production workloads here. Not complaining about the free service though and the dashboard/metrics stuff seems nice.Re: Migrating from AWS to Fly.io
#158Earlier quoted context omitted.
Any caveats? This sounds really great.
No. There is even a lot more included: https://www.oracle.com/cloud/free/#always-free . 90% of the internet can run on the free tier. I also really like the dashboard much better than AWS or GCP.
Only, of course, it really, really can't, and their current offer is very much contingent on that not happening.
Re: Migrating from AWS to Fly.io
#159Earlier 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.
> 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?