Serverless Horrors

It is amazing, isn't it? Something starts as an oversight but by the time it reaches down to customer support, it becomes an edict from above as it is "expected behavior".

> AWS was kind enough to cancel my S3 bill. However, they emphasized that this was done as an exception.

The stench of this bovine excrement is so strong that it transcends space time somehow.

That's the best part!

The devs probably never thought of it, the support people who were complained to were probably either unable to reach the devs, or time crunched enough to not be able to, and who as a project manager would want to say they told their Devs to fix an issue that will lose the company money!

And does some of their suggested solutions actually work or not...

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.

If you can't run locally, productivity drops like a rock. Each "cloud deploy" wastes tons of time.

Buckets are used for backups, user uploads, and lots of things other than distributing files publicly.

The trade-off being that your site falls over with some amount of traffic. That's not a criticism, that may be what you want to happen – I'd rather my personal site on a £5 VPS fell over than charged me £££.

But that's not what many businesses will want, it would be very bad to lose traffic right at your peak. This was a driver for a migration to cloud hosting at my last company, we had a few instances of doing a marketing push and then having the site slow down because we couldn't scale up new machines quickly enough (1-12 month commitment depending on spec, 2 working day lead time). We could quantify the lost revenue and it was worth paying twice the price for cloud to have that quick scaling.

And it's getting harder and harder to make them public because of people misconfiguring them and then going public against AWS when they discover the bill.

The real question is if they considered caching and thus configured it appropriately. If you don't, you're telling everyone you want every request to go to origin

You just shouldn't be using S3 to serve files directly. You can run most public and many private uses through CloudFront. Which gives you additional protections and reduces things like per object fetch costs.

> you hit natural rate limits

Seen by your customers or the public as a "denial of service." Which may actually be fine for the people who truly do want to limit their spending to less than $100/month.

Serverless eliminates the management of servers; the name is meaningful and directionally aligned with what the thing does, even if it can cause confusion when you first encounter the topic.

That doesn't mean it isn't a bad name. But it is not comparable to the Ministry of Plenty deliberately causing famine. "Famine" and "plenty" are directionally opposed and so require dissonance to maintain. "Serverless" and "abstracting resources provided by servers so that you can focus on application logic rather than managing physical or virtual machines" are not opposed and only require learning the terminology. There's no active, ongoing effort to deliberately maintain cognitive dissonance.

Unless you find yourself in a situation where you have that queasy feeling of being gaslit or having to actively push thoughts out of your head to continue operating under premises you know are false, no, it is not doublethink.

I think figuring out how to do this faster is less trivial than it might sound. I agree that synchronous checks aren’t reasonable. But let’s take Lambdas. They can run for 15 minutes, and if you consolidate within five minutes after a resource has been billed, that gives you a twenty minute lag.

I’m not trying to make apologies for Amazon, mind you. Just saying that this isn’t exactly easy at scale, either. Sure, they bill by invocation, but that’s far from synchronous, too. In fact, getting alerts might very well be happening at the frequency of billing reconciliation, which might be an entirely reasonable thing to do. You could then argue that that process should happen more frequently, at Amazon’s cost.

Software runs on so many things we depend on IMO it also in many cases falls in the "dangerous technology" category.

Non-hobby OSes, non-hobby web browsers, device drivers, software that runs critical infrastructure, software that runs on network equipment, software that handles personal data, --IMHO it would not be unreasonable to require formal qualifications for developers working on any of those.

It’s basic stuff.

If a tool is designed for experts, but you as the manufacturer or distributor know the tool is used by general populace, you know it's being misused every now and then, you know it harms the user AND YOU KNOW YOU BENEFIT FROM THIS HARM, AND YOU COULD EASILY AVOID IT - that sounds like something you could go to jail for.

I think if Amazon was a Polish company, it would be forced by UOKiK (Office of Competition and Consumer Protection) to send money to every client harmed this way. I actually got ~$150 this way once. I know in USA the law is much less protective, it surprises me Americans aren't much more careful as a result when it comes to e.g. reading the terms of service.

What would be helpful, would be if when you set up your account there was a default limit – as in an actual limit, where all projects stop working once you go over it - of some sane amount like $5 or $50 or even $500.

I have a handful of toy projects on AWS and Google cloud. On both I have budgets set up at $1 and $10, with notifications at 10% 50% and 90%. It’s great, but it’s not a limit. I can still get screwed if somehow, my projects become targets, and I don’t see the emails immediately or aren’t able to act on them immediately.

It blows my mind there’s no way I can just say, “there’s no conceivable outcome where I would want to spend more than $10 or more than $100 or whatever so please just cut me off as soon as I get anywhere close to that.”

The only conclusion I can come to is that these services are simply not made for small experimental projects, yet I also don’t know any other way to learn the services except by setting up toy projects, and thus exposing yourself to ruinous liability.

> There can be a delay between when you incur a charge and when you receive a notification from AWS Budgets for the charge. This is due to a delay between when an AWS resource is used and when that resource usage is billed. You might incur additional costs or usage that exceed your budget notification threshold before AWS Budgets can notify you, and your actual costs or usage may continue to increase or decrease after you receive the notification.