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

31–40 of 160 posts

Re: Migrating our backend from Vercel to Fly.io

#31

Post by SOLAR_FIELDS »

maccard wrote: post #23
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.

> 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.

Re: Migrating our backend from Vercel to Fly.io

#32

Post by NicoJuicy »

danpalmer wrote: post #26
NicoJuicy wrote: post #8

Earlier quoted context omitted.

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…

$5 / 1k requests... wow. That's like, entirely unworkable for almost all use-cases surely? Even coming from a backend-heavy world where one request does a lot of work, that's got to be an order of magnitude off the mark at least. If you go for a frontend-heavy setup where there are more smaller requests (in my experience, common, when using things like Lambda), this could be another order of magnitude off again!

Sorry about that. The pricing was about Image Resizing requests ( updated my comment).

On http requests itselve.

Vercel is 2 $ per million requests. Cloudflare is 0,15$ per million requests.

So Cloudflare in this case is > 13 x cheaper.

Re: Migrating our backend from Vercel to Fly.io

#33

Post by NicoJuicy »

junon wrote: post #28
NicoJuicy wrote: post #8

Earlier quoted context omitted.

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…

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/

Re: Migrating our backend from Vercel to Fly.io

#34

Post by solarkraft »

danpalmer wrote: post #24
steve_adams_86 wrote: post #7

Unreliable deployments are my experience as well. I also encountered unexpected and unannounced downtimes surprisingly often. I was excited about fly, but ended up sticking with digitalocean. I have only had one issue with deployment reliability there (when they changed their build tooling for Python applications on the apps platform), but they responded quickly with a fix and shortly after announced the change and p…

At my last place we ran into a number of issues with using DO in production. It was fine for dev machines, testing, etc, but we had production downtime due to DO's networking setup, and support were unable to understand the problem, let alone fix it. Quick summary: we backed up our other prod hosting to DO over SSH. One day our backups went offline, DO claimed this was because of a DDoS attack, but our backups were w…

That level of uselessness is impressive. They must've trained on Microsoft's forum.

Re: Migrating our backend from Vercel to Fly.io

#36

Post by [deleted] »

leerob wrote: post #14
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…

Edit: Nevermind, wrong thread. Vercel does honor DCMA, of course, though.

[deleted]

Re: Migrating our backend from Vercel to Fly.io

#37

Post by rozenmd »

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.io, will write a follow-up.

Re: Migrating our backend from Vercel to Fly.io

#38

Post by robertlagrant »

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?

Re: Migrating our backend from Vercel to Fly.io

#39

Post by xmonkee »

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…

> 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 to care about the details of how that happens as long as it works reliably.

Yeah, same. As long as it works, I have no problem. 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. And now suddenly your infra is way more complicated than mine. I am still one that single dockerfile.

>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 first place.

How is running a clean-up script anything to do with having a server? That is the most common use-case for ssh-ing into your server. 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. Fly.io (or AWS, or GCP) has problems, for sure, but none of them are because I am running a server.

Re: Migrating our backend from Vercel to Fly.io

#40

Post by dboreham »

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 haven't used Vercel in production, but I have used a similar "layer over AWS" service (Aptible). The problem where wasn't to do with QoS or support, but rather that the narrowing of the functionality of the "interface" (which is pretty much the point) ends up causing frustration when you want to integrate with other stuff you're doing in AWS.

Post reply on HN