This article discusses four different ways of sending logs to Cloudwatch from a Lambda function implemented in .NET. Using ILambdaContext.Logger The ILambdaLogger is the most limited option, but it is also the only one readily available in the lambda without requiring any configuration. It just writes messages in one line, without any specific structure. There is no support to add exceptions when logging errors, or using message template with parameters. This is a good option for a very basic logging needs.

As the grace period to use Docker Desktop for free is coming to an end, organisations are looking into alternatives to retain much of the convenience Docker Desktop offers, without incurring in the extra costs. One of that convenience is the seamless integration between Visual Studio 2022 (and some previous versions) and docker engine allowing to run and debug applications as naturally as if we were running and debugging them natively on the host.

One of the first things we learn about resiliency is that dependencies will fail at some point, and our applications must be prepared to deal gracefully with these failures. What gracefully means will vary from app to app, but in all cases, this graceful behaviour should be covered by some sort of tests. We have therefore to cover those failure scenarios to ensure our applications are resilient. In this post I will show you how to use Interceptors to simulate failures when using Entity Framework Core with relational databases like SQL Server.

It is common for APIs to route requests based on a combination of HTTP verb (GET, POST, etc.) and path. For example, we can have same path /api/items/123 for both retrieving the information about item 123 and deleting item 123, using HTTP verbs GET and DELETE respectively. But what if we have the same verb and path and need to route the requests based on the value of a HTTP header?