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

451–460 of 503 posts

Re: Serverless Horrors

#451

Post by Etherlord87 »

sokoloff wrote: post #402
Touche wrote: post #387

Earlier quoted context omitted.

Why would they need to delete storage, they could just not accept past the cap.

Storage billing is partly time-based. EBS is billed by the second (with a one minute minimum, I think). Once a customer hits their billing cap, either AWS has to give away that storage, have the bill continue to increase, or destroy user data.

I think most of the "horror stories" aren't related to cases like this. So we can at least agree most such stories could be easily avoided, before we looked at solutions to these more nuanced problems (one of which would be clearly communicating the mechanism of a limit and what would be the daily cost of maintaining the maxed storage - and for a free account the settings could be adjusted for these "costs" to be within free quota)

Re: Serverless Horrors

#452

Post by easyThrowaway »

fredophile wrote: post #262
bee_rider wrote: post #122

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?

Because usually marketing works next to administration and legal, while dev, devops or infra is 2-3 layers of management below.

Re: Serverless Horrors

#453

Post by mgkimsal »

unethical_ban wrote: post #397
bee_rider wrote: post #287

Earlier quoted context omitted.

So, are you looking for some “rate of charges” cap? Like, allow the charges to accumulate indefinitely, but keep track of how much $/sec is being accumulated, and don’t start up new services if it would cause the rate of charges to pass that threshold? Might work. I do think that part of the appeal of these types of services is that you might briefly want to have a very high $/sec. But the idea makes sense, at least.

I don't understand how this is hard to grasp. Compute and API access to storage is usually the thing that bites people with cloud costs. I want an option that says if I go over $20 on my lambda costs for lambda X, shut it off. If I go over $10 on s3 reads, shut it off.

The disconnect comes from the difference between 'shut it off' and 'clear the account'. If I read an earlier poster correctly, the claim is "the only reasonable interpretation is to immediately delete the contents of the entire account". But to you point, yes, this seems like it would be pretty easy to grasp. Stop incoming access, don't delete the entire account 5 seconds after I go 3 cents over a threshold.

I missed a water bill payment years ago. They shut off the water. They didn't also come in and rip out all my plumbing and take every drop of water from the house.

Re: Serverless Horrors

#454

Post by joshstrange »

mikepurvis wrote: post #24
thousand_bats wrote: post #16

Earlier quoted context omitted.

> I thought this would be about the horrors of hosting/developing/debugging on “Serverless” but it’s about pricing over-runs. Agreed about that. I was hired onto a team that inherited a large AWS Lambda backend and the opacity of the underlying platform (which is the value proposition of serverless!) has made it very painful when the going gets tough and you find bugs in your system down close to that layer (in our c…

Is that what people do is test/develop primarily with local mocks of the services? I assumed it was more like you deploy mini copies of the app to individual instances namespaced to developer or feature branch, so everyone is working on something that actually fairly closely approximates prod just without the loading characteristics and btw you have to be online so no working on an airplane.

SST has the best dev experience but requires you be online. They deploy all the real services (namespaced to you) and then instead of your function code they deploy little proxy lambdas that pass the request/response down to your local machine.

It’s still not perfect because the code is running locally but it allows “instant” updates after you make local changes and it’s the best I’ve found.

Re: Serverless Horrors

#455

Post by gloomyday »

mikeocool wrote: post #124
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…

> I had them refund the bill (as in how am I going to pay it?) but to this day I've hated Amazon with a passion They refunded you $100k with few questions asked, and you hate them for it? I’ve made a few expensive mistakes on AWS that were entirely my fault, and AWS has always refunded me for them. I imagine if Amazon did implement “shut every down when I exceed my budget” there’d be a bunch of horror stories like “I…

Well, shutting down is the obvious choice if you are getting DDOSed. The alternative is infinite potential debt. That's the real horror.

Re: Serverless Horrors

#456

Post by Foobar8568 »

Ciantic wrote: post #284
Foobar8568 wrote: post #113

Earlier quoted context omitted.

As far as I know, neither Google, Amazon or Azure have a budget limit, only alerts. This is a reason why I am not only clueless of anything related to cloud infrastructure unless it's stuff I am doing on the job, nor I am willing to build anything on these stacks. And while I guess I have less than 10 products build with these techs, I am appeal by the overall reliability of the services. Oh lastly, for Azure, in dif…

I've used Azure with spending limits. They do work, they shut down things, and the lights go off. [1], Only some external resources you are unlikely to use don't follow spending limits, but when you create such resources, they are clearly marked as external. That's one positive side of Azure. [1]: https://learn.microsoft.com/en-us/azure/cost-management-

These limits are only for subscriptions with a credit amount e.g. $200 trials, Visual Studio subscriptions etc. As soon as you are on a pay as you go, you only have access to budget limit.

Re: Serverless Horrors

#457

Post by kbart »

psychoslave wrote: post #439
bdangubic wrote: post #421

Earlier quoted context omitted.

run entire aws infra locally while studying for aws certification?

Let’s rephrase the question then, why makes an application dependent on AWS?

AWS skills are in quite strong demand, so it totally pays off to know the platform and have some hands-on experience if you work in the related area.

Re: Serverless Horrors

#458

Post by EGreg »

qcnguy wrote: post #315
McGlockenshire wrote: post #245

Earlier quoted context omitted.

You seem to be describing this as a bad thing instead of the objectively good thing that it is.

The ideal is obviously smoothed limits, such that you can absorb a big traffic spike if it still fits within your budget. Nobody seems to offer that.

How would you predict the smooth curve ahead of time?

Re: Serverless Horrors

#459

Post by AbstractH24 »

bapak wrote: post #246
VectorLock wrote: post #144

Earlier quoted context omitted.

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.

You wake up to a bill of one hundred thousand dollars and now it's up to you to dispute it. I think hating them for it is very fair.

Its just numbers on a screen.

If you woke up to the auto-withdrew $100k from your bank account and now you need to get it back that's another story.

Re: Serverless Horrors

#460

Post by AbstractH24 »

JustExAWS wrote: post #271
cjbgkagh wrote: post #156

Earlier quoted context omitted.

Amazon is currently permissive which splits opposition, this won’t always be the case, they will tighten the screws eventually as they have done in the past in other areas. Amazon because it’s so broadly used undermines the utility of chargebacks, you can do it but it’ll be a real hassle to not be able to use Amazon for shopping. A lot of people will just eat the costs, is Amazon knows this they will force the situat…

AWS has been very liberal about refunds and credits because of mistakes since 2006.

Every company was for 10 or 15 years... until they weren't.

Particularly the other side of Amazon.

Post reply on HN