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

431–440 of 503 posts

Re: Serverless Horrors

#431

Post by jiggawatts »

trillic wrote: post #70
Ekaros wrote: post #61

Earlier quoted context omitted.

I recently had customer who had smart idea to protect Container Registry with firewall... Breaking pretty much everything in process. Now it kinda works after days of punching enough holes in... But I still have no idea where does something like Container registry pull stuff from, or App Service... And does some of their suggested solutions actually work or not...

Convince them to add IPv6 and you’ll be set for life

They did!

But they network address translate (NAT) IPv6, entirely defeating the only purpose of this protocol.

It's just so, so painful that I have no words with which I can adequately express my disdain for this miserable excuse for "software engineering".

Re: Serverless Horrors

#432

Post by jiggawatts »

Touche wrote: post #385
nostrebored wrote: post #305

Earlier quoted context omitted.

Then you’re the person who took down their small business when they were doing well. At AWS I’d consistently have customers who’d architected horrendously who wanted us to cover their 7/8 figure “losses” when something worked entirely as advertised. Small businesses often don’t know what they want, other than not being responsible for their mistakes.

Everyone who makes this argument always assumes that every website on the internet is a for-profit business when in reality the vast majority of websites are not trying to make any profit at all, they are not businesses. In those cases yes absolutely they want them to be brought down.

Or instead of an outage, simply have a bandwidth cap or request rate cap, same as in the good old days when we had a wire coming out of the back of the server with a fixed maximum bandwidth and predictable pricing.

Re: Serverless Horrors

#433

Post by wpm »

vntok wrote: post #186
wpm wrote: post #171

Earlier quoted context omitted.

Why would I apoplectic at Amazon if I set “turn my shit off after it has accrued $10 in charges” to TRUE and they actually followed what I asked them to do?

Is it a serious question? Because then I could have you shutdown just by posting a call to ddos with a link to your search form on an anime image board.

OK? Good! That's what I want to happen! I want that. I do not care if some weirdos on an anime image board can't access some image. I don't want my credit card maxed out.

Is that not a serious request? I play around in the same big-boy cloud as some SaaS company, but I'm on the free tier and I explicitly do not want it to scale up forever, and I explicitly do not want to destroy my credit or even think about having to call Amazon over a $100,000 bill because I set my shit up wrong or whatever. I want it to shut off my EC2 instance once it has used up whatever amount of resources is equal to $X.

Obviously any world with this feature would also feature customizable restrictions, options, decision trees, etc etc. I don't think anyone is or was suggesting that someone's SaaS app just gets turned off without their permission.

Re: Serverless Horrors

#434

Post by rgoulter »

mlhpdx wrote: post #257
estimator7292 wrote: post #239

Earlier quoted context omitted.

I mean, would you rather have a $10k build or have your server forcefully shut down after you hit $1k in three days? One of those things is more important to different types of business. In some situations, any downtime at all is worth thousands per hour. In others, the service staying online is only worth hundreds of dollars a week. So yes, the solution is as simple as giving the user hard spend caps that they can c…

If you want hard caps, you can already do it. It’s not a checkbox in the UX, but the capability is there.

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

Sounds like you're saying "there aren't caps because it's hard".

> If you want hard caps, you can already do it. ... the capability is there.

What technique are you thinking of?

Re: Serverless Horrors

#435

Post by slow_typist »

tetromino_ wrote: post #194
JJMcJ wrote: post #83

Earlier quoted context omitted.

This is an example of why cloud hosting is so scary. Yes, Amazon, and I assume Azure and Google's cloud and others, "usually" refund the money. But I don't want to be forced into bankruptcy because my five visitor a week demo project suddenly becomes the target of a DDOS for no reason at all and the hosting company decides this isn't a "usually" so please send the wire transfer.

If you sign up for electrical service for your house, and your shithead neighbor taps your line to power his array of grow lamps and crypto mining rigs, the power company will happily charge you thousands of dollars, and you will need a police report and traverse many layers of customer service hell to get a refund. If you sign up for water service and a tree root cracks your pipe, the water company will happily char…

At least in my country the metering is done _in_ the house so my neighbour has to break and enter to tap the line behind the meter. I would probably notice well before bills would pile up. If he taps it outside, probably no one would ever notice if done right. The grid looses energy all the time. Not every kWh that goes into the network is billed in the end.

As always, it just doesn’t make an awful lot of sense to compare physical and virtual worlds. As in leaving your front door unlocked in rural areas vs not securing your remote shell access.

