> The ability to have the infrastructure isolated from the raw code being written. (Think more of a grid computing and automatic planning being included)

Can you elaborate? It sounds like you're saying that if you write code that's deployed to a serverless infra you end up with 'serverless code'. This hasn't been my (very limited) experience - where the serverless stuff is just a thin layer around your business logic.

I think they’re saying that you can expose your lower-level atomic APIs as serverless functions, and then, separately, build a “routing and aggregation layer” that exposes APIs that people might actually want to use. And that, for a lot of projects, that routing/aggregation can be entirely specified in a declarative manifest format, rather than involving any coding.

This neatly cleaves responsibility: your business logic team can just build+deploy+expose functions; and your frontend and ecosystem teams can build+deploy+expose the APIs they want on top, perhaps being maintained within their own codebases.

These can even be done on two entirely-separate platforms, rather than both being a part of the same “serverless” IaaS. You could use any combination of commodity FaaS providers (including your own hosted FaaS clusters) to deploy functions to; and then you could use some “smart” load-balancing system (e.g. Cloudflare Workers, or the routing component of an FaaS) to do the routing+aggregation on.

That is exactly what I was shooting for. I just didn't have the words at the moment to explain it.

What I've seen AWS Lambda being used: One-off functions with manual output management. They aren't really being chained together.

You can also use AWS API Gateway for that.

Thanks for the more in depth explanation.