6 ms·
'lambda' apps. Do people still use them for full production systems? We use them a bit for ancillary things but TBH, if you have some k8s or similar, solution,
by mianos 2y ago
'lambda' apps.
Do people still use them for full production systems? We use them a bit for ancillary things but TBH, if you have some k8s or similar, solution, it's maybe not worth it to not use a standard container deployment environment that everyone knows.
- halfcat 2y ago> lambda apps Yes, SST [1] uses lambdas heavily but makes it more seamless and less visible, just the place your code runs. I’ve also found Azure Container Apps to hit the right balance. It’s kubernetes under the hood, which you don’t have to mess with at all, except that it can use KEDA [2] scaling rules to scale your containers to zero, then scale up with any of the supported KEDA scalers like when a message hits a queue. [1] https://sst.dev/ https://sst.dev/ [2] https://keda.sh/ https://keda.sh/
- ledgerdev 2y agoExcept when you scale to zero, you get a 23+ second cold start time on .net apps. Google cloud run pulls some black magic to get ~3 second cold starts on .net apps, and ~500ms for golang/python/native apps.
- righthand 2y agoI 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.
- jamesfinlayson 2y agoYes, 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. And of course, no easy way to test locally.
- thanksgiving 2y agoI 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.
- jamesfinlayson 2y agoHey, me too! AWS or nothing is the way to run things.
- righthand 2y agoOh 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.
- hmaxdml 2y agoI 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 https://github.com/dbos-inc/dbos-transact-py). With lambdas you need step functions which is not exactly easy to test locally. Also no need for "layers".