[presentation]

I choose to host on Vercel because I can spin up a production-ready, globally distributed web app in about 5 minutes with marginal, predictable costs without hiring a single other person, procuring any hardware nor learning anything beyond what’s necessary for coding my application. Pair it with analogous services like Upstash and Fly.io for persistence, and you can achieve incredible scale with minimal operational burden. Obviously this depends on your workload - for mine I can imagine this would cover the majority of use cases for the lifetime of my company. And there are many companies like mine.

[CodesInChaos]

At a glance, Vercel's pricing looks unbelievably expensive. $550/TB traffic, and $60k/yr for a 128MB function running at 100% utilization. What's the point of scalability, if you can't afford it to scale above the size of a small vserver? I'd have nightmares about a small DDoS attack costing me millions running on infrastructure like that.

What does it offer compared to other serverless offerings (aws lambda, google cloud run) to justify this cost?

[sofixa]

I think you're misunderstanding Vercel.

You host static, or slightly dynamic (calling APIs from the front-end) websites. Serverless functions are a bonus to use occasionally. If you're using a serverless function at 100%, you're doing something terribly wrong.

As for DDoSes, such providers are genuinely okay with waiving bills from serious mistakes or DDoSes (besides also having anti-DDoS services for "free" and transparently, so must DDoSes won't even show up on your bill).

[presentation]

Exactly, you’re incentivized to make your website as static as possible, and I attach standard http cache headers to most of the server rendered stuff so that their responses get cached in Vercel’s CDN, and once again not invoked super often.

[CodesInChaos]

1. But you still pay $550/TB for traffic, right? That's 5-10x the cost of AWS, which is already very expensive.

2. What advantages does Vercel offer?

[presentation]

1. My workload is an early stage enterprise SaaS where traffic is not the limiting factor for our growth. If you’re planning to push a lot of bandwidth you probably want to use something else.

2. Like I said, it’s that I don’t have to spend even a minute thinking about how I’m going to deploy my app. It just listens on our git repo and runs the NPM standard build and start commands to run the app, so I don’t need to do any vendor specific configuration. We use NextJS as our web framework, so we just write pure web frontend/backend code and automatically everything’s hooked up so that it’s served with serverless infra (so I don’t have to care about scaling or machine resources ever), with a global CDN that caches the API responses we return by just attaching a Cache-Control header, which is very transparent. On top of that Vercel instruments deploys for all of our git branches so that I can see what my teammates do directly in their PRs, once again with no configuration. And if the pricing becomes an issue, all our code is just following web standards and next to no vendor-specific code exists in the app, so I can move off it any time, but really I don’t see that happening even if our SaaS 100x’d in size (which is the aim).

I really have trouble seeing how we can do less work on nor get less locked into a specific infra this way. I’m sure for resource intensive workloads it’s not ideal, but for ours, optimizing for resource efficiency by running our own stack of servers is a case of YAGNI; the simplicity of the DX is totally in our team’s favor.

Not really sure why this argument wouldn’t make sense by now, Heroku has always been expensive and yet it always has been popular since it’s so much simpler than dealing with the choice paralysis and complexity of either using the full AWS system and of running your own servers.