Warum wir Apache OpenWhisk gewählt haben

Die Architektur-Entscheidung hinter evrtng Functions

Die Architektur von evrtng Functions – aufgebaut auf Apache OpenWhisk.

Einleitung

Wir lieben Serverless. Aber wir lieben es noch mehr, wenn wir die Kontrolle behalten. Als wir bei evrtng vor der Entscheidung standen, unsere Functions-Plattform aufzubauen, war klar: Kein proprietäres System, bei dem ein einziger Anbieter die Regeln diktiert. Wir wollten Transparenz – den Code einsehen und verändern können, eine Architektur, die mitwächst, und ein Ökosystem, das auf offenen Standards basiert. Wenn du eine Plattform baust, auf der andere Entwickler ihren Code deployen, dann musst du jeden Baustein verstehen – nicht nur die API-Oberfläche, sondern auch das, was darunter passiert.

Deshalb haben wir uns für Apache OpenWhisk entschieden¹ – ein Open-Source-Serverless-Framework der Apache Software Foundation mit einer Event-getriebenen, verteilten Architektur. OpenWhisk ist kein Spielzeug: Es wurde ursprünglich von IBM entwickelt, wird in Produktion von mehreren Cloud-Anbietern eingesetzt und hat eine aktive Community, die den Code kontinuierlich weiterentwickelt². Für uns war das die perfekte Grundlage – robust genug für Produktion, offen genug für unsere Anpassungen.

Warum OpenWhisk?

Die grossen Anbieter kennt jeder: AWS Lambda, Google Cloud Functions, Azure Functions – solide Plattformen, keine Frage. Aber sie kommen mit einem Preis, der nicht auf der Rechnung steht: Vendor Lock-in. Dein Code läuft in einer Blackbox. Skalierungsverhalten, Cold-Start-Optimierungen, Runtime-Versionen – alles in der Hand des Anbieters. Du kannst Feedback geben, aber am Ende entscheidet jemand anderes, wann deine Runtime ein Update bekommt oder wie sich das Scheduling verhält. Für eine Plattform wie evrtng, die selbst Entwicklern eine stabile Grundlage bieten will, ist das ein No-Go.

OpenWhisk gibt uns die volle Kontrolle. Die Architektur ist modular, jede Komponente ist dokumentiert, und der gesamte Stack basiert auf bewährten Technologien³. Wenn wir das Cold-Start-Verhalten optimieren wollen, können wir den Invoker anpassen. Wenn wir ein neues Messaging-System evaluieren, tauschen wir Kafka aus. Wenn wir die Persistenzschicht ändern müssen, ersetzen wir CouchDB. Kein Ticket an den Support, kein Warten auf ein Feature-Release – wir machen es einfach selbst.

Die Komponenten unseres Stacks

Jede Anfrage an evrtng Functions durchläuft eine Kette von spezialisierten Komponenten. Hier ist, was unter der Haube steckt:

• Nginx – Eintrittspunkt für alle Requests. Übernimmt SSL-Terminierung, Load Balancing und leitet Anfragen an die Controller weiter. Bewährt, schnell, konfigurierbar.
• Controller (Scala/Pekko) – Das Herzstück der REST-API. Authentifiziert Requests gegen CouchDB, validiert die Action und fungiert als Load Balancer für die Invoker-Auswahl. Seit Oktober 2025 läuft der Controller auf Apache Pekko – der Community-Fork von Akka, nachdem Lightbend die Lizenz geändert hat⁴.
• Apache Kafka – Unser Message Broker zwischen Controller und Invoker. Sorgt für Reliable Delivery und gibt die ActivationId sofort an den Nutzer zurück. Asynchron, resilient und horizontal skalierbar – genau das, was du für Event-getriebene Architekturen brauchst.
• CouchDB – Die Persistenzschicht für alles: Actions, Activations, Namespaces und Auth-Daten. Dokumentenbasiert, horizontal skalierbar und mit Multi-Master-Replikation ausgestattet – ideal für verteilte Setups.
• Invoker (Scala) – Der Ausführungsmotor. Spawnt Docker-Container, injiziert den Code des Nutzers, führt die Function aus und zerstört den Container danach wieder. Jede Ausführung ist isoliert – kein State-Leaking zwischen Invocations.
• Docker – Jede Function läuft in einem eigenen, isolierten Container. Datei- und Netzwerk-Isolation sorgen dafür, dass Functions sich gegenseitig nicht beeinflussen. Sicherheit und Vorhersagbarkeit by Design.

Modularität als Prinzip

Was uns an OpenWhisk besonders überzeugt, ist die konsequente Modularität. Jede Komponente ist austauschbar. Du willst CouchDB gegen eine andere Datenbank tauschen? Geht. Kafka gegen ein alternatives Messaging-System ersetzen? Kein Problem. Den Invoker modifizieren, um ein anderes Container-Runtime zu nutzen? Mach es. Alles ist Open Source, alles ist dokumentiert, und die Schnittstellen zwischen den Komponenten sind klar definiert. Das gibt uns die Freiheit, den Stack exakt auf unsere Bedürfnisse zuzuschneiden – heute und in Zukunft.

Ausblick

Du weisst jetzt, welche Bausteine hinter evrtng Functions stecken und warum wir uns für OpenWhisk entschieden haben. Aber wie arbeiten diese Komponenten zusammen, wenn du tatsächlich eine Function aufrufst? Im nächsten Artikel nehmen wir dich mit auf die Reise einer einzelnen Invocation – Schritt für Schritt durch den gesamten Flow, vom HTTP-Request bis zur Ausführung im Container.

1. Apache OpenWhisk – Official Documentation, https://openwhisk.apache.org ↩︎
2. Apache OpenWhisk GitHub Repository, https://github.com/apache/openwhisk ↩︎
3. Apache OpenWhisk Serverless for Kubernetes (FAUN), https://faun.pub/apache-openwhisk-serverless-for-kubernetes-820f62534f24 ↩︎
4. Akka BSL Lizenz, https://akka.io/bsl-license-faq ↩︎