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 granting 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.
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.