Live data from Hacker News

Serverless Horrors

serverlesshorrors.com

81–90 of 174 posts

Re: Serverless Horrors

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

Selling a put has a fixed downside, so perhaps selling a naked call would be more appropriate? Unlimited loss potential! :^)

Re: Serverless Horrors

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

I won't run a VPS. I'm entirely capable of doing it.

Badly.

I'm a mediocre Linux admin, at best. The current environment is so dangerous, these days, that it's worth your life, to have your essential services run by a mediocre admin; even if I can convince myself that I'm the best (spoiler: I'm not).

I'll generally run shared hosting, or managed servers.

Re: Serverless Horrors

#83

Earlier quoted context omitted.

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

I won't run a VPS. I'm entirely capable of doing it. Badly. I'm a mediocre Linux admin, at best. The current environment is so dangerous, these days, that it's worth your life, to have your essential services run by a mediocre admin; even if I can convince myself that I'm the best (spoiler: I'm not). I'll generally run shared hosting, or managed servers.

I can't speak for you, but it's really not too difficult to host some static content on a VPS. At the very worst, the VPS is compromised somehow, and you refresh it from the admin panel.

Re: Serverless Horrors

#85
post #83

Earlier quoted context omitted.

I won't run a VPS. I'm entirely capable of doing it. Badly. I'm a mediocre Linux admin, at best. The current environment is so dangerous, these days, that it's worth your life, to have your essential services run by a mediocre admin; even if I can convince myself that I'm the best (spoiler: I'm not). I'll generally run shared hosting, or managed servers.

I can't speak for you, but it's really not too difficult to host some static content on a VPS. At the very worst, the VPS is compromised somehow, and you refresh it from the admin panel.

I'm not talking about static content.

I need the whole enchilada: DB, Web Server, Dynamic Languages, etc. Also, for a shipping, production application, with hundreds of users; where privacy and security are of paramount importance.

It's easy, sure. It's easy to create an insecure server, that can be pwned. I know of which I speak. I have done just that.

"A man who holds a cat by the tail, learns a lesson he can learn in no other way."

- Mark Twain

Re: Serverless Horrors

#86

Earlier quoted context omitted.

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

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

Is that new (relative to some previous point in time)? They don't have my card details.

Re: Serverless Horrors

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

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.

Re: Serverless Horrors

#88

Earlier quoted context omitted.

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?

Representational state terrorism

Re: Serverless Horrors

#89
post #83

Earlier quoted context omitted.

I can't speak for you, but it's really not too difficult to host some static content on a VPS. At the very worst, the VPS is compromised somehow, and you refresh it from the admin panel.

I'm not talking about static content. I need the whole enchilada: DB, Web Server, Dynamic Languages, etc. Also, for a shipping, production application, with hundreds of users; where privacy and security are of paramount importance. It's easy, sure. It's easy to create an insecure server, that can be pwned. I know of which I speak. I have done just that. "A man who holds a cat by the tail, learns a lesson he can learn…

It's easy to create a secure server.

Use private keys. Use a firewall (ufw is really simple) and only expose your reverse proxy (e.g nginx or haproxy). Use docker to run your crap.

Any software engineer should be well capable of setting up a secure server. It really is simple.

Re: Serverless Horrors

#90

Earlier quoted context omitted.

where?

[dead]

I explicitly block everything in Russia (and China and Hong Kong) from accessing my servers, because otherwise the rate of SSH attacks is so high it actually prevents SSH from working reliably -- the connection pool fills up.

Just an FYI; I don't think it's that unusual. Blocking those geoips dramatically reduced my logging volume.

Post reply on HN