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

41–50 of 160 posts

Re: Migrating our backend from Vercel to Fly.io

#41

Post by bastawhiz »

rjh29 wrote: post #3

> Edge functions are cost-effective as you only pay for the actual CPU execution. > We have over 1000 monitors, and the monthly cost to run them would be $150. > While on fly we only have 6 servers with 2vcpu/512Mb It cost us $23.34 monthly ($3.89*6). So edge functions are in no way cost-effective right? People using lambda functions are getting ripped off, they could just buy a couple of VPS.

In what universe is the difference between $23/mo and some amount less than that incomparable? That's what? Two paid users worth of revenue? $23 per month is a rounding error. It's one T-shirt. It's the cost of a few minutes of your time. If you're running a business and you're worried about saving ones of dollars on hosting, you need to reconsider how you're spending your time and how your business makes money.

Re: Migrating our backend from Vercel to Fly.io

#42

Post by bastawhiz »

SOLAR_FIELDS wrote: post #31
maccard wrote: post #23

Earlier quoted context omitted.

> People using lambda functions are getting ripped off, they could just buy a couple of VPS. A non-zero amount of our CICD pipelines are "perform API call with secret pulled from SSM/Secrets Manager". They happen 1-2 times per day and take less than a 5 seconds to run on each invocation. We currently have a burstable EC2 instance running 24/7 to handle these which costs us ~$5/mo. My napkin math says that this would…

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 deleting the fifty lines of code that export your lambda handler. It couldn't be more simple.

Which is to say, you'll almost always have more trouble going from something else to Lambda and not the other way.

Re: Migrating our backend from Vercel to Fly.io

#43

Post by grrowl »

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?

Re: Migrating our backend from Vercel to Fly.io

#46

Post by mattnewton »

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…

Plenty of people end up building vercel-but-worse out of CI pipelines on aws or similar, doesn’t strike me as crazy to keep using it well past the prototype stage for projects that for its constraints.

Re: Migrating our backend from Vercel to Fly.io

#47

Post by [deleted] »

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…

[deleted]

Re: Migrating our backend from Vercel to Fly.io

#48

Post by shoo »

I love a good migration post-mortem, thank you to the author for publishing it! There's a bit of extra detail I'd be curious to know, as someone completely unfamiliar with both Vercel & Fly.io:

Re: "we required a lightweight server" as one of the drivers to migrate -- how did deploying to Vercel impede this? What specific business/operational issues was this causing?

Re: migration issue of large container image -- what business or operational issues did the large container image size cause? Why was it necessary to shrink the image size, when it could be previously ignored?

edit: it appears that fly.io previously had a 2GB container image size limit, relaxed on 2023/08/11 to "roughly 8GB" -- https://community.fly.io/t/docker-image-size-limit-raised-fr...

Re: Migrating our backend from Vercel to Fly.io

#49

Post by lmm »

xmonkee wrote: post #39
lmm wrote: post #10

Earlier quoted context omitted.

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…

> 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, guess what, you have to suddenly care about the options your provider is giving you, or go out and buy some stupid cron-as-service or ssh-as-service because you don't have any control over your infrastructure.

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?

Running your own unix system gives you a bunch of options that a higher-level abstraction doesn't, sure. But those options are rarely worth the cost, IME. (And like I said, if you're actually getting a unique value-add from running the whole server, then do it!)

> And now suddenly your infra is way more complicated than mine. I am still one that single dockerfile.

I guarante you that anything Docker-based is more complicated than what I'm doing. Docker is the worst kind of layer; it doesn't provide a consistent abstraction of its own, you still have to know all the ins and outs of how the unix system it's running on works, it just adds a whole bunch of extra concepts on top that you have to learn. And then sometimes breaks the usual rules of the platform it's running on as well! (e.g. silently bypassing your iptables rules).

> In fact I am wracking my brains right now to come up with anytime I had a problem because of having a server and coming up short.

- Your program runtime crashing because of mismatched system library ABIs

- A dependency you didn't expect is suddenly available because it got installed by the base system

- /var filling up because of out of control logs or the like

- Any other disk filling up for whatever reason

- Log collectors going AWOL

- Directory traversal order differing because two servers are using different filesystems

- Upgrade changed the network management commands and now all your traffic is being blocked

- Buggy RAID controllers

- Thermal throttling kicking in when it shouldn't because of a broken temperature sensor

- Power outages

All this stuff still needs to be fixed, but it's great to have it be someone else's problem and get on with your program.

Re: Migrating our backend from Vercel to Fly.io

#50

Post by shrubble »

NicoJuicy wrote: post #8
rjh29 wrote: post #3

> Edge functions are cost-effective as you only pay for the actual CPU execution. > We have over 1000 monitors, and the monthly cost to run them would be $150. > While on fly we only have 6 servers with 2vcpu/512Mb It cost us $23.34 monthly ($3.89*6). So edge functions are in no way cost-effective right? People using lambda functions are getting ripped off, they could just buy a couple of VPS.

Edge functions are cost effective, the problem is that they are comparing from Vercel. Vercel is basically a dev friendly wrapper for tier 1 services: https://news.ycombinator.com/item?id=35774730 Eg. Vercel is 25x more expensive than eg. Cloudflare Workers. Raw guess would be that their 150$ bill would have become 6$. https://news.ycombinator.com/item?id=37891412 Eg. Image resizing > Vercel : 5$ / 1000 requests > Cl…

According to this page at Cloudflare, their pricing is 50 cents per 1000, is that correct? Or is it a different product... https://blog.cloudflare.com/merging-images-and-image-resizin...
Post reply on HN