Would be keen to see a complete production setup that you are running. There are so many ways to deploy lambdas: SST, cdk by it's own, terraform etc... All of these have different drawbacks especially when it comes to local development environment experience but it is hard to find resources on the internet what real companies are doing
Regarding your PDF generation example, it depends on how you look at it. You could try to force the standard javascript way of doing it, which you described, and not have it be optimal, or you can ditch Pupeteer and harness the power of Lambda and write the function in a language and runtime that are best suited for native PDF generation. That's another great benefit of lambdas- they are naturally microservices and each can have its own runtime and language
Hi Cody, many thanks for your insights into lambda, would be cool to see an example of how you would use puppeteer to generate pdf's from html (with css styling)😊
serverless works fine when there are budget limitations, but another good approach for this might be to have your express/nest API web server as a container and deploy it using a management service such as ECS or even better, Kubernetes. However as I mentioned that won't apply to every project (specially if there are budget restrictions)
You can also get around the 250MB constraint by wrapping your lambda in a docker image and building your lambda from ECR instead. It will require a bit more on the development side with versioning but allows up to 10GB in dependencies
@@WebDevCody Not too much, since AWS provides specific docker base images. I am currently deploying every lambda as a docker image, because it simplifies the deployment process.
why would you want to do that? Lambas should be short running (there's a time limit on how long it can run for) and stateless. Anything that needs more than 250MB throws up a lot of red flags because it sounds like it would be doing way too much. Wrapping them in a docker image means you have to add the docker registry lookup, download that image and all those dependencies and then start up that docker image, even if its docker running inside docker. Being able to run a lamba inside docker for local testing makes sense, but I think keeping it within the base restrictions should be the goal. Remember you are paying for compute cycles and memory space on AWS so you want to be as small and as fast as you can get.
@@uome2k7 Its 250MB for dependencies. There are many cases where you have a quick and useful lambda, but library requirements just surpass the 250MB allowed in layers :)
@@uome2k7 there are many use cases, for example I need a lambda to generate a pdf for my users. In order to generate a pdf, you need a bunch of binaries which use a LOT of space. Generating the pdf takes maybe 1 second, but installing a chromium binary can take like 80mb by itself, not to mention your all your required node_modules. I'd also say using docker as a way to standardize your lambdas is actually very useful. I've wasted hours debugging issues that work locally but fail on lambda because of incorrect setup of the binary paths, etc.
I've worked with serverless and AWS for 3 years and never had any fun developing on it. Debugging was always painful, documentation is poor and you end up having to buy into a ton of other services just to have a functioning yet complicated system. Not to mention the developer experience sucks, issues always cropping up on AWS but not local or you accidentally forget a permission and have to wait 10+ mins each time for the build to upload. If you're a small company who needs to move fast I would stop and consider whether it's worth slowing down your team for the sake of penny pinching. On the other hand if you are a larger team I would probably adopt a platform engineering approach to help your developers so they dont have to worry about all the intricacies
Somehow lambda containerization is good I get pip issues in python psycopg2 and layers doesn't work I did google and chatgpt didn't help and got to the point to call AWS support
I am very interested to hear your thoughts on CF Workers. You can even create them programmatically on an enterprise plan. CF Workers also have environments so you can do a test deploy. There is also built-in monitoring now, too. I have some basic experience with Lambda, but not much. The CF Edge also doesn't have cold starts, I think (I could be very wrong about this!). Idk about limits... but I do know there are ways to change and alter them to be unbound I think. I only use it for work, so idk about pricing.
so one thing I've wondered for a while, is does lambda/serverless architecture replace a normal backend built in Express, Django, etc.? I'm beginning to work on a web portal for an app startup idea, and I'm generally just confused out what the best way to build up a back end is. in the past I've used lambda for a lot, but I'm wondering if building an Express API is better, or if generally companies use both. I guess i'm just confused on where each comes into play. thanks for the help!
I typically have a single express app that I wrap and get deployed to a single lambda function. There is a library called aws-serverless-express you can use to wrap your express app and deploy to a lambda, super easy to use. You can also use existing tools such as the serverless framework to host an express app directly to lambda. Honestly, deploying a django app to heroku or some other container service host works perfectly fine, I’m just a big fan of only pay for what you use. Some people deploy a separate lambda for each endpoint, but that causes deployments to take forever
@@WebDevCody oh that's actually really cool you can wrap it and then reap the benefits of lambda still. i guess im just wondering what the benefit of deploying it to a server is then.
Is it best practice to just have one lambda function for your application? Or one lambda function per DynamoDB? Or multiple lambda functions for multiple REST-like requests? Kind of confused about this
@@WebDevCody I suppose having one lambda would be best because it would minimize the possibility of cold-starts as well. But I'm almost sure that cold-starts will be a relic-of-the-past someday
@@johndebord7802 yeah much higher chance stuff will be warm, but it does mean every endpoint will need to be configured the exact same. So if one endpoint requires more memory, you need to increase it for all endpoints. If one endpoint needs a higher timeout, you need to increase for all. It’s just trade offs
We managed to get puppeteer working on lambdas by making sure the deployed .zip had as little as possible in it. If we his limits again I think we’ll need to move to running docker containers on lambda
What about when you have your lambda backend connected to a database and there is a spike in the number of users (number of concurrent lambda executers at the same time) but your db has a maximum number of connections? How do you handle that?
you have to scale everything based on expected demand, ideally with some extra margin, but none of these should have unlimited growth allowances because nobody has unlimited pockets.
You’d either need to scale or configure your db to accept more concurrent connections, or you need to wrap your database behind a connection pool service gateway which will limit how many connections can be made, and your lambdas will invoke that via rest. Lambdas do stay warm so you can potentially keep a database connection open between requests as long as you put the connection outside of the scope of the handler into a global code level. But like joe mentioned, there is no silver bullet, you need to re analyze your system when you hit certain levels of scale. If you choose to just use planetscale from the start, you’ll get that scaling in the future more than likely for a price tag
http or websocket based connection models support serverless by design. There's no reason to try to finagle a stateful connection model to work with a stateless compute platform, you'd only be bandaiding an gunshot wound and you will hit a wall if you intend on going past ~100 concurrent users. Firestore is probably the most well established solution in the category but there are a few reasonable providers for both SQL and noSQL like AWS Aurora, Planetscale (not actually stateless but can handle a ton of connections), DynamoDB , MongoDB Atlas (only if you're using the new Data API) to name a few. Sorry for venting; this exact issue nearly ended me.
Zero benefits I heard are not native with using ECS on AWS. Logging, auto scaling, metrics are all supported out of the box. Lambda has so much overhead and duplicated effort , if you like being inefficient but stupidly simple I see the appeal. But if youre running a production enterprise environment, I can't imagine you wouldnt want to save money and execution time by implementing autoscaled container services.
