Live data from Hacker News

Serverless Horrors

serverlesshorrors.com

71–80 of 174 posts

Re: Serverless Horrors

#71
post #46

Earlier quoted context omitted.

I remember a comment from this site. Something like: we must study how Amazon and other big cloud's marketing work so great to make this generation developers think that vps or selfhosting are hard. IMO vps was easy before and even easier now to manage.

Please explain how you rotate ssh keys, store audit logs, backup (and test backup procedures), configure secure network between vpses such that your neighbor cannot eavesdrop.

1. You didn't do that on a VPS

2. Often there would be a cPanel plugin/extension/app/config value (if the hoster enabled it for you) that would just do for you what you needed.

Re: Serverless Horrors

#72
post #46

Earlier quoted context omitted.

I remember a comment from this site. Something like: we must study how Amazon and other big cloud's marketing work so great to make this generation developers think that vps or selfhosting are hard. IMO vps was easy before and even easier now to manage.

Please explain how you rotate ssh keys, store audit logs, backup (and test backup procedures), configure secure network between vpses such that your neighbor cannot eavesdrop.

You don't need to do any of that for hosting a content website.

The content & config are pushed by rsync/ssh from a git repo, so there's no need for backups. I can recreate a server in half an hour. I guess I lose the webserver logs, but I rarely look at them so I don't care.

A single server has plenty of bandwidth for a personal site, so there's only one EC2 instance and no secure network is needed. If I need more bandwidth, I'll use a load balancer but there's no need for secure connections between the load balancer & web servers because what's the eavesdropping threat model for a public content site?

Let's Encrypt seems to deal with https key rotation without manual intervention.

The cloud servers just have the usual ~cloud/.ssh/authorized_keys login setup, and I guess I rotate them every time a stronger crypto is recommended, which is 4ish times in 30 years.

Re: Serverless Horrors

#73

Earlier quoted context omitted.

There is no free plan, there is just free limit - you must add a card.

And what if you add a debit card without money? Or add a disposable card and then the next day you deactivate it? Nowadays everyone push you to add a card to open free* account. Such disposable cards is a solution to this issue.

Your debt will be sold to a collection company.

Re: Serverless Horrors

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

oooh i really like that stop loss example. having a netlify serverless website is basically selling a put option without receiving any premium.

The premium is the website itself ;D Still, potentially unlimited costs is wayy too much risk.

Re: Serverless Horrors

#75

Earlier quoted context omitted.

There is no free plan, there is just free limit - you must add a card.

And what if you add a debit card without money? Or add a disposable card and then the next day you deactivate it? Nowadays everyone push you to add a card to open free* account. Such disposable cards is a solution to this issue.

Many don't accept prepaid cards.

Re: Serverless Horrors

#76
post #51

I feel like cloud vendors overcharging for things they have the right to charge you are like a car mechanic that tells you you have to pay him a billion dollar for a routine maintenance check of your car because when he was fixing some small item, it broke and he had to get another one and put in in place, but then it broke for the same reason (that is not the mechanic's fault or the item constructor's), so he kept d…

Well there are differences. The mechanic from your example caused the situation. Netlify didn't and it might be hard to distinguish between unwanted traffic and a SaaS having overnight success.

A more accurate allegory would be if you told the mechanic to do whatever anyone who knows the registration plate asked, and he did so.

Re: Serverless Horrors

#77

Earlier quoted context omitted.

I also prefer to get a (decaf) coffee, listen to some music while someone DDoS'd my VPS. I prefer to pay few $ / month for my VPS instead of paying thousands and "survive" the DDoS.

I pay $10/year for my VPS and host a WordPress Woocommerce store on it... It doesn't get much traffic, but it didn't take long to pay for itself either

where?

Re: Serverless Horrors

#78
The thing I don't understand is why people go for cloud route for the simple sites, when there are options like Github static hosting or self hosting using secure tunnels from Cloudflare or Ngrok? The risk presented by these horrors stories greatly outweigh possible complications from setting something quickly on your own.

Re: Serverless Horrors

#79
post #45

Earlier quoted context omitted.

... which you generally get with serverless offers.

Correlation does not imply causation. There is no inherent reason why a serverless architecture would force a provider to have insane high traffic costs, hence it doesn't make sense to put blame on the term "serverless" for that. On the other hand, if one could explain such causation, then I would be very interested in hearing about it.

> Correlation does not imply causation.

Correct, but the effect on the wallet doesn't care if there is a causal relationship. And since my wallet is closer to me than a philosophical debate, the conclusion I reach in this case, is to move my site ;-)

Re: Serverless Horrors

#80

Earlier quoted context omitted.

It used to be we will take your server down. Now its we'll DDOS your serverless website and leave you a 100k bill. I'm not sure how sustainable such business model is. When you owned the server, you could unplug it. Now you have no way of knowing if somebody is going to hit your /api a million times per minute

AWS guarantees protection from all DDoS attacks done at level 3-4 (Google aws shield). If someone calls your api million times then there is throttling.

So instead of DDoSing someone, you could make some not-so-large amount of requests to their APIs and instead of taking down their servers, you'll just take them down by bankrupting them with a huge invoice?
Post reply on HN