Live data from Hacker News

Serverless Horrors

serverlesshorrors.com

91–100 of 174 posts

Re: Serverless Horrors

#91
post #4

Earlier quoted context omitted.

That's my favorite thing about all these services. None of them have an equivalent of a stop-loss. They'll notify you IF you setup an alert, but that's it. Often times the alerts are way after the damage is done, with some billable metrics often lagging in reporting/alerting by hours. The default should be safe with easy options to increase the limits.

You can totally build a GCP function that will tear down your site if a billing alert hits the pubsub bus, but you can also set billing caps for a bunch of the APIs.

Why not add it directly into the interface where you configure the site to begin with? It's a pretty reasonable ask.

Re: Serverless Horrors

#92
post #4

Also see the Netlify comment thread linked from one of the Reddit posts ( https://answers.netlify.com/t/limit-bandwidth-to-avoid-high-... ), where one of their representatives specifically says that if you suffer a DDOS they will do nothing to stop you from getting a bajillion-dollar bandwidth bill, even if you're on the "free" tier.

That's my favorite thing about all these services. None of them have an equivalent of a stop-loss. They'll notify you IF you setup an alert, but that's it. Often times the alerts are way after the damage is done, with some billable metrics often lagging in reporting/alerting by hours. The default should be safe with easy options to increase the limits.

I remember trying AWS Glacier as a broke university student, thinking it was a cheap way to back up my data. I was wrong.

A decade later I played around with AWS, set up a free 1-core VPS. It was fine for a year or so (I ended up not using it at all), and suddenly I got a bill. It wasn't much, but it reminded me how these services make it very hard to be aware of your bills until you get them.

I was trying out Azure recently, and I found it too confusing to make any sort of quick risk assessment.

It's clearly just for people for whom "What's the worst that could happen?" is always a rethorical question.

Re: Serverless Horrors

#93
post #91

Earlier quoted context omitted.

You can totally build a GCP function that will tear down your site if a billing alert hits the pubsub bus, but you can also set billing caps for a bunch of the APIs.

Why not add it directly into the interface where you configure the site to begin with? It's a pretty reasonable ask.

I don't really know although I can make up an answer but it contradicts

> None of them have an equivalent of a stop-loss.

Cynically, it's because they want to take your money. Practically, it's because a company that breaks your thing because you didn't pay, even if you asked it to, just isn't going to be a popular move.

Re: Serverless Horrors

#94
Don't Netlify/Vercel run on top of the likes of AWS/GCP? That means they need to markup on those already inflated hyperscaler markups for data transfer.

Re: Serverless Horrors

#95
I agree with the consensus here that the cost issues are a cloud problem, not serverless. Ironically, something like AWS lambda has a default 1,000 simultaneously activated lambda limit, so the platform defaults to throttling.

Not that serverless is perfect.

Re: Serverless Horrors

#97
post #91

Earlier quoted context omitted.

You can totally build a GCP function that will tear down your site if a billing alert hits the pubsub bus, but you can also set billing caps for a bunch of the APIs.

Why not add it directly into the interface where you configure the site to begin with? It's a pretty reasonable ask.

It takes real leadership to back a product feature like this. That's why.

Re: Serverless Horrors

#98

Perhaps I'm overreacting, but I had my personal site on Netlify and decided to move it. I don't need anything more than a dumping ground for HTML, and Netlify was "good enough" (I wasn't aware that this issue existed) What brought it closer to home was the characteristics of the recently affect site (same number of daily visits, not popular (a bit niche), etc) where similar to mine. Moving is easy enough, mostly requ…

(I work at Vercel) We do have DDoS protection, and spend limits. Working on releasing some further improvements to both of these imminently as well.

https://vercel.com/blog/introducing-spend-management-realtim...

Re: Serverless Horrors

#99

Earlier quoted context omitted.

VPSs being “easy to manage” is a strong option full of assumptions.

a basic bitch static website takes three commands in the terminal and a very basic nginx config file to setup on a completely fresh ubuntu VPS. you could read a guide from 2012 and it would work perfectly fine. is this harder than dealing with cloud 'platforms' and their ever-changing UIs, APIs, SDKs?

maybe? You go on Cloudflare's console, click on "pages", click on "new app", name it, drag your folder of website files in and you are done. automatic deploys are also available by linking a github account.

It's probably one less click to get a droplet turned up on Digital Ocean, and then you have to configure nginx or caddy (which is like five minutes if you've done it before, 30 if you haven't). Probably worth doing if it's your livelihood and you're afraid of Cloudflare disappearing, but if it's just a mess around... eh.

Re: Serverless Horrors

#100

Also see the Netlify comment thread linked from one of the Reddit posts ( https://answers.netlify.com/t/limit-bandwidth-to-avoid-high-... ), where one of their representatives specifically says that if you suffer a DDOS they will do nothing to stop you from getting a bajillion-dollar bandwidth bill, even if you're on the "free" tier.

So what do I do if this happens to me on the free tier? Just never pay the bill and leave? Will they come after me?
Post reply on HN