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

321–330 of 733 posts

Re: Serverless: slower and more expensive

#321

Post by nailer »

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…

> > Writing a function in node 12 and then running it on node 4 and throwing your hands in the air cos it didn’t work isn’t the fault of Lambda.

> It's great to see that factual evidence is answered with ad-hominem by the Lambda hype crowd.

I don't think that was a personal attack.

We've answered technical questions with technical answers.

- You have a definition of stateless which includes having no persistence layer, which is at best at odds with the industry.

- You think serverless was created with AWS Lambda which we've been kind about, but most people would say you're simply wrong.

- You're advocating for containers, which are well known for having their own hype as people write their own cloud providers on top of the cloud provider their employer pays for with dubious benefit.

Re: Serverless: slower and more expensive

#322

Post by falcolas »

ShinTakuya wrote: post #80
cuu508 wrote: 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.

Low latency for 1m requests in one second? Yeah, Lambda won’t help you with that. Their cold starts will stop you dead. Particularly if you’re in a VPC and they have to allocate servers with the appropriate ENI. Not to mention, you’ll be hitting concurrency limits.

Sure, if you ping your lambdas frequently to keep them from having cold starts, and you’ve worked with Amazon to increase your concurrency limits 100 fold, you might be able to handle 1M requests in a second. But then you’re being charged a lot more than just for those 1M requests.

Re: Serverless: slower and more expensive

#323

Post by CapmCrackaWaka »

rdsubhas wrote: post #114

This is how a conversation with a colleague who were enthusiastic about Serverless, and who's company was mostly on Java/JVM stack went: Colleague: Lambda is awesome, we can scale down to zero and lower costs! We love it! We use cool tech!! Me: What did you do about JVM warm up? Colleague: We solved it by having a keepalive daemon which pings the service to keep it always warmed up. ... Me thinking: Uhh, but what abo…

> ... Me thinking: Uhh, start small and STAY SMALL?

This does happen. We have a serverless API forwarding service on Azure that was designed to simply format and forward calls from a vendor. We know the volume, there will not be any surprises, and it is immensely profitable over the old solution to the tune of thousands of dollars per day. Our use case is probably pretty uncommon, however.

Re: Serverless: slower and more expensive

#325

Post by nfRfqX5n »

lovetocode wrote: post #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 the…

lambda is perfect for high volume bursty traffic. you will never have to worry about a server being overloaded or going down.

Re: Serverless: slower and more expensive

#326

Post by spamizbad »

tus88 wrote: post #164
cryptica wrote: post #17

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.

The only application where I've found serverless to work well is for simple plumbing/event sourcing in AWS. They are less apps and more "tiny scripts that automatically run". 99% of the work is still done in containers on actual servers. The serverless portion is by far the least "developer ergonomic" but that's not a problem if your code is less than a hundred lines and rarely subject to changes.

The idea of running your entire app as serverless sounds like pulling teeth. Thought leaders are free to pat each other on the back on that one... I won't mind being called a luddite.

Re: Serverless: slower and more expensive

#328

Post by coldtea »

0xbadcafebee wrote: post #171
coldtea wrote: post #138

Earlier quoted context omitted.

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…

>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 you're doing a toy demo app, or a website for your local flower shop, yes...

Any non trivial company's systems are not just some random container with a "Nodejs app" inside. They need to keep state, handle caching, redundancy, global CDNs, and lots of other layers.

You either build all those and full ops on top of containers (or whatever), or you get them off the selves and ready to play with a serveless service and their state solution, plug-and-play ready-to-use caching layer, and so on...

Re: Serverless: slower and more expensive

#329

Post by 1337shadow »

k__ wrote: post #244
ainiriand wrote: post #219

Earlier quoted context omitted.

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.

AWS Lambda made both deployment and development a pain, even though the decision to use that platform for their use-case (a regular API) was just one of the mistakes done by a team that was brainwashed by expensive marketing and then paid the price for having only cheap and proprietary tools for development and deployment at their disposal.

If only AWS was open source, then we could have deployed our own cognito and lambda instances to develop locally, instead of the open source mocks that didn't pass the field test in my opinion: lack of quality, maintenance, documentation were critical factors.

Re: Serverless: slower and more expensive

#330

Post by 0xbadcafebee »

claudiusd wrote: post #311

I did the same experiment as OP and ran into the same issues, but eventually realized that I was "doing serverless" wrong. "Serverless" is not a replacement for cloud VMs/containers. Migrating your Rails/Express/Flask/.Net/whatever stack over to Lambda/API Gateway is not going to improve performance or costs. You really have to architect your app from the ground-up for serverless by designing single-responsibility mi…

> You really have to architect your app from the ground-up for serverless by designing single-responsibility microservices that run in separate lambdas, building a heavy javascript front-end in your favorite framework (React/Ember/Amber/etc), and taking advantage of every service you can (Cognito, AppSync, S3, Cloudfront, API Gateway, etc) to eliminate the need for a web framework.

At least I don't have to learn that complex "systems admin" stuff.

Post reply on HN