Sometimes all you need is a single function. That is the core idea behind serverless computing: individual functions spin up on demand, perform a minimal piece of work—serving an API endpoint, returning static content, processing an event—and then shut down. The model is cost-efficient, resource-light, and requires little operational overhead.
Most of what we now call serverless computing grew from AWS Lambda, later joined by equivalent managed services on Microsoft Azure, Google Cloud Platform, and IBM Bluemix. However, a healthy ecosystem of open source serverless frameworks also exists. These projects range from foundations that commercial clouds build on top of, to experimental research platforms for exploring the boundaries of the model without commercial constraints.
The five frameworks below are self-contained serverless runtimes—not thin wrappers around a specific cloud provider’s service. Projects whose primary purpose is to facilitate an existing managed offering (such as Zappa for AWS Lambda) are out of scope here.
1. Apache OpenWhisk
Apache OpenWhisk is one of the most mature open source serverless frameworks available. Written primarily in Scala, it follows an event-driven model: triggers represent named event streams, actions are the functions that execute in response, and rules bind triggers to actions. A single trigger can chain multiple actions together, enabling simple workflows without a dedicated orchestration layer.
Actions can be written as JavaScript or Swift snippets, or packaged as arbitrary binaries inside Docker containers. OpenWhisk integrates with external services that expose webhooks or API endpoints—including GitHub and Slack—making it straightforward to build event-driven automations across SaaS tools.
IBM chose OpenWhisk as the foundation for its managed serverless offering on IBM Bluemix (now IBM Cloud Functions), which is a strong signal of production readiness. The project graduated through the Apache Incubator process and is a top-level Apache project.
Key characteristics
- Event-driven trigger/action/rule model
- Supports JavaScript, Swift, Python, Java, and Docker-packaged runtimes
- REST API and CLI for managing functions and triggers
- IBM Cloud Functions is built directly on OpenWhisk
2. Fission
Fission is a Kubernetes-native serverless framework created by Platform9. Rather than managing its own container scheduler, it runs on top of an existing Kubernetes cluster—whether that cluster is managed by Platform9 or self-hosted. This means your serverless functions share the same infrastructure and operational tooling as the rest of your Kubernetes workloads.
Functions are provisioned in Docker containers and executed in response to HTTP requests or other event triggers. One notable feature is pool-based pre-warming: Fission keeps a pool of idle containers ready so that commonly invoked functions avoid the cold-start penalty typical of serverless platforms.
The philosophical argument for Fission is that Kubernetes already solves the hard problems of scheduling, networking, and resilience. Serverless on Kubernetes lets developers focus purely on function logic while operators work with familiar Kubernetes primitives rather than a proprietary control plane.
Key characteristics
- Runs on any standard Kubernetes cluster
- Pre-warmed container pools reduce cold-start latency
- HTTP trigger support; integrates with Kubernetes ingress controllers
- Language support via container images—any language that fits in a container
3. IronFunctions
IronFunctions, from Iron.io, takes a container-first approach: each function is a Docker container. Because the unit of work is just a Docker image, IronFunctions is language-agnostic by design—any runtime that can be containerized is a valid choice. The only hard dependency is Docker and a Docker Hub account; an orchestrator like Kubernetes is optional rather than required.
Functions written in Go—the same language used to build IronFunctions itself—can be compiled and deployed directly from the framework’s CLI, making Go a particularly ergonomic choice. IronFunctions also features AWS Lambda compatibility: Lambda functions can be imported and executed within IronFunctions without modification, which provides a migration or multi-cloud path and reduces vendor lock-in.
Key characteristics
- Docker container as the fundamental unit of execution
- Language-agnostic: any containerizable runtime works
- AWS Lambda import compatibility
- Kubernetes and other orchestrators are optional, not required
4. Gestalt
Gestalt positions itself as a pre-integrated suite of microservices for cloud-native applications. Its serverless component—referred to by the project as the Lambda Engine—is one layer within that broader platform rather than a standalone tool.
The Lambda Engine supports a wide range of language runtimes out of the box, including JavaScript, Python, Go, Ruby, Scala, and .NET. If your language is not on the default list, Gestalt supports custom executor implementations. Deployment targets include Kubernetes clusters (installed via Helm) and Mesosphere DC/OS, so the framework fits naturally into organisations that already operate either of those orchestration platforms.
Note: Claims about Gestalt’s performance relative to AWS Lambda in the original source article are not independently verified. Treat such comparisons with caution until you can benchmark against your own workloads.
Key characteristics
- FaaS is one component of a broader cloud-native platform
- Broad language support; extensible with custom executors
- Helm-based install for Kubernetes; DC/OS installer also available
- Designed for organisations already invested in Kubernetes or Mesosphere
5. OpenLambda
OpenLambda is not designed for production. It is an academic and research project whose stated goal is to enable exploration of new approaches to serverless computing. The project’s accompanying research paper outlines its intentions explicitly: provide a minimal, hackable platform where researchers and engineers can experiment with the fundamentals of serverless design without the constraints imposed by a production-ready system.
Only basic functionality is implemented, and the developers themselves warn against production deployment due to intentional security trade-offs made in favour of simplicity and explorability. If you want to understand what happens at the lowest layers of a serverless runtime—scheduling, isolation, cold-start mechanisms—OpenLambda gives you a small, readable codebase to work from.
Key characteristics
- Research and experimentation platform, not for production
- Minimal codebase designed for readability and modification
- Useful for understanding serverless internals at a low level
- Intentional security limitations—do not deploy in shared or public environments
Choosing the Right Framework
The right open source serverless framework depends on your existing infrastructure and goals:
- Already running Kubernetes? Fission integrates directly and adds pre-warming to reduce latency.
- Need AWS Lambda compatibility? IronFunctions imports Lambda functions and removes cloud lock-in.
- Want a battle-tested, cloud-vendor-backed option? Apache OpenWhisk is the most mature choice and powers IBM Cloud Functions.
- Operating a Kubernetes or DC/OS cluster and want broader platform features? Gestalt bundles serverless into a wider cloud-native stack.
- Researching serverless internals? OpenLambda provides a minimal, hackable foundation—just keep it off the public internet.
Open source serverless frameworks give teams control over runtime environment, deployment target, and cost model that managed cloud functions cannot match. As the ecosystem matures, several of these projects have already influenced or become the foundation of commercial offerings—a sign that the underlying designs are sound.
Original article source: infoworld.com (2017). Framework status and features may have evolved since publication—verify current documentation before adopting any project for production use.