TLDR: Deployed buggy code with infinite trigger. Hosting costs increased.
The only difference here is that if he deployed it on his own server, he wouldn't have lost money.
Serverless: A lesson learned the hard way
51–60 of 139 posts
Re: Serverless: A lesson learned the hard way
#52Earlier quoted context omitted.
They didn't a year and a half ago. Created a 3k bill for my employer over RemoteApp. Yeah, charge per user, they said. Oh yeah, min 20 users, and we round up - of course in small print at the time. Unless I have hard guarantees, I give "cloud providers" re-loadable cards. Can't take more money than what's on there.
The vendor could still assign the debt to a collection agency or sue; a declined charge does not get you off the hook unless they decide it's not worth pursuing.
That's very true. That's why I provide generic usernames and everything. Because how the current providers offer service is as through a debt system. You rack up the $$$, and they tell you after the fact.
I would greatly prefer to pay up front, and have services take my credit. That way, I could control my costs directly and concisely. No surprise billing. DOS'es get stopped by no more funds- they aren't the infinite money piggybank they are now with debt.
I also understand why some clients would want a debt based system where they can expand and contract their costs. I'm cool with that, as long as you know what you're signing up for. The person in this article didn't, and surprise billing is majorly at fault here.
My solution would stem this "You owes us $20,000 by end of month", to "Your credit is exhausted after 10 minutes. Something seems wrong with this account cwhen compared to history."
Re: Serverless: A lesson learned the hard way
#53Earlier quoted context omitted.
It's "serverless" in the sense that if the developer had provisioned a "server" then the max incursion of cost would equal the cost of that server, no more no less. So yeah, let's blame the developer, but let's not play like mistakes don't happen and they're not costly in the "serverless" world.
LOL WAT? How is it "serverless" if you're provisioning a server?
He's saying that the problem is with "serverless architecture", because the problem could not possibly have happened without the use of a serverless architecture (e.g. provisioning a server). The problem is exclusive to serverless.
Re: Serverless: A lesson learned the hard way
#54Off topic, but the "serverless" moniker needs to die. I propose "adminless" as in "server I don't have to admin, configure, or patch" as being much more descriptive of whats really going on.
Eh, if I'm deploying a cloud function, the server truly doesn't exist for me. It's more like a Web Worker running in a privileged environment. I'm ok with the name.
No, it's really a server running your function. You just (are told you) don't have to worry about the server or what it's actually doing.
Re: Serverless: A lesson learned the hard way
#55This has nothing to do with serverless itself but it's rather problem of AWS.
Re: Serverless: A lesson learned the hard way
#56The main issue here is the budget notification emails aren't an adequate mechanism to catch infinite loops. They are too slow and you've already racked up big overages by the time you see it.
Idea: use API Gateway to configure a quota to match your budget projections. That will force a hard stop. Would be nice if AWS made this easier.
Re: Serverless: A lesson learned the hard way
#57There's a lesson in there about how AWS makes a crisp $10m dollar bill for the richest man in the world every day.
I know you're being sarcastic but I feel it's partly true. They announce so many different services, each month something new appears, but this very basic feature - bill capping - asked by users from the very beginning, has never been implemented. It's hard to believe they lack the skill or that it would be much more complicated than the current alert system.
Re: Serverless: A lesson learned the hard way
#58If you are big enough and want serverless no-ops yet don't want to pay per burger when you already breed cows then consider kubeless.io
Re: Serverless: A lesson learned the hard way
#59Run+know your infra, none of this is a problem. Serverless is a scam.
So run my static content only blog on dedicated hardware that I have to administer rather than throw it in an S3 bucket with a Cloudfront on it? No thank you. Qualify your statements.
You don't really need to administer it, there are plenty of hosting options, not just bare metal. And you can always add Cloudlflare anyway.
Re: Serverless: A lesson learned the hard way
#60"a $180 actual cost. I was left with a light headed feeling, it's a lot of money for me" people still play with fire. limit your losses, go with digital ocean or something for 5$/mo flat no matter what.
that depends for 5$ it breaks after a certain level of traffic. for many applications its always better to spend $$ instead of things shutting down. (hosting is usually insignificant compared to people, revenue etc)
it's better to have an ability to cap $. With something like DO it'a way easier to control costs compared to AWS.