Serverless Computing 2026 — Update August

Was sich seit März 2026 getan hat – und warum EVRTNG den Stack wechselt

Fünf Monate, die den Serverless-Markt neu sortiert haben.

Einleitung: Fünf Monate, die den Markt neu sortieren

Am 22. März 2026 haben wir unsere Analyse Serverless Computing 2026 veröffentlicht, in der wir den globalen Markt auf USD 28 Milliarden (2025) schätzten und USD 92 Milliarden bis 2034 projizierten. Fünf Monate später hat sich das Bild deutlich geschärft: Mordor Intelligence bewertet den Markt 2026 nun auf USD 32,59 Milliarden und projiziert USD 91,56 Milliarden bis 2031 — der Prognosehorizont ist fünf Jahre näher gerückt. Der Markt wächst schneller als erwartet.

Dieses Update behandelt drei Entwicklungen, die die Landschaft seit März neu geformt haben: (1) fünfzehn Business-Events zwischen April und August 2026, die einen Markt in Konsolidierung signalisieren, (2) das öffentliche Auslaufen von Apache OpenWhisk — der Plattform, auf der unser Originalartikel basierte — und (3) EVRTNGs Antwort: ein abgeschlossener Pekko-Fork in Produktion, eine laufende Migration zu Fission, und Kata-Firecracker als konstante Isolationsstufe über beide Stack-Generationen hinweg.

Markt-Update April–August 2026: Fünfzehn Ereignisse, die zählen

Die Periode seit unserem März-Artikel war die aktivste in der Serverless-Geschichte. Konsolidierung, KI-native Pivotierungen und vertikale Hyperscaler-Plays dominieren.

Chronologische Timeline

• 13. April — Vercel: IPO-Signal, ARR 340 Mio. USD, 30 % der Apps agent-generiert [TechCrunch]
• 28. April — DigitalOcean: AI-Native Cloud Launch, RPO 10× auf 800 Mio. USD angehoben [BusinessWire]
• 5. Mai — Cloudflare Investor Day: 50 % niedrigere TCO als AWS Lambda behauptet [Cloudflare]
• 7. Mai — Cloudflare Q1: 639,8 Mio. USD Umsatz (+34 %), 1.100 Entlassungen, „agentic AI-first»-Pivot; ein AI Studio skalierte 0→1M+ Dynamic Workers in 15 Tagen [Cloudflare Earnings]
• 19. Mai — Anthropic: Übernahm Stainless (SDK-Generierung) für >300 Mio. USD [TechCrunch]
• 1. Juni — AWS Lambda: Managed Instances regionsweit GA, 15 % EC2-Aufschlag für dedizierte Kapazität [AWS]
• 19. Juni — Azure Functions: Serverless Agents Runtime auf Build angekündigt, .agent.md-Manifest, „no agents tax»-Positionierung [InfoQ/Microsoft]
• 13. Juli — Prefect übernimmt Dagster: Zwei Airflow-Rivalen fusionieren für agentic Data Orchestration [The New Stack]
• 22. Juli — Google Cloud Q2: 24,8 Mrd. USD Umsatz (+82 %), 514 Mrd. USD Backlog, 90 % der Fortune 100 auf Gemini [Alphabet/CNBC]
• 30. Juli — AWS Q2: 42,23 Mrd. USD Umsatz (+37 %, schnellstes Wachstum seit 2021), 496 Mrd. USD Backlog, 169 Mrd. USD Run Rate, OpenAI-+Meta-Deals [CNBC/Reuters]
• 30. Juli — Nscale übernimmt Anyscale: ~1,65 Mrd. USD vertikale AI-Hyperscaler-Konsolidierung [TechCrunch]
• 6. August — Synergy Research: AWS-Anteil 28 % (−2 Pts), Google Cloud 15 % (+2 Pts, Rekord), Gesamtmarkt +43 % YoY — 8-Jahres-Hoch [CRN]
• 11. August — Databricks übernimmt Electric: PGlite/WASM Postgres für disposable Agent-Datenbanken [The New Stack]
• April–August fortlaufend — Apache OpenWhisk: Öffentliches Auslaufen laut Board-Minuten (siehe nächste Sektion) [Apache Whimsy]

