Migration von Pages zu Workers: wann es sinnvoll ist und wie hoch die tatsächlichen Kosten der Änderung sind

Teams übernehmen Pages, weil der Git-Push-Flow mit automatischer Erstellung und sofortiger Bereitstellung wirklich einfacher ist als der Aufbau einer CI-Pipeline von Grund auf. Das ist ein echter Vorteil, kein Marketing. Das Problem tritt auf, wenn das Projekt wächst und Sie an Grenzen stoßen, die Pages nicht lösen können: Cron-Trigger, mehrere Worker mit unterschiedlichen Verantwortlichkeiten, Staging mit unterschiedlichen Bindungen. An diesem Punkt scheint die Migration zu Workers offensichtlich – aber die wahren Kosten dafür werden selten vorher berechnet.

Die eigentlichen Migrationsauslöser

Der häufigste Auslöser sind Cron-Trigger. Pages unterstützt Cron nicht nativ. Wenn Sie einen Job benötigen, der regelmäßig ausgeführt wird – Zahlungen verarbeiten, externe Daten synchronisieren, geplante Berichte erstellen –, verfügen Sie bereits über einen separaten Worker, der neben Ihrem Pages-Projekt ausgeführt wird. Da die Anzahl der Satelliten-Worker wächst, beginnt sich das Team zu fragen, ob es sinnvoller wäre, alles in Workern zusammenzufassen.

Der zweite Auslöser ist die Fragmentierung der Bereitstellung. Ein Pages-Projekt ist eine monolithische Bereitstellungseinheit – Frontend, Funktionen, alles zusammen. Wenn Sie Verantwortlichkeiten zwischen spezialisierten Mitarbeitern aufteilen möchten (einen für die öffentliche API, einen für die interne Verarbeitung, einen für Webhooks), bietet Pages diese Granularität nicht. Die Bereitstellung einer Änderung am Webhooks-Handler löst einen Neuaufbau des gesamten Frontends aus.

Der dritte Schritt ist die Bereitstellung mit Produktionsparität. Seiten verfügen über Produktions- und Vorschauumgebungen, aber nicht über benannte Umgebungen mit völlig unterschiedlichen Bindungen. Wenn Sie eine vollständig von der Produktionsdatenbank getrennte Staging-D1-Datenbank mit anderen Umgebungsvariablen und vielleicht sogar einem anderen KV-Modell wünschen, besteht die Lösung in Pages darin, ein separates Pages-Projekt zu erstellen und die Synchronisierung manuell zu verwalten. In Workers ist dies in wrangler.toml mit den Blöcken [env.staging] und [env.production].

Was Sie verlieren, wenn Sie Pages verlassen

Die richtige Berechnung besteht darin, vor der Migration aufzulisten, welche Pages-Angebote Sie ersetzen müssen.

Die Build-Pipeline ist das am meisten unterschätzte Element. Pages stellt eine Verbindung zum Repository her, erkennt das Framework, führt den Build aus und lädt die Assets hoch. In Workers übernehmen Sie diese Verantwortung: eigenes CI/CD (GitHub Actions, GitLab CI, was auch immer), Build-Skript und Hochladen von Assets auf R2, wenn Sie weiterhin statische Dateien bereitstellen müssen.

Das zweite Element sind Vorschaubereitstellungen pro Zweig. Pages generiert automatisch eine Vorschau-URL für jeden Zweig – Push, verfügbare URL, Kommentar zu PR. Um dies in Workers zu replizieren, ist Arbeit erforderlich: ein CI-Skript, das den Branch-Namen erkennt, mit einem vom Branch abgeleiteten Worker-Namen bereitstellt (minha-api-pr-247) und die URL im PR über die GitHub-API kommentiert. Es funktioniert, aber es ist Infracode, den Sie schreiben und pflegen.

Das dritte Element ist das CDN für statische Assets. Dies zu ignorieren ist am teuersten.

Das Konto der statischen Vermögenswerte

In Pages werden statische Assets (HTML, CSS, JS, Bilder) direkt vom Cloudflare CDN bereitgestellt, ohne die Workers-Laufzeit auszulösen. Jede Anfrage für ein statisches Asset kostet 0 $ pro Anfrage, unabhängig vom Volumen.

