Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Serverless: slower and more expensive

einaregilsson.com

Post reply on HN
Print view View original

231–240 of 733 posts

Re: Serverless: slower and more expensive

#231

Post by cle »

188201 wrote: post #220
tus88 wrote: 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.

I really doubt not managing servers is an advantage other than initial launch for MVP or some simple webhook. The overhead of managing API gateway, monitoring and log in a more large scale serverless application is larger than managing several linux servers.

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.

Re: Serverless: slower and more expensive

#232

Post by icebraining »

jfoster wrote: post #160
icebraining wrote: post #109

Earlier quoted context omitted.

If Amazon has to dedicate a full server permanently to your applications, I don't see why it would cost them more or less depending on the statelessness of your application.

Are you sure your assumption that Amazon still has to dedicate a full server permanently to the application is correct?

If you application, due to the requests it receives, consumes enough CPU time to occupy all the cores available in a server and/or most of its RAM, how can they not?

Re: Serverless: slower and more expensive

#233

Post by im3w1l »

AdrianB1 wrote: post #57
dunk010 wrote: post #26

Lambda is too expensive at the moment, sure. But I think we all know that the costs will, over time, go through the floor, and in 5 years time nobody will want to create server software using anything else.

Predicting the future is a job for fortune tellers, not developers. Being sure about what will be the cost in 5 years is beyond fortune telling. Based on what I know, my company will continue to have on-premise servers and all the companies in the sector will continue to do the same. "server software" is not just Internet software, the world is larger than that.

I disagree. Whether it's a good design depends critically on what the future holds. Will costs go through the floor? We should, and can predict this.

What does it cost to host lambdas? Not a lot. So we are good from that PoV.

Will it be commoditized, or will there be crazy markups? Can any random guy set this up? If you really want to check this, try setting one up yourself and see if there are any roadblocks. (I didn't)

Re: Serverless: slower and more expensive

#234

Post by jerf »

LunaSea wrote: post #159
philliphaydon wrote: post #147

Earlier quoted context omitted.

Nothing you mentioned has anything to do with the ability to test a Lambda. You’re trying to use limitations and restrictions as friction to backup your inability to test. There’s a lot of annoying things about lambda. And a lot of stuff I wish was easier to find in documentation. But that doesn’t change the fact that Lambda is more or less passing an event object to your function and executing it. Writing a function…

It's great to see that factual evidence is answered with ad-hominem by the Lambda hype crowd. In any case, if you have a Node.js module or code with a native C/C++ build, that runs shell commands, that writes to disk (not allowed besides /tmp in Lambda) or makes assumptions about the OS, your "simple" function will absolutely return different results. e.g: My lambda is called when somebody uploads an image and return…

"In any case, if you have a Node.js module or code with a native C/C++ build, that runs shell commands, that writes to disk (not allowed besides /tmp in Lambda) or makes assumptions about the OS, your "simple" function will absolutely return different results."

This is true, but it's not Lambda qua Lambda. That's just normal production vs. testing environment issues, with the same basic solutions.

Lambda may offer some minor additional hindrances vs. something like Docker, but I wouldn't consider that catastrophic.

Re: Serverless: slower and more expensive

#235

Post by Bombthecat »

Uhhh did you check what a vserver costs on aws and compare it to digital Ocean? The cost increase is quit a too!

What you actually buy is abstraction and the need to not manage... Well everything beside code (in simple terms)... It is not an apple to Apple comparison...

Re: Serverless: slower and more expensive

#236

Post by michannne »

We had a requirement early on in our org where we had to split off long-running tasks to run asynchronously, while remaining painfully easy to test and deploy, configure, or swap out, as our dev team was not very comfortable with new technology and we had to move fast.

I looked in to Serverless before, and decided, then and now, it was wholly unnecessary, and I don't know when it will ever become necessary for our org. Azure already had what was necessary - Webjobs. I set up a simple event framework, drop some events into a DB, which get processed asynchronously by some Webjob. It's easy to run on local as it's just a console application, gets pushed to CI and again, is just a console application so it tests the same as other projects, is easily scalable, configurable, and it uses no new technologies.

I always look to see what pre-existing technology or paradigms are already existing that can accomplish the solution, and I found that serverless, in the idea the cloud providers employ it, is usually unnecessary

Re: Serverless: slower and more expensive

#237

Post by vips7L »

k__ wrote: post #137
LunaSea wrote: post #118

Earlier quoted context omitted.

> Serverless is specifically a stateless paradigm, making testing easier than persistent paradigms. No because Lambdas are proprietary which means you can't run it in a CI or locally. Also, it becomes stateful if it pulls data from a database, S3 or anywhere else on AWS which it almost always does. > Serverless isn't much younger than say, node.js and Rust are. AWS Lambdas which I consider to be the first widely used…

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

Re: Serverless: slower and more expensive

#238

Post by mbrumlow »

cle wrote: post #231
188201 wrote: post #220

Earlier quoted context omitted.

I really doubt not managing servers is an advantage other than initial launch for MVP or some simple webhook. The overhead of managing API gateway, monitoring and log in a more large scale serverless application is larger than managing several linux servers.

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 somebody else's server is not going to make the auditors happy.

Enterprise folks don't want to manage servers for a whole host of reasons. But I would say the number #1 reasons is they don't understand the cost, and the #2 is the management team has no clue what they are doing -- and probably running a play book somebody else wrote one time long ago that happened to work exactly once.

Re: Serverless: slower and more expensive

#239

Post by crtlaltdel »

x86_64Ubuntu wrote: post #224
scarface74 wrote: post #108

Earlier quoted context omitted.

You’re always locked into your infrastructure. People don’t willy nilly change their infrastructure once they reach a certain size any more than companies get rid of their six figure Oracle infrastructure just because a bushy tailed developer used the “repository pattern” and avoided using Oracle specific syntax. And the “lock-in” in lambda is over exaggerated. If you’re using lambda to respond to AWS events, you’re…

Do you have any resources on testing a Lambda? When I was fooling around with it, the only thing I ran into was that AWS Sam-client or whatever. Thing looked like an absolute nightmare to get up and running.

seriously, its a function. if you remove the aws/lambda specifics you _should_ have something testable that you then call from your lambda handler.

Re: Serverless: slower and more expensive

#240

Post by kolanos »

If your workload isn't sparse, then AWS Lambda has a complimentary service called AWS Fargate built on the same tech designed for more predictable workloads). Here's a comparison with AWS Lambda [0] and a crash course in setting up a load balanced web app on it [1].

[0]: https://read.iopipe.com/how-far-out-is-aws-fargate-a2409d2f9... [1]: https://read.iopipe.com/how-far-out-is-aws-fargate-part-2-e8...

Post reply on HN