AWS Lambda: Difference between revisions

Content deleted Content added
Line 22:
 
==Best practices==
Following [[DevSecOps]] practices can help end-users to use and secure Lambda-based applications more effectively. <ref>{{Cite book |last=Katzer |first=Jason |title=Learning Serverless: Design, Develop, and Deploy with Confidence |publisher=O'Reilly Media |year=2020 |isbn=978-1492057017}}</ref> 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 (computing)|orchestration]] within the [[Domain-driven design|bounded context]] of a [[Microservices|microservice]], and should use [[Service choreography|choreography]] between the bounded-contexts.<ref name=":1">{{Cite book |last=Cui |first=Yan |title=Serverless Architectures on AWS |publisher=Manning |year=2020 |isbn=978-1617295423 |edition=2nd}}</ref>
 
==Portability==
Migration from AWS Lambda to other AWS compute services (e.g., Amazon ECS) can be challenging due to tight integrations with the service provider, a phenomenon known as service lock-in. Tools like [https://github.com/awslabs/aws-lambda-web-adapter AWS Lambda Web Adapter] can facilitate [[Software portability|portability]] by enabling developers to build web applications using familiar frameworks, employing the Lambdalith or [https://docs.aws.amazon.com/lambda/latest/dg/monolith.html Lambda monolith] pattern. <ref>{{Cite web |title=AWS Lambda Web Adapter |url=https://github.com/awslabs/aws-lambda-web-adapter |url-status=live}}</ref><ref>{{Cite web |title=The Lambda monolith |url=https://docs.aws.amazon.com/lambda/latest/dg/monolith.html |url-status=live}}</ref> However, this approach has some limitations:
 
* Coarser-grained alerting and access controls compared to functionsingle-levelpurpose segmentationfunctions.
* Potential cold start penalties, particularly with large web framework dependencies.
* May require refactoring to accommodate integration differences.
* May not work as well with non-HTTP APIs.
[[Hexagonal architecture (software)|Hexagonal architecture]] can facilitate workload portability. It can help with both HTTP and non-HTTP APIs. <ref name=":1" />
 
==Helper Tools==