Relay bietet selbst gehostete, ereignisgesteuerte Laufzeitumgebung für Funktionen und Dienste

Am 7. Oktober 2026 stellte der GitHub-Nutzer sergiors Relay vor, ein neues Open-Source-Projekt, das darauf ausgelegt ist, ereignisgesteuerte Anwendungen auf selbst verwalteter Infrastruktur auszuführen. Diese Laufzeitumgebung ermöglicht es Entwicklern, serverlose Funktionen, geplante Aufgaben und langlaufende Dienste innerhalb eines einzigen deklarativen Modells bereitzustellen, wodurch proprietäre Cloud-Plattformen überflüssig werden.

Was passiert ist

Relay fungiert als einheitliche Ausführungsumgebung, die drei verschiedene Arten von Workloads verarbeitet: ephemere Funktionen, die durch externe Ereignisse ausgelöst werden, Funktionen, die durch zeitbasierte Zeitpläne angestoßen werden, sowie persistente Dienste, die kontinuierlich laufen. Das System basiert auf dem Konzept einer "App", die als zentrale Einheit für Quellcode, Konfiguration und Bereitstellung dient. Innerhalb dieser App können Entwickler kurzlebige Funktionen mit langlaufenden Prozessen wie APIs oder Workern mischen, wobei alle dieselben Netzwerk-, Geheimnis- und Ressourcenkontrollen nutzen.

Die Laufzeitumgebung verlässt sich stark auf Redis Streams zur Verwaltung der Nachrichtenübermittlung und des Zustands. Wenn ein externes Ereignis auftritt, gelangt es in einen Redis Stream, wo Relay es anhand deklarierter Muster klassifiziert, um den entsprechenden Handler zu finden. Geplante Aufgaben folgen einem ähnlichen Pfad, umgehen jedoch das Muster-Matching und lösen direkt ihre konfigurierten Handler auf. Beide Arten der Funktionsausführung profitieren von einer geteilten Infrastruktur für Wiederholungsversuche, Dead-Letter-Warteschlangen und die Verfolgung des Aufrufzustands. Persistente Dienste operieren hingegen außerhalb dieser Ereignispipeline; sie laufen als kontinuierlich abgeglichene Container, die die Konfiguration der App teilen, aber ihren eigenen Lebenszyklus beibehalten.

Wichtige Details

• Einheitliches Bereitstellungsmodell: Funktionen, Zeitpläne und persistente Dienste werden gemeinsam in einer App-Konfiguration deklariert, was die Verwaltung vereinfacht und einen konsistenten Zugriff auf Secrets und Umgebungsvariablen gewährleistet.
• Redis-Stream-Rückgrat: Externe Ereignisse und Zeitplan-Ausführungen werden an Redis Streams publiziert, was eine mindestens-einmalige Zustellung, dauerhafte Outboxes für Wiederholungen und clusterweite Deduplizierung für geplante Aufgaben ermöglicht.
• Verwaltete Laufzeiten: Die Plattform unterstützt Python 3.14 und Node 24 (einschließlich TypeScript) und nutzt warme Container, um Cold-Start-Zeiten zu reduzieren, während begrenzte Concurrency-Limits erzwungen werden.
• Präzise Planung: Cron-Jobs unterstützen Timing mit Minutenpräzision unter Verwendung von IANA-Zonen, deterministische Ausführungsidentitäten und Nachholmechanismen beim Start, um verpasste Ausführungen während Ausfallzeiten zu behandeln.
• Ressourcenisolierung: Jeder Container kann spezifische Limits für Speicher, CPU und PID haben, um sicherzustellen, dass schwere Workloads andere Dienste auf demselben Host nicht aushungern.
• Observability-Suite: Integrierte Unterstützung für Prometheus-Metriken, strukturierte Logs und OpenTelemetry-Tracing bietet Einblicke in die Leistung von Funktionen und die Systemgesundheit ohne externe Agenten.

Hintergrund

Um Relay zu verstehen, hilft es, zwischen serverlosen Funktionen und traditionellen Diensten zu unterscheiden. Serverlose Funktionen sind "stateless" und "ephemeral", was bedeutet, dass sie hochfahren, eine bestimmte Aufgabe als Reaktion auf einen Trigger ausführen und dann herunterfahren. Dieses Modell ist effizient für sporadische Workloads, erfordert jedoch oft komplexe Orchestrierung, wenn es mit langlaufenden Prozessen wie Webservern oder Hintergrundworkern gemischt wird. Traditionell würden Teams separate Tools für diese Bedürfnisse verwenden: einen Cloud-Anbieter für Funktionen, einen Cron-Daemon für Zeitpläne und Docker oder Kubernetes für Dienste.

