Single responsibility principle, frequent deployments, least privilege security principle, infrastructure as code, ... are engineering practices we should always (try to) apply. Is serverless encouraging those practices? Maybe... At least, that's the idea of this article.

Node.js 14 is now supported in AWS Lambda, which means new features like nullish coalescing (??), but also deprecation of version 10 on April 30, 2021. Node.js 14 was also announced in preview on Azure Functions and Google Cloud Functions.

While serverless is often synonymous with cutting edge technologies, it's important to note that 43% of banking systems are running on Cobol and 95% of ATM rely on Cobol code, according to a report of 2017 by Thomson Reuters. So Didier Durand decided to provide this github repository for people who'd like to publish a Cobol Lambda Function.

In my last newsletter, I talked about Alex Debrie and his deep knowledge in DynamoDB. But this man is also incredible with API Gateway! This article goes really deep in the details of API Gateway access logs, what they are, what they contain, how to configure them and obviously how to use them to troubleshoot your API. A must read!

Last November, Chris Bailey wrote an article I already shared in this newsletter about direct integration between API Gateway and DynamoDB. And I really like this pattern as it ensures to be more resilient by saving the data before any processing. In this second article, he explains why you shouldn't do it... My point of view is that you should do it while you don't need too much VTL. If you need more code (event validation, security, data transformation and processing), use a lambda function.

If you don't yet have a cloud provider and want to compare available solutions on the market when talking about functions, this article does a great job: capabilities, performances, pricing, ... And looking at performances, I also discovered faastest.com that provides multiple benchmarks for AWS, Azure and GCP.

If you want to see how Lambda works under the hood, this article is a good introduction. If you want to go a bit further, I strongly encourage you to look at this re:Invent session from 2020: "Deep dive into AWS Lambda security: Function isolation", fascinating!

If the Lambda environment (with firecracker) is well secured, developers have also responsibilities to secure their functions. This article provides 7 recmomendations you should be aware of. To this list, I would add to sign your function code.

Announced in preview back in October, Eventarc is now Generally Available! I really like event-driven architectures and Eventarc brings this capability to Google Cloud. Good job!

The Lambda function code is not the only place where you can put code. You actually have many choices now: layers, extensions or docker image. This article explains the differences and when to use one versus another. Interesting.

TypeScript is not natively supported by AWS Lambda, Javascript is. So if you want to benefit from TypeScript static typing, you can read this article that explains how to setup your project. To be complete, it would be interesting to include the use of a Makefile to automate everything (see doc).

When building a serverless application, you often use Lambda (several functions), API Gateway, Step Functions, SQS, SNS and it quickly becomes necessary to implement observability in order to understand what is happening and be able to troubleshoot in case of a problem. X-Ray definitely helps in that and this article provides a significant example, not a simple hello world, of how to implement it.
Early in February, AWS announced X-Ray Insights, which provides anomaly detection and helps developers to quickly detect issues and identify root causes, particularly useful if you forgot to put some Cloudwatch alarms (see the blog post).