Lambda

Rationale

AWS Lambda  is the service we use for serverless compute  in the cloud. It allows us to execute workloads without managing servers, scaling automatically based on demand, and with minimal operational overhead.

The main reasons why we chose it over other alternatives are the following:

• It integrates seamlessly with other AWS services, allowing us to easily connect with a variety of event sources .
• As all its infrastructure is managed by AWS, administration and scaling are largely handled automatically, reducing operational complexity.
• It complies with several certifications  from ISO  and CSA . Many of these certifications are focused on ensuring that the entity follows best practices regarding secure cloud-based  environments and information security.
• It supports multiple runtimes, including Python, Go, Node.js, and Ruby, giving flexibility to run different types of workloads.
• It integrates with EventBridge Scheduler , enabling the execution of recurring short-lived workloads.
• Resources can be written as code  using Terraform .
• Lambda logs and performance can be monitored using CloudWatch .

Alternatives

• Cloudflare Workers : Mainly focused on edge processing, and presents limitations such as the lack of a file system (not even ephemeral), does not integrate easily with AWS services, and fragments our stack and know-how by requiring us to support two cloud providers.
• Google Cloud Functions : Provides serverless execution, but adopting it would require supporting another cloud provider, increasing operational complexity and fragmenting knowledge and tooling across platforms.
• Azure Functions : Also supports serverless workloads, but using it would introduce a second cloud platform to manage, adding complexity and operational overhead.
• EKS /ECS : Preferred for CPU-bound, long-running workloads that require more control over runtime, dependencies, or networking, but they typically have higher operational overhead and costs.

Usage

We use Lambda  for

• serving I/O-bound APIs;
• consuming SQS queues to process messages as they arrive;
• consuming DynamoDB Streams to perform actions when table items change;
• processing webhook requests to power our GitLab bot and Google Chat app;
• cleaning GitLab CI  stale machines on a scheduled basis.