1. lock in to a specific platform with limited visibility tools and a dependency on a 3rd party when shit doesn't work
The logging analysis tools are excellent and it’s quite easy to tie your lambda logging to whatever tool you are using.
As far as “lock-in”, there is an Amazon provided framework in every supported language to just add a proxy that allows you to use your standard framework (Node/Express C#/ASP.Net, etc) and you cab deploy to Lambda or your traditional web server with no code changes.
2. when functions change you run into function incompatibility chaos and no smart way to handle that mess
What???
3. the "scalability" win is a lie, it's just deferred to whatever data storage service you are using - which ends up blowing up because while serverless scales, the db doesn't
Serverless Aurora (Mysql) and DynamoDB both have autoscaling. You can also auto scale Read Replicas fast with traditional Aurora.
4. addendum to 3, the statelessness of lambda means you can not use local caches to increase your throughput - increasing your hardware requirement
Again not true, if you are calling an endpoint frequently, the instance stays warm for up to around 15 minutes and can maintain state.
The logging analysis tools are excellent and it’s quite easy to tie your lambda logging to whatever tool you are using.
As far as “lock-in”, there is an Amazon provided framework in every supported language to just add a proxy that allows you to use your standard framework (Node/Express C#/ASP.Net, etc) and you cab deploy to Lambda or your traditional web server with no code changes.
2. when functions change you run into function incompatibility chaos and no smart way to handle that mess
What???
3. the "scalability" win is a lie, it's just deferred to whatever data storage service you are using - which ends up blowing up because while serverless scales, the db doesn't
Serverless Aurora (Mysql) and DynamoDB both have autoscaling. You can also auto scale Read Replicas fast with traditional Aurora.
4. addendum to 3, the statelessness of lambda means you can not use local caches to increase your throughput - increasing your hardware requirement
Again not true, if you are calling an endpoint frequently, the instance stays warm for up to around 15 minutes and can maintain state.