| AWS Lambda | |
| Developer: | Amazon.com |
| Operating System: | Cross-platform |
| Language: | English |
AWS Lambda is an event-driven, serverless Function as a Service (FaaS) provided by Amazon as a part of Amazon Web Services. It is designed to enable developers to run code without provisioning or managing servers. It executes code in response to events and automatically manages the computing resources required by that code. It was introduced on November 13, 2014.[1]
Each AWS Lambda instance is a container created from Amazon Linux AMIs (a Linux distribution related to RHEL) and a configurable execution time. Node.js, Python, Java, Go,[2] Ruby,[3] and C# (through .NET) are all officially supported . In late 2018, custom runtime support[4] was added to AWS Lambda.
In 2019, at the AWS annual cloud computing conference (AWS re:Invent), the AWS Lambda team announced "Provisioned Concurrency", a feature that "keeps functions initialized and hyper-ready to respond in double-digit milliseconds."[5] The Lambda team described Provisioned Concurrency as "ideal for implementing interactive services, such as web and mobile backends, latency-sensitive microservices, or synchronous APIs."[6]
The Lambda Function URL gives Lambda a unique and permanent URL which can be accessed by authenticated and non-authenticated users alike.[7]
AWS Lambda Layers allow developers to easily manage and share common components across multiple Lambda functions. It's designed to promote code reusability and simplify the deployment of libraries, custom runtimes, and other dependencies that Lambda functions might need. Lambda Layers can be particularly useful in microservices architectures, where multiple functions might share the same dependencies.[8] By using layers, one can ensure that all functions are using the same version of a library, making the application more consistent and easier to manage.
Following DevSecOps practices can help end-users to use and secure Lambda-based applications more effectively. [9] In Lambda-based applications, the line between the infrastructure and business logic is blurred and the apps are usually spread across various services. According to Yan Cui, to get the most value from testing efforts, Lambda-based applications should be tested mainly for their integrations, and unit tests should be used only if there is a complex business logic. Also, to make debugging and implementation of Lambda-based easier, developers should use orchestration within the bounded context of a microservice, and should use choreography between the bounded-contexts.[10]