Cloudflare Dynamic Workers: Sandboxes jetzt 100x schneller

BBetter Stack
AI/미래기술창업/스타트업컴퓨터/소프트웨어

Transcript

00:00:00(Fröhliche Musik)
00:00:01Cloudflare hat vor Kurzem Dynamic Workers angekündigt,
00:00:04ein Low-Level-Worker-Primitiv,
00:00:06das programmatisch von einem bestehenden Worker erstellt werden kann.
00:00:09Sie sind hundertmal schneller und speichereffizienter
00:00:12als herkömmliche Container, da sie auf V8-Isolates laufen.
00:00:16Und weil sie so günstig sind,
00:00:18kann man so viele davon spawnen, wie man möchte,
00:00:20um KI-generierten Code auszuführen, Entwicklungs-Previews,
00:00:23benutzerdefinierte Automatisierungen und vieles mehr.
00:00:25Es hieß sogar, man könne eine Million Dynamic Workers
00:00:29pro Sekunde ausführen, wenn man wollte.
00:00:31Aber schränkt die Tatsache, dass man darauf nur
00:00:33JavaScript ausführen kann, deren Nutzung ein?
00:00:36Abonniert den Kanal und lasst es uns herausfinden.
00:00:37(Fröhliche Musik)
00:00:40Letztes Jahr habe ich ein Video über Cloudflare Sandboxes gemacht,
00:00:44was im Grunde kurzlebige Linux-Container sind,
00:00:47die auf einem Durable Object laufen.
00:00:49Falls das für euch keinen Sinn ergeben hat,
00:00:50schaut euch am besten das Video dazu an.
00:00:52Aber sie sind perfekt, wenn man einen vollen OS-Container
00:00:55mit Dateisystem und der Fähigkeit benötigt,
00:00:59fast jede Sprache und jede Binärdatei auszuführen.
00:01:01Wenn ihr aber etwas sucht, das ein bisschen schneller ist –
00:01:03eigentlich viel schneller und viel leichtgewichtiger –
00:01:06mit der Fähigkeit, unbegrenzt gleichzeitige Sandboxes auszuführen,
00:01:09innerhalb der Limits eines regulären Workers,
00:01:12dann solltet ihr zu einem Dynamic Worker greifen.
00:01:15Gehen wir mal durch, wie man einen einrichtet.
00:01:16Hier ist ein Basis-Worker, den ich gerade mit Wrangler erstellt habe,
00:01:19voller TypeScript-Fehler,
00:01:21vielleicht weil ich vergessen habe, "wrangler types" auszuführen.
00:01:23In unserer Wrangler-Konfigurationsdatei
00:01:26habe ich dieses "worker_loaders"-Array hinzugefügt,
00:01:28mit einem Binding namens "loader".
00:01:30Das kann man nennen, wie man möchte,
00:01:32aber ich habe "loader" gewählt, weil es konventioneller ist.
00:01:34Dieses Binding erlaubt es uns, andere Worker
00:01:37zu erstellen und zu steuern.
00:01:38Im aktualisierten Code haben wir eine neue Worker-Konstante,
00:01:42die das Loader-Binding mit diesen Werten nutzt.
00:01:45Man kann sich das wie eine Wrangler-Konfigurationsdatei
00:01:49für den verschachtelten Worker vorstellen,
00:01:50wobei das Kompatibilitätsdatum dem Worker sagt,
00:01:53welche Runtime-Version er verwenden soll.
00:01:55Und hier ist der Code, den er ausführen wird.
00:01:57Wie ihr seht, ist der Code dem eines Workers
00:01:59selbst sehr ähnlich.
00:02:00Er hat eine Fetch-Funktion
00:02:02mit den Argumenten Request, Env und Context.
00:02:05Alles, was er hier tut, ist mit
00:02:06"Hello World aus der Sandbox" zu antworten.
00:02:08Wir haben dann jeglichen Netzwerkzugriff unterbunden,
00:02:10führen die Fetch-Funktion mit den Request-Argumenten
00:02:13des ursprünglichen Workers aus und geben das Ergebnis zurück.
00:02:16Wenn wir den Worker lokal starten und "curl localhost" ausführen,
00:02:19sollten wir "Hello aus der Sandbox" sehen.
00:02:21Führen wir denselben Curl-Befehl aber erneut aus,
00:02:24erhalten wir einen Fehler.
00:02:24Das liegt daran, dass wir momentan
00:02:26einen brandneuen Worker laden.
00:02:28Was wir stattdessen tun können, ist einen bestehenden Worker abzurufen,
00:02:31dem wir den Namen "worker-1" geben,
00:02:33und den Code dann als asynchrone Funktion ausführen.
00:02:35Das bedeutet: Wenn wir jetzt Curl nutzen, erhalten wir die Antwort.
00:02:38Führen wir es erneut aus, kommen die Informationen
00:02:41aus der bereits existierenden "worker-1"-Sandbox.
00:02:43Was ich gerade gezeigt habe,
00:02:45war natürlich ein sehr einfaches Beispiel,
00:02:47aber man kann mit Dynamic Workers coole Sachen machen,
00:02:50wie zum Beispiel benutzerdefinierte Bindings definieren,
00:02:52wie diese "chatroom.post"-Methode, um einen Stub zu erstellen,
00:02:55mit dem der Worker via Cap'n Proto kommuniziert –
00:02:57ja, dazu haben wir bereits ein Video gemacht,
00:02:59schaut es euch also an, falls es euch interessiert.
00:03:00Man kann NPM-Abhängigkeiten wie Hono verwenden
00:03:03und sie mit der "createWorker"-Funktion bündeln.
00:03:05Und man kann sogar ausgehende Anfragen abfangen,
00:03:08um etwa Anmeldedaten einzufügen.
00:03:10Einer der Hauptgründe für Dynamic Workers
00:03:13ist jedoch die Ausführung von Code, den KI-Agenten generiert haben.
00:03:17Versuchen wir das also mal.
00:03:18Hier ist Code aus dem E2B Cookbook,
00:03:21der das Anthropic SDK nutzt, um Sonnet 3.5
00:03:25mit diesem System-Prompt und einem Custom-Tool
00:03:28auszuführen, um Python in einem Jupyter Notebook zu starten.
00:03:31Die Funktionsweise ist so: Es erkennt,
00:03:33wenn das Custom-Tool genutzt wird,
00:03:34und führt es dann innerhalb der E2B Sandbox aus,
00:03:38deren Code wir hier sehen können.
00:03:40Es wird mit diesem sehr spezifischen Prompt ausgeführt,
00:03:42um den Wert von Pi mit der Monte-Carlo-Methode
00:03:46in tausend Iterationen zu berechnen.
00:03:47Und da es Zugriff auf das Dateisystem hat,
00:03:50kann es dieses PNG-Bild erstellen
00:03:52und speichern, damit der Nutzer es herunterladen kann
00:03:54oder was auch immer damit geschehen soll.
00:03:56Leider haben Dynamic Workers keinen Zugriff
00:03:58auf ein echtes Dateisystem,
00:04:00auch wenn sie ein virtuelles erstellen können,
00:04:02zum Beispiel mit dieser Shell-Library.
00:04:04Aber weil sie durch einen Worker laufen,
00:04:06können wir Ressourcen bereitstellen, wie einen R2-Bucket –
00:04:08Cloudflares Version von S3 –,
00:04:11in dem das Bild gespeichert werden kann.
00:04:12Schauen wir uns den Code an,
00:04:14der dem von E2B ähnelt.
00:04:16Zuerst sehen wir den System-Prompt, der verwendet wird.
00:04:19Und das benutzerdefinierte Python-Execution-Tool,
00:04:22das in diesem Fall kein Jupyter Notebook nutzt,
00:04:25aber eine SVG-Grafik der Visualisierung generiert.
00:04:28Hier haben wir den Code für den Worker,
00:04:30der neben JavaScript auch Python ausführen kann.
00:04:33Man sieht hier, dass Sonnet 3.5 (4.6) genutzt wird.
00:04:35Hier ist der Prompt, der zum Einsatz kommt.
00:04:37Hier wird der Code des Agenten in der Sandbox ausgeführt.
00:04:41Die Antwort aus der Sandbox
00:04:43geht zurück an den Haupt-Worker,
00:04:45der darin nach dem SVG-Code sucht
00:04:47und ihn dann in R2 speichert.
00:04:49Wenn wir die URL aufrufen, dauert es einen Moment,
00:04:51aber die Seite wird generiert,
00:04:53mit den relevanten Informationen von Claude.
00:04:55Und wenn wir nach unten scrollen,
00:04:56sehen wir das SVG, das aus R2 geladen wird.
00:05:01Es sieht ganz anders aus als das von E2B,
00:05:03aber ich vertraue darauf, dass Claude Sonnet
00:05:04die richtigen Informationen geliefert hat.
00:05:06Wie erwähnt, ist es auch möglich,
00:05:09programmatisch so viele Dynamic Workers zu spawnen, wie man will.” Das geht mit Code wie diesem.
00:05:13Das ist eine For-Schleife, die brandneue Worker erstellt,
00:05:16basierend auf dem Wert aus der API.
00:05:19Sie prüft auch, ob ein Worker bereits existiert
00:05:21und verwendet ihn gegebenenfalls wieder.
00:05:23Der ausgeführte Code ist im Grunde ein Console-Log
00:05:25und eine Antwort vom Worker
00:05:27mit der spezifischen ID des Workers,
00:05:29basierend auf dem Index der For-Schleife.
00:05:31Wenn der Code läuft,
00:05:32könnte ich 50 brandneue Dynamic Workers spawnen,
00:05:34und wir sehen, dass sie alle sofort erstellt werden.
00:05:36Das ging extrem schnell.
00:05:40Probieren wir es mal mit 10.000,
00:05:41aber ich mache das nicht lokal,
00:05:43weil ich meinen Rechner nicht sprengen will.
00:05:44Ich habe meinen Parent-Worker also bei Cloudflare deployed,
00:05:46um deren Infrastruktur zu nutzen.
00:05:49Hier werde ich nun 10.000 verschiedene Worker spawnen.
00:05:50Sobald ich Enter drücke, werden alle wahnsinnig schnell erstellt.
00:05:53Wir sehen hier eine Seite mit 30 Stück,
00:05:56und ich kann weiterblättern, um die verschiedenen IDs zu sehen.
00:05:59Und je weiter ich gehe, desto mehr Seiten werden angezeigt.
00:06:03Ich kann mit einem spezifischen Worker kommunizieren,
00:06:05wie zum Beispiel Worker 1156,
00:06:07der mit "Hello von Worker 1156" antwortet.
00:06:09Das war ein kurzer Überblick über Dynamic Workers,
00:06:12die bereits von Cloudflare für den Code-Modus
00:06:15und von Zite für LLM-generierte Apps genutzt werden.
00:06:18Ich sollte jedoch erwähnen: Sie sind zwar jetzt kostenlos,
00:06:21aber das werden sie nicht ewig bleiben.
00:06:24Auch wenn man eine Million Dynamic Workers pro Sekunde
00:06:25laufen lassen kann, sollte man sich vielleicht zurückhalten,
00:06:28außer man hat sehr tiefe Taschen.
00:06:30Und wo wir gerade beim Thema Cloudflare sind:
00:06:32Wenn ihr mehr über deren Open-Source-VIVE-SDK erfahren wollt,
00:06:34mit dem man App-Generatoren wie v0 und Lovable bauen kann,
00:06:38dann schaut euch das nächste Video an.
00:06:42(Fröhliche Musik)

