Ask HN: Pain Points of Serverless Architecture

In my last job, we migrated our infrastructure from flask based python micro-services which were deployed in AWS ECS to AWS Lambda but after some time, we realized that serverless infrastructure is not perfect and it has its own pain points e.g.

- Shared business logic between multiple lambda functions i.e. if we change shared logic, we'll have to re-deploy all the functions which were are that shared logic.

- Handling of DB connections i.e. to avoid creating a new connection for each new invocation, we need to check if db connection was already initialized in previous invocation.

- Cold start problem. I have tried the solution of keeping the lambda function warm by pinging it periodically but it'll only keep one container warm. What if suddenly QPS goes up to 100 and 100 containers are running in parallel?

- Problem of double billing i.e. in a micro-service, it's common to call another micro-service but if you call another lambda function, you'll be charged twice.

- No support of routing i.e. you'll have to create 50 API Gateway endpoints if you have 50 lambda functions.

- No support of websockets in lambda functions.

All of the above issues can easily be solved by writing micro-services and deploying them using Kubernetes for production use then why do developers prefer serverless? Is it just because of the ease of use? or developers don't want to do deployment and scaling work?

Thanks,