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

291–300 of 733 posts

Re: Serverless: slower and more expensive

#291

Post by pm90 »

hnal943 wrote: post #246
dave_sid wrote: post #195

Earlier quoted context omitted.

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]

Socialism is an ideology though. It might sound similar but that’s it.

Every technology has a break in period where good ideas are badly implemented. It’s after you pass that initial stage and understand both the tech and how to implement and use it efficiently do you start to see the real gains of it.

Re: Serverless: slower and more expensive

#292

Post by dradtke »

wongarsu wrote: post #288
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.

Whenever I've spoken with engineers from AWS and Google Cloud they saw serverless as a platform for glue code, webhooks, cronjobs and the like. In that role it works great: you don't care if it takes 300ms to start and it's genuinely easier and cheaper than running that code on a server. But somehow in marketing materials and blog posts it's instead discussed as if it was a good idea to run everything serverless. May…

Wasn't it originally called Function as a Service? That seems to be a better name for its intended use-case than serverless.

Re: Serverless: slower and more expensive

#293

Post by tgeek »

Hey there, I lead Developer Advocacy at AWS for Serverless (https://twitter.com/chrismunns) and have been involved in this space since pretty much the start. Thought I'd toss my hat in the ring there as there seem to be some fairly passionate responses across the board here.

This post is accurate. It's accurate in the new dev experience of someone picking up a framework tool and following the standard walkthroughs/examples that folks like my team and I have been creating the past few years. As far as I'm concerned Einar (the author of the post) did everything I would have done in their position with their experience with this tech. The math Einar did also seems to be accurate given a 1gb RAM and Einar got feedback later on that they should have looked at ALB (Application Load Balancer) which does provide a different HTTP request interface back to a Lambda invoke. ALB is the right choice for dead simple proxy requests where you aren't using any of the more advanced features of API-GW. It would lower the cost significantly as well as increase the performance due to a slightly lesser overhead in request path. It would change both the numbers in the blogs title though I can't say it would be 1:1.

We've done a shit job of making this clear and thanks to Einar's post lighting the fire under our butts we'll make work to correct that.

What I am happy about in Einar's post is that they were able to get up and running in almost no time, explore, poke, test, and write this post about their experience very very quickly.

The other thing to highlight here is that I am happy to lose a battle to Elastic Beanstalk, or ECS, or Fargate pretty much any day of the week. All of these exist to significantly reduce the operator burden which compared to running your own container management can be incredibly high. Most companies I've run into in the past 7 years that I've been at AWS have struggled to really measure operator cost but when they compare it to just raw time difference both the technologies I just mentioned and "Serverless" tech like Lambda shift the time spent factor so greatly that cost savings becomes painfully obvious.

Anyway, we're here, we're listening, there's a lot going on behind the scenes (see recent announcement about how VPC cold-start pains will be gone soon).

Thanks, - Chris Munns - AWS - Serverless - https://twitter.com/chrismunns

Re: Serverless: slower and more expensive

#294

Post by crypteasy »

jedberg wrote: post #5

They're doing over 100rps if they're doing 10M requests a day. That's not a good use case for Lambda. If you're going to be that heavily utilized it makes more sense to run your API on EC2 or ECS/Fargate/etc. Lambda is a good use case for when you have lots of not-often-used APIs. Lambda is a great solution for an API that's called a few times a day. It's also great for when you're first starting out and don't know w…

I've always found Troy Hunt's tech stack of haveibeenpwned.com interesting. The API does 5M requests a day with Azure Functions and Cloudflare caching. Ultimately only costing him 2.6c per day.

https://www.troyhunt.com/serverless-to-the-max-doing-big-thi...

Re: Serverless: slower and more expensive

#295

Post by owenmarshall »

darkwater wrote: post #151
opsunit wrote: post #79

A comparison of Serverless to any kind of compute that uses line-item comparison and, crucially, doesn't mention Total Cost of Ownership (TCO) of the latter is flawed. To conclude that Serverless is more expensive one would have to compare the calculated TCO of managing EC2 against the line-item cost of Lambda. The article is also operating at the small change end of the spectrum where cost differences are basically…

This "TCO" thing usually comes out always from people interested in making companies migrate (i.e. consultants). Do you account into this TCO the time spent in retraining an gaining operational, production grade experience with serverless for all the teams involved? It's a one-shot cost, true, but it's a long one. And laying off perfectly capable employees because they are now redundant because serverless has a cost…

> Do you account into this TCO the time spent in retraining an gaining operational, production grade experience with serverless for all the teams involved?

Hopefully, or else it wouldn't be a total cost of ownership!

> And laying off perfectly capable employees because they are now redundant because serverless has a cost too (financial and emotional)

No doubt. But if your capable employees aren't providing value outside of "keeping the servers humming" there's a very good chance that someone is counting up their fully loaded cost and comparing it to bids from Accenture, Capgemini or Infosys.

I'm fairly ambivalent on the whole push towards serverless but arguments like this feel an awful lot like the pushback against virtualization vs. running bare metal.

Re: Serverless: slower and more expensive

#296

Post by gnrlst »

herf wrote: post #174

Lambda is the recommended way to host an Alexa Skill: https://developer.amazon.com/docs/custom-skills/host-a-custo...

It's the perfect use-case for it tbh. If you read the comments here, the pricey part of Serverless is API Gateway. With Alexa Skill development the Alexa service triggers your lambda directly, bypassing API Gateway. So it's really super cheap. I have built numerous skills and my bill is literally $0.00. Alexa also gives you $100 credits per month if you build & publish a skill..which is also free.

Re: Serverless: slower and more expensive

#297

Post by tomcam »

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.

> For the 80% or more, serverless works just fine.

Citation?

Re: Serverless: slower and more expensive

#298

Post by nailer »

LunaSea wrote: post #143
philliphaydon wrote: post #126

Earlier quoted context omitted.

> 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. Lambda is a function call. So it makes no difference if it’s proprietary or not. Are you saying that it’s difficult to test passing an object to a function and asserting that it’s functioning as intended?

Lambas are not simple functions because your environment is different in local compared to production. If I run a Node.js function in AWS Lambda, my Node.js version might be different, my dependencies might be different, the OS is different, the filesystem is different, so I or one of my node_modules might be able to write to /tmp but not elsewhere, etc. It's the reason people started using Docker really. If you don'…

> Node.js version might be different

Yes, in major only. Your lambda has node 10, you might be running 10.x or 10.y

> my dependencies might be different

No, the lockfile does that.

> the OS is different, the filesystem is different

Agree, but how much does one Linux+systemd different from other Linux+systemd? How much does the FS?

> It's the reason people started using Docker really.

VMs, docker and having to care about and manage isolation platforms is the reason people started using serverless.

Re: Serverless: slower and more expensive

#299

Post by SkyPuncher »

avip wrote: post #263
mbrumlow wrote: post #238

Earlier quoted context omitted.

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

But they do go away. They go straight away to a vendor which is very likely to address them faster, and with more competent resources, than you and your team (or, if that sound insulting - me and my team). They become covered with that famous someone else's problem field

> They go straight away to a vendor

This argument only works until you reach a certain size or security requirements.

At the end of the day, if it's critical to the business it doesn't matter what the paper says, you're still responsible for any damage to the business from a bad vendor.

----

It's just like car manufacturers, nobody cares that Takata was actually responsible for faulty airbags. They simply know their GM vehicle has a dangerous recall.

Re: Serverless: slower and more expensive

#300

Post by missosoup »

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.

> For the 80% or more, serverless works just fine.

Cite this. I don't believe you. I'm across a pretty broad slice of industry and can only draw on anecdotes from colleagues, but the majority of people with actual hands-on experience are disillusioned and say that the biggest (only?) drive for serverless at this point is top-down organisational pressure created by technically incompetent strategic management that looks to 'thought leaders' and Gartner to tell them what technologies to use.

if serverless works for 80%, then why is that 80% not even remotely reflected in the sentiment here? HN is usually a pretty good gauge for how the wider engineering community feels about a particular technology.

Post reply on HN