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

441–450 of 733 posts

Re: Serverless: slower and more expensive

#441

Post by bmm6o »

dullgiulio wrote: post #150
nailer wrote: post #89

Earlier quoted context omitted.

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

Just to be clear: lambdas are not stateless if you, for example, connect to a DB or use any other external service. State could be somewhere else, but if you are not also "pure", you don't have any improvement over a normal service.

That's not what I've understood "stateless" to mean. Sure, anything more complicated than a calculator app is going to rely on data stored elsewhere, and in Lambda world that means you're reading from DynamoDB, S3, RDS or whatever. Those are definitely dependencies and that's where the state lies. But the pattern encouraged by Lambda is that your instance contains no state of its own. The disk is used as scratch for each invocation, objects are created for each request and not shared between them, etc. That's what people mean by stateless.

Re: Serverless: slower and more expensive

#442

Post by speleding »

maccam912 wrote: post #367
missosoup wrote: post #300

Earlier quoted context omitted.

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

I like serverless for my own use cases, but I don't usually comment about it. People would probably not be interested. I have an HTTP call happen once every five minutes or so and just record the response. Thats it. About 100 ms of time. I would be paying more if I just had an always-on server doing this type of work. The sentiment we normally hear on HN is from people who really love or really hate something. I appr…

Hear, hear. I have a use case where I need to run some data extraction a few times a week that takes a few minutes and a few GB RAM to complete. I could simply squeeze it in on one of our other servers but that means the whole setup there would get slightly less elegant and would pollute the logs with weird load spikes.

Lambda is just perfect for such a use case, and the number of processing minutes makes it almost free.

Re: Serverless: slower and more expensive

#443

Post by falcolas »

orasis wrote: post #355
falcolas wrote: post #322

Earlier quoted context omitted.

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…

Cold starts for node are ~500ms.

Add a couple of seconds when spinning up an ENI. New nodes in a VPC are around 3 seconds (and our last EBC with Amazon indicated that it won't get lower than that for awhile). It's worth noting that this impacts ECU scaling for Aurora Serverless as well.

Why would you need to put a Lambda in a VPC? For access to a database, other EC2 bound resources, or overall network security reasons (such as outbound network monitoring).

Re: Serverless: slower and more expensive

#444

Post by iforgotpassword »

tgeek wrote: post #347
missosoup wrote: post #300

Earlier quoted context omitted.

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

Hi there, Hey there, I lead Developer Advocacy at AWS for Serverless ( https://twitter.com/chrismunns ). I'll give you that this 80% number seems pretty out there. I don't know how that is measured or what it would be referencing. If you step back and remove all the commercial software from the argument (something like 50%+ of enterprise workloads, the kind of things you buy from a 3rd party and just run it, like Sha…

> In terms of HN sentiment and in being a member of this community for almost a decade, I don't know if I'd say it widely represents most of the dev world as it tends to lean way more open-source and less enterprisey.

They also like to join the latest hype more often than not so that should even out the anti-enterprise sentiment. I don't think serverless is over that point yet.

General opinion regarding the topic: I haven't done serverless in any way yet, but if it's similar to "regular"/other cloud services then in my experience it only makes sense of you're so big that building a scalable infrastructure yourself is too expensive (unless you're Facebook or Google). The other use case is if your load is actually fluctuating a lot, to a point where having enough resources available just to handle the peaks at all time is too expensive.

Whenever you can somewhat predict your load, having your own infra is almost always less expensive (at least here in Europe/Germany).

Re: Serverless: slower and more expensive

#445

Post by munns »

kurige wrote: post #440
shiftpgdn wrote: post #412

Earlier quoted context omitted.

Kinda wild in your post history you're advocating for AWS as a cheaper superior platform without disclosing that you work there.

Maybe that's how he got the job.

No. I've been at AWS for over 7 years in a few different roles. Came to the serverless space >2.5 years ago because I felt passionate about it (could have literally done almost anything). Again, sorry for mis-posting under my older personal account, it was rarely used fwiw.

Re: Serverless: slower and more expensive

#446

Post by richmarr »

mytailorisrich wrote: post #397
kstrauser wrote: post #365

Earlier quoted context omitted.

An example of where serverless is lovely for us : We run on AWS. We log lots of stuff to CloudWatch. CloudWatch allows you to scan for regexps (more or less) and send matching lines to a destination of your choosing. There are about 5-10 such matching events per day that we care about, and when they happen, we want an alert in a Slack channel (or email or text or PagerDuty or...). Option A: Stand up a server. Deploy…

If you have spare capacity on a server you can probably squeeze in such functionality at no extra cost.

> ...at no extra cost

Complexity and dependency are costs too, and I would argue often more significant costs than the $30/month to run a server.

Re: Serverless: slower and more expensive

#448

Post by miguelmota »

Serverless is simply not worth the premium cost for convenience. It's get expensive if using it for serving APIs with decent traffic. Serverless however is good for low volume one-off requests that you can compose together. For example a lamda function to resize an image which then calls another lamda function to put it in a S3 bucket which then calls another lamda function to trigger a notification. Each function just does one thing and does it well.

Re: Serverless: slower and more expensive

#449

Post by staticassertion »

missosoup wrote: post #300
tus88 wrote: post #164

Earlier quoted context omitted.

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

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

Every time something sympathetic to a "hyped" technology is posted it's largely derided for being the "popular, hyped" option. MongoDB absolutely ruined the idea of NoSQL for years because everyone just meme'd about "webscale", without being willing to consider that maybe there's merit to the technology.

Are you seriously doubting that lots of people are moving towards serverless infrastructure?

Even internally at big companies they use "serverless-like" models eg:

* Lots of big companies have an internal FaaS

* Those FaaS are owned and managed by other internal teams, and are treated in much the same way as how you'd treat a 3rd party offering.

Serverless just outsources what those companies are doing already.

I leverage AWS lambdas almost exclusively. Yes I am paying a higher price for worse latency. That's OK. I'll pay money for that, if what I get in return is a managed hardware, os, and runtime environment - problems that generate billions of dollars in revenue for many different companies that are working on making it easier.

Performance is a problem I wish to address aggressively, but it's 3rd on the list. A rough approximation of my priorities might be:

1. Security

2. Complexity (including operational complexity)

3. Performance

Serverless gives me the tools to manage (1) and (2) in a way that has worked extremely well for me personally, and I have not found latency to be a problem for me.

Sadly, the site is down so I can not view the article and comment on things more concretely, however I saw the 8x figure and that's fine. 8x latency is fine for many workloads, but operational overhead isn't fine for mine.

edit: OK, so they just don't support HTTPS. It loads now. 8x cost, 15% performance. Cool.

Cool numbers and article, I appreciate what they're getting at. I don't see how you can walk away with "Serverless is all hype and never an option" from it, but whatever. I will once more point to the "Any time this comes up people bash it because 'hype bad'". The top voted comment currently is someone bashing serverless and contains literally no substance.

> Finally, I'm not trying to bash API Gateway, Lambda or serverless in general here, just showing that for some workloads they are a lot more expensive than boring old EC2 and Elastic Beanstalk

Really makes sense to me! Pick the right technology for your constraints. If serverless offerings like lambda could solve every use case AWS wouldn't need other services.

Re: Serverless: slower and more expensive

#450

Post by scarface74 »

cdelsolar wrote: post #418
scarface74 wrote: post #260

Earlier quoted context omitted.

Heroku is just an easier way to deploy to servers. It doesn’t scale down to zero, scale up as needed, etc. You still have distinct servers that you know about, can manage. S3, Fargate (Docker), DynamoDB, even SNS/SQS are considered Serverless by AWS’s nomenclature.

i'm not sure Fargate is considered Serverless.

“What is Serverless Architecture”

https://aws.amazon.com/lambda/serverless-architectures-learn...

https://aws.amazon.com/fargate/

AWS Fargate is a compute engine for Amazon ECS that allows you to run containers without having to manage servers or clusters. With AWS Fargate, you no longer have to provision, configure, and scale clusters of virtual machines to run containers

Post reply on HN