91–100 of 131 posts
No. It's a gross misuse and misunderstanding of serverless and lambda functionality.
How so? Lambdalith means simpler, faster deployments, and easier to run locally.
The question strikes me as odd. I can't imagine why one would split an API across separate isolated compute nodes. I've used isolated functions in the context of "message orchestration" scenarios, but I'd never do that for an API.
Another example could be permissions granularity (each lambda can have its own IAM role). For example one of your lambdas could have access to something in Secrets Manager.
There are also disadvantages to this approach, for example build times and deployment times.
> Now the big one, reusing code is by far easier in a monolith.
> Consider the scenario for patching an error in a library that is used in all your single-purpose functions:
> You have to publish shared code into packages that need to be used by all of your routes > You would have to context switch, make the change in the library, merge, publish the package > Then context switch again and update the version in each of your 100’s of routes to use the new version > Then you need to test and deploy all the 100’s of routes
I don't use a monolith mainly due to size. I had enough problems packaging all my functions in 1 archive and hitting size limits that I can't imagine a monolith would do anything but lock me into that issue with no solution other than splitting it up into smaller services. Currently I package all my functions individually so they only contain the code/deps that that specific function needs. This works very well and keeps my function sizes small (except for the Prisma engine, stay away from this if you can). Also I have shared code that multiple function use (wrapping code for catching errors, DB access, various other reusable services), it all works just fine and I don't package/publish my shared code, my packaging grabs what each function needs and includes it.
Everything else he says, especially about getter /more/ warm starts and being able to really take advantage of PC is true, but the size issue steered me away from a monolith. If size wasn't a problem I'd probably be running express in my lambda but instead I have a 1 function per endpoint and that seems to work pretty well for my company.
Earlier quoted context omitted.
There's obviously a static load level where it makes more sense to have an always-on server vs. a FaaS and you need to monitor that boundary point. The point of doing something like this "Lambda Monolith" is that transitioning to an always-on server is trivial. I've been doing this exact setup for a while and our static costs basically evaporated. Seeing your costs drop below a dollar/month on a project you are build…
always-on EC2 instances start at like $20/mo? I don't understand this argument whatsoever. > Seeing your costs drop below a dollar/month on a project you are building is amazing. Honestly, this just means you don't have any users
Which is where many small ideas start.
My buddy had an idea for a few SaaS products and I've helped him develop them. The initial costs were small, but give it was an expense with no income in the near future, finding a way to scale to zero was the only way this became something he'd consider. It's got _very_ sporadic use currently and his bill for each service is literally around $1/month right now. Even the cheapest instance would be more than he's paying.
Yes, but not only API... We figured out how to get Azure Functions to serve a complete webapp without any extra crap wrapped around it. No gateways/proxies/etc. One function that serves the root URL[0] and has conditionals for GET/POST methods. Beyond this point, anyone with old-school mastery of HTML/CSS/JS can get the rest of the job done with basic-ass SSR and multipart form posts. For data, we just use Azure SQL…
Earlier quoted context omitted.
I've found that "permissions" are what bites most developers. It's always either IAM or security groups...
Using the ChatGPT prompt I said above, it did the permissions correctly table.grantReadWrite(lambda function) Just as an experiment, I’ve thrown Lambda code I’ve written from scratch into ChatGPT and asked it what permissions it needed. It got it right. ChatGPT is well trained on everything AWS related. It can transform CloudFormation to idiomatically correct CDK or Terraform. I hate to say this because it sounds lik…
Small functions that can be reused in multiple APIs, tiny deployments, small tests incrementally building a system.
Lambdas primarily shine in an event based system. I'd rather use the serverless tooling as they're intended i.e cognito, gateway, event bridge, dynamodb.
Each are designed to solve a particular problem in what I'd say as a different paradigm.
If you want a traditional monolith I'd look to fargate instead since you'll be rolling a permission system/auth system and probably a framework of sorts.
In my past using only a part of lambda eventually lead me to having to build an already solved problem with a serverless service and make it fit in. Lessons learned I suppose.
Yes, but not only API... We figured out how to get Azure Functions to serve a complete webapp without any extra crap wrapped around it. No gateways/proxies/etc. One function that serves the root URL[0] and has conditionals for GET/POST methods. Beyond this point, anyone with old-school mastery of HTML/CSS/JS can get the rest of the job done with basic-ass SSR and multipart form posts. For data, we just use Azure SQL…
Sounds like a cool hack, but why not just self-host with on-premises hardware, or rent a cloud server from a hosting provider like e.g. Digitalocean? Then you wouldn't have to worry so much about what Microsoft wants, no?
We've got some experience with on-prem IT shops that have taken way more out of us than we probably should have allowed. Every one of their issues with getting our software to run in prod was unhappy in its own special way.
Earlier quoted context omitted.
There's obviously a static load level where it makes more sense to have an always-on server vs. a FaaS and you need to monitor that boundary point. The point of doing something like this "Lambda Monolith" is that transitioning to an always-on server is trivial. I've been doing this exact setup for a while and our static costs basically evaporated. Seeing your costs drop below a dollar/month on a project you are build…
I just can't get my head around this argument of 'scales to zero'. If you have one or more professional developers working on a project how can you be bothered about an extra $20-$200/month when you know you'll also be spending a couple of engineering hours (worth more than $200) on migrating later?
Yes, you should. Especially if you want to scale up without tons of extra work. The model of "every function should be a separate Lambda" is just moronic - I've seen people run into hard limits on AWS going all-in on this model. Instead Build a single executable/library and deploy it as a Lambda function. Now you have automatic versioning, just push and it's a new version. You can label versions and call them based o…
AWS limits are there to be worked around! Have too many lambdas to fit them in a single cloudformation stack? Just split it up into ‘per family’ stacks. Enjoy your nested cloudformation stacks. Oh, you say you have more than 200 endpoints in your REST API gateway, and suddenly your CloudFormation stop working? Yes, unfortunately CF only load 8 pages of resources in alphabetical order when starting, and your root reso…