Ask HN: Pain Points of Serverless Architecture
3 comments
I never use serverless because micro-services always works perfectly. Im lazy
Thanks for sharing ! I think I won't switch to serverless (maybe this architecture require a specific use case ?)
Well there are definitely some advantages of serverless i.e.
- you don't have to create docker images and complex CI/CD pipelines. - You don't need to worry about deployments (using Heroku, AWS ECS or Kubernetes) and scaling. - you don't need to write a lot of unnecessary boilerplate code which you do in the case of micro-services. - You pay per invocation and resources used for that invocation.
But then serverless comes with all the issues which I have described in original post. I think serverless is good for quick prototyping but for production use, we should still be using micro-services. It'd be idea if we can create a new layer of abstraction which has good things of both micro-services and serverless architectures.
- you don't have to create docker images and complex CI/CD pipelines. - You don't need to worry about deployments (using Heroku, AWS ECS or Kubernetes) and scaling. - you don't need to write a lot of unnecessary boilerplate code which you do in the case of micro-services. - You pay per invocation and resources used for that invocation.
But then serverless comes with all the issues which I have described in original post. I think serverless is good for quick prototyping but for production use, we should still be using micro-services. It'd be idea if we can create a new layer of abstraction which has good things of both micro-services and serverless architectures.
That's right ! Thanks for this accuracy and for sharing.
Maybe you can create your own tool which takes good from both architectures ? ;)
- 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,