I inherited some lambdas on my team and the amount of effort I have to go through to:
- make them testable locally
- planning/qa-ing yaml configs with devops team, because they only grant me readonly access on their precious over engineered helm chart stack, they don’t even offer running my unit tests in their pipeline for me
- painful debugging process because everything that touches a lambda is another aws service config somewhere
I honestly don’t know why anyone wastes their time. We will be deprecating these aws lambdas for traditional api on our next version of our app. Serverless is garbage way to deploy code and is designed to tax you/charge you fees at every turn. It is for people who want to deploy poorly thought out code and rewrite it later, and explain the bill later.
Yes, I inherited a Lambda code-base too, and it is an absolute knot - Lambdas sending requests to other Lambdas, Lambdas sending messages and other Lambdas reading the messages, Lambdas reading and disregarding messages due to poorly thought-out queues etc.
I remember at one job, they were talking about the overall architecture of code at the company and when I asked how can I run this on my computer, they said well you can just run it but I pushed... How can I run this whole thing on my computer to interact with everything else and it was met with silence.
I can understand having to stub out external calls to vendors and clients but this is ridiculous. There is no local story.
Oh yeah I have a lambda that needs another lambda to complete before running. The first is on a Cloudwatch event interval. So the data in the second can be stale, but the one saving grace of the situation is that no one cares enough to make me fix it, not even me.
I worked on a system built on FAAS for a few months and it was (already when I arrived) one of the more well-tested systems I ever worked with, so it is clearly doable.
I took the system from dev to prod and much of it was boring in the very best sense of boring (also helped that I had a good team, although they were new to it as well).
I had one major gripe with it (and everything Azure) afterwards:
On dev there are absolutely no guarantees: components might go down half a workday and they don't care.
And when you go to production the prices goes absolutely through the roof (IIRC $9000/year for the most basic message broker I could configure that wouldn't have the risk of being offline half a day, and every component is like this).
So while it was really cool to work on a cloud native system if someone ever asks me to design one for them, that design will be presented with a price tag for what it will cost to take it to production.
I wouldn't equate the lambda UX with "serverless" at large. I work on a serverless system that runs the same code you upload (e.g, python). You write it as a traditional API then upload it to the cloud and done.
One thing that makes it possible is that "orchestration" is embedding in your code, using a library (https://github.com/dbos-inc/dbos-transact-py). With lambdas you need step functions which is not exactly easy to test locally.
There are a bunch of gotchas outside of UX, that make them just as awful. Like if you need secrets you have to find a way to cache them so that aws.secretsmanager doesn’t ding your bill every request. Depending on how your devops team requires you to load secrets this can make the code worse in operation and review.
But the main point why serverless is garbage is that the old stack does everything better.
- make them testable locally
- planning/qa-ing yaml configs with devops team, because they only grant me readonly access on their precious over engineered helm chart stack, they don’t even offer running my unit tests in their pipeline for me
- painful debugging process because everything that touches a lambda is another aws service config somewhere
I honestly don’t know why anyone wastes their time. We will be deprecating these aws lambdas for traditional api on our next version of our app. Serverless is garbage way to deploy code and is designed to tax you/charge you fees at every turn. It is for people who want to deploy poorly thought out code and rewrite it later, and explain the bill later.