The architectural decision behind evrtng Functions
The architecture of evrtng Functions – built on Apache OpenWhisk.
Introduction
We love serverless. But we love it even more when we retain control. When we at evrtng were faced with the decision to build our functions platform, one thing was clear: no proprietary system where a single provider dictates the rules. We wanted transparency—the ability to view and modify the code, an architecture that scales with us, and an ecosystem based on open standards. When you build a platform where other developers deploy their code, you need to understand every component—not just the API surface, but also what happens underneath.
That’s why we chose Apache OpenWhisk1 —an open-source serverless framework from the Apache Software Foundation with an event-driven, distributed architecture. OpenWhisk is no toy: It was originally developed by IBM, is used in production by several cloud providers, and has an active community that continuously evolves the code2. For us, it was the perfect foundation—robust enough for production, open enough for our customizations.
Why OpenWhisk?
Everyone knows the big providers: AWS Lambda, Google Cloud Functions, Azure Functions—solid platforms, no question. But they come with a hidden cost: vendor lock-in. Your code runs in a black box. Scaling behavior, cold-start optimizations, runtime versions—it’s all in the provider’s hands. You can provide feedback, but ultimately someone else decides when your runtime gets an update or how scheduling works. For a platform like evrtng, which aims to provide even developers with a stable foundation, that’s a no-go.
OpenWhisk gives us full control. The architecture is modular, every component is documented, and the entire stack is based on proven technologies2. If we want to optimize cold-start behavior, we can customize the Invoker. When we evaluate a new messaging system, we swap out Kafka. When we need to change the persistence layer, we replace CouchDB. No support ticket, no waiting for a feature release—we just do it ourselves.
The components of our stack
Every request to evrtng Functions passes through a chain of specialized components. Here’s what’s under the hood:
- Nginx – The entry point for all requests. Handles SSL termination and load balancing, and forwards requests to the controllers. Proven, fast, and configurable.
- Controller (Scala/Pekko) – The heart of the REST API. Authenticates requests against CouchDB, validates the action, and acts as a load balancer for invoker selection. Since October 2025, the controller has been running on Apache Pekko – the community fork of Akka, following Lightbend’s license change3.
- Apache Kafka – Our message broker between the controller and invoker. Ensures reliable delivery and immediately returns the ActivationId to the user. Asynchronous, resilient, and horizontally scalable – exactly what you need for event-driven architectures.
- CouchDB – The persistence layer for everything: actions, activations, namespaces, and auth data. Document-based, horizontally scalable, and equipped with multi-master replication – ideal for distributed setups.
- Invoker (Scala) – The execution engine. Spawns Docker containers, injects the user’s code, executes the function, and then destroys the container. Each execution is isolated—no state leakage between invocations.
- Docker – Each function runs in its own isolated container. File and network isolation ensure that functions do not interfere with one another. Security and predictability by design.
Modularity as a principle
What really impresses us about OpenWhisk is its consistent modularity. Every component is interchangeable. Want to swap CouchDB for a different database? Go ahead. Replace Kafka with an alternative messaging system? No problem. Modify the Invoker to use a different container runtime? Go for it. Everything is open source, everything is documented, and the interfaces between the components are clearly defined. This gives us the freedom to tailor the stack exactly to our needs—today and in the future.
Forecast
Now you know what components make up evrtng Functions and why we chose OpenWhisk. But how do these components work together when you actually call a function? In the next article, we’ll take you on a journey through a single invocation—step by step through the entire flow, from the HTTP request to execution in the container.
- Apache OpenWhisk – Official Documentation, https://openwhisk.apache.org ↩︎
- Apache OpenWhisk GitHub Repository, https://github.com/apache/openwhisk ↩︎
- Apache OpenWhisk Serverless for Kubernetes (FAUN), https://faun.pub/apache-openwhisk-serverless-for-kubernetes-820f62534f24 ↩︎
- Akka BSL Licence, https://akka.io/bsl-license-faq ↩︎