In Workers gibt es dieses Grundelement nicht von Haus aus. Um Assets bereitzustellen, benötigen Sie R2 (Objektspeicher) und eine Logik im Worker, die nach dem richtigen Asset sucht, Cache-Header anwendet und den Inhalt zurückgibt. Jede Anforderung, die die Laufzeit durchläuft, zählt als Worker-Aufruf.

Der bezahlte Tarif für Arbeitnehmer umfasst 10 Millionen Anfragen pro Monat und berechnet darüber hinaus 0,30 US-Dollar pro Million. Eine Website mit 100 Millionen monatlichen Anfragen, davon 90 Millionen für statische Assets: Auf Pages betragen die Anfragekosten 0 US-Dollar. In Workers gibt es 90 Millionen Aufrufe über dem enthaltenen Paket – 27 US-Dollar pro Monat allein für dieses Delta, das linear mit dem Datenverkehr wächst.

Bei einer Website mit 500 Millionen monatlichen Anfragen und 85 % statischen Assets beträgt die Differenz mehr als 120 $/Monat. Die Kosten für den Pages Pro-Plan betragen 20 $/Monat. In diesem Szenario ist die Migration zu Arbeitskräften eine Entscheidung, die im Austausch für Flexibilität die Betriebskosten erhöht.

Die wrangler.toml zur Bereitstellung von R2-Assets

Wenn die Migration trotz der Kosten sinnvoll ist, verwendet das richtige Muster für die Bereitstellung statischer Assets in Workers R2 mit Cache-API:

# wrangler.toml
name = "meu-site"
main = "src/index.ts"
compatibility_date = "2024-09-24"

[[r2_buckets]]
binding = "ASSETS"
bucket_name = "meu-site-assets"

[[routes]]
pattern = "meusite.com/*"
zone_name = "meusite.com"

// src/index.ts
export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const cache = caches.default;
    const cached = await cache.match(request);
    if (cached) return cached;

    const url = new URL(request.url);
    const key = url.pathname.slice(1) || "index.html";
    const object = await env.ASSETS.get(key);

    if (!object) {
      return new Response("Not Found", { status: 404 });
    }

    const response = new Response(object.body, {
      headers: {
        "Content-Type": object.httpMetadata?.contentType ?? "application/octet-stream",
        "Cache-Control": "public, max-age=31536000, immutable",
      },
    });

    await cache.put(request, response.clone());
    return response;
  },
};

Dies repliziert das CDN-Verhalten von Pages, Sie zahlen jedoch für jeden Cache-Fehler (erste Anfrage pro Datei pro Cloudflare PoP). Das Pages-CDN verfügt über diese Caching-Ebene ohne zusätzliche Kosten pro Anfrage.

So migrieren Sie ohne Ausfallzeiten

Die risikoärmste Reihenfolge: Halten Sie zunächst das Pages-Projekt am Laufen. Erstellen Sie parallel neue Worker. Konfigurieren Sie Routen, die Datenverkehr für bestimmte Pfade an neue Worker senden (beginnend mit den Pfaden mit dem geringsten Risiko, z. B. Webhooks oder Admin-Routen). Validieren Sie das Verhalten in der Produktion mit echtem Datenverkehr, bevor Sie die Hauptpfade verschieben. Deaktivieren Sie erst dann die entsprechenden Seitenfunktionen.

Migrieren Sie für das Frontend die Pages-Assets erst dann zu R2, wenn Sie sicher sind, dass die zusätzlichen Kosten im Rahmen des Projektbudgets liegen. In vielen Fällen ist die Hybridarchitektur – Seiten für Frontend und Assets, Worker für asynchrone Jobs und spezialisierte Dienste – günstiger und ebenso flexibel wie eine vollständige Migration.

Was Migration wirklich löst

Cron-Trigger, mehrere Worker mit granularem Routing, Staging mit völlig isolierten Umgebungen – das sind die eigentlichen Probleme, die eine Migration rechtfertigen. Wenn Sie aus einem anderen Grund migrieren, sollten Sie prüfen, ob Sie eine Einschränkung nicht gegen höhere Kosten eintauschen.

Die Flexibilität der Mitarbeiter hat einen konkreten Betriebspreis: Sie übernehmen die CI-Pipeline, die Vorschau der Bereitstellung und die Kosten für die Bereitstellung statischer Assets. Für reine Backend-Dienste ohne nennenswerte Vermögenswerte sind diese Kosten gering. Bei Anwendungen mit einem umfangreichen Frontend und einem hohen Volumen an statischem Datenverkehr kann dies erheblich sein.