Key Takeaway

Cloudflare Dynamic Workers revolutionieren die serverlose Ausführung durch hocheffiziente V8-Isolates, die massenhaftes Spawning von Sandboxes für KI-Anwendungen und Automatisierungen in Millisekunden ermöglichen.

Highlights

Cloudflare Dynamic Workers sind ein neues Low-Level-Primitiv, das programmatisch aus bestehenden Workern erstellt werden kann.

Sie basieren auf V8-Isolates und sind dadurch 100-mal schneller und speichereffizienter als herkömmliche Container.

Dynamic Workers ermöglichen das Ausführen von KI-generiertem Code, Entwicklungs-Previews und benutzerdefinierten Automatisierungen in großem Maßstab.

Im Gegensatz zu Cloudflare Sandboxes (Linux-basiert) sind Dynamic Workers auf JavaScript und WebAssembly spezialisiert, bieten aber eine extrem geringe Latenz.

Entwickler können Ressourcen wie R2-Buckets einbinden, um fehlende native Dateisysteme zu kompensieren und Daten dauerhaft zu speichern.

Die Skalierbarkeit ist beeindruckend, da theoretisch bis zu eine Million Worker pro Sekunde in der Cloudflare-Infrastruktur gestartet werden können.

Timeline

Einführung in Dynamic Workers und V8-Isolates

