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.
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?
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).
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.
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.
Rent colo space, rent transit, rent equipment (which you should absolutely do below gigantic footprint). Boom - your physical dc is now an opex. Still cheaper than public cloud by an order of magnitude on certain workloads (egress heavy, gpus, etc)
OPEX in the US is tax deductible for the current financial year; a lot easier to calculate and maintain. It’s basically the cost to run the company, taking away from revenue.
CAPEX items are amortized over multiple fiscal cycles; it’ll count and can helps raise the value(valuation) of your company, but tricker to calculate.
So depending what financial number goals your company has, the accounting of items can go one way or the other.
If your dev work brought permanent value to the company, then it can be capex. If you were a contractor instead, it could be either cap or opex. AWS services are basically rented and not permanent value to the company, ie, if you sold everything the company owned for cash, you couldn’t sell the AWS part, just the terraform scripts.
For business perspective, it's large irreversible upfront investment on capex vs ongoing opex. Sizing and building a data center is risky, execs not wanting to attach their names to $xxM data center project.
Cost wise Capex are depreciated, this gives less visibility on month on month costs compared with opex which goes onto income statement.
Developer work as capex is intangible asset, which has a bit more 'flexibility' depending on what management wants. It can operate on the same idea, developer wages for 1 year spread over several years via amortization of intangible asset.
Depreciation of assets also goes on P&L so no difference on periodic visibility. Also, while not capex, prepayments/reservations for cloud services are in fact assets/liabilities so yes opex vs capex is a good high level distinction but not 100% the essence.
The capex vs opex argument in cloud is more about having better transparency on your infra costs on a monthly/quarterly/yearly basis. With DCs you need to make large upfront purchases for todays and the next 3 years needs. If you under estimate you’ll be unable to grow further. If you over estimate you’ll be stuck with a bunch of unused infra.
Now say you want to spin up a new feature/product. Can you accurately forecast the compute needs? How difficult would it be to get a large capex PO out through your internal orgs on the unreleased non-revenue functionality.
Compare that to cloud where you pay for what you need. Calculating marginal cost is much easier, and securing budget on an ongoing basis to pay for clouds opex is also much easier, as you can easily show to finance the profit margins.
As the other commentor has mentioned, much easier for management to manage costs and assign to cost centers or buckets. It's a big difference to track consumption monthly based on actual instead of straight line depre, eg. depreciation hits even if everything turned off