Every time I read about serverless it looks too good to be true. And we all know how much hype every "new thing" gets in our community 😏
So I'd like to ask you all what is the WORST thing that you experienced in using serverless?
The worst, and only the worst. No buts, no excepts, no goods allowed!
Latest comments (43)
Version control & deployment
1- Cold start
2- Function execution time
3- SDK tuning to fit with serverless
4- If you are using AWS....then you have to deal with huge documentation
5- Tuning everything related to lambda function
I need to provide my own log server to have lagless debugging. I use to think it just took a while for lambda to update, once I finally got a normal *ing log server installed in the environment and syslog libraries in code shipping everything to that I realized cloudwatch is just a piece of * and this really could be nice and realtime but it isnt.
People will try to take their existing expertise and build a project the '3-tier way' not realizing that's the wrong way to build a serverless app and then complain incessantly that serverless is terrible.
That and logging...
And what is the serverless way, how is it different?
The only issue that i think is just having a deeper understanding of the architecture itself. Authentication and Policies just require more detailed concepts for them to work.
Interesting... Would you be able to give a simple example?
Sure, I`ll upload an article. So keep your self posted
My experience is that most cost and complexity issues can be overcome but the security is always an issue. Not the outside security but the internal development. For instance for a developer to create a lambda that works, they need not only all lambda permissions but the ability to create IAM roles, attach policies etc, upload to S3 if they aren't developing in console, possibly create the S3 bucket they will use etc.
Which means. Now you have to develop complex gates all over on their users or roles they assume. The newly released feature of ABAC in IAM (AWS specifically) should help this complexity but adds others.
Hello! That's called vendor lockin. :)
Time outs for long running scripts.
We experienced this where I work too. :/
Code Complexity.
Handler code and infrastructure code are all over the place in most code bases. It can be extremely difficult to walk through how an event goes through all of the services.
A single app with some in memory queues and rest handler would is far simpler to read.
You spend half the day writing glue code between different services and configuring the "infrastructure" becomes a nightmare. If I could, I'd pick ssh to a good ol' server over serverless every time.
Make that half-a-month 🙄