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

51–60 of 160 posts

Re: Migrating our backend from Vercel to Fly.io

#51

Post by NicoJuicy »

grrowl wrote: post #43
NicoJuicy wrote: post #11

TLDR: They could have done it cheaper, quicker and without adding DevOps to their workload with just migrating to Cloudflare. - Vercel: 150$/m. - Fly: 23$/m ( + managing servers and devops) - Cloudflare: 11 $/m. --- (original comment) They could have gone from Vercel to Cloudflare to reduce their costs. But that would have been almost no work to create a blog post about :p https://developers.cloudflare.com/pages/fram…

Can you deploy 700MB Dockerfiles to Cloudflare, as they mention as a minimum requirement in the article?

Why would they need that on Cloudflare?

Since they didn't had to change much of their original functions to docker, if they would have switched to Cloudflare from Vercel directly.

That would have been a lot quicker for them to do...

Alternatively, Cloudflare supports hono which they moved too.

https://developers.cloudflare.com/pages/framework-guides/dep...

Re: Migrating our backend from Vercel to Fly.io

#52

Post by maxbond »

lmm wrote: post #10
xmonkee wrote: post #6

Every day I need to add a new feature to my app, I am grateful I picked fly (serverful) rather than Vercel. The fact that as far as I'm concerned, it's just a computer, is incredibly useful. We've added long-running tasks, background jobs, scheduled tasks, side-car processes, custom-code execution, etc etc. Then, the fact that I can run something like Redis or Metabase within the same VPN with just a dockerfile is in…

It's not "just" a computer, a computer is a whole bunch of complicated stuff that I don't want to have to care about. 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. Being able to ssh into your server is giving you more tools to fix problems, sure, but mostly problems that you created for yourself by having a server in the…

Here's a thought experiment people may or may not find helpful. If you're writing say a Flask app, what Flask is doing for you is routing a request to a function. That's where the core kernel of value is; the rest of what's going on is overhead you pay to wire your function up to what it needs, like a database connection pool and such.

So if you were AWS and you saw everyone running an instance of Flask, you might think to yourself, I could run one really big instance of Flask that everyone could share, and the economies of scale would mean I could charge a cheaper price.

And you as the software developer might think, well, I get paid to execute these functions, not to run Flask, so I might as well rent a spot in the big Flask. Then I won't have to spend time updating and maintaining the framework, I can focus on writing my functions.

This may or may not work out for a specific use case, eg maybe that database connection pooler that we threw out was load bearing and moving to serverless overwhelms our database or causes us to spin up more database servers and costs more money. YMMV.

Re: Migrating our backend from Vercel to Fly.io

#53

Post by reducesuffering »

junon wrote: post #30
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…

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.

Re: Migrating our backend from Vercel to Fly.io

#54

Post by factormeta »

rozenmd wrote: post #37

My uptime monitoring business made a similar migration (AWS Lambda to fly.io), and I ended up rolling it back a few months later. I wrote more about the move to fly.io here: https://onlineornot.com/on-moving-million-uptime-checks-onto... and (part of) the move back to AWS here: https://onlineornot.com/scaling-aws-lambda-postgres-to-thous... Edit: forgot that second link doesn't actually explain that I moved off fly.i…

[flagged]

Re: Migrating our backend from Vercel to Fly.io

#56

Post by Swizec »

dboreham wrote: post #40
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…

> I really don’t understand how people can trust platforms like Vercel It's not an apples to apples choice. The people who use Vercel don't know anything about how to deploy on AWS. That's the whole point of Vercel. Whether or not they can be trusted is really orthogonal to the reason they were selected as a provider. But that said, they're just a layer over AWS so why should they be significantly less trustworthy? I…

> The people who use Vercel don't know anything about how to deploy on AWS

Ehhhh. I’ve been deploying to AWS professionally for years and I’d choose Vercel for a personal project any day of the week.

Life’s too short to play devops/sysadmin/sre without someone paying you the big bucks.

Re: Migrating our backend from Vercel to Fly.io

#58

Post by drwl »

schneems wrote: post #55

I’m curious if you looked at Heroku (I work there). You mention functions (which we don’t support), also servers (which we definitely support). I’m curious if that’s it or there was more to the decision.

I’m a bit out of the loop but I thought heroku died or is languishing under Salesforce. That’s my current perception of everything and no longer see it recommended in HN threads. Hopefully this does not come off as an attack (it’s not).

Re: Migrating our backend from Vercel to Fly.io

#59

Post by infecto »

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.

Re: Migrating our backend from Vercel to Fly.io

#60

Post by maxbond »

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.

You could have your realtime competitive FPS game like Call of Duty host the data and compute necessary to run a match as close to the median location of all the players involved as possible to reduce latency. You could make the same case for something like Zoom or a collaborative editing tool.
Post reply on HN