Einleitung
Im August haben wir beschrieben, wie wir die Migration unserer Functions-Plattform auf Fission angehen wollten [1]. Heute können wir melden: Es ist vollbracht. Die Migration auf serverless-v4 ist abgeschlossen, alle produktiven Functions auf functions.evrtng.cloud laufen auf der neuen Plattform, und der alte OpenWhisk-Stack ist ausser Betrieb. Zur Serie: Artikel 1 erklärte im März, warum wir damals Apache OpenWhisk gewählt haben, Artikel 2 im August den technischen Tiefblick auf die Migration selbst [4]. Dieser Artikel gehört Ihnen. Wir fassen zusammen, was sich für Sie als Kundin oder Kunde von evrtng Functions ändert, was Sie jetzt besser bekommen als vorher, und warum wir einige unbequeme Entscheidungen bewusst in Kauf genommen haben, damit Ihr Code danach einfacher dasteht als davor.
Der Ausgangspunkt: ein Fundament ohne Zukunft
Ehrlich gesagt: Wir wären nicht umgezogen, wenn es einen einfacheren Weg gegeben hätte. Die Engine hinter unserer bisherigen Plattform, Apache OpenWhisk, hat sich nicht so weiterentwickelt, wie ein Produktivbetrieb über Jahre es braucht. Der Pekko-Fork, den wir als Brücke betrieben haben, ist inzwischen im ASF Attic gelandet, dem Archiv für ausgediente Apache-Projekte. Auf einem toten Fundament weiterzubauen wäre gegenüber unseren Kunden unverantwortlich gewesen: keine Sicherheitsupdates, keine Weiterentwicklung, kein Support, falls etwas passiert. Bleiben wäre kurzfristig bequem gewesen, langfristig aber ein Risiko, das wir Ihnen nicht zumuten wollten.
Deshalb haben wir auf Fission v1.27.0 gesetzt [2], eine aktiv gepflegte, Kubernetes-native Engine mit einer gesunden Community. Für Sie heisst das vor allem eines: Ihre Functions laufen auf einer Plattform, die weitergebaut wird, mit regelmässigen Updates und einem Betrieb, das nicht ständig gegen die eigene Grundlage arbeiten muss.
Sicherheit: Jeder Aufruf in einer eigenen virtuellen Maschine
Das wichtigste Ergebnis der Migration ist für uns kein Feature, sondern eine Garantie. Bei serverless-v4 läuft jeder einzelne Function-Aufruf in einer Firecracker-MicroVM [3], betrieben über Kata Containers. Firecracker ist dieselbe Technologie, die auch bei den grossen Cloud-Anbietern hinter serverless-Plattformen steckt. Der Unterschied zu klassischen Containern: Eine MicroVM ist eine echte virtuelle Maschine mit eigenem Kernel. Ihr Code und Ihre Daten sind damit auf Hypervisor-Ebene von anderen Tenants getrennt, nicht nur auf Containerebene.
Für Sie bedeutet das konkret: Die Isolation Ihrer Workloads entspricht der einer eigenen virtuellen Maschine, ohne dass Sie eine verwalten müssten. Sie konfigurieren nichts, Sie schalten nichts ein. Diese Isolationsstufe gilt für jeden Aufruf, bei jeder Function, in jedem Tarif. Zusätzlich laufen Function-Ausführungen auf eigenen, dedizierten Cluster-Nodes, vollständig getrennt vom Rest der Plattform. Ihre Ausführungen teilen sich Hardware mit anderen Functions, aber niemals einen Kernel.
Geschwindigkeit: Warme Pools statt kaltem Start
Isolation allein reicht nicht, wenn jede Anfrage träge antwortet. Deshalb haben wir warme Pools eingeführt. Häufig genutzte Functions bleiben vorgeladen und warten auf den nächsten Aufruf, statt bei jedem Request neu zu starten. Wir haben den Weg vom Eingang der Anfrage bis zur Antwort verkürzt, weil kein Container pro Aufruf neu erzeugt und wieder zerstört wird.
Spürbar ist das vor allem bei Functions, die regelmässig aufgerufen werden, etwa in einer Integration oder hinter einem Webhook: Sie antworten zügig, ohne Kaltstart-Pause. Auch unregelmässig genutzte Funktionen profitieren, weil der Nachschub an warmen Instanzen schneller nachrückt als früher. Ihr Vorteil: kurze, vorhersehbare Antwortzeiten auch im Tagesgeschäft, ohne dass Sie dafür irgendetwas tunen müssen.
Die neue API: einfacher schreiben, klarer lesen
Wir haben bewusst einen harten Schnitt gemacht und die Function-API vereinfacht. Die neue Signatur ist eine einzige, offensichtliche Form:
// Neu - serverless-v4
module.exports = async function(ctx) {
const name = ctx.body.name || "Welt";
return { status: 200, body: { message: `Hallo ${name}` } };
};Drei Änderungen im Überblick: Der Einstiegspunkt heisst jetzt module.exports, das Argument ist ein Kontext-Objekt statt nur der Parameter, und die Antwort nutzt status statt statusCode. Der öffentliche Pfad lautet /fission-function/*.
Das ist ein Breaking Change, und das war Absicht. Wir hätten eine Kompatibilitätsschicht bauen können, die beide API-Welten am Leben hält. Wir haben stattdessen den sauberen Schnitt bevorzugt: einmal kurz anpassen, danach für immer einfacher. Kompatibilitätsschichten wären zu Daueraufgaben geworden, mit Fehlerquellen, die Sie am Ende ausbaden müssten. Wer Funktionen aus v3 übernimmt, passt den Einstiegspunkt in wenigen Minuten an. Die Migrationsschritte haben wir im August-Artikel beschrieben [4], und unser Support begleitet die Umstellung, falls Sie Fragen haben.
Multi-Tenancy: garantierte Ressourcen, keine lauten Nachbarn
Auf einer geteilten Plattform ist die grösste Sorge klassischerweise: Was passiert, wenn ein anderer Tenant alle Ressourcen frisst? Wir haben diese Frage technisch entschieden, bevor sie Ihnen Sorgen macht. Jeder Tenant wird auf serverless-v4 als eigenes Objekt geführt, einem sogenannten FissionTenant, mit eigenen Kontingenten und eigener Trennung auf Kubernetes-Ebene. Limits gelten pro Tenant, nicht global.
Ihr Vorteil: Die Ressourcen, die Ihrem Tarif entsprechen, sind garantiert. Ein Nachbar mit Lastspitzen kann Ihre Function nicht ausbremsen, weil seine Ausführungen sauber von Ihren getrennt sind und seine Kontingente sein Kontingent bleiben. Das ist der Unterschied zwischen geteilt auf dem Papier und tatsächlich garantiert. Für Teams mit mehreren Umgebungen bedeutet die strenge Trennung zusätzlich: Produktion und Experimentieren kommen sich nicht in die Quere.
Abrechnung: nachvollziehbar bis auf den einzelnen Aufruf
Wir haben die Abrechnung selbst gebaut, damit sie nachvollziehbar ist. Abgerechnet wird in GB-Sekunden (GBS): Speicherbedarf mal Laufzeit, summiert über den Abrechnungszeitraum. Jeder einzelne Aufruf wird protokolliert: Unser API-Gateway schreibt bei jedem Request einen Log-Eintrag mit Pfad, Status, Latenz und Tenant, der direkt in unsere Billing-Pipeline fliesst und dort zu Ihrer Abrechnung verarbeitet wird.
Für Sie heisst das: Sie zahlen genau für das, was Sie nutzen, nicht für eine pauschale Schätzung. Und Sie können es nachprüfen. Wenn eine Rechnung eine Frage aufwirft, liegt jedem Betrag eine protokollierte Aufrufliste zugrunde. Keine Blackbox, keine geheimnisvollen Nutzungsdaten, sondern Buchung für Buchung. Diese Transparenz haben wir bewusst selbst in die Hand genommen, statt fremde, intransparente Nutzungsstände weiterzureichen.
Betrieben in der Schweiz
Souveränität ist bei uns kein Marketingbegriff, sondern ein Betriebsumstand. Die Plattform läuft vollständig in der Schweiz. Ihr Code bleibt in der Schweiz, Ihre Daten bleiben in der Schweiz, und der Betrieb nutzt dieselben bewährten Cluster-Werkzeuge wie bisher. Für Kunden mit Anforderungen an Datenlokalität ist das vermutlich die ruhigste Zeile dieses Artikels: nichts verlässt das Land, nichts muss es.
Entscheidungen, die wir für Sie getroffen haben
Komplexe Migrationen bestehen aus Dutzenden kleinen Entscheidungen. Vier davon haben das Ergebnis geprägt, und jede wurde mit Blick auf Sie getroffen.
Aktiv gepflegte Plattform statt Archiv. Wir haben OpenWhisk verlassen, weil sein Fork tot war. Bleiben wäre bequem gewesen, kurzfristig. Langfristig hätten Sie auf einem Fundament ohne Updates gestanden. Fission wird aktiv weiterentwickelt [2], Sie profitieren von Sicherheitsupdates und neuen Funktionen, ohne selbst Hand anzulegen.
Ein sauberer Bruch statt ewigem Ballast. Wir haben den Breaking Change der neuen API akzeptiert, damit die API danach für immer einfach bleibt. Zwei Signaturen parallel zu pflegen, hätte dauerhaft Fehlerquellen produziert. Kurz weht es, danach ist die Luft rein: eine offensichtliche Art, Functions zu schreiben.
MicroVM-Betrieb in eigener Regie. Firecracker-MicroVMs selbst zu betreiben ist komplex, das war der aufwendigste Teil der Migration. Genau diese Komplexität haben wir übernommen, damit Sie VM-Isolation bekommen, ohne selbst virtuelle Maschinen managen zu müssen. Sie schreiben Funktionen, wir kümmern uns um Hypervisor, Kernel und Betrieb.
Selbst gebaute Abrechnung statt Blackbox. Wir hätten Nutzungsdaten einfach aggregiert ausgeben können. Stattdessen haben wir eine Pipeline gebaut, die jeden Aufruf einzeln protokolliert, damit Ihre Abrechnung verifizierbar bleibt, bis auf die letzte Sekunde Rechenzeit.
Ausblick
Die Migration ist abgeschlossen, der Ausbau geht weiter. Das Self-Service-Portal läuft: Ihr Tenant wird bei der Registrierung automatisch angelegt, Kontingente ändern Sie selbst über Ihr Abo – beides ohne Support-Umweg. Als Nächstes verbessern wir die Trigger-Typen und das Entwickler-Erlebnis, damit Sie noch schneller von der Idee zur laufenden Function kommen.
Was Sie jetzt tun sollten: Falls Sie noch Funktionen aus v3 in der alten Signatur betreiben, passen Sie sie auf die neue API an. Die Schritte stehen im August-Artikel [4], und pro Funktion dauert es Minuten. Bei Fragen ist unser Support da. Danke, dass Sie mit uns umgezogen sind. Ihre Functions laufen jetzt auf einem Fundament, das hält: sicher getrennt, schnell genug für den Alltag, transparent abgerechnet, und alles in der Schweiz.
- August-Strategie-Artikel: https://evrtng.cloud/2026/08/15/serverless-computing-2026-update/
- Fission v1.27.0: https://fission.io
- Firecracker-MicroVM: https://firecracker-microvm.github.io
- Artikel 2 (Migration Deep Dive): https://functions.evrtng.cloud/2026/08/18/wie-wir-zu-fission-migrieren-serverless-v4/
