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