Der Sprecher stellt Cloudflare Dynamic Workers als neues, leistungsstarkes Werkzeug für Entwickler vor. Diese Workers zeichnen sich dadurch aus, dass sie direkt aus einem übergeordneten Worker heraus generiert werden können. Da sie auf V8-Isolates anstelle von schweren Containern basieren, bieten sie eine drastisch höhere Geschwindigkeit und Effizienz. Dies macht sie ideal für Szenarien, in denen kurzlebige Umgebungen für KI-Code oder Automatisierungen benötigt werden. Der Abschnitt betont die theoretische Kapazität, eine Million dieser Instanzen pro Sekunde auszuführen.

Vergleich: Linux Sandboxes vs. Dynamic Workers

In diesem Teil wird der Unterschied zwischen den bereits bekannten Cloudflare Sandboxes und den neuen Dynamic Workers erläutert. Während Linux-basierte Sandboxes volle Betriebssystem-Funktionalität und beliebige Binärdateien bieten, sind sie schwerfälliger. Dynamic Workers hingegen sind für Anwendungsfälle konzipiert, die maximale Leichtigkeit und minimale Startzeiten erfordern. Der Sprecher erklärt, dass Dynamic Workers innerhalb der Grenzen eines regulären Workers operieren, aber unbegrenzte Gleichzeitigkeit ermöglichen. Dies ist entscheidend für Entwickler, die Geschwindigkeit über die Flexibilität eines kompletten Betriebssystems stellen.

