Live data from Hacker News

Serverless: slower and more expensive

einaregilsson.com

161–170 of 733 posts

Re: Serverless: slower and more expensive

#161

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…

I think you are right with your assumption that Docker images that don't resemble the production environment aren't sufficient to test.

But isn't the idea of Docker that you can recreate the production environment? If you can't why use Docker in the first place?

Re: Serverless: slower and more expensive

#162

Finally reality is catching up to the hype. I was saying this 3 years ago. Tech should be about results, it should not be a religion. We should accept that most famous CTOs, engineers and other "thought leaders" are not geniuses (also, they're often corrupted by financial interests) and we should not outsource our decisions to them. To innovate, we need to start thinking independently and make our own rational assess…

Agreed.

~2 years ago I seriously looked into Serverless and very quickly discarded it after seeing a large production deployment of it. I didn't have access to the billing info but the site loaded much slower than a regular site and developer productivity was quite low.

I'm going to stick with good old servers for now. If anyone is curious, a few years ago I did a write up on "Should your next project be built as a Serverless app?" which compares deployment styles in a bit more detail: https://nickjanetakis.com/blog/should-your-next-project-be-b...

Re: Serverless: slower and more expensive

#163
post #39

Earlier quoted context omitted.

Bursty or not, if the aggregated number of requests per day is in millions not hundreds, AWS API Gateway & Lambda is significantly more expensive than the more traditional options.

Not if you have to serve 1 million requests in one second (with low latency) and then don't get any requests for the rest of the day. On the contrary, traditional options will probably end up costing a lot more since you'll need to have them ready in advance to serve the requests instantly and so you could be paying for the entire day of capacity or at least several hours.

All Lambda does is spin up a bunch of containers to handle that. Why is that any different than traditional options? You would just horizontally auto scale in the exact same way. You don't HAVE to pre-provision anything.

Plus, receiving 1 million requests in one second, you'll have cold starts for every new container that gets created for you, so achieving consistent low latency would be impossible since you don't control that.

Re: Serverless: slower and more expensive

#164

Finally reality is catching up to the hype. I was saying this 3 years ago. Tech should be about results, it should not be a religion. We should accept that most famous CTOs, engineers and other "thought leaders" are not geniuses (also, they're often corrupted by financial interests) and we should not outsource our decisions to them. To innovate, we need to start thinking independently and make our own rational assess…

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.

Re: Serverless: slower and more expensive

#165
Our company has customers who install our SDK, and that SDK pushes and pulls data from our service.

We service ~400 million API calls per month. Half of the calls pull static cached data from a CDN (Cloudfront), and the other half ingests data pushed to it from the SDK (anywhere from 10kb to 400kb per call).

We run of Elastic Beanstalk, which is basically an abstraction later on top of an autoscaling EC2 cluster.

Back when Lambda (and API Gateway) first came out we were excited. It sounded like the perfect way to break free from our “legacy” server architecture.

Until you do the pricing calculations. It wasn’t even close. Managed services like Lambda and API Gateway were prohibitively expensive. (Thank god we didn’t begin development with the services before scaling - we would have never been able to scale at those prices).

Not only price, but performance was horrible. Lambdas take forever to warm up (unacceptable for latency sensitive use cases).

I’ve never really thought of Lambda / API Gateway as anything other than a cool pet toy. Although maybe thats being a little harsh..?

Re: Serverless: slower and more expensive

#166

It's concerning how typical the hype machine is in IT. I believe Serverless has its place and value. So does Kubernetes or many other products that are often discussed on HN. But let's be clear, we are talking about commercial products and there is a capital interest in selling these services to all of us devs and engineers. So while use cases exists and benefits wait to be reaped, as a consultant I strongly feel tha…

> correct me if wrong

Stack Overflow is built on ASP.NET: https://stackoverflow.blog/2008/09/21/what-was-stack-overflo...

Re: Serverless: slower and more expensive

#167
post #12

I disagree with all the comments posted so far. This should be a perfect use case for lambda, not "oh you're API is receiving more than 10M req/day? Use Elastic Beanstalk instead with an EC2 instance and ELB". This kind of comment is just to abuse the free tier that AWS provide you with. The whole idea of serverless is so you don't have to manage infrastructure. OS patching, mucking around with Docker and and port fo…

Exactly. Like anything, right tool for the right job.

I was hosting my personal website on EC2 with an RDS instance and it cost around $20/month. But since the site gets little-to-no traffic and I got sick of EC2 upkeep, I switched S3 & Cloudfront: now my bill is $0.80/month.

Another example: at work we inherited an old EC2 instance that was set up solely to run cron jobs on other servers. Occasionally it would lock up or go down, for whatever reason, creating chaos for the servers that needed specific jobs run frequently.

We switched to AWS Lambda functions for those cron jobs and they've never failed once.

If you're running a games website that gets pinged 24/7, don't use Serverless. But the notion that it's slow and overpriced is misguided if you're applying the wrong use case.

Re: Serverless: slower and more expensive

#168
post #164

Finally reality is catching up to the hype. I was saying this 3 years ago. Tech should be about results, it should not be a religion. We should accept that most famous CTOs, engineers and other "thought leaders" are not geniuses (also, they're often corrupted by financial interests) and we should not outsource our decisions to them. To innovate, we need to start thinking independently and make our own rational assess…

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 suspect if you were to put "your money where your mouth is" those 80% of yours would turn into 20 or less. ;)

Re: Serverless: slower and more expensive

#170
post #161

Earlier quoted context omitted.

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…

I think you are right with your assumption that Docker images that don't resemble the production environment aren't sufficient to test. But isn't the idea of Docker that you can recreate the production environment? If you can't why use Docker in the first place?

You are absolutely right that you could recreate a similar environment to Lambda in Docker. But you would first need to reverse engineer Lambda's environment to discover how it is actually configured and the limits that are set.

Even if you did find a way, you would still need to keep it up to date in case AWS decides to update that environment.

Post reply on HN