* Well, obviously we use a hosted database
* And obviously, AWS provides our logging and all our analytics.
* Obviously when people call our lambda functions, they do so either through an AWS-specific API, or one constrained to a very limited set of forms.
* Of course, we can't blindly let everything access everything, so naturally we have IAM roles and permissions for every lambda function.
* Well, the cloud provider will look after secrets and things like that for us, no need for us to worry about database passwords.
* Naturally, with all these functions and IAM roles to look after, and we need tagging for billing. We should define it all with CloudFormation scripting.
* Well, the nosql database the they provide comes with their specific library. And as it shards things like this, and doesn't let you index things like that, you've got to structure your data this specific way if you want to avoid performance problems.
* You don't want your function to take 200ms+ to respond, your users will notice how slow it is. So no installing things with apt-get or pip for you, let me get you a guide on how to repackage those into the vendor-specific bundle format.
* You want to test your functions locally, with access to an interactive debugger? You're living in the past, modern developers deploy to a beta environment and debug exclusively with print statements.
* And so on.
In this case, a lot of the 'complexity' one hoped to eliminate has just been moved into XML files and weird console GUIs.
It was a complete omnishambles - to the point I avoided the fancy lunch and went to the Pub for a ploughman's lunch, In case I suddenly blurted out "this is all S*&T" and caused a political row with the mobile side of the company I worked for.
Of the actual function code, sure.
Of course, if you aren't manually configuring everything and are doing IaC, that isn't generic. And if you are supporting the Lambda with any other AWS serverless services, the code interfacing with them is pretty AWS specific.
Sure they do.
Because if you need a DB for persistence you are either setting up a server for it (and therefore not serverless, even if part of your system uses a Lambda) or consuming a serverless DB service. And so on for other parts of the stack. On AWS, for DB, that might be Dynamo (lock-in heavy) or, say, Aurora Serverless (no real lock-in if you don't use the RDS Data API but instead use the normal MySQL or Postgres API, but that's higher friction—more involved VPC setup—to use from Lambda than RDS Data API is, so the path of least resistance leads to lockin.)
Lambda or other FaaS is often part of a serverless solution, but is rarely a serverless solution by itself.