Re: Serverless Horrors

#436

Post by acoustics »

jiggawatts wrote: post #432
Touche wrote: post #385

Earlier quoted context omitted.

Everyone who makes this argument always assumes that every website on the internet is a for-profit business when in reality the vast majority of websites are not trying to make any profit at all, they are not businesses. In those cases yes absolutely they want them to be brought down.

Or instead of an outage, simply have a bandwidth cap or request rate cap, same as in the good old days when we had a wire coming out of the back of the server with a fixed maximum bandwidth and predictable pricing.

There are plenty of options on the market with fixed bandwidth and predictable pricing. But for various reasons, these businesses prefer the highly scalable cloud services. They signed up for this

Re: Serverless Horrors

#437

Post by exe34 »

bee_rider wrote: post #409
exe34 wrote: post #379

Earlier quoted context omitted.

I wouldn't. I've explained what I want.

There isn’t an option to not resolve “you’ve reached your billing limit and now storage charges are exceeding it.” You can resolve it by unceremoniously dumping the user data. You can resolve it by… continuing to charge the user, and holding their files hostage until they pay the back storage charges, and then the egress fees (so, it isn’t really a limit at all). Or you can resolve it by just giving the user free sto…

I said you could put the limit at 1 trillion dollars if that's your concern. there's no limit for you!

(for my hobby projects, I'm happy for the limit to be $5 and delete everything when the limit is reached. that's what my backups are for.)

Re: Serverless Horrors

#438

Post by mcv »

LeifCarrotson wrote: post #168
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.

As the saying goes, when you owe the bank $100 you've got a problem, when you owe the bank $100k the bank has a problem... On serverless, I can enter numbers in a calculator and guess that running my little toy demo app on AWS will cost between $1 and $100. Getting hit with a huge $1000 bill and a refusal to refund the charges (and revocation of my Prime account and a lifetime ban from AWS and cancellation of any oth…

> (and revocation of my Prime account and a lifetime ban from AWS and cancellation of any other services I might otherwise run there)

Also a vital lesson from the big tech companies that sell a wide variety of services: don't get your cloud hosting from a company that you also use other services from.

I had to disable photo syncing because Google photos eats up my Gmail space. Having Amazon's cloud billing fuckup threaten your TV access is another level.

We clearly need to keep the option open to burn those bridges.

In any case, if I ever host anything, I'm going to host it from my home.

Re: Serverless Horrors

#440

Post by tstrimple »

AtlasBarfed wrote: post #429
JJMcJ wrote: post #83

Earlier quoted context omitted.

This is an example of why cloud hosting is so scary. Yes, Amazon, and I assume Azure and Google's cloud and others, "usually" refund the money. But I don't want to be forced into bankruptcy because my five visitor a week demo project suddenly becomes the target of a DDOS for no reason at all and the hosting company decides this isn't a "usually" so please send the wire transfer.

Aws, able to bill everything down to like milliseconds of usage... We can't implement a basic cost limiter policy. I think we all know why.

It's extra frustrating I think on the Azure side because they absolutely have cost limited accounts for MSDN subscribers but won't extend that functionality to general users. Just let me set a cap on the cost I'm willing to pay per month and let me deal with the consequences of the resource being shut down unexpectedly. You can work around these things if you instrument the right metrics and create the right alerts so you can take action in time. But those are often hard learned lessons and not the happy path to using the cloud.

It's entirely possible to build cloud first solutions that scale better and are cheaper than your standard reliable colo solutions. But you've got to understand the tradeoffs and when to limit scaling otherwise things can run away from you. I still reach for "cloud first" tools when building my own projects because I know how to run them extremely cheaply without the risk of expenses blowing up because some random thing I've built lands on HN or the equivalent. Many hobby projects or even small businesses can leverage free tiers of cloud services almost indefinitely. But you've got to architect your solutions differently to leverage the advantages and avoid the weaknesses of the cloud. Actually understand the strengths and limitations of the various cloud "functions as a service" offerings and understand where your needs could be solved from those tools and how to work within those cost constraints. Repeatedly I see people trying to use the cloud as if it's just another colo or datacenter and build things in the same way they did before and only think about things in terms of virtual machines tend to have a more difficult time adopting the cloud and they end up spending far more than the companies who can tear down and spin up entire environments through IaC and leverage incremental pricing to your benefit.

Post reply on HN