Praktische Einrichtung und Code-Beispiele

Der Prozess der Einrichtung eines Dynamic Workers mit dem Wrangler-Tool wird schrittweise demonstriert. Hierbei spielt das "worker_loaders"-Binding in der Konfigurationsdatei eine zentrale Rolle, um die Kontrolle über verschachtelte Worker zu erhalten. Der Sprecher zeigt, wie man Code innerhalb einer Sandbox ausführt und wie die Kommunikation zwischen Parent- und Child-Worker abläuft. Ein wichtiger technischer Aspekt ist das Laden bestehender Worker über Namen, um den Zustand zwischen Anfragen beizubehalten. Diese Demonstration verdeutlicht, wie nah die Syntax an herkömmlichen Cloudflare Workers bleibt.

KI-Integration und Umgang mit Ressourcen

Hier liegt der Fokus auf einem Hauptanwendungsfall: der Ausführung von Code, der durch KI-Agenten wie Claude Sonnet 3.5 generiert wurde. Der Sprecher vergleicht die Cloudflare-Lösung mit dem E2B Cookbook und zeigt, wie Python-Ausführung in Sandboxes simuliert werden kann. Da Dynamic Workers keinen direkten Dateisystemzugriff haben, wird die Nutzung von Cloudflare R2 als S3-Alternative zur Datenspeicherung gezeigt. Dies ermöglicht es, Ergebnisse wie generierte SVG-Grafiken dauerhaft verfügbar zu machen. Der Abschnitt verdeutlicht die Mächtigkeit dieser Architektur für moderne, KI-gesteuerte Applikationen.

Massen-Spawning und Skalierungstests

In einem beeindruckenden Skalierungstest demonstriert der Sprecher das gleichzeitige Erstellen von bis zu 10.000 Dynamic Workers. Zunächst erfolgt ein lokaler Test mit 50 Workern, der die sofortige Erstellung ohne nennenswerte Verzögerung zeigt. Um den Computer nicht zu überlasten, wird der Test schließlich auf die Cloudflare-Infrastruktur verlagert. Hier wird gezeigt, wie schnell tausende von Instanzen bereitgestellt und über IDs einzeln angesprochen werden können. Dies beweist die Robustheit der Cloud-Infrastruktur für hochgradig parallele Aufgabenstellungen.

Zusammenfassung, Kosten und Ausblick

Zum Abschluss gibt der Sprecher einen Überblick über Unternehmen wie Zite, die Dynamic Workers bereits produktiv nutzen. Er warnt jedoch davor, dass die derzeitige kostenlose Phase nicht ewig anhalten wird. Entwickler sollten die Kosten im Auge behalten, besonders wenn sie massenhaft Instanzen in Betrieb nehmen. Es wird auch darauf hingewiesen, dass Dynamic Workers primär für KI-Agenten und Code-Editoren gedacht sind. Abschließend verweist der Sprecher auf das Cloudflare VIVE-SDK für den Bau von App-Generatoren im nächsten Video.

Community Posts

View all posts