Marktzahlen: Wachstum beschleunigt sich

Mordor Intelligence (31. Juli 2026) bewertet den Serverless-Markt auf USD 32,59 Milliarden für 2026 und projiziert USD 91,56 Milliarden bis 2031 bei einer CAGR von 22,94 %. Das liegt vor unserer März-Prognose (USD 28 Mrd.→USD 92 Mrd. bis 2034) — dasselbe Ziel, fünf Jahre früher.

Synergy Research (6. August) meldet, dass der Cloud-Infrastrukturmarkt um 43 % Jahr-over-Jahr wuchs — die höchste Rate seit acht Jahren. AWS verlor 2 Prozentpunkte Anteil (nun 28 %), Google Cloud gewann 2 (nun 15 %, Rekord). IDC misst das reine FaaS-Segment auf USD 6,0 Mrd. für CY2025, +38,2 % YoY, mit Cloudflare als am schnellsten wachsendem Anbieter bei 79,8 %.

Das Muster ist klar: Die Hyperscaler wachsen absolut, aber die Anteilsverteilung gleicht sich aus — und KI-getriebenes Serverless (Cloudflare Workers, Azure Agents, Lambda MicroVMs) ist der Wachstumsvektor.

Apache OpenWhisk: Das Ende einer Ära

Unser März-Artikel beschrieb EVRTNG Functions als gebaut auf „der Apache OpenWhisk Engine». Fünf Monate später braucht dieser Satz ein Update — nicht weil EVRTNG OpenWhisk verlassen hat, sondern weil OpenWhisk selbst sich verabschiedet.

IBM Cloud Functions, die größte kommerzielle OpenWhisk-Deployment, erreichte im Oktober 2024 das End-of-Life. Neue Entities wurden Dezember 2023 blockiert; verbleibende Funktionen wurden Oktober 2024 gelöscht. IBMs offizielles Migrationsziel ist IBM Cloud Code Engine, eine Knative-basierte Plattform. Die ibm-functions GitHub-Repositories sind archiviert.

Das Apache OpenWhisk-Projekt wurde fünf Quartale in Folge bis Mai 2026 als Dormant eingestuft. Im Juni 2026 wies der ASF-Vorstand „counsel an, die OPENWHISK-Registrierungen in Frankreich erlöschen zu lassen» — der erste rechtliche Schritt zur formellen Auflösung. PMC-Vorsitzender Dave Grove erklärte im Mai 2025: „Nutzer von OpenWhisk haben sich anderen Serverless-Plattformen zugewandt … das Projekt scheint sich abzuwickeln und sollte 2026 ernsthaft über einen Übergang zum Attic diskutieren.»

Qualtrics, das OpenWhisk fast ein Jahrzehnt betrieb und die Pekko-Migration im Oktober 2025 leitete, kündigte am 16. Oktober 2025 öffentlich an, die OpenWhisk-Nutzung bis 2027 einzustellen und zu einer internen „next generation platform» zu wechseln. Naver Cloud (Korea) betreibt noch einen OpenWhisk-basierten Cloud Functions-Service, deprecate jedoch im September 2025 die meisten Runtimes und spendete IDE-Plugins an das ASF — ein Wartungsmodus-Signal.

Adobe I/O Runtime bleibt die bemerkenswerte Ausnahme: noch OpenWhisk-basiert, noch aktiv, kein Deprecation-Signal. Es untermauert Adobe App Builder. OpenServerless (Apache Incubating, von Nuvolaris im Juni 2024 gespendet) ist die einzige aktive Downstream-Distribution von OpenWhisk, aber sein Schicksal ist an das Upstream gebunden.

Wohin migrieren die Nutzer?

Ein OpenWhisk-PMC-Bericht vom November 2023 nannte vier Ziele: Knative, OpenFaaS, Fission und Nuclio — beschrieben als „dünnere FaaS-Schichten auf top of fairly general Container-as-a-Service-Runtimes». IBM Code Engine selbst ist Knative-basiert. Das Muster ist konsistent: Der Markt bewegt sich von OpenWhisks selbst-contained Stack (eigene Datenbank, eigener Message Bus, eigener Invoker) hin zu dünneren Kubernetes-nativen Schichten.

