Serverless im Agent-Zeitalter

Warum der September 2026 bestätigt, was EVRTNG bereits betreibt

Der Serverless-Markt konvergiert auf isolierte, langlebige Compute-Umgebungen für Agenten.

Einleitung: Ein Monat der Bestätigung

Im März haben wir unsere Marktanalyse Serverless Computing 2026 veröffentlicht; im August folgte ein Update über die Konsolidierung des Marktes, das öffentliche Auslaufen von Apache OpenWhisk und unsere eigene Antwort: ein abgeschlossener Pekko-Fork, eine angekündigte Migration zu Fission und Kata-Firecracker als konstante Isolationsstufe. Dieser Artikel ist kein weiteres datumsbasiertes Update. Er ist eine These: Der Markt konvergiert auf die Architektur, die EVRTNG bereits betreibt - eine dünne, Kubernetes-native FaaS-Schicht, VM-Isolation und Pay-per-Use-Ökonomie.

Drei Entwicklungen der letzten fünf Wochen stützen diese These: Langlebige Workloads werden zum Normalfall, VM-Isolation wird zum Kaufkriterium, und Functions werden zu Agent-Werkzeugen. Und die Migration, die wir im August angekündigt haben, ist heute Produktrealität - functions.evrtng.cloud läuft auf Fission mit Firecracker-isolierten Workloads, auf Schweizer Infrastruktur.

Was seit Mitte August passiert ist

Fünf Wochen, eine Richtung. Die September-Releases lesen sich wie eine Checkliste der Anforderungen, die Agent-Workloads an Serverless-Plattformen stellen.

Chronologische Timeline

• 31. August - Google Cloud Run instances: Public Preview dedizierter Singleton-Runtimes für langlebige, stateful Workloads wie AI-Agenten - bis 7 Tage Laufzeit, stabile HTTPS-URL, 5,70 USD/Monat für 1 vCPU/1 GiB [Google Cloud]
• 1. September - Google Agent Platform: systemverwaltete Agent Identities und Agent Registry (Preview) zur Authentifizierung von Agenten und MCP-Servern auf Cloud Run; Go 1.27 Runtime GA [Google Cloud]
• 2. September - AWS Lambda SnapStart für Container-Images: Startzeiten sinken von mehreren Sekunden auf Sub-Sekunde für Functions als Container-Images - bis 10 GB [AWS]
• 4. September - AWS MCP Server: neue Serverless-Capability lässt Coding-Agents Lambda-Functions und ihre verbundenen Ressourcen diagnostizieren (API Gateway, EventBridge, S3, DynamoDB, SQS, Step Functions) [AWS]
• 9. September - AWS Lambda 90-Minuten-Timeout: 6× das bisherige Limit für asynchrone und ESM-Invocations auf Managed Instances; Durable Functions können Schritte bis zu 1 Jahr checkpointen [AWS]
• 9. September - AWS Graviton5 auf Lambda: C9g/M9g-Instances mit bis zu 25 % besserer Compute-Performance für Managed Instances [AWS]
• 10. September - Recursive-Loop-Detection in Europe Sovereign Cloud: Serverless-Sicherheitsfeatures erreichen souveräne Regionen - ein Signal, dass Souveränität zum Mainstream-Anspruch wird [AWS]
• 12. September - Firecracker v1.17.0: der MicroVM-Monitor hinter AWS Lambdas Isolation hält seinen stabilen Release-Rhythmus [Firecracker]
• 14. September - Azure Functions Runtime 1.x Support-Ende: v3 Linux Consumption stoppt am 30. September; das In-Process-Modell endet am 10. November - vollständige Konsolidierung auf v4 [Microsoft]
• 16. September - Kata Containers 4.2.0: das zweite Minor-Release nach der Rust-Rewrite-4.0.0 (runtime-rs als Default, 20. Juli) - Firecracker bleibt First-Class-VMM [Kata Containers]
• Laufend - Azure Connector Namespace (Preview): Logic-Apps-Connectors als .NET-SDK für code-first Function Apps [Microsoft]

Drei Konvergenzen

Liest man diese Releases zusammen, zeigt sich ein Muster, das über einzelne Features hinausgeht. Drei Linien laufen zusammen - und alle drei zeigen auf die Architektur, die wir im August beschrieben haben.

1. Langlebig wird der Normalfall

AWS verlängert das Lambda-Timeout auf 90 Minuten; Durable Executions laufen bis zu einem Jahr. Google führt einen eigenen Ressourcentyp ein, dessen ganzer Zweck Workloads sind, die tagelang laufen - ausdrücklich für AI-Agenten. Der FaaS-Reflex der frühen Jahre „ein Function ist ein kurzer Request" gilt nicht mehr. Agenten laufen Minuten, Tage oder Wochen, und Serverless-Plattformen, die nicht mithalten können, werden so lange erweitert, bis sie es können. Was im März ein Randfall war, ist heute der Mainline-Use-Case, auf den die Hyperscaler optimieren.

2. VM-Isolation wird zum Kaufkriterium

Agenten-Code ist nicht-vertrauter Code. Ihn in einem geteilten Container-Kernel auszuführen, ist eine Risikoentscheidung, die immer mehr Unternehmen nicht mehr treffen wollen. Der Markt reagiert: Firecracker - der VMM hinter AWS Lambda - shippt v1.17.0; Kata Containers liefert das dritte Release seit dem Rust-Rewrite, mit Firecracker als First-Class-VMM; und das Kubernetes sig-arch Agent Sandbox-Projekt empfiehlt kata-fc ausdrücklich für Serverless-Workloads. VM-Isolation ist vom Nischen-Feature zur Anforderung geworden - genau die Isolationsstufe, die EVRTNG auf seinen Invoker-Nodes bereits betreibt.

3. Functions werden Agent-Werkzeuge

Das Model Context Protocol wird zum Bindegewebe zwischen Agenten und Infrastruktur: AWS shippt eine Serverless-Diagnostics-Capability in seinem MCP Server, Google verwaltet Agent-Identitäten und eine zentrale Registry, Azure positioniert Functions als Runtime für Agenten und MCP-Server. Und Fission - die Engine, zu der EVRTNG migriert ist - hat in v1.26.0 Functions-as-MCP-Tools ausgeliefert. Ein Function ist nicht mehr nur ein HTTP-Endpoint; es ist ein Tool, das Agenten entdecken und aufrufen. Plattformen, die ihre Functions nicht so exponieren können, werden im Agent-Zeitalter unsichtbar.

EVRTNG: Die Migration ist abgeschlossen

Im August haben wir die Migration zu Fission als nächsten Schritt beschrieben. Heute ist sie Produktrealität: functions.evrtng.cloud läuft auf Fission, mit Function-Workloads in Firecracker-MicroVMs. Eine Python-Function deployt über die Provisioning-API und ist nach Sekunden unter ihrer Tenant-URL erreichbar - ohne Server, ohne Infrastruktur-Management.

Was die Migration konkret gebracht hat:

• Dünnere Engine-Schicht: keine CouchDB, kein Kafka für die FaaS-Engine - Function- und Trigger-State lebt in Kubernetes CRDs. Die operative Wartungsfläche ist messbar geschrumpft.
• Unveränderte Isolation: kata-fc übernimmt 1:1 über die Kubernetes-RuntimeClass - die stärkste Isolationsstufe hat den Stackwechsel ohne Modifikation überstanden.
• Unveränderte Commerce-Layer: billing-consumer, provisioning-api und quota-enforcer metern, provisionieren und erzwingen weiter - die Schicht, die aus einer FaaS-Engine ein Produkt macht.
• Transparentes Pricing: CHF 9.95/Monat Basis, CHF 0.20 pro Million Requests, Compute per GB-Sekunde - idle Functions kosten nichts.

Die Engine-Wahl bewährt sich auch in ihrer Roadmap. Fission v1.26.0 hat Gateway-API-Routing, OCI-native Package-Delivery und Streaming-Responses (SSE, chunked, WebSocket) ausgeliefert, die nicht mehr am Function-Timeout hängen - sowie Functions als MCP-Tools. Ein RFC für Function-Versionen, Aliases und Instant-Rollback ist in Review. Die Engine entwickelt sich also genau in die Richtung, die das Agent-Zeitalter verlangt: langlebige Streaming-Interaktionen, agenten-konsumierbare Tools, sichere Rollouts.

Auch die Isolation bleibt zukunftssicher. Mit Kata 4.x wird die Rust-basierte runtime-rs zur Standard-Runtime. Firecracker wird weiterhin voll unterstützt. Für uns bedeutet das: Wir aktualisieren die RuntimeClass im Cluster, mehr nicht. Keine Migration.

Was das für Kunden bedeutet

Die obigen Konvergenzen sind Marktbeobachtungen; das hier ist ihre Übersetzung für Teams, die heute auf EVRTNG Functions bauen.

Agent-Workloads ohne Kompromisse

Nicht-vertrauter oder Third-Party-Agenten-Code läuft hinter einer VM-Grenze - verschiedene Kunden teilen Hardware, aber niemals einen Kernel. Man muss nicht warten, bis ein Hyperscaler sein Timeout verlängert oder MicroVM-Sandboxes in der eigenen Region ausrollt; das Isolationsmodell, das AWS Lambda bei 15 Billionen monatlichen Invocations bewiesen hat, ist auf unseren Invoker-Nodes Standard.

Functions, die Agenten nutzen können

Mit Fissions MCP-Tool-Support lassen sich eigene Functions als Tools exponieren, die Agenten entdecken und aufrufen - keine separate MCP-Server-Infrastruktur nötig. Die Business-Logik einmal bauen; Menschen via HTTP bedienen, Agenten via MCP.

Workloads, die den 15-Minuten-Reflex überwachsen

Streaming-Responses - SSE, chunked, WebSocket - werden nicht mehr von einem Function-Timeout abgeschnitten. Agenten-Dialoge, langlaufende Transformationen und interaktive Workflows passen aufs Plattform-Modell, statt in architektonische Workarounds gequetscht zu werden.

Souveränität ab Tag eins

Während AWS die Recursive-Loop-Detection in seine Europe Sovereign Cloud bringt - ein lobenswerter Schritt -, ist Souveränität bei EVRTNG kein Produkt-Tier, sondern der Standort: Cluster in ch-ge1-az3, Daten, Logs und Activation-Records unter Schweizer Gerichtsbarkeit. Für regulierte Industrien ist das der Unterschied zwischen einem Feature-Request und einem unterschriebenen Vertrag.

Fazit: Der Markt bewegt sich auf eine Architektur zu, die bereits existiert

Der September 2026 hat die drei Wetten validiert, die wir im August gemacht haben. Langlebige Workloads: Die Hyperscaler erweitern ihre Plattformen, bis Agenten hineinpassen. VM-Isolation: Firecracker und Kata reifen im Gleichschritt, und Isolation wird zum Kaufkriterium. Agent-Integration: MCP wird zur Standardschnittstelle zwischen Agenten und Infrastruktur - und Fission unterstützt sie nativ.

Der Unterschied zwischen dem Beobachten dieses Trends und der Bereitschaft dafür ist eine Architektur. Unsere ist keine Roadmap-Position - sie läuft in Produktion: eine dünne, Kubernetes-native FaaS-Schicht, Firecracker-isolierte Workloads, eine Metering- und Billing-Schicht, die daraus ein Produkt macht, und ein Schweizer Cluster, das Kundendaten unter Schweizer Gerichtsbarkeit hält.

Der Serverless-Markt bewegt sich auf die Architektur zu, die EVRTNG bereits betreibt. Für Teams, die heute Agent-Workloads bauen, ist die Frage nicht, ob Plattformen sie unterstützen werden - sondern ob man wartet oder dort baut, wo die Unterstützung bereits existiert. functions.evrtng.cloud ist dieser Ort.

1. Google Cloud Blog, "Introducing Cloud Run instances," August 31, 2026, Google Cloud - Cloud Run instances; Sara Ford, "Continuing the coffee shop saga with Cloud Run instances," September 14, 2026 ↩︎
2. Google Cloud Run release notes, September 1, 2026 - Agent Platform Agent Identities, Agent Registry (preview), Go 1.27 GA, cloud.google.com/run/docs/release-notes ↩︎
3. AWS, "AWS Lambda now supports SnapStart for container image functions," September 2, 2026, aws.amazon.com/about-aws/whats-new; InfoQ, "Lambda SnapStart Comes to Container Images," September 12, 2026 ↩︎
4. AWS, "AWS MCP Server adds a serverless capability for AWS Lambda functions," September 4, 2026, aws.amazon.com/about-aws/whats-new ↩︎
5. AWS, "AWS Lambda now supports 90-minute function timeout on Lambda Managed Instances," September 9, 2026, aws.amazon.com/about-aws/whats-new ↩︎
6. AWS, "AWS Lambda now supports Graviton5-powered EC2 instances on Lambda Managed Instances," September 9, 2026, aws.amazon.com/about-aws/whats-new ↩︎
7. The AWS News Feed, "AWS Lambda recursive loop detection is now available in Europe Sovereign Cloud," September 10, 2026, aws-news.com ↩︎
8. Fission v1.26.0 release notes - Gateway API route provider, OCI-native package delivery, streaming responses, functions as MCP tools, fission.io/docs/releases/v1.26.0; RFC-0025 (function versions, aliases, instant rollback), PR fission/fission#3599 ↩︎
9. Firecracker v1.17.0 release, September 2026, github.com/firecracker-microvm/firecracker ↩︎
10. Kata Containers 4.0.0 (July 20, 2026, runtime-rs as default), 4.1.0 (August 21, 2026), 4.2.0 (September 16, 2026), github.com/kata-containers - releases ↩︎
11. Microsoft Learn, "Compare Azure Functions runtime versions" - v1.x support ends September 14, 2026; v3 Linux Consumption stops September 30, 2026; in-process model ends November 10, 2026, learn.microsoft.com - functions-versions ↩︎
12. EVRTNG Cloud Functions, evrtng.cloud/functions; Functions platform, functions.evrtng.cloud ↩︎
13. AWS Lambda MicroVMs, June 2026 GA - Firecracker design paper, aws.amazon.com/blogs/aws; invocation scale per EVRTNG Serverless Computing 2026 - Update August ↩︎