Live data from Hacker News

Serverless Horrors

serverlesshorrors.com

381–390 of 503 posts

Re: Serverless Horrors

#381
post #210

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?

[dead]

Re: Serverless Horrors

#382

Earlier 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.

Think half an abstraction layer higher. You're on the right track with multiple PHP virtual runtimes on a single VM - that could conceptually be viewed as a sort of precursor to function runtimes.

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

#383
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…

The difference is this actually happens, a lot, unlike your straw man. It happens enough that there's a website dedicated to it.

Re: Serverless Horrors

#384

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

You script it by hand.

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

#385
post #211

Earlier 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.

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.

Re: Serverless Horrors

#387

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

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

Re: Serverless Horrors

#388
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…

For your scenarios, I have the police, the public service commission, utility regulators, my elected officials and homeowners insurance to potentially help. Not that it always works, not that it's easy, quick or without pain, but there are options.

For the cloud, I have the good will of the cloud provider and appealing to social media. Not the same thing.

Re: Serverless Horrors

#389

Earlier 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.

How many small charges get written off though? If you make a $20 mistake, maybe you let it go and just pay.

Is that worth the support to refund the 10k and 100k charges? Maybe it is.

Re: Serverless Horrors

#390
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…

In addition to everything that's already been mentioned, another obvious difference is that energy and water are finite resources that are already provided at relatively low margins. Cloud services are provided at obscene gross margins. The numbers are all made-up and don't reflect the actual costs in providing those services.
Post reply on HN