Live data from Hacker News

Serverless Horrors

serverlesshorrors.com

291–300 of 503 posts

Re: Serverless Horrors

#291
post #256

Earlier quoted context omitted.

Not everything on AWS is a Web app

TCP session close? Don't reply back the UDP response? Stop scheduling time on the satellite transceiver for that account?

Interesting that you mention UDP, because I'm in the process of adding hard-limits to my service that handles UDP. It's not trivial, but it is possible and while I'm unsympathetic to folks casting shade on AWS for not having it, I decided a while back it was worth adding to my service. My market is experimenters and early stage projects though, which is different than AWS (most revenue from huge users) so I can see why they are more on the "buyer beware" side.

Re: Serverless Horrors

#292

Earlier quoted context omitted.

I’ve accidentally hit myself with a bigger than expected AWS bill (just $500 but as a student I didn’t really want to spend that much). So I get being annoyed with the pricing model. But, I don’t think the idea of just stopping charging works. For example, I had some of their machine image thingies (AMI) on my account. They charged me less than a dollar a month, totally reasonable. The only reasonable interpretation…

There is no reason that cloud providers shouldn't be able to set up the same kind of billing options that advertisers have had access to for years. In Google and Meta ads I can set up multiple campaigns and give each campaign a budget. When that budget gets hit, those ads stop showing. Why would it be unreasonable to expect the same from AWS?

Cloud providers charge for holding data, for ingress/egress, and for compute (among other things). If I hit my budget by using too much compute, then keeping my data will cause the budget to be exceeded.

The difference is that cloud providers charge you for the “at rest” configuration, doing nothing isn’t free.

Re: Serverless Horrors

#293

I tried AWS serverless, figured out that it is impossible to test anything locally while you are forced to use AWS IAM role for serverless run which has access to everything. That's just a problem waiting to happen while you are always running tests on production...

This is nowhere near being true.

Re: Serverless Horrors

#294
post #209

Earlier quoted context omitted.

Yes, they do. You create resources and you delete resources and if you care about cost you creat alarms and tie them to scripts that automatically delete resources. It’s basic stuff.

Those alarms can take hours to cut in, because AWS does not report costs in real time

It's true that they can but mostly they don't (particularly with "serverless" services).

Re: Serverless Horrors

#295

In my experience: Fuck serverless. If we're building anything bigger than a random script that does a small unit of work, never go for serverless. A company I recently worked for went with Serverless claiming that it would be less maintenance and overhead. It absolutely was the worst thing I've ever seen at work. Our application state belonged at different places, we had to deal with many workarounds for simple thing…

Why was your PM making tech decisions?

Re: Serverless Horrors

#296

Earlier quoted context omitted.

Its not expensive for them, its expensive for their customers. If you went over your spending limit and they deleted all your shit, people would be absolutely apoplectic. Instead they make you file a relatively painless ticket and explain why you accidentally went over what you wanted to spend. This is an engineering trade-off they made to make things less painful for their customers.

There is a huge difference between deleting data and stopping running services. You're right in that there's a few services that expose this complexity directly, the ones where you're paying for actual storage, but this is just complex, not impossible. For one thing, storage costs are almost always static for the period, they don't scale to infinite in the same way.

If it’s a web server, sure. But if you drop data because you’re no longer processing it, or you need to do an expensive backfill on an ETL, then turning off compute is effectively the same as deleting data

Re: Serverless Horrors

#297

When I was learning to program through a bootcamp I spun up an elastic beanstalk instance that was free but required a credit card to prove your identity. No problem that makes sense - it's an easy way to prove authentication as a bot can't spam a credit card (or else it would be financial fraud and most likely a felony). Amazon then charged me one hundred thousand dollars as the server was hit by bot spam. I had the…

> Amazon then charged me one hundred thousand dollars as the server was hit by bot spam.

That would make you one of the most successful websites on the internet, or the target of a DDoS -- which was it? I assume you're not saying that "bots" would randomly hit a single, brand-new "hello world" site enough to generate that kind of bill.

Re: Serverless Horrors

#298

Earlier quoted context omitted.

I’ve accidentally hit myself with a bigger than expected AWS bill (just $500 but as a student I didn’t really want to spend that much). So I get being annoyed with the pricing model. But, I don’t think the idea of just stopping charging works. For example, I had some of their machine image thingies (AMI) on my account. They charged me less than a dollar a month, totally reasonable. The only reasonable interpretation…

> But, I don’t think the idea of just stopping charging works. You don't stop CHARGING. You stop providing the service that is accumulating charges in excess of what limit I set. And you give some short period of time to settle the bill, modify the service, etc. You can keep charging me, but provide a way to stop the unlimited accrual of charges beyond limits I want to set. > No, I think cloud billing is just inheren…

"They want an option to stop/limit/cap the stuff that causes the charges."

Most (aws) services support limits which prevents unlimited autoscaling (and thus unlimited billing)

Re: Serverless Horrors

#299
post #138

Earlier quoted context omitted.

But your so called "no-code" system runs on code. Checkmate atheists. There becomes a point where being mad that the specific flavor of PaaS termed serverless achtually has severs is just finding a thing to be mad at.

In the "no-code" system, the end user does not write code. In the "serverless" system, the end user does connect to a server. It doesn't just "have" servers; they aren't a hidden implementation detail. Connecting to a website is an instrumental part of using the software.

"Serverless" refers to the demarcation point in the shared responsibility model. It means there aren't any servers about as much as "cloud hosting" means the data centers are flying.

Re: Serverless Horrors

#300

When I was learning to program through a bootcamp I spun up an elastic beanstalk instance that was free but required a credit card to prove your identity. No problem that makes sense - it's an easy way to prove authentication as a bot can't spam a credit card (or else it would be financial fraud and most likely a felony). Amazon then charged me one hundred thousand dollars as the server was hit by bot spam. I had the…

> Amazon then charged me one hundred thousand dollars > as in how am I going to pay it? Really? Amazon charged your card for $100,000 and your bank allowed it? You're filthy rich by most people's standard, and you were able to pay it. Amazon was operating in such a good faith that they ate the computational cost you spent. And you hate them for this to this day...

Let’s be real: OP needed that money way more than Amazon does.
Post reply on HN