I've seen a ton of write-ups on the benefits of serverless computing (AWS Lambda, Google Cloud Functions, etc.) and spent a decent amount of time playing around with the Chalice framework [1] on a couple personal projects. I'm currently debating on adopting it for a new project at my day job, but I've encountered some rough edges that have made me realize that, for all of the positives, there are still a lot of negatives. I was curious what issues other people have experienced and what the dealbreakers ended up being.<p>So, effectively, I'm asking HN to convince me to not go serverless :)<p>[0] - https://github.com/aws/chalice
For the sake of adding to my own discussion, my issues (specific to AWS) were:<p>1. Installing dependencies became complicated. When Chalice worked, it was great. Certain dependencies (in my case lxml) required a precompiled bundle that someone had thankfully already taken care of packaging.<p>2. Visibility into the process was poor. It felt hard to get into the system and really introspect it once it was deployed.<p>3. I felt pushed to other "serverless" solutions within AWS that I wasn't comfortable with. I understand the inherent vendor lock-in with the current serverless offerings, but I felt like I was doubly locked in when e.g. the "best" choice for a db was Amazon Dynamo.<p>4. Current serverless frameworks feel very minimal. I'm a big fan of both Django (batteries included) and Express (bring everything on your own). The tech that is out there now feels like Express, except that there isn't a lot of extensions to layer on top. You sort of have to cobble your own together still.<p>5. Lack of Best Practices. I just didn't see a ton of thought leadership on how to do things the right way in a serverless environment. I might have just missed this though.<p>----<p>Overall, I've come away impressed but I feel like building something entirely on serverless isn't quite as fleshed out as it needs to be yet. I think it's <i>very</i> close though.
So, the arguments I'd give against serverless (and this is dynamic serverless functions like lambda, etc, not serverless PAAS offerings like RDS or S3):<p>* they tie you to a certain cloud provider (though tooling like the serverless framework can help)<p>* they force you into the microservices model (and sometimes you should just start with a monolith until you understand the problem space<p>* they aren't good for running existing applications that are expecting more traditional execution environments<p>* still rapidly evolving which means that you may run into "bleeding edge" issues
1. Most serverless solutions tie you to a cloud provider
2. Difficult to set up CI/CD with decent auditability
3. Hugely overkill for most projects