Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Migrating our backend from Vercel to Fly.io

openstatus.dev

Post reply on HN
Print view View original

61–70 of 160 posts

Re: Migrating our backend from Vercel to Fly.io

#61

Post by oefrha »

Lucasoato wrote: post #13

I really don’t understand how people can trust platforms like Vercel, Fly.io over robust could providers like Cloudflare, AWS or Azure. I mean, Vercel has its usefulness, it’s so well integrated with the NextJS stack, it totally makes sense for small amateurish projects since it saves you time and money… but once you want to push to production, have real customers and satisfy them reliably, these platforms can’t comp…

This is what happens when you do HN-frontpage-driven development. I mean, they use Bun (which I’m sure will be great in a couple years’ time) and quickly ran into an fd leak in it. Does that sound like a production grade runtime?

However, I suppose it’s good for content marketing. You’re not going to make front page by choosing boring old technology (unless you’re migrating back to boring old technology after failed HN-frontpage-driven development).

Re: Migrating our backend from Vercel to Fly.io

#62

Post by simonw »

infecto wrote: post #59
Lucasoato wrote: post #13

I really don’t understand how people can trust platforms like Vercel, Fly.io over robust could providers like Cloudflare, AWS or Azure. I mean, Vercel has its usefulness, it’s so well integrated with the NextJS stack, it totally makes sense for small amateurish projects since it saves you time and money… but once you want to push to production, have real customers and satisfy them reliably, these platforms can’t comp…

Whats the use case for edge computing like Fly.io. I have yet to figure it out the use case where a edge provider is necessary. That is, having a database on the edge.

Having customers in places around the world. If you site is hosted in North Virginia, and you have customers in Australia, they are going to really suffer from the speed of light.

Re: Migrating our backend from Vercel to Fly.io

#63

Post by hntorpldisb »

lmm wrote: post #49
xmonkee wrote: post #39

Earlier quoted context omitted.

> I want to write some code and have it run and I don't want or need to care about the details of how that happens as long as it works reliably I'm sorry, this is an incredibly stupid take. You always "need" to care about the abstraction that your infrastructure is providing to you. Vercel also provides a abstraction in terms of serverless functions. >I want to write some code and have it run and I don't want or need…

> You always "need" to care about the abstraction that your infrastructure is providing to you. Sure. But as long as it implements something reasonable, you don't care about the details of how. "Runs version x of this programming language" is generally an easier abstraction to run business functionality on than "it's an x86-compatible computer". > Now add background tasks or streaming responses or a cron job. Oh, gue…

> Cron is a terrible model for actually solving business problems with. Do you know what happens when a cron job fails to run/errors out?

Do lambdas not fail to run / error out? I’m not following.

Re: Migrating our backend from Vercel to Fly.io

#64

Post by yowlingcat »

pech0rin wrote: post #20

