A Detailed Comparison of Serverless App Platforms

From AWS Lambda to Azure Functions to Fermyon Spin to Oracle Cloud Functions, there are plenty of options from which to choose. This matrix is often updated, so check back often.

Where Can They Run?

Some serverless functions are specific to a particular cloud provider. Others can run anywhere Kubernetes runs. Some are even more flexible, able to run in environments ranging from embedded to edge to cloud, and beyond. This matrix gives a basic feel for where a platform can run.

❌ Unsupported ✅ Supported Fully 🕰️ Partially Supported

• ¹ Only for dev
• ² Only paired with JavaScript
• ³ Assuming that this is available via V8, but limited

There are various locations where a serverless function may execute. These are covered below.

Edge

Edge compute runs close to the user, often in the same locations where CDNs run. Some of the providers above (CloudFlare, Fastly) host their edge environments. Others, such as Azure, Vercel, and Netlify, use environments provided by others. Notably, Azure Functions do not currently run on Azure’s edge, though we understand that to be a work in progress.

Cloud

Public clouds (which we have abbreviated to Cloud) run in large datacenters, like Azure, Google, Civo, Vultr and others. This box is marked “Supported” if it is possible for a developer to deploy to that services without running their own infrastracture. For example, one can run OpenWhisk in Google Cloud, but to do so must first set up GKE (Google Kubernetes) and then manually install the OpenWhisk runtime into GKE.

Kubernetes

Kubernetes is an orchestrator and scheduler. Some serverless applications can be run inside of Kubernetes. If a platform can be installed into Kubernetes using any of Kubernetes’ traditional installation means (Helm charts, manifests, operator framework, etc.), we consider it fully supported.

Local

We use the term “Local” to mean that the runtime can be installed locally for development or for production. For example, Spin can install onto a desktop or a RaspberryPi or a bare metal server, and does not need a larger orchestration system.

If a “non-production” version of a local runtime can be installed, we consider this partially supported. This may be due to restrictive licensing, incomplete feature set, or artificial limitations (such as low number of invocations)

Embedded

IoT, RaspberryPi, and constrained devices all fit into the definition of “embedded.” An embedded environment assumes that the serverless framework can execute under tighter resource constraints. For example, Spin runs in production inside of at least one automobile manufacturer’s cars.

For practical purposes, we’ve used 50MB memory on an 1-core ARM64 CPU as the limit though we’ve marked a few platforms as “partially supported” because with some additional resources they may be able to run in similar environments.

Wasm (WebAssembly)

WebAssembly is a sandboxed binary format that over two dozen languages can compile to. If this box is checked, then the runtime supports the Wasm specification plus the WASI system interface addition, and the Wasm binary can be invoked directly.

If it is marked partially supported, it does not support Wasm + WASI or it cannot be directly invoked. CloudFlare is an example of both conditions. It supports core WebAssembly 1.0, but does not support WASI (and so has no system interface). WebAssembly in CloudFlare can be embedded into JavaScript apps, but cannot be invoked directly. Writing at least some JS is required.

What Events Can They Handle?

The most common trigger for serverless functions is an HTTP event, such as an inbound HTTP request. Most serverless frameworks can also handle CloudEvents, which are HTTP-based. For some edge functions, it is unclear whether they support CloudEvents, but it is often impractical to do so (since the events are generated inside a datacenter).

Pubsub (Publish/Subscribe) describes non-HTTP pubsub systems like Kafka and Redis. For our purposes, if the framework provides any non-HTTP pubsub system, we mark it as supported.

Cron or Timer-based triggers are invoked periodically according to a timed event. Kubernetes has a default CronJob timer, so we assume that anything that runs inside of Kubernetes can use that facility.

Custom triggers are those where a platform user can define an arbitrary trigger. For example, Spin exposes a plugin-like system for custom triggers. Most of the time, this support requires that the platform itself is not hosted. So Lambda, CloudFlare and others do not provide this capability.

What Languages Do They Support?

• ¹ Languages that compile to Wasm v1 can be run inside of JS, but with shim code
• ² We believe any Wasm-capable language can run at least in a basic mode on Fastly
• ³ Our understanding is that it is easy to bring other languages to OpenFaaS if you can containerize them, but we could not figure out which languages were “officially” supported