Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Serverless Horrors

serverlesshorrors.com

Post reply on HN
Print view View original

211–220 of 503 posts

Re: Serverless Horrors

#211

Post by cm2187 »

acoustics wrote: post #188

The assignment of blame for misconfigured cloud infra or DOS attacks is so interesting to me. There don't seem to be many principles at play, it's all fluid and contingent. Customers demand frictionless tools for automatically spinning up a bunch of real-world hardware. If you put this in the hands of inexperienced people, they will mess up and end up with huge bills, and you take a reputational hit for demanding tho…

How about spending caps / circuit breakers? Doesn't seem an unsolveable problem to me.

Re: Serverless Horrors

#213

Post by mlhpdx »

herpdyderp wrote: post #207
acoustics wrote: post #188

The assignment of blame for misconfigured cloud infra or DOS attacks is so interesting to me. There don't seem to be many principles at play, it's all fluid and contingent. Customers demand frictionless tools for automatically spinning up a bunch of real-world hardware. If you put this in the hands of inexperienced people, they will mess up and end up with huge bills, and you take a reputational hit for demanding tho…

The solution is simple: budget caps.

Is it simple? So what happens when you hit the cap, does AWS delete the resources that are incurring the cost and destroy your app?

Imagine the horror stories on Hacker News that would generate.

Re: Serverless Horrors

#214

Post by ndsipa_pomu »

christophilus wrote: post #191
Vvector wrote: post #153

Earlier quoted context omitted.

If it is a "free tier", Amazon should halt the application when it exceeds quota. Moving the account to a paid tier and charging $100k is not the right thing to do.

I agree, but I could also see how someone would complain about that: “Our e-commerce site was taken down by Amazon right on our biggest day of the year. They should have just moved us up to the next tier.”

Seems like the most flexible option is to put a spending limit in place by default and make it obvious that it can affect availability of the service if the limit is reached.

My credit cards have credit limits, so it makes sense that a variable cost service should easily be able to support a spending limit too.

Re: Serverless Horrors

#215

Post by psychoslave »

VectorLock wrote: post #144
phoenixhaber wrote: post #43

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 refunded you and you hate them for it? I think one of the reasons I appreciate AWS so much is that any time there has been snafu that led to a huge bill like this they've made it pretty painless to get a refund- just like you experienced.

Once I've been kidnapped by a guy who also happen to run a security business. After a bit of discussion, I was about to convince some of his sbire to release me without paying the ransom. I'm so glad they did accept that, and I never fail to use and recommend the services of the security business now.

Re: Serverless Horrors

#216

Post by TheSoftwareGuy »

caboteria wrote: post #55

The real serverless horror isn't the occasional mistake that leads to a single huge bill, it's the monthly creep. It's so easy to spin up a resource and leave it running. It's just a few bucks, right? I worked for a small venture-funded "cloud-first" company and our AWS bill was a sawtooth waveform. Every month the bill would creep up by a thousand bucks or so, until it hit $20k at which point the COO would notice an…

Sounds like your organization isn’t learning from these periods of high bill. What lead to the bill creeping up, and what mechanisms could be put in place to prevent them in the first place?

Re: Serverless Horrors

#217

Post by webdevver »

stressback wrote: post #121

I read a lot of the posts at the little blog here and, uh, every single one sounds like a complete amateur making a cloud configuration mistake. I haven't found one that is the provider's fault or the fault of "serverless" I would be embarrassed to put my name on these posts admitting I can't handle my configs while blaming everyone but myself. Serverless isn't a horror, serverlesshorrors poster. You are the horror.…

truth nuke

Re: Serverless Horrors

#218

Post by ndsipa_pomu »

mlhpdx wrote: post #213
herpdyderp wrote: post #207

Earlier quoted context omitted.

The solution is simple: budget caps.

Is it simple? So what happens when you hit the cap, does AWS delete the resources that are incurring the cost and destroy your app? Imagine the horror stories on Hacker News that would generate.

Surely that's the fault of the purchaser setting the cap too low.

Maybe rather than completely stopping the service, it'd be better to rate limit the service when approaching/reaching the cap.

Re: Serverless Horrors

#219

Post by zahlman »

I don't understand why it should be called "serverless" when using cloud infrastructure. Fundamentally you're still creating software following a client-server model, and expecting a server to run somewhere so that your users' clients work.

To me, "serverless" is when the end user downloads the software, and thereafter does not require an Internet connection to use it. Or at the very least, if the software uses an Internet connection, it's not to send data to a specific place, under the developer's control, for the purpose of making the software system function as advertised.

Re: Serverless Horrors

#220

Post by zorked »

mlhpdx wrote: post #213
herpdyderp wrote: post #207

Earlier quoted context omitted.

The solution is simple: budget caps.

Is it simple? So what happens when you hit the cap, does AWS delete the resources that are incurring the cost and destroy your app? Imagine the horror stories on Hacker News that would generate.

Stop accepting requests like has been the case since the beginning of time?
Post reply on HN