[bleeding]

I think with Lambda there are a lot of downsides to either approach. When you build the Lambda as a monolith, you also give all the code executing from that monolith access to all the resources needed by every single route in the Lambda. When I was working with Lambda a lot, we had a lot of secrets that were only needed by a few routes, and which would have been very bad if someone misused those secrets from a different place.

But if you have a sufficiently large enough API surface, doing one lambda per endpoint comes with a lot of pain as well. Packaging and deploying all of those artifacts can be very time consuming, especially if you have a naive approach that does a full rebuild/redeploy every time the pipeline runs.

I think there's a happy medium where you group lambdas by resource type or domain, but even still it can be tricky to enforce "least privileged access" for those when the content of the lambdas is constantly being added to. Eventually there is creep in the IAM permissions available to those lambdas.

I came up with a system that did incremental build/deploys for all of our lambdas based on the code changes since the last builds/deploys, but even so that came with some pain and definitely some hacks that I wouldn't do again (and relied on technologies it was difficult to get other people to engage with, like Bazel.) I also think Lambda (in particular of the FaaS options) is...not great for APIs, especially if you use a language with a long cold start time.

[joshstrange]

> But if you have a sufficiently large enough API surface, doing one lambda per endpoint comes with a lot of pain as well. Packaging and deploying all of those artifacts can be very time consuming, especially if you have a naive approach that does a full rebuild/redeploy every time the pipeline runs.

Yeah, thankfully SST [0] does the heavy lifting for me. I've tried most of the solutions out there and SST was where I was the happiest. Right now I do 1 functions per endpoint. I structure my code like url paths mostly, 1 stack per final folder, so that the "users" folder maps to "/users/*" and inside I have get/getAll/create/update/delete files that map to GET X/id, GET X, POST X, POST X/id, DELETE/id. It works out well, it's easy to reason about, and deploys (a sizable a backend) in about 10min on GitHub Actions (which I'm going to swap out probably for something faster).

I agree with the secrets/permissions aspect and I like that it's stupid-simple for me to attach secrets/permissions at a low level if I want.

I use NodeJS and startup isn't horrible and once it's up the requests as very quick. For my needs, an the nature of the software I'm writing, lambda makes a ton of sense (mostly never used, but when it's used it's used heavily and needs to scale up high).

[0] https://sst.dev

[bleeding]

Nice, we evaluated their Seed product but didn't pull the trigger, which caused me to eventually roll our own. I'm pretty proud of what we ended up with but due to reasons we ended up with _hundreds_ of lambdas, for which a full re-build re-deploy took around 45m (Go lambdas).

We used Go and the Serverless framework (ugh), and if I had to do it all over I would probably just use AWS SDK since it would make doing the "diff" to redeploy dead simple, since everything is just a binary to build.

Your use case definitely makes sense for Lambda APIs though! I think my complaint is more directed at APIs that back frontends. We had a JVM lambda API there for a while that was horrificly slow startup unless you set provisioned concurrency, which gets expensive fast.

[joshstrange]

Yeah, I totally understand and agree with your "downsides" for lambdas. My use case just happens to gel perfectly with them but it's not a "one-size-fits-all".

I also looked at SEED and I would like to give them money but some of their methodology with SEED didn't fit with mine and since my deploys aren't horrible I left my system as-is. Also I understand they need to make money but I wish more tools geared towards serverless "scaled to zero". I'm happy to pay but my company has such bursty traffic that paying for a plan (on SEED or something like monitoring) that can handle our "peak" means burning money 70%-90% of the time while our app is scaled to zero but we still have to pay for tools around it.

Some monitoring tools, like New Relic, are based on usage but both NR and DataDog have absolute shit serverless monitoring solutions and their docs are a dumpster fire (at least around serverless). It's also unfortunate that most serverless monitoring means adding ~$10 per account per month (in increased AWS costs) just for their data pipelines to scan CloudWatch logs. This again sucks since we have an AWS account per client but each client is only active for ~1mo every year so it can get expensive fast.