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

81–90 of 733 posts

Re: Serverless: slower and more expensive

#81

Post by guiriduro »

aserafini wrote: post #36
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 think the problem is that moving from Lambda/FaaS to a container-centric alternative (ECS and friends) requires a complete re-architect of your stack. Whereas starting with a simple, single container solution and organically evolving that into container-orchestration is much simpler - because the fundamental building block hasn't changed. It's all just containers. Personally I'd like to see the industry coalesce on…

Aren't there abstractions to reduce the impedance mismatch between serverless offerings, e.g. Serverless (javascript framework)[1], which should allow easier portability to self-hosted solutions - openfaas or openwhisk etc - including running in containers on more traditional infrastructure, which is cheaper for this particular scale and use-case?

Sure, they're still FaaS which seems to be the unit of deployment for the serverless movement. For (hidden) managed server container deployment, Fargate is the offered solution I believe.

[1] https://serverless.com

Re: Serverless: slower and more expensive

#82

Post by pojzon »

einaregilsson wrote: post #64
aserafini wrote: post #36

Earlier quoted context omitted.

I think the problem is that moving from Lambda/FaaS to a container-centric alternative (ECS and friends) requires a complete re-architect of your stack. Whereas starting with a simple, single container solution and organically evolving that into container-orchestration is much simpler - because the fundamental building block hasn't changed. It's all just containers. Personally I'd like to see the industry coalesce on…

> requires a complete re-architect of your stack. Not necessarily. The reason I decided to try this was exactly because I found a tutorial showing you could easily host a bog-standard ASP.NET web app on Lambda with the serverless framework. I had to add a small startup class, and one config file to our existing app and I was up and running.

Recently we had to test a posibility of our core application being hosted in contenerized environment. It was really hard, because some tweaks we used are not really documented well. Kernel Tweaks had to be tested separately because we were not sure whether they work or not, recource management had to be done from zero level. JVM optimalizarion from zero level. Service Discovery configuration from zero level. --- Sure it works from the go for punny small apps. But when it comes to huge corporations running extrordinary workloads - no its not that easy.

Re: Serverless: slower and more expensive

#83

Post by laumars »

coldtea wrote: post #69
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…

> We should accept that most famous CTOs, engineers and other "thought leaders" are not geniuses (also, they're often corrupted by financial interests) That goes without saying! That said, serverless might be 2x slower and 8x more expensive, but all that would be irrelevant if it's e.g. 10x easier, so that e.g. 1 programmer/ops guy can do what it took 10 before. I don't think anybody uses things like AWS or serveless…

> That said, serverless might be 2x slower and 8x more expensive, but all that would be irrelevant if it's e.g. 10x easier, so that e.g. 1 programmer/ops guy can do what it took 10 before.

Lambda can often actually add to development time because it takes more work to test locally and remote testing adds significant time to the write/test cycle.

Other forms of serverless might save time. However there's always edge cases where they don't and you can lose hours or even days investigating an issue that would be a quick fix if you actually managed the host and/or application.

So the short answer is: not always faster nor easier. It really depends on what you're trying to accomplish.

> I don't think anybody uses things like AWS or serveless services because they're faster or cheaper...

Actually yes they do. But like my previous answer, it depends on what you're trying to accomplish.

This is the problem with serverless (and cloud computing in general). People try to distil it down to "this is better for x" and "that is better for y" but actually the benefits and trade offs are far more granular than that. To the extent that you could have two companies in the same sector releasing competing products and still what architecture makes sense for one company might not for the other.

This is also why nobody ever agrees about these topics online - by the time you've generalised the examples enough to describe them in a forum post, they lose the specificity that makes any accurate design possible.

Re: Serverless: slower and more expensive

#84

Post by EwanToo »

einaregilsson wrote: post #65
EwanToo wrote: post #14

Earlier quoted context omitted.

Yes, it would be a much less dramatic headline if they'd used an ALB instead of an API Gateway, it shows the complexity of the AWS product offering though that someone picking up lambda for the first time didn't find this out. They already have a classic ELB in place, so switching to an ALB wouldn't be a significant change in cost or capability (the ALB is often cheaper, though it's hard to tell in this case)

Yes, ALB would have been a much better fit for us. We used API Gateway because that's what the serverless framework sets up (at least by default) and I didn't know you could use ALB in front of Lambda.

Yes, it does show there's a gap in the documentation, hopefully someone from AWS will pick this up (and the serverless framework has only just added ALB support a couple of months ago)

Re: Serverless: slower and more expensive

#85

Post by Multicomp »

laumars wrote: post #72

It's not as clear cut as the article describes though. For low usage stuff serverless is cheaper. For "spiky" traffic - particularly when those spikes are unpredictable - serverless is often cheaper and sometimes faster too (eg if your spikes ramp up quicker than the spin up times of virtual machines). Also AOT compiled languages like C# will run slower on lambda than pre-compiled on an EC2. You shouldn't need benchm…

> AOT compiled languages like C# will run slower on lambda than pre-compiled on an EC2. You shouldn't need benchmarks to work that much out - it's software development 101. However (if) you then went on to compare JIT compiled languages on lambda vs EC2 you'd notice the performance is much closer to each other.

But that is what the author did. C# is not 'fully' AOT, it is JITed into MSIL on .net CLR, at least under normal circumstances. Does elastic beanstalk use .net native style binaries somehow?

Re: Serverless: slower and more expensive

#86

Post by avip »

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…

There are enough results to prove that serverless is useful (may I say, correct) architecture in many use cases. Not everyone is dumb, contrary to a common belief. Don't be religious.

Re: Serverless: slower and more expensive

#88

Post by atroche »

abiro wrote: post #50

PSA: porting an existing application one-to-one to serverless almost never goes as expected. Couple of points that stand out from the article: 1. Don’t use .NET, it has terrible startup time. Lambda is all about zero-cost horizontal scaling, but that doesn’t work if your runtime takes 100 ms+ to initialize. The only valid options for performance sensitive functions are JS, Python and Go. 2. Use managed services whene…

The Rust runtime has a fast start time as well, FWIW.

Re: Serverless: slower and more expensive

#89

Post by nailer »

holografix wrote: post #48

Disclaimer: I work for Salesforce, Heroku’s parent organisation. I have had so many conversations with devops managers and developers who are individual contributors and the Lambda hype reached frothing levels at one point. Contradictory requirements of scale down to zero, scale up infinitely with no cold starts, be cheap and no vendor lock in seemed to all be solved at the same time by Lambda. Testability? Framework…

> Testability?

Serverless is specifically a stateless paradigm, making testing easier than persistent paradigms.

> Framework adoption?

Generally we use our own frameworks - I do wish people knew there was more than serverless.com. AWS throw up https://arc.codes at re:Invent, which is what I'm using and I generally like it.

> Stability? Industry Skills? Proven Architectures...?

These are all excellent questions. GAE, the original serverless platform, was around 2010 (edit: looks like 2008 https://en.wikipedia.org/wiki/Serverless_computing). Serverless isn't much younger than say, node.js and Rust are. There are patterns (like sharding longer jobs, backgrounding and assuming async operations, keeping lambdas warm without being charged etc) that need more attention. Come ask me to speak at your conference!

Post reply on HN