EVRTNGs Antwort: Der Pekko-Fork

Als die Akka-Lizenz sich 2023 zu BUSL änderte, forkte die Apache-Community Pekko unter Apache License 2.0. OpenWhisk mergte Pekko-Support im Oktober 2025 (PR #5551) — ein Breaking Change, der vollständiges Cluster-Redeployment erforderte. EVRTNG schloss diese Migration ab und betreibt jetzt einen eigenen Pekko-Fork von OpenWhisk in Produktion, gepflegt in einer privaten Registry. Das war keine defensive Maßnahme; es war die Voraussetzung, um operativ zu bleiben, während der nächste Schritt geplant wurde.

Das EVRTNG Serverless Cluster — sechs Schichten, dreizehn Knoten, Swiss Zone ch-ge1-az3.

Das Cluster, verifiziert am 15. August 2026, läuft auf Gardener on EWCS in der Schweizer Verfügbarkeitszone ch-ge1-az3. Dreizehn Knoten: acht a1.large Core-Nodes und fünf a1c.large Invoker-Nodes mit dem Label katacontainers.io/kata-runtime=true. Der Stack:

• OpenWhisk (Pekko-Fork): Controller, 5× Invoker (StatefulSet), user-events — alle auf Image-Tag :pekko-1.0 aus EVRTNGs privater Registry
• Data Layer: CouchDB 3.5.2 (10Gi PVC), Strimzi Kafka 1.1.0 (10Gi PVC), Redis 7.4 (1Gi PVC)
• Edge: APISIX (2 Replicas + 3-Node etcd), Traefik, Nginx 1.27.5 (NodePort 80/443)
• Observability: Prometheus v3.13.1 (10Gi PVC), Grafana 12.4.5 mit 8 Custom Dashboards, node-exporter DaemonSet auf allen 13 Nodes
• Commerce Layer: billing-consumer, provisioning-api, quota-enforcer (CronJob, ~15min), private registry:2 (5Gi PVC)
• Backup: K8up + Restic, verifizierter Restore 144 Minuten bevor dieser Artikel geschrieben wurde

Der Fork war eine taktische Brücke, kein Endzustand. Einen Fork eines Projekts zu betreuen, das ins Attic geht, bedeutet, die gesamte Wartungslast allein zu tragen — tragbar für eine Übergangszeit, nicht tragbar als permanente Strategie. Die Frage war nie ob migriert wird, sondern wohin.

Der nächste Schritt: Migration zu Fission

EVRTNG migriert zu Fission, dem CNCF Sandbox FaaS-Framework. Die Wahl deckt sich mit den Migrations-Empfehlungen des OpenWhisk-PMC vom November 2023 — Fission wurde neben Knative, OpenFaaS und Nuclio als Ziel benannt.

Wo OpenWhisk ein selbst-contained verteiltes System ausliefert (CouchDB für State, Kafka für Messaging, eigener Invoker-Prozess für Container-Lifecycle), ist Fission ein CRD-basiertes Control Plane on top of the Kubernetes API Server. Keine eigene Datenbank. Kein eigener Message Bus. Kein eigener Load Balancer. Function- und Trigger-State lebt in Kubernetes CRDs; Function-Pods werden von Kubernetes direkt gescheduled. Der Trade-off: Fission setzt voraus, dass man Kubernetes bereits gut betreibt — was EVRTNG tut.

Warum Fission?

• Dünnere Schicht: Fission addet ~5 Controller + CRDs. OpenWhisk addet einen vollständigen verteilten Stack. Weniger Code zu warten, weniger bewegliche Teile, die scheitern können.
• Kubernetes-nativ: Keine CouchDB, kein Kafka zu betreiben. State lebt in etcd via CRDs. Backups, RBAC und Observability nutzen die vorhandene Kubernetes-Toolchain.
• RuntimeClass-Support: Fissions PodSpec-Allowlist erhält runtimeClassName explizit, sodass Kata-Firecracker als Top-Isolationsstufe ohne Custom-Integration anhängt.
• Apache 2.0, aktiv: Fission v1.27.0 erschien am 22. Juni 2026. CNCF Sandbox-Governance ist leichter als Knatives Incubating-Status — ein Trade-off, den man ehrlich benennen sollte.

Ein Hinweis zur Governance: Fission ist CNCF Sandbox, nicht Incubating oder Graduated. Es hat keine TOC-Due-Diligence durchlaufen. Commit-Aktivität konzentriert sich auf einen einzigen Maintainer. Wir faktorieren dies in unseren Migrationsplan ein — der Wert von Fission liegt in seiner Einfachheit, die die Wartungsoberfläche reduziert, falls die Upstream-Aktivität nachlässt.

Konstant: Kata-Firecracker als höchste Isolationsstufe

Über beide Stack-Generationen hinweg — OpenWhisk-Pekko und Fission — bleibt Kata-Firecracker die höchste Isolationsstufe. Das ist kein Fission-Feature und kein OpenWhisk-Feature; es ist ein Kubernetes-RuntimeClass-Feature, und beide Stacks erhalten es.

Kata Containers 3.31.0 (veröffentlicht 19. Mai 2026) liefert die kata-fc RuntimeClass, die Function-Pods an eine Firecracker-MicroVM via io.containerd.kata-fc.v2-Shim routet. Der Stale-Process-Bug (#13008), der dichte FaaS-Deployments beeinträchtigte, wurde in dieser Version behoben. Kata 4.0.0 ist in Preview mit runtime-rs als Default, aber Firecracker bleibt ein First-Class-VMM.

AWS Lambda beweist Firecrackers Production-Fitness im Hyperscale-Maßstab — über 15 Billionen Invocations pro Monat. Lambda nutzt Firecracker direkt, nicht via Kata. Das Kubernetes sig-arch Agent Sandbox-Projekt empfiehlt kata-fc explizit für „serverless-style workloads» mit ~125ms Boot-Zeiten. Für EVRTNG ist kata-fc auf den fünf Invoker-Nodes (a1c.large, gelabelt katacontainers.io/kata-runtime=true) die Isolationsgrenze für nicht-vertraute Workloads — und sie bleibt unverändert in die Fission-Migration bestehen.

Was das Cluster liefert – Business-Perspektive

Die technische Architektur übersetzt sich in vier konkrete Business-Outcomes — die Gründe, warum das Cluster existiert, nicht nur wie es gebaut ist.

Vier Quadranten Business-Value — Souveränität, Isolation, Observability, Commerce.

1. Schweizer Souveränität

Das Cluster läuft in Verfügbarkeitszone ch-ge1-az3 auf Gardener on EWCS (Schweiz). Daten, Logs und Activation-Records bleiben unter Schweizer Gerichtsbarkeit. Für Enterprise-Kunden in regulierten Industrien — Finanzwesen, Healthcare, Regierung — ist das kein Feature; es ist eine Voraussetzung. Kein Hyperscaler-FaaS bietet eine Schweizer Souveränitäts-Story auf dieser Schicht.

2. Kata-Firecracker-Isolation

Fünf Invoker-Nodes laufen mit katacontainers.io/kata-runtime=true, was bedeutet, dass nicht-vertraute Function-Workloads in Firecracker-MicroVMs ausgeführt werden — VM-Level-Isolation, nicht Container-Level. Multi-Tenant-Workloads verschiedener Kunden teilen Hardware, aber keinen Kernel. Das ist das Isolationsmodell, das AWS Lambda pioneered hat; EVRTNG liefert es auf Kubernetes, via Standard-RuntimeClass, auf Schweizer Infrastruktur.

3. Full-Stack-Observability

Prometheus v3.13.1 scrapet Metriken aus jeder Schicht — OpenWhisk-Controller und -Invoker, Kubernetes-Nodes (node-exporter DaemonSet auf allen 13 Nodes), APISIX-Edge, CouchDB, Kafka. Grafana 12.4.5 liefert acht Custom Dashboards, aktualisiert 29 Stunden vor diesem Artikel. Ein k8s-health-monitor CronJob führt kontinuierliche Health-Checks aus. Kunden müssen ihre Functions nicht instrumentieren, um Visibility zu bekommen — die Plattform liefert sie.

4. Commerce-Layer — Operationale Unabhängigkeit

Vier proprietäre Workloads machen dies zu einem Produkt, nicht zu einem Deployment: billing-consumer (Python 3.12) metert Function-Executions; provisioning-api (Python 3.12) managt Customer-Onboarding und Namespace-Lifecycle; quota-enforcer (CronJob, ~15-Minuten-Intervall) verhindert Resource-Overruns; registry:2 (5Gi PVC) hostet Function-Images privat. Diese Schicht ist es, die EVRTNG Functions von „OpenWhisk on Kubernetes» unterscheidet — es ist die Commerce- und Governance-Schicht, die einen FaaS-Engine in ein abgerechnetes, gemeteretes, kundenorientiertes Produkt verwandelt.

Fazit: Independent Serverless ist eine Architektur, keine Behauptung

Die fünf Monate seit unserem März-Artikel haben die Serverless-Landschaft geklärt. Die Hyperscaler wachsen absolut, gleichen sich aber im Anteil aus. KI-getriebenes Serverless ist der Wachstumsvektor. Und Apache OpenWhisk — die Plattform, auf der unser Originalartikel basierte — wird öffentlich abgewickelt, mit IBM, Qualtrics und Naver, die alle aussteigen oder deprecate.

EVRTNGs Antwort ist dreiteilig und bereits in Bewegung: Der Pekko-Fork ist in Produktion (verifiziert), die Migration zu Fission läuft (architektonisch solide, RuntimeClass-kompatibel), und Kata-Firecracker bleibt die konstante Isolationsstufe über beide Stack-Generationen. Das Cluster in ch-ge1-az3 — dreizehn Knoten, Schweizer Souveränität, volle Observability, eine Commerce-Schicht, die metert und abrechnet — ist der Beweis.

Independent Serverless ist keine Marketing-Position. Es ist ein Cluster, auf das man zeigen kann, ein Fork, den man pflegt, eine Migration, zu der man sich bekannt hat, und eine Isolationsstufe, die man nicht kompromittiert. Das ist es, was EVRTNG Functions per August 2026 liefert.

1. Mordor Intelligence, Serverless Computing Market — Global Forecast to 2031, 31. Juli 2026, mordorintelligence.com/industry-reports/serverless-computing-market ↩︎
2. Synergy Research Group, Cloud Infrastructure Market Q2 2026, via CRN, 6. August 2026; IDC FaaS Tracker CY2025, idc.com ↩︎
3. IBM Cloud Functions End-of-Life-Ankündigung; Dave Tropeano, „Migrating IBM Cloud Functions to Code Engine“, IBM Blog, Februar 2024, ibm.com/blog ↩︎
4. Apache Software Foundation Board Minutes, OpenWhisk-Statusberichte November 2024 – Juni 2026, whimsy.apache.org/board/minutes ↩︎
5. Brendan Doyle (Qualtrics), E-Mail an dev@openwhisk.apache.org, 16. Oktober 2025, lists.apache.org — dev@openwhisk ↩︎
6. Apache OpenWhisk PMC, „Serverless Landscape and OpenWhisk Position“, November 2023 Bericht, openwhisk.apache.org ↩︎
7. Fission v1.27.0, github.com/fission/fission — v1.27.0; RuntimeClass-Allowlist: pkg/executor/util/merge_allowlist.go, Commit 1e1401c ↩︎
8. Kata Containers 3.31.0 Release, 19. Mai 2026, github.com/kata-containers — 3.31.0; Stale-Process-Fix: PR #13009 ↩︎
9. AWS Lambda MicroVMs, Juni 2026 GA; Firecracker Design-Paper, aws.amazon.com/blogs/aws ↩︎
10. EVRTNG Cloud Functions, evrtng.cloud/functions; Functions-Plattform, functions.evrtng.cloud ↩︎