Live data from Hacker News

Serverless: slower and more expensive

einaregilsson.com

241–250 of 733 posts

Re: Serverless: slower and more expensive

#241
post #231

Earlier quoted context omitted.

You should work in enterprises where you have to deal with stringent security requirements, emergency CVE mitigation across multiple regions, compliance requirements, etc., and you’ll quickly gain an appreciation for why enterprise folks don’t want to manage servers.

>> emergency CVE mitigation across multiple regions, compliance requirements These don't go away because you went serverless. They are jut now outside your control -- and you will have to wait for somebody else to fix them, usually with no insight into how long it will take leaving you with a very poor messaging you can give your clients as to when things will be back on line. Simply hand-waving -- this is running on…

> Simply hand-waving -- this is running on somebody else's server is not going to make the auditors happy.

It shifts blame, especially if it's in the contract with the provider.

Re: Serverless: slower and more expensive

#242
There is one crucial piece of data I was unable to find in the article, what memory size was Lambda set at?

For those unfamiliar with Serverless, you can choose how much RAM each function gets. Higher RAM costs more but also gives you a faster CPU. His Lambda functions are, on average, being billed for 500ms (according to one graphic).

If he is running with the base RAM allocation bumps it up he might see significantly faster performance and potentially billed for less.

Tuning lambdas and selecting the most optimal RAM (CPU) allocation is automatic with the help of tools provided by the community.

tl;dr Lambda is billed in 100ms increments and has configurable RAM. Higher RAM Lambda is more expensive but faster CPU. This can reduce your bill.

Re: Serverless: slower and more expensive

#243
post #34

Earlier quoted context omitted.

There's already serverless where you don't have to do anything with OS/servers/infra: PaaS, like Heroku. But no, that's not Amazon, so no one cares either way (pro/contra, cheap/expensive, fast/slow, easy/hard) :|

Heroku is not Serverless in the modern definition of the word and doesn’t Heroku run on AWS?

> Heroku is not Serverless in the modern definition of the word

Heroku seems to be serverless in the way cloud vendors, including Amazon, have been using it recently; it's not serverless in the sense that Amazon first introduced it, which was a synonym for Lambda. It's pretty similar to GAE, which is definitely within the current usage of “serverless”.

Re: Serverless: slower and more expensive

#244

I recently saved a company from serverless: development had completely stalled, continuous delivery was insanely inefficient (you couldn't deploy your set of functions at once because of dependencies), vendor lock-in made it a pain to develop locally (cognito in particular), CI testing was also a big pain (serverless-offline), the project also had reached the endpoint limit so basically they had to split the project…

Sometimes the right solution is just the easiest. Most of the time just is. Congrats.

Replacing badly executed solution A with well executed solution B is obviously a good idea, but adds nothing to the conversation.

Re: Serverless: slower and more expensive

#245
I enjoy using AWS Lambda and believe it has many valid use cases. Unfortunately, Einar learned the hard way and hastily made a significant decision with regards to their architecture. To be fair, Einar admitted their faults in their decision was rooted in a lack of understanding in the AWS API Gateway and Lambda pricing model. However, a lot of comments are using this as a source to validate their opinions on why they believe AWS Lambda and AWS API Gateway is bad. Lambda is excellent for low volume, bursty traffic. It is not designed to be a solution for a web api that gets 300M reqs/month. It is technically feasible but fiscally irresponsible. Conversely, if going Serverless means you can get rid of a system administrator for a dedicated API server then that is a whole different situation where it would be fiscally irresponsible not to use serverless. With regards to the performance concerns, concurrent requests spin up concurrent Lambda functions. If you can limit the number of concurrent processes you _might_ actually see better performance with Lambda than you are seeing now.

Re: Serverless: slower and more expensive

#246
post #164

Earlier quoted context omitted.

This is all strawman. There are valid reasons for serverless, most people choose it for reasons other than hype, and the savings and security of not self managing servers is tangible. All technology can be misused or poorly utilized, and even the best can have pathological edge cases. For the 80% or more, serverless works just fine.

While in most cases I would agree, in this case I have to disagree. I think serverless has been a good idea implemented badly in every instance.

[flagged]

Re: Serverless: slower and more expensive

#247
I disagree with most of the comments here.

Right now, you can build much much quicker and with a less skilled team using serverless than traditional servers. This is very very important.

Serverless is not static and stuck in time, it's going to change and become cheaper over time as competition increases. Pretty soon everyone except already built products and large businesses will be using serverlesss architecture. The barriers to entry of building a website will be so low, you would be an idiot not to use serverless.

Re: Serverless: slower and more expensive

#248

I thought commenter W. Van Dam made some good points: “ First, you don't need API Gateways if you use an AWS SDK. Like this guide shows. And of course you don't need a load balancer, because that's precisely one of the things that serverless takes care of for you :-) More importantly, you didn't actually compare serverless to your current situation. With serverless solutions you can typically save cost in terms of se…

You can do the same thing with Lambda @ Edge and CloudFront for .60 per million requests and there is a free tier. ( https://aws.amazon.com/lambda/pricing/ )

Yeah I just wanted to point out like the authors whose post I copied here that the way of going serverless taken by the story author was probably not ideal.

Re: Serverless: slower and more expensive

#249
post #237
post #137

Earlier quoted context omitted.

"No because Lambdas are proprietary which means you can't run it in a CI or locally." It kinda is, but not really. You get an event object as param and often only need a few fields from it. Also, you can run Lambda locally, AWS SAM CLI lets you run them in Docker for debugging purposes.

I found SAM to be extremely difficult to use, especially on windows where docker is just plain old terrible.

True.

I stopped using windows for dev machines long time ago, but I'd guess with the Linux subsystem stuff it will catch-up in the next years.

Re: Serverless: slower and more expensive

#250
post #112

Earlier quoted context omitted.

Is there any fundamental reason for this, apart from AWS' pricing model? It seems to me that ideally, serverless should scale from extremely small to very big without too many problems.

You're basically hiring an AWS devops position since you don't need to manage anything yourself. Great for the small startup but not so great for the already established enterprise that has some devops guys anyway.

An AWS DevOps should be able to manage a lot more than one company's lambdas. That's one of the big reasons the cloud can save money. I don't see why it would be different for serverless setups.
Post reply on HN