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

151–160 of 733 posts

Re: Serverless: slower and more expensive

#151

Post by darkwater »

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 too (financial and emotional)

Re: Serverless: slower and more expensive

#152

Post by edw »

coldtea wrote: post #146
goatinaboat wrote: post #141

Earlier quoted context omitted.

1 programmer/ops guy can do what it took 10 before. The myth: devs are expensive and hardware is cheap The reality: webdevs are a commodity and AWS is making record profits

The real reality: not all devs required are webdevs, especially if you want to build an infrastructure that can handle millions of people worldwide. It's not like some React and CSS will get you that. The amount you'll pay for a single additional developer, even if it's "just" 70K, is already close (if not double) your whole Clould costs when you start...

Yes. And there’s also the issue that even if someone would choose to work for free, incremental bodies in an org tend to increase the org’s complexity.

Re: Serverless: slower and more expensive

#153

Post by tedk-42 »

skrebbel wrote: post #129
tedk-42 wrote: 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…

> I'm in the container camp Can anyone explain to me why there's "camps" to this debate?

I'd say modern API deployments are either containerised or go the serverless route.

On one hand you have a docker image with your source code/static binary baked in. The other you have your source code/binary encapsulated in a serverless framework (with an Event handler of sorts as your input).

The container doesn't lock you into a particular ecosystem, but hasn't solved how you deploy and run your container (Heroku, managed k8s, AWS ECS/EKS/Fargate). Serverless on the other hand will give you a runtime for your API and allow you to go live (assuming you've setup an account or whatever).

To migrate something that already works to serverless is a bad idea. Maybe if you're pretty comfortable with serverless frameworks and you like to hack a lot of projects up quickly, sure serverless might be a good fit. But why not instead start off with a container? At least you have the flexibility to run that on whatever you damn want - Even a t2.small instance with a docker daemon running.

Re: Serverless: slower and more expensive

#154

Post by tedk-42 »

dunk010 wrote: post #28
tedk-42 wrote: 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…

> I'm in the container camp because serverless isn't cheap and you can't have long running processes. Do you think you'll have the same opinion in five years time? Or how about three years?

Containers will be around for at least another 5 years.

If you look at where AWS makes most of their money, it's selling EC2 hardware.

Re: Serverless: slower and more expensive

#156

Post by tedk-42 »

discordance wrote: post #19
tedk-42 wrote: 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…

>The whole idea of serverless is so you don't have to manage infrastructure That's one of the ideas. Serverless shines for burst-y traffic where the traffic timing is unknown. If I had known static high loads I wouldn't use serverless.

Burst traffic with high writes? --> Use a stream. Burst traffic with high reads? --> Use a cache.

Large compute and memory intense stuff isn't suitable for serverless

Re: Serverless: slower and more expensive

#157

Post by KuhlMensch »

There are many even-handed comments here. But I feel a few might be influenced by "relief bias".

As in:

> phew! that Serverless stuff turned out to be pure hype, lets dump on it and destroy the hubris of human-kind

But that is just not the case, serverless is a legitimate option. I've seen it work (increasingly well) at various companies.

I will also say, I'm loving the comments here that are trying to boil down the core-principles to follow to achieve serverless success. Great stuff.

Re: Serverless: slower and more expensive

#158

Post by tiborsaas »

jokoon wrote: post #18

I don't understand the term or brand "serverless", to me it seems it's still using a server, meaning a fast computer somewhere running 24/7 in a datacenter. To me "serverless" implies decentralized networking, with a DHT or some kind of network authority, meaning P2P networking at one point or another. Am I missing something?

It's a misnomer, but the underlying idea has lots of valid uses.

Re: Serverless: slower and more expensive

#159

Post by LunaSea »

philliphaydon wrote: post #147
LunaSea wrote: post #143

Earlier quoted context omitted.

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

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 returns a resized and compressed version of it. This is done using Node.js and the mozjpeg module which is dependent on cjpeg which is built natively on install.

If I test my function on my machine and in Lambda it's very possible that I get different results.

Also, certain OSs like Alpine which are heavily used for Docker don't event use glibc as compiler, so again, another difference.

Re: Serverless: slower and more expensive

#160

Post by jfoster »

icebraining wrote: post #109
Jack000 wrote: post #27

Earlier quoted context omitted.

isn't that just a limitation of the current incarnation of serverless systems? ie. serverless is only effective for burst traffic because it's expensive. You would think that after you tailor the code to the platform and make it stateless, it would cost less for the cloud provider and not more.

If Amazon has to dedicate a full server permanently to your applications, I don't see why it would cost them more or less depending on the statelessness of your application.

Are you sure your assumption that Amazon still has to dedicate a full server permanently to the application is correct?
Post reply on HN