Earlier quoted context omitted.
Putting stuff on the internet is dangerous, but the absence of hard caps is a choice and it just looks like another massive tech company optimizing for their own benefit. Another example of this is smartphone games for children, it's easier for a child to spend $2,000 then it is for a parent to enforce a $20/month spending limit.
Are you really comparing a software developer provisioning an online service to a child buying tokens for loot boxes?
Serverless Horrors
381–390 of 503 posts
Re: Serverless Horrors
#382Earlier quoted context omitted.
A "Server" is typically a single machine that has a specific OS and runs layers of various software that allows your business logic to be accessed by other computers (by your users). For a "Server" you typically have to choose an OS to run, install all the support software (server monitoring, etc), update the software, and if the server fails you have to fix it or rebuild it. With "Serverless", your code is in a "fun…
> Essentially you do not have to deal with any of the hassle that comes with setting up and maintaining your own "server", all you have to do is write the code that is your business logic. Also known as "shared hosting". It's been done since the 90's (your folder full of PHP files is an NFS mount on multiple Apache servers), just that the techbros managed to rebrand it and make it trendy.
The serverless function has higher-order features included as part of the package: you get an automatic runtime (just as with PHP but in this case it can be golang or dotnet), the function gets a unique endpoint URL, it can be triggered by events in other cloud services, you get execution logging (and basic alerting), multiple functions can be chained together (either with events or as a state machine), the function's compute can be automatically scaled up depending on the traffic, etc.
Think of it as: What do I have to do, in order to scale up the conpute of this URL? For hardware it's a call to DELL to order parts, for VMs or containers it's a matter of scaling up that runtime, or adding more instances - neither of those processes are simple to automate. One key characteristic of the function is that it will scale horizontally basically however much you want (not fully true, aws has a limit of 1500 instances/second iirc, but that's pretty massive), and it will do it automatically and without the request sources ever noticing.
Functions are also dirt cheap for low/burst traffic, and deployment is almost as easy as in the PHP FTP example. Personally I also think they are easier to test than traditional apps, due to their stateless nature and limited logical size (one endpoint). The main downsides are cost for sustained load, and latency for cold starts.
With that said, they are not "endgame". Just a tool - a great one for the right job.
Re: Serverless Horrors
#383Earlier 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…
Re: Serverless Horrors
#384Earlier quoted context omitted.
Not _really_. AWS has a budget tool, but it doesn’t natively support shutting down services. Of course, you can ingest the alerts it sends any way you want, including feeding them into pipelines that disable services. There’s plenty of blueprints you can copy for this. More seriously - and this is a legitimate technical limitation - of course AWS doesn’t check each S3 request or Lambda invocation against your budget,…
> of course AWS doesn’t check each S3 request or Lambda invocation against your budget If it can bill them per-invocation, why can't it also check against a budget? I don't expect it to be synchronous, but a lag of minutes to respond is still better than nothing. Can you even opt-in to shutting down services from the budget tool, or is that still something you have to script by hand from Cloudwatch alarms?
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.
Re: Serverless Horrors
#385Earlier quoted context omitted.
How about spending caps / circuit breakers? Doesn't seem an unsolveable problem to me.
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.
Re: Serverless Horrors
#386Re: Serverless Horrors
#387Earlier quoted context omitted.
Or simply returns 503? Why would you go directly to destroying things??
Suppose you’re going over the billing cap based on your storage consumption, how would AWS stop the continued consumption without deleting storage?
Re: Serverless Horrors
#388Earlier 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…
For the cloud, I have the good will of the cloud provider and appealing to social media. Not the same thing.
Re: Serverless Horrors
#389Earlier quoted context omitted.
Cloud providers charge for holding data, for ingress/egress, and for compute (among other things). If I hit my budget by using too much compute, then keeping my data will cause the budget to be exceeded. The difference is that cloud providers charge you for the “at rest” configuration, doing nothing isn’t free.
Great so they can give you an option to kill all charges except basic storage. Or let you reserve part of your budget for storage. Or let you choose to have everything hard deleted. Surely these billion and trillion dollar companies can figure out something so basic.
Is that worth the support to refund the 10k and 100k charges? Maybe it is.
Re: Serverless Horrors
#390Earlier 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…