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

381–390 of 733 posts

Re: Serverless: slower and more expensive

#381

Post by Illniyar »

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…

Firebase now makes most of these painless. They've done a really good job. If your starting from the grounds up and can stomach using a google product Firebase is the easiest to work with by far.

Re: Serverless: slower and more expensive

#382

Post by innocentoldguy »

mfer wrote: post #221

Serverless has it's place. If you have lots of events and they don't fire all the time it's great. Or, for small additive things on a mostly static site (like one hosted out of s3). Or for some other specific cases. Serverless may change the landscape of development but it's going to take time. The costs need to settle into place while tools and processes need to come together. Right now it appears it takes longer to…

Serverless may work well for sites that don't have a lot going on or don't have a lot of traffic. In our case, Serverless could not handle the number of requests we were receiving nor could it handle the small compute job we handed it (zipping image files and pushing them to S3) at any kind of scale.

Even if Serverless performs well for certain sites, I think it is too much of a pain in the ass to set up for local development and deployment. There are better technologies out there that provide easier development setups and easier deployments that can also handle greater loads and compute needs. After using Serverless for the past year, I'm having a really hard time finding where it might make sense. It certainly doesn't belong in our tech stack and I would never reach for it again personally.

Re: Serverless: slower and more expensive

#383

Post by mypalmike »

LargeWu wrote: post #270
crtlaltdel wrote: post #239

Earlier quoted context omitted.

seriously, its a function. if you remove the aws/lambda specifics you _should_ have something testable that you then call from your lambda handler.

That works for unit testing a specific component, but not so well for testing your system end-to-end.

The need for a staging instance for integration testing doesn't disappear when you run your API in lambda.

Re: Serverless: slower and more expensive

#384

Post by ehsankia »

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…

Exactly, it's like saying to someone running a restaurant that buying their bottled water from a convenient store is more expensive than buying it in bulk from Costco.

It's entirely missing the point. At the end of the day, you have to look at your specific usage pattern and pick the best option for you. Obviously, as with any other technology, anyone who forces a specific option in every possible situation is most likely wrong.

Re: Serverless: slower and more expensive

#385

Post by cthalupa »

missosoup wrote: post #377
tgeek wrote: post #347

Earlier quoted context omitted.

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…

> And so for data processing/streaming/batch [...] serverless actually does work out pretty well. This is my field of expertise. Serverless in the sense of lambda/functions is not usable for serious analytics pipelines due to the max allowed image size being smaller than the smallest NLP models or even lightweight analytics python distributions. You can't use lambda on the ETL side and you can't use lambda on the que…

That article appears to be discussing a migration from Redshift to Clickhouse. Redshift is a managed data warehouse, not a serverless solution in the same vein as Lambda.

I don't understand the point you are trying to make.

Edit: The comment I am replying to was originally just 'Please explain' and a link to the article in question, and contained no other context or details.

Re: Serverless: slower and more expensive

#386

Post by scarface74 »

mywittyname wrote: post #316
scarface74 wrote: post #119

Earlier quoted context omitted.

Docker can also be serverless and gets rid of all the limitations of lambda - Fargate.

Fargate is not a replacement for Lambda. While there's some capability overlap, each have their own respective niches.

There is no reason that Fargate can not be a replacement for lambda.

There are three use cases for lambda:

1. Event based triggers where something happens externally that you want to process. You can do the same thing with Fargate by either having a continuously running process that reads from a queue or responds to an API request (AWS Event -> SNS -> API).

2. Timed events. You can do this with Fargate directly (https://aws.amazon.com/about-aws/whats-new/2018/08/aws-farga...)

3. APIs. Fargate supports autoscaling.

Fargate can do anything that lambda can do without the limitations - request and response payload size, a 10GB temporary storage drive instead of a half megabyte, and no 15 minute runtime limit. Of course no cold start times since you can have a minimum number of instances always running without Ping hacks.

Re: Serverless: slower and more expensive

#387

Post by bmm6o »

matthewbauer wrote: post #334
mywittyname wrote: post #266

Earlier quoted context omitted.

I've found unit testing to work fine for Lambdas. The biggest difference between running as a Lambda and running locally is the entry point. With a Lambda you have an event payload that (usually) needs to be parsed and evaluated. I'll typically write all the core functionality first, test it, then write the lambda_handler function.

But how do you test lamba_handler then? Without a way to run lambdas locally, this sounds like a big black hole in your infrastructure.

We deploy to a test stack and run a full integration test of the code running in AWS. I believe it's also possible to self-host locally, but we never really looked into it.

Re: Serverless: slower and more expensive

#388

Post by erikerikson »

x86_64Ubuntu wrote: post #224
scarface74 wrote: post #108

Earlier quoted context omitted.

You’re always locked into your infrastructure. People don’t willy nilly change their infrastructure once they reach a certain size any more than companies get rid of their six figure Oracle infrastructure just because a bushy tailed developer used the “repository pattern” and avoided using Oracle specific syntax. And the “lock-in” in lambda is over exaggerated. If you’re using lambda to respond to AWS events, you’re…

Do you have any resources on testing a Lambda? When I was fooling around with it, the only thing I ran into was that AWS Sam-client or whatever. Thing looked like an absolute nightmare to get up and running.

We created serverless-artillery[1] for testing end to end. As the bonus the load tests can then be used for acceptance and monitoring as well.

[1] https://github.com/Nordstrom/serverless-artillery

Re: Serverless: slower and more expensive

#389

Post by jaequery »

When I put on my instructor hat, serverless is ideal as it drastically simplifies what a student has to learn to get a website up and running.

But if you already are a full-stack engineer, then I think having an entire stack at your hands is way more powerful and flexible.

I think it's matter of time though where just like how Bootstrap paved the way for re-usable components, serverless will soon pave the way for re-usable functions or even services which I think would be a total game changer.

Re: Serverless: slower and more expensive

#390

Post by erikerikson »

TazeTSchnitzel wrote: post #145
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'…

It is far too easy to have all the tests pass locally and be completely broken in production for this reason.

See https://github.com/Nordstrom/serverless-artillery

Note performance, acceptance, and monitoring modes

Post reply on HN