If you are reading this newsletter, I guess you understand what is serverless and what benefits you can expect from it. However if you have doubts or if you have passionate discussions with a k8s aficionado colleague, this article can help you. The author is fighting against an argument for not going serverless: cold start. Only looking at the speed of your application, you are missing a lot of benefits (TCO, productivity, speed, scalability...). Great article and conclusion, well written by Anna Anisienia.

If you are using Provisioned Concurrency, to avoid cold starts, you must know it has a cost, and you should use it with parsimony, for example by scheduling it for known peaks (see my article from last year). Or you can do like Vamsi Vikash in this article, and list all the functions using this feature, to ensure it is really needed.
And if cold start is still an issue for you, throw an eye on this article from Emrah Samdan, who gives interesting insight on how to reduce/avoid them.

I rarely speak about databases in this newsletter, but I thought this deck was worth a read if you want to discover DynamoDB.
And if you already know DynamoDB and want more, I recommend you to have a look at Alex Debrie content (blog, book, website, reInvent session part 1 and part 2).
This article from Den Dribbles can also help you work with DynamoDB locally with NoSQL Workbench.

To continue with DynamoDB, this article explains how to combine GraphQL and DynamoDB (without AWS AppSync). The first half of the article provides a good description of DynamoDB modeling and the second part deals with GraphQL and resolvers. I would probably recommend looking at AppSync but there may be some case where it does not fit, so why not!
And if you are using AppSync, this article from Yan Cui can help you monitor and troubleshoot your GraphQL APIs.

When building distributed systems, the circuit-breaker pattern often helps. It avoids cascading failures and provides better resiliency. When calling an external service from Lambda, you may want to implement this pattern to avoid your Lambda to fail or to avoid overloading this 3rd party service. This article gives an example of architecture and implementation.

Very complete article from Amit Jambusaria explaining how to build a serverless web application using Firebase and its ecosystem (database, cloud functions, authentication, storage, hosting, messaging and analytics).

Few months ago, I talked about an article from the BBC who was moving to the cloud and leveraging serverless for their website. Johnathan Ishmael is coming back with 2 articles. The first one explains why they choose serverless over VM or containers. And the second what services they used and how they optimised to get the most of them. Interesting feedback from the BBC who runs more than 100 millions function invocations per day.

Interesting point of view of Payam Moghaddam, who states that we can consider AWS (and especially with managed services and serverless services) as a framework. A framework tends to simplify development, providing everything you need for you to build an application. And actually, AWS is not (just) an infrastructure provider anymore and you can definitely be very productive with Lambda, built-in scalability and load balancing, have logs with Cloudwatch, tracing with X-ray, with whatever programming language suits your need.

Good series of articles on Event-Driven Architecture from James Beswick:

• Part 1: Operating Lambda: Understanding event-driven architecture
• Part 2: Operating Lambda: Design principles in event-driven architectures)
• Part 3: Operating Lambda: Anti-patterns in event-driven architectures

Automated testing has always been a topic I do care about, and this article from Louis John Bichard, is quite good at describing how to test your Lambda functions: unit test mocking external calls (HTTP or AWS SDK), that you can run locally or integration tests that you run on the platform using a CI/CD pipeline (using Github actions or CodePipeline for example). In god we trust, everything else we test!

I was mentioning Github Actions to deploy your Lambda functions, but you can go further and deploy complete serverless applications. This AWS blog post details how to deploy a State Machine (Step functions), some Lambda functions and an API Gateway, using Github Actions. And the source code is available... on Github ;)

I was just talking about tests, and CI/CD pipelines. This article is dealing with both, and others (monitoring, observability, agility), and provides great advice to build serverless applications serenely.