
Ask HN: Pain Points of Serverless Architecture - ufarooqi
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.<p>- Shared business logic between multiple lambda functions i.e. if we change shared logic, we&#x27;ll have to re-deploy all the functions which were are that shared logic.<p>- 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.<p>- Cold start problem. I have tried the solution of keeping the lambda function warm by pinging it periodically but it&#x27;ll only keep one container warm. What if suddenly QPS goes up to 100 and 100 containers are running in parallel?<p>- Problem of double billing i.e. in a micro-service, it&#x27;s common to call another micro-service but if you call another lambda function, you&#x27;ll be charged twice.<p>- No support of routing i.e. you&#x27;ll have to create 50 API Gateway endpoints if you have 50 lambda functions.<p>- No support of websockets in lambda functions.<p>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&#x27;t want to do deployment and scaling work?<p>Thanks,
======
Colegno
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 ?)

~~~
ufarooqi
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.

~~~
Colegno
That's right ! Thanks for this accuracy and for sharing. Maybe you can create
your own tool which takes good from both architectures ? ;)

