Live data from Hacker News

Serverless Horrors

serverlesshorrors.com

51–60 of 174 posts

Re: Serverless Horrors

#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 doing that on an infinite loop but after 2 weeks of him doing that without sending you any info, you went to the garage to check on him and told him to stop, so he stops and bills you for 999999999 items that are broken.

As a small user and not a large organisation, I'll never be able to read the full documentation on throttling every nook and cranny, I want to set a fixed spending limit that if reached, will kill the whole thing, even lose data if it must. But they won't do that because it hurts their bottom line if people are careful with budgets, and sometimes it's tricky to compute billing ahead of time.

Re: Serverless Horrors

#52
post #45

Earlier quoted context omitted.

Yup, this is exactly my point. It's not the serverless architecture, something you set up on Hetzner yourself with OpenFaaS ( https://github.com/openfaas/faas ), that is to blame here but the insane pricing scheme for traffic.

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

Re: Serverless Horrors

#53
I think the biggest Cloud horror, probably not serverless, is that we have accepted to pay for inter-AZs traffic just in case the Cloud provider fails. In other words, they charge (and a lot) for a mitigation for the problems they might have.

Re: Serverless Horrors

#54

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.

Can you use free tier under a fake name? To drop ridiculous bills. How do they validate the customer?

Re: Serverless Horrors

#55
The creator of the blog is Andres who is also building coolify[0], a heroku/netflify self-hosted alternative. I wanted to give a shoutout to him and his product. I've been running it for a few months and love it. Really was has been kinda the secret sauce of ease of use for me to start self-hosting things like changedetector, jdownloader, vaultwarden, etc.

It also has a pretty nicely growing community where people are contributing new templates (I added one for Syncthing) and helping each other debug.

The only issue I've had with it is things kinda fall over if you run out of disk space, which happened when I was running on an instance with just 10GB storage. So a little better alerting or prevention around that would be great but otherwise it has been pretty solid.

https://github.com/coollabsio/coolify

Re: Serverless Horrors

#56
Presumably the costs for a platform are passed on to the platform's customers from that platform's cloud provider (with profit). When a spike happens due to, say, a DDOS, does the platform first have to negotiate with the cloud provider to waive the cost?

Presumably the costs for a cloud provider are passed on to the cloud provider's customers from that cloud provider's operating costs (with profit). When a spike happens due to, say, a DDOS, does the cloud provider first have to negotiate with its downstream suppliers (e.g., energy, network peering, etc.) to waive the cost?

...

How far down the chain does this go? Or maybe insurance steps in at some point -- or every point -- to break the chain?

Re: Serverless Horrors

#57
post #46

Earlier quoted context omitted.

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

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.

Re: Serverless Horrors

#58
post #38

> The ddos attack was focused on a file on my site. Yes it’s partly my fault to put a 3.44MB size sound file on my site rather than using a third-party platform like SoundCloud. But still this doesn’t invalidate the point of having protection against such attacks, and limit the spending. This is extremely sad. It's like we are taking steps backward. A 3.44MB should not be an issue and if it is, the answer should not…

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

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

There are definitely many footguns with managing a VPS but I think the threshold to get vaguely competent with a VPS is not really that far off with getting familiar with the average cloud platform - which comes with its own dangers, like the near-total inability to put an upward cap on fees that that person found out with Netlify recently.

Having a $5 VPS and knowing it's never going to cost your more than $5 might balance out a lot of things on the other side for a lot of people.

(And, as a bonus, it comes with the benefit of having a better idea of what is going on on the actual computer which is running your code.)

Platforms like https://coolify.io/ (which I have not tried, but looks interesting) seem to give you some of the abstractions that you get in cloud platforms to save you having to mess with too much low level stuff and become an expert in a billion separate systems.

If you have Debian with automatic updates that does most of the heavy lifting for you. The hardest problem I have is resisting the temptation to just install everything, because the cost to do it is capped at my VPS monthly fee.

So yep, it comes with a lot of assumptions. But so does everything!

Re: Serverless Horrors

#59

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.

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.

Re: Serverless Horrors

#60
post #38

> The ddos attack was focused on a file on my site. Yes it’s partly my fault to put a 3.44MB size sound file on my site rather than using a third-party platform like SoundCloud. But still this doesn’t invalidate the point of having protection against such attacks, and limit the spending. This is extremely sad. It's like we are taking steps backward. A 3.44MB should not be an issue and if it is, the answer should not…

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?

Post reply on HN