Live data from Hacker News

Serverless: slower and more expensive

einaregilsson.com

171–180 of 733 posts

Re: Serverless: slower and more expensive

#171

Earlier quoted context omitted.

Who would argue that? Why would you ever want to do 10 times something just because you do it once?

Well, the "You already have to manage patches for your app and its libraries, so OS (really container) patching is just another part of your patching strategy." is close to making that argument. Just because I have to manage patches for 'my app and it's libraries' doesn't mean also handling the OS and everything else that would already be covered by the serverless service is no biggie...

Literally the only other thing to maintain with a Fargate service is what container you run your tasks with. If you have a Nodejs app, use the public Nodejs container. If the container version ends up with a vulnerability, bump the version in the task definition, and do a rolling restart. This isn't some onerous, complex task that only the most cunning sysadmin can fathom. If that alone is what causes somebody to run Serverless I don't think they understand all the other complications that come with it.

Re: Serverless: slower and more expensive

#172

Earlier quoted context omitted.

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.

So possibly a good fit for IoT.

No. It depends on the IoT application. The one I'm involved with (smart metering) produces data at regular 15 minute periods 24/7.

This is a very predictable and constant traffic load and not at all suitable for serverless/lambda.

In fact, its the complete opposite.

Many IoT applications are very predictable (anything with regular sensor-readings for example or with repeatable patterns such as people returning from work and turning things on).

Re: Serverless: slower and more expensive

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

How did you replace a site that needed rds with s3? Was it a blog that you moved to Jekyll or something?

Re: Serverless: slower and more expensive

#175

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…

Why not then have lambda run the same container you can run and test locally?

I don't use lambda but we have our jenkins spin up the same ec2 to run tests that we would spin up to do development so that we never run into this problem.

Re: Serverless: slower and more expensive

#176
There are valid points in the article. But the author seems enraged that he is charged $35 for 10M API calls per day (his main complaint). He knew (or should have known) that he needs in the ballpark of 10M API calls per day and the pricing explicitly calls out $3.50 per million API calls. This may or may not be a lot (probably is), but he should not be surprised. Before any purchase, check the price. My 2c.

Re: Serverless: slower and more expensive

#177
A big part of the savings would come from reducing the operational overhead of managing instances. Serverless is turnkey and doesn’t require any ops personnel, or skills. Even k8s requires a lot of TLC to get proper scaling and do upgrades and rolling deployments without downtime.

Re: Serverless: slower and more expensive

#178

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…

Why not then have lambda run the same container you can run and test locally? I don't use lambda but we have our jenkins spin up the same ec2 to run tests that we would spin up to do development so that we never run into this problem.

I'm not sure I understood your question correctly.

If you mean running a Docker container in Lambda, that is to may knowledge to possible. You could schedule Docker tasks in AWS ECS (their managed container service) but it's not meant for anything realtime and more for cron job type tasks.

If you mean emulating the Lambda environment in Docker, then I wrote an answer with the difficulties of doing that below to another user.

Re: Serverless: slower and more expensive

#180
Serverless - not efficient. Cloud computing - More resource usage and lot of intermediate agents. Client - server model - Server needs to be up all time. More traffic.

Standalone / Primitive softwares - Uses computing power for running business.

No software - Better humanity. Lets evolve biologically than just 0s and 1s.

Post reply on HN