Hacker News Reader

> A lambda is just someone else's computer running your function, which you call through a fancy rpc interface. There is no infrastructure.

“someone else’s computer” _is_ infrastructure. _everything_ you run in cloud runs on someone else’s computer. Besides, you need to specify the amount of cpu and ram you need for your lambda, the kind of scaling you want, whether you can live with a cold start or not, optimise that cold start, potentially configure networking and so on. You can claim all you want, in the end it is an extra piece of infrastructure that you have to be aware of and configure.

> You don't change the way your system is deployed or is operating if you run your background task as a lambda.

Seriously? You do not need some kind of authentication to call your lambda? The lambda does not need access to some kind of private data to store its results? You won’t introduce a queue or something to offload background tasks?

I think it is naive to state that introducing lambdas into the architecture of an application does not have an impact on the infrastructure you need for it. And it makes me honestly wonder how much experience you have with lambdas or functions on production systems.

> "someone else’s computer” _is_ infrastructure. _everything_ you run in cloud runs on someone else’s computer.

That's meaningless pedantry. You don't talk nor care about infrastructure when you're adding a controller to one of your services, or when a container scales up.

The only thing that matters are the relevant attributes like performance and operational costs. You don't care if running a task in the background ends up scaling up your service, just like you don't care about that when running the same task in a function-as-a-service service like AWS Lambda. You only care if your system is stable and the invoice you get at the end of the month.

If your mental model cares about meaningless low-level details that do not factor in your operations, your mental model is brokenand you have no business lecturing others on how they are doing things wrong.

> Seriously? You do not need some kind of authentication to call your lambda?

You don't, if you configured them right.

> The lambda does not need access to some kind of private data to store its results?

What? It does not have any extra requirements than calling them from a service running on EC2, ECS, Fargate, EKS, whatever. It's an internal AWS service that, just like any AWS service, is covered by AWS' access management. In fact, arguably it has less requirements, specially considering least-privilege policies.

> I think it is naive to state that introducing lambdas into the architecture of an application does not have an impact on the infrastructure you need for it.

I argue that talking about infrastructure when talking about function-as-a-service is ignorant and naive, and reflects lack of insight and first-hand experience which materializes in a mental model that's fundamentally broken.

And people suffering from this problem should not be making bold statements about something they know nothing about.

The term "infrastructure" has kind of a loose and fuzzy definition these days. But basically I think of a serverless function as like a one-shot container that is spun up when a webhook or some other invocation method is called, handles some kind of request, puts out some kind of response, and shuts down. A container is infrastructure, ECS is infrastructure. Therefore a Lambda is some kind of ephemeral invocation-based infrastructure. It's infrastructure the whole way down.

My personal take here is just that serverless functions have a time and a place in one's infrastructure, and it requires good engineering to determine where that time or place is or isn't. We use Cloudflare Workers fairly heavily, for example, to perform web redirects for some statically generated sites. It's a fairly sensical use-case for "serverless" in my opinion.

> But basically I think of a serverless function as like a one-shot container (...)

Implementation details don't really matter. The CloudFormation/CDK deployment of a lambda can include only the source code of the task you want to run. We don't know if AWS uses containers, an intern pressing enter, or purple unicorns.

> Therefore a Lambda is some kind of ephemeral invocation-based infrastructure.

Not really. A lambda is your function running somewhere. Unless you explicitly create your lambdas as runnable containers instead of simply passing your handler's code, you don't know or care how are things under the hood.

> My personal take here is just that serverless functions have a time and a place in one's infrastructure, and it requires good engineering to determine where that time or place is or isn't.

There is no magic or arcane wizardry involved. If you need to peel a background task out of a server that doesn't run that often and requires no internal data other than input parameters and takes far less than 15min to run, and you're already on AWS, then lambdas are far easier to implement and to run and to operate than modifying some server deployment to include support for a background task. In some cases, they can also be free to run.

There's also the usecase for plugging together AWS events, such as processing a file that's uploaded to a S3 bucket.

If you are already neck deep in AWS, lambdas are not an arcane trick that only fit weird corner cases. You need to know what's the free tier, lambda pricing scheme, and do back of the napkin math to figure out where it makes sense to you to switch from lambdas to a dedicated service.

> Implementation details don't really matter. The CloudFormation/CDK deployment of a lambda can include only the source code of the task you want to run. We don't know if AWS uses containers, an intern pressing enter, or purple unicorns.

I'd argue the intern pressing enter at AWS is my infrastructure.

> Not really. A lambda is your function running somewhere. Unless you explicitly create your lambdas as runnable containers instead of simply passing your handler's code, you don't know or care how are things under the hood.

I feel like you took my pragmatic explanation and obfuscated it.

> There is no magic or arcane wizardry involved.

Never said there was, I think you think that I'm more confused than I am. I run my own serverless platform, and make use of serverless platforms from other companies. I know how they work.

> then lambdas are far easier to implement and to run and to operate than modifying some server deployment to include support for a background task. In some cases, they can also be free to run.

You're trying to sell me on lambdas again. I said I already make use of serverless. I just am saying there is a time and place for them, and a time where they don't make any sense. You seem to be agreeing with me, where you placed a few qualifiers on when you should use a Lambda, so I don't know why you're framing this like we're in disagreement. Maybe you're confused as to what I actually said?

>But basically I think of a serverless function as like a one-shot container that is spun up when a webhook or some other invocation method is called, handles some kind of request, puts out some kind of response, and shuts down.

we used to call those "cgi scripts"

You’re right on the money but I think what you’re missing is people are using lambda functions not just to run some image resizing function, but as their entire backend.

That’s the part that’s being critiqued.

> but I think what you’re missing is people are using lambda functions not just to run some image resizing function, but as their entire backend.

Sometimes it makes sense. I see people criticizing stuff they know nothing about.

I worked on a project where I had to put together a REST API for an internal project. After considering the traffic projections, we noticed a API Gateway + lambdas fitted quite neatly in the AWS free tier, and we did everything in lambdas. We also did a proof of concept in ECS and everything was far more complex and convoluted. With lambdas, the whole project consisted of a single CDK package which included also the nodejs code for the handlers.

In another project, we even skipped the API gateway and instead had a NLB invoke a couple of lambdas. It worked flawlessly, and in the free tier.

I'm seeing comments about the need to do engineering, but these same comments are outright clueless and fail to do the faintest cursory research. It's just people commenting on stuff they know nothing about with a demeaning tone. Not cool, not smart.

I guess a lot depends on your developer costs, a docker in e.g. GCPs cloud run costs peanuts compared to a devs salary per month.

IMO the less you need to code on top of your actual business logic functions - the better off you are for small projects.

Docker is still one of the best options, as if your tiny app is somehow business critical you can easily migrate it to other infra. With lambdas you’re stuck on AWS.

> With lambdas you’re stuck on AWS.

You're not getting stuck on AWS because you added a lambda to offload a background task, or because you implemented a low-traffic REST API with API Gateway. If you're rethinking where you deploy services, your decision won't factor in these irrelevant details. Odds are you are more concerned with S3 and CloudWatch than REST APIs.

You're completely right, the only criticisms of serverless in this bizarre thread are from a complete lack of understanding or experience