Live data from Hacker News

Migrating our backend from Vercel to Fly.io

openstatus.dev

141–150 of 160 posts

Re: Migrating our backend from Vercel to Fly.io

#141
post #93

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…

Some people avoid large providers, since large providers have approximately no incentive whatsoever to keep you, specifically , as a customer. I.e. large providers will happily raise their prices, alter the deal, throw you under the bus, disable your account, delete all you data and then refuse to talk to you. They can do this because, when they look at the big picture, you don’t matter to them. And since doing this…

Right. Plus, large providers usually don't offer support for small-sized instances/containers/whatever, so even if you optimized your deployment to use less resources, you need to buy a bigger thing.

But to the main point: using an extra layer which is on the top of said large provider, like here Vercel over AWS, is not a solution, as this middle man also can be marginalized by the big bully at some moment.

This is why I prefer small providers, like Vultr. (Not affiliated with them in any way; just a happy customer).

Re: Migrating our backend from Vercel to Fly.io

#142
post #66

Earlier quoted context omitted.

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…

> That’s for an app which sends a ping to a URL every x minutes… My bigger question is: How the fuck do these companies keep getting created? There's gotta be more uptime-monitor SaaS companies than todo MVC demos in existence.

Because these people are bad businessmen. There is not a single reason yet another uptime monitoring business needs to exist. They have no chance at succeeding the likes of Datadog, New Relic.

Conclusion: promising builders being bad at startups

Re: Migrating our backend from Vercel to Fly.io

#143

Earlier quoted context omitted.

> That’s for an app which sends a ping to a URL every x minutes… My bigger question is: How the fuck do these companies keep getting created? There's gotta be more uptime-monitor SaaS companies than todo MVC demos in existence.

It’s easy to get the free users, where of just a smaller % need to upgrade to keep you afloat. Then there’s the possibility to upsell other related services like analytics or logs. Betterstack did this very well.

> a smaller % need to upgrade to keep you afloat

Until yet another free competitor comes along. Then you're out of business

Re: Migrating our backend from Vercel to Fly.io

#144

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…

Founder of OpenStatus here: We can't use Cloudflare because there's no way to execute in a specific region, if you know how to do it let me know

That was an interesting rabbit hole, thanks :p

Found this to be the best resource:

https://community.cloudflare.com/t/how-to-force-region-in-cl...

Guess it's a bit more work than originally expected.

An alternative would be to use proxy ip's to hint regions, which would resolve to other locations. And then parse the Colo from the request.

Re: Migrating our backend from Vercel to Fly.io

#145

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…

I really want to love Fly (for some reason? Maybe I've succumbed to the darling effect? Idk, their tech is cool in any case)

But yeah, failing deployments and the weirdness around persistent storage (if my VM starts up on another physical host my data just no longer exists) I can't use them. I'd be doing the same amount of systems work as I would anywhere bespoke, with less ability to fix any issues that come up

This is fine for the app part, 12 factor and all that, but I don't want a database relying on it.

Really hope they fix these two issues somehow, I've had to learn kubernetes instead lmao (I was going to get round to it anyway in all fairness)

Re: Migrating our backend from Vercel to Fly.io

#146
post #111

I joined a project that was fully deployed on Vercel. We routinely ran into issues with limitations, outages and sharp edges. Our junior devs had also taken advantage of Vercel specific features (I remember a Vercel specific request object in the code specifically). Given all the problems and the vendor lock in from tight coupling I advise everyone I discuss Vercel with to avoid them like the plague.

Can you elaborate more on this? Or point me to a discussion? My org is planning to move to Vercel it'd be nice to know its pitfalls

Re: Migrating our backend from Vercel to Fly.io

#147
post #99
post #59

Earlier quoted context omitted.

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.

Lots of us (well, me at least) use fly because it's a bundled set of aws best practices that I could configure in aws if I wanted to, but I'd waste another week of my life. alb + various vpcs + autoscaling group + fargate + ecs + their super shitty vpn service to vpn to a console + rds + elasticache or... just type "fly deploy" and go from zero to live in 20 minutes. That said, fly's deploys are flaky. I hope they ge…

The first part is good to hear. And the last part is the only reason I have not consistently used them. As an aside, I have started to use chatgpt heavily for aws questions and walkthroughs. Have been using ECS heavily and this has been super helpful for me to get through what I consider the hardbits, non-obvious permissions and configurations that aws that does tell you about but is buried in the documentation for a json like configuration object.

Re: Migrating our backend from Vercel to Fly.io

#148
post #62
post #59

Earlier quoted context omitted.

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.

Definitely. I guess where my ignorance comes in, from an engineering perspective is the way fly.io thinks about edge databases more difficult to architect than a more traditional route creating a subdomain for a region and just replicating your entire infrastructure in a new region?

I guess you can setup the same kind of structure inside of fly.io but I remember some of their writeups have been talking about deployment and pushing the DB to the edge and then having eventual consistency across?

I think that is my hangup on use cases.

Re: Migrating our backend from Vercel to Fly.io

#149

Earlier quoted context omitted.

That's what you get for working in a famous company that took over an open source software. If the destruction of React by Vercel paid your bills and you feel disrespected by my total despise for this get rich fast schema (a la crypto rugpulls), that's a problem for you to solve, not me. Edit: but in reality I'm happy and thankful to Vercel for imploding React, it helped me to finally check that there are so many bet…

I started using Next.js in 2017. It made React a real production framework. Prior to Next.js, React was hard to setup and maintain and hard to make it go fast (on first load). Next.js solved the worst React problems. I don't think it ruined React at all. I think it helped React gain in popularity - which you might interpret as "destruction".

> Prior to Next.js, React was hard to setup and maintain

No, it wasn't. Now it is an engineering process.

> I started using Next.js in 2017. It made React a real production framework

In 2017 I had React projects in production for years.

> React was hard to setup and maintain and hard to make it go fast (on first load)

And it only got worse and the overengineering to make it looks fast in the first load is not worth it as modern JS frameworks are faster than React out-of-the-box.

> I don't think it ruined React at all. I think it helped React gain in popularity

That's not what stackoverflow's Insights says[0]. Looks like a free fall for me.

0. https://insights.stackoverflow.com/trends?tags=reactjs

Re: Migrating our backend from Vercel to Fly.io

#150
post #112

Earlier quoted context omitted.

Its not about vercel or fly.io. Its about openstatus dev Their migration timeline from their blog: 1. August 2, 48 hours after public launch 400+ users 2. August 20, migrate from planetscale to turso (sqlite) 3. Oct 29, migrate from vercel to fly.io, migrate from nextjs to hono, also mentioned change to bunjs. This is seems like they tend to (sorry I'm judging here): 1. move fast break things or 2. don't have a plan…

We are trying, breaking and learning. And you were right we did not have plan before launch, we wanted to build something that bring us excitement. and we are planing more about the future, since the project took off FYI we still both have full time job

Sorry for the harsh words.

Obviously I can't speak about excitement but if you're worried about cost, you might want to research aws grant or things like that.

In 2019 my company invest in a startup, while doing IT due diligence I found out they get $100K AWS grant to be used for 2 years. Fyi this company business is writing articles about baby and almost no revenue at that time.

Post reply on HN