If you’re delving into or considering AWS (Amazon Web Services), chances are you’ve encountered Lambdas. Lambdas represent serverless functions that can be triggered in various ways, operating either asynchronously or synchronously, and capable of initiating additional actions as side effects. The essence of lambda functions lies in their singular responsibility, where each function encapsulates concise logic following the “clean function” approach, taking an input and producing an output.
AWS provides Lambdas across multiple programming languages such as Java, Go, PowerShell, Node.js, C#, Python, and Ruby, although personally, I’ve primarily worked with Node.js.
During my experimentation, a few insights emerged:
- Coding without relying on external packages isn’t straightforward. The AWS Management Console could streamline the process by facilitating the installation of third-party npm packages directly, rather than necessitating the cumbersome upload of a zip file.
- As widely noted, AWS Lambda’s provisioning time (the duration before code execution) poses a significant challenge. In my scenario, where it powered a publicly accessible REST API, every millisecond counted. While Lambdas excel in executing logic, they might not be the optimal choice when speed is paramount.
- AWS employs Firecracker, an open-source framework, to provision Lambdas, effectively spinning up a micro-container upon each invocation. Consequently, each instance requires its own set of node_modules packages and active database connections. While this architecture may be less efficient for repetitive executions, it shines in handling one-time tasks.
- AWS offers robust tracking and auditing capabilities through CloudWatch, facilitating the monitoring of Lambda executions.
Stay tuned for further insights in the upcoming article.