3 ms·

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

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

rewmie 3y ago
> "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.

rewmie 3y ago

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