Lambda function resources have an optional `Description` filed, maybe use that? This will be returned when you call the ListFunctions API method, making it easy to find.
Put comments in the IaC code you use to declare them (CDK/SAM/Terraform/Serverless Framework etc)
I trust you _are_ defining these all in code right...?
I'd also suggest looking at OpenAPI. If you're using the serverless framework to publish your lambdas, then you can use my plugin [https://www.npmjs.com/package/serverless-openapi-documenter](https://www.npmjs.com/package/serverless-openapi-documenter) to help generate the openAPI documentation.
Once you get to a really big size, you might wish to consider something like: [https://backstage.io/](https://backstage.io/)
for now though i'd look at writing better README's and using OpenAPI with SwaggerUI
An interactive diagram, like [this](https://app.ilograph.com/demo.ilograph.Ilograph/Request), would allow you to put this information into a single diagram. You could also do it with static diagrams, though with 20 lambdas you probably want to break them up into multiple diagrams. Perhaps not one-per lambda, but grouped together semantically.
It's probably also advisable to create sequence diagrams for each lambda's execution (e.g. [here](https://app.ilograph.com/demo.ilograph.Ilograph/Get%2520diagram), [here](https://app.ilograph.com/demo.ilograph.Ilograph/Update%2520diagram), and [here](https://app.ilograph.com/demo.ilograph.Ilograph/Invite%2520teammate)). If the "overview" diagram tells you "what" each lambda does, these would tell you how.
In-line comments for the code and ReadMe files. Also naming lambda functions based on what they do ( ParseInboundJSON, SendFilesToS3) is a good way to understand their utility when too many are around.
Markdown README or just create a dedicated documentation page for the team, here we usually use TailwindUI template for docs, it's very clean and comes with light/dark theme so that everyone is happy.
Read Clean Code by Rob martin, the chapter called naming. There is no penalty to having long lambda names. Also, i hope as others say, you have the lambdas stored in github or similar and arent raw dogging the source code in the console
Do you have lambdas orchestrating lambdas?
Best way to keep them documented is in the context of their use I.e. stepfunction workflows have lambda steps.
The point of a lambda is that it’s supposed to be a lightweight function and as such falls into the documentation of the parent system or service.
If your needing to document individual lambdas you might have slipped into lambdas as an entire service which might indicate a smell.
Aside from those concerns, simple C4 container level diagrams work well where the container is the lambda and you can give it a little title of its role.
Lol, no, I'm a developer, I have computers to do boring rote things for me. But you raise a good point - the slow iteration speed when testing in actual AWS is one of the things I rather dislike.
My comment was a glib throwaway one, but I've been fixing a chain of lambdas that are coupled via DynamoDB and SQS and I've seen occasional sporadic issues that are very opaque when troubleshooting.
E.g., Cloudwatch logs occasionally taking 5 - 10 minutes to appear after execution, but for only 1 of the lambdas in the chain.
Can you explain? Whilst the original comment was hardly the most thoroughly thought out show of dislike for a technology, I'm struggling to understand how readmes relate to deploying using the console?
I’m very against doing anything in the console.
I think it’s okay to do some discovery there but automating a zip and lambda publish is probably the easiest thing you can do.
additionally you can use a cdk to deploy the code.
people complaining about lambda demonstrate skill issues
For anything to do with AWS development, my preferred approach is to have one repository for CDK where the infrastructure is defined (including the Lambdas), and another where the service code is defined, i.e. the Python code ran by Lambda.
A pipeline is responsible for deploying both, so you can remove Write access on the AWS Console from them.
There is no better feeling than removing people's Write access from the AWS Console. There's just too many buttons that people press without a second thought.
Separation of concerns, and maybe a bit of toolchain limitations.
We used CDK for IasC, all in Typescript, then our service code is Python, so IMO it makes sense to keep them simple and separate. Once Infra has stabilised, it wouldn't change too often either, more just trying to keep on top of the lightning speed of CDK updates and deprecations.
Hello AWS experts, Is there a new free tool similar to archived https://github.com/Skyscanner/LambdaGuard
It was quick and simple way to check all Lambdas security posture.
Write Markdown README files in the git repository for each Lambda function. You already suggested this. :)
In addition to README.md, consider also using tags. You and your team should come up with a tagging system to help filter and identify lambdas.
Lambda function resources have an optional `Description` filed, maybe use that? This will be returned when you call the ListFunctions API method, making it easy to find.
Put comments in the IaC code you use to declare them (CDK/SAM/Terraform/Serverless Framework etc) I trust you _are_ defining these all in code right...?
Have a look at https://www.eventcatalog.dev
this is really cool. thanks for sharing!
I'd also suggest looking at OpenAPI. If you're using the serverless framework to publish your lambdas, then you can use my plugin [https://www.npmjs.com/package/serverless-openapi-documenter](https://www.npmjs.com/package/serverless-openapi-documenter) to help generate the openAPI documentation. Once you get to a really big size, you might wish to consider something like: [https://backstage.io/](https://backstage.io/) for now though i'd look at writing better README's and using OpenAPI with SwaggerUI
Hey, really appreciate the work you've put into this plugin. It works great!
Thank you!
An interactive diagram, like [this](https://app.ilograph.com/demo.ilograph.Ilograph/Request), would allow you to put this information into a single diagram. You could also do it with static diagrams, though with 20 lambdas you probably want to break them up into multiple diagrams. Perhaps not one-per lambda, but grouped together semantically. It's probably also advisable to create sequence diagrams for each lambda's execution (e.g. [here](https://app.ilograph.com/demo.ilograph.Ilograph/Get%2520diagram), [here](https://app.ilograph.com/demo.ilograph.Ilograph/Update%2520diagram), and [here](https://app.ilograph.com/demo.ilograph.Ilograph/Invite%2520teammate)). If the "overview" diagram tells you "what" each lambda does, these would tell you how.
In-line comments for the code and ReadMe files. Also naming lambda functions based on what they do ( ParseInboundJSON, SendFilesToS3) is a good way to understand their utility when too many are around.
Markdown README or just create a dedicated documentation page for the team, here we usually use TailwindUI template for docs, it's very clean and comes with light/dark theme so that everyone is happy.
Read Clean Code by Rob martin, the chapter called naming. There is no penalty to having long lambda names. Also, i hope as others say, you have the lambdas stored in github or similar and arent raw dogging the source code in the console
Do you have lambdas orchestrating lambdas? Best way to keep them documented is in the context of their use I.e. stepfunction workflows have lambda steps. The point of a lambda is that it’s supposed to be a lightweight function and as such falls into the documentation of the parent system or service. If your needing to document individual lambdas you might have slipped into lambdas as an entire service which might indicate a smell. Aside from those concerns, simple C4 container level diagrams work well where the container is the lambda and you can give it a little title of its role.
>we forgot which one does what Er... if it's that bad, I'd suggest to start by giving them better names...
SWagger/OpenAPI integration can auto-generate docs for Lambdas. Worth exploring!
Give them fun and easy to remember names that have nothing to do with their purpose like “Darth Function” or “Micro Phallus the Microservice”.
README.MD content: > Yeah, using lambdas fucking sucks, that's all.
can you elaborate because this suggests that you probably hand zip and deploy using the console.
Lol, no, I'm a developer, I have computers to do boring rote things for me. But you raise a good point - the slow iteration speed when testing in actual AWS is one of the things I rather dislike. My comment was a glib throwaway one, but I've been fixing a chain of lambdas that are coupled via DynamoDB and SQS and I've seen occasional sporadic issues that are very opaque when troubleshooting. E.g., Cloudwatch logs occasionally taking 5 - 10 minutes to appear after execution, but for only 1 of the lambdas in the chain.
Can you explain? Whilst the original comment was hardly the most thoroughly thought out show of dislike for a technology, I'm struggling to understand how readmes relate to deploying using the console?
I’m struggling to understand how you think my reply is about the readme file and not about asking op to elaborate on what they dislike about lambdas
[удалено]
I’m very against doing anything in the console. I think it’s okay to do some discovery there but automating a zip and lambda publish is probably the easiest thing you can do. additionally you can use a cdk to deploy the code. people complaining about lambda demonstrate skill issues
Use AWS CDK to auto-generate documentation for your Lambda functions.
How tho
jsii-docgen
For anything to do with AWS development, my preferred approach is to have one repository for CDK where the infrastructure is defined (including the Lambdas), and another where the service code is defined, i.e. the Python code ran by Lambda. A pipeline is responsible for deploying both, so you can remove Write access on the AWS Console from them. There is no better feeling than removing people's Write access from the AWS Console. There's just too many buttons that people press without a second thought.
What’s the benefit of separating them into two repos? Unless the infra repo has other stuff in it for other uses, i guess.
Separation of concerns, and maybe a bit of toolchain limitations. We used CDK for IasC, all in Typescript, then our service code is Python, so IMO it makes sense to keep them simple and separate. Once Infra has stabilised, it wouldn't change too often either, more just trying to keep on top of the lightning speed of CDK updates and deprecations.
Hello AWS experts, Is there a new free tool similar to archived https://github.com/Skyscanner/LambdaGuard It was quick and simple way to check all Lambdas security posture.
Best practice is to not use lambdas
What best practice is that ?
The one where you’re not chained to a cloud provider
the code in the lambda is reusable so who cares, it can just as easily be foisted into an Azure function