I find it interesting that people seem to be trading short term gains with long term reliability and maintenance costs. This glut of 0-friction deploy services lull people into a nice false sense of security. But in actuality you are wasting hours, days, weeks of time when they become unreliable, support is unresponsive, or something unexpected pops up. There is a huge advantage (outside of amateur, low importance pr…

> I find it interesting that people seem to be trading short term gains with long term reliability and maintenance costs. This glut of 0-friction deploy services lull people into a nice false sense of security.

I find it interesting as well. I agree that it's a false sense of security, and there is no real long-term gain from avoiding the one time paydown of deploying to a big 3 cloud services provider. Still, I think the impulse reflects something a very real pain, and something I find my team continuing to face as we try to manage a the operationally minimalistic stack we can get away with on AWS -- poor DX.

It does still boggle my mind that AWS still doesn't have a Heroku-esque happy path DX that lets you get started easily and then add in complexity on an as needed basis rather than forcing it to get the most basic thing running. It seems like every minor customization requires in AWS parlance spinning up a Lambda to do something that should be a first class feature in the platform by default. Will I migrate off the platform? No. Would I use a simpler, opinionated interface that let me focus on my application and not arcanae, if AWS made it avaiable? Absolutely.

Re: Migrating our backend from Vercel to Fly.io

#65

Post by arcanemachiner »

reducesuffering wrote: post #53
junon wrote: post #30

Earlier quoted context omitted.

I worked at ZEIT (before it became Vercel) and if they've retained even a 10th of their engineering culture then they're solid, if not a bit "niche" in what and who they target. Anecdotal, sure, but it'd be hard to quantify it.

It’s funny how frontend has a stigma of less serious engineering when the caliber of programming being done at Vercel is far beyond the level of inadequacy I’ve seen being in big tech FAANG eng departments.

I think this comment is intended as a compliment to Vercel, but it's hard to tell from the wording.

Re: Migrating our backend from Vercel to Fly.io

#66

Post by ushakov »

oefrha wrote: post #61
Lucasoato wrote: post #13

I really don’t understand how people can trust platforms like Vercel, Fly.io over robust could providers like Cloudflare, AWS or Azure. I mean, Vercel has its usefulness, it’s so well integrated with the NextJS stack, it totally makes sense for small amateurish projects since it saves you time and money… but once you want to push to production, have real customers and satisfy them reliably, these platforms can’t comp…

This is what happens when you do HN-frontpage-driven development. I mean, they use Bun (which I’m sure will be great in a couple years’ time) and quickly ran into an fd leak in it. Does that sound like a production grade runtime? However, I suppose it’s good for content marketing. You’re not going to make front page by choosing boring old technology (unless you’re migrating back to boring old technology after failed…

Their stack speaks for itself:

Next.js, TailwindCSS, shadcn/ui, tinybird, turso, drizzle, clerk, Resend

That’s for an app which sends a ping to a URL every x minutes…

Re: Migrating our backend from Vercel to Fly.io

#67

Post by maxbond »

bastawhiz wrote: post #42
SOLAR_FIELDS wrote: post #31

Earlier quoted context omitted.

Also, if you implement it as lambdas, your solution is now less portable. Your EC2 instance can probably be ported to something else easier than some lambda solution.

This is objectively false. In fact, it's the opposite of true. Lambda forces you to have a single entry point to your code that passes the details of a request to your application in a structured way. Wrap that in the http server of your choice in about fifty lines of code and you're done. Or, you use something like Express inside Lambda with Serverless and adapting it to a long running server is literally just delet…

> This is objectively false. In fact, it's the opposite of true.

I apologize for the tangent but in your mind, is false sometimes but not always the opposite of true? Or is this just emphasis? (Genuinely asking, not being snarky.)

ETA: Thanks for clarifying.

Re: Migrating our backend from Vercel to Fly.io

#68

Post by urschrei »

robertlagrant wrote: post #38

Why is Fly apparently so unstable? I like many love the idea, but get a little scared by the many many anecdotes of issues. What are they doing that makes it unstable? Lots of new locations spinning up that shake bugs loose? Cost-reducing refactorings that reduce stability?

(Fly customer for the past 12 months: small web app (three machines across two regions plus replicated Postgres across two regions, on a paid plan)). Fly has been extremely stable for us, with the sole exception of deploys: once a month or so, deploys from CI start failing for a couple of hours. That doesn’t result in any downtime (I have never experienced any downtime due to a failing machine on Fly), just that new code doesn’t end up on prod until it’s fixed. If it’s urgent I email support (highly competent), or wait it out.

I would describe myself as “extremely happy with the service, yet also annoyed by this aspect”. Fly allows me to manage my resources in a way that isn’t really possible elsewhere (from standard Python web apps in multi-hundred-mb containers to specialised Rust apps in < 10mb containers), and in a way that is (now) extremely simple to reason about, and the support has been excellent when I’ve needed it (they were very patient and understanding when I screwed up a region move and managed to somehow break my db leader beyond repair), but I’d like them to address this, because it’s a widespread issue. Given the evolution of their architecture, I suspect they will. But I’d also like them to talk about it more.

Re: Migrating our backend from Vercel to Fly.io

#69

Post by junon »

NicoJuicy wrote: post #33
junon wrote: post #28

Earlier quoted context omitted.

Workers are also free for the first 100k every month I believe.

10 million included per month. On the free plan, it's 100 k. per day included - https://blog.cloudflare.com/workers-pricing-scale-to-zero/

Oh, even better. Thanks :)

Re: Migrating our backend from Vercel to Fly.io

#70

Post by elxx »

robertlagrant wrote: post #38

Why is Fly apparently so unstable? I like many love the idea, but get a little scared by the many many anecdotes of issues. What are they doing that makes it unstable? Lots of new locations spinning up that shake bugs loose? Cost-reducing refactorings that reduce stability?

(Background: I'm currently using Fly for some hobby apps. I like it.)

It is still wildly unstable right now because they're basically still building the platform and figuring out how to run a business. Earlier this year there was a migration to their "Apps V2" platform [0] which was supposed to be simple but it was extremely poorly communicated which led to a lot of users hitting issues along the way and being forced to make forum posts to try and desperately figure out how to keep their production apps up. None of the migrations worked for me either, I didn't complain as a freeloader - but seeing the support requests from paying customers painted a really bad picture.

[0] https://community.fly.io/t/get-in-losers-were-getting-off-no...

Post reply on HN