Relay versucht, diese Lücke zu schließen, indem es einen einzelnen Laufzeitprozess bereitstellt, der alle drei Workload-Typen verwaltet. Es nutzt Redis Streams als zentrales Nervensystem für die Ereignisverteilung. Redis Streams sind eine Datenstruktur, die zuverlässige Nachrichtenverarbeitung, Consumer Groups und Historienaufbewahrung ermöglicht, was sie ideal für den Aufbau robuster ereignisgesteuerter Architekturen macht. Indem Relay die Komplexität der Nachrichtenrouting-, Retry-Logik und Container-Lebenszyklusverwaltung intern handhabt, zielt es darauf ab, die Entwicklererfahrung einer verwalteten Cloud-Plattform zu bieten, bleibt dabei aber vollständig selbst hostbar.

Warum es wichtig ist

Für Teams, die ihre Software selbst hosten, ist die Verwaltung der Infrastruktur für ereignisgesteuerte Architekturen oft eine erhebliche operative Belastung. Cloud-Anbieter bieten praktische Lösungen für serverlose Funktionen und verwaltete Warteschlangen, aber diese kommen mit Vendor Lock-in, unvorhersehbaren Kosten und Bedenken hinsichtlich der Datenspeicherung. Relay bietet eine Möglichkeit, diese Funktionalität on-premises oder in privaten Clouds zu replizieren, was Organisationen volle Kontrolle über ihre Daten und Ausführungsumgebung gibt. Dies ist besonders wertvoll für Unternehmen mit strengen Compliance-Anforderungen oder solche, die Kosten optimieren möchten, indem sie vorhandene Hardware effizienter nutzen.

Darüber hinaus reduziert die Vereinigung von Funktionen und Diensten die architektonische Fragmentierung. Anstatt separate CI/CD-Pipelines, Monitoring-Stacks und Konfigurationsspeicher für verschiedene Workload-Typen zu pflegen, können Teams alles über eine einzige deklarative Schnittstelle verwalten. Diese Vereinfachung kann zu schnelleren Entwicklungszyklen und einfacherer Fehlerbehebung führen, da die Grenzen zwischen Ereignistriggern, geplanten Aufgaben und persistenten APIs innerhalb eines konsistenten Betriebsmodells verschwimmen. Die Fähigkeit, sowohl kurzlebige als auch langlaufende Prozesse mit geteilten Ressourcenkontrollen auszuführen, verbessert zudem die Hardwareauslastung und verhindert die Verschwendung, die mit der Überprovisionierung separater Umgebungen einhergeht.

Was Sie tun können

• Bewerten Sie Ihre aktuelle Workload-Mischung: Identifizieren Sie, ob Ihr Team mehrere Tools für Cron-Jobs, Webhooks und Hintergrundworker jongliert, und überlegen Sie, ob eine einheitliche Laufzeitumgebung Ihren Stack vereinfachen könnte.
• Testen Sie die Laufzeit lokal: Klonen Sie das Relay-Repository und verwenden Sie den Befehl relay start, um den Prozess im Vordergrund auszuführen, überwacht von Docker oder systemd, um seinen Ressourcenverbrauch zu bewerten.
• Überprüfen Sie Redis-Abhängigkeiten: Stellen Sie sicher, dass Ihre Infrastruktur die erforderliche Nutzung von Redis Streams unterstützt, einschließlich Persistenz und Speicherallokation für Hochdurchsatz-Ereignisverarbeitung.
• Kartieren Sie bestehende Cron-Jobs: Auditieren Sie Ihre aktuellen geplanten Aufgaben, um zu sehen, ob sie von Relays deterministischen Ausführungsidentitäten und Nachholmechanismen beim Start profitieren würden.
• Prüfen Sie Sprachkompatibilität: Verifizieren Sie, dass Ihre bestehenden Funktionen mit den unterstützten Laufzeiten kompatibel sind, insbesondere Python 3.14 oder Node 24, bevor Sie eine Migration planen.
• Konfigurieren Sie Observability frühzeitig: Richten Sie Prometheus- und OpenTelemetry-Collector ein, um Metriken und Traces von Anfang an zu erfassen, und nutzen Sie Relays integrierte Instrumentierung für sofortige Sichtbarkeit.