Edge vs. Cloud Computing: Ein Leitfaden für moderne Entwickler

Die Entwicklung von Content Delivery Networks (CDNs)

Ursprünglich konzentrierten sich CDNs auf das Zwischenspeichern und den Schutz von Ursprungsservern, doch mit dem Aufkommen des serverlosen Computingsbegannen sie sich weiterzuentwickeln. Eine neue Idee wurde sehr schnell populär: Entwickler konnten eine atomare "Funktion" definieren, die bei Bedarf als Reaktion auf ein Ereignis, z. B. einen neuen Bild-Upload oder einen neuen Datenbankdatensatz, ausgeführt wird, ohne dass sie die zugrunde liegende physische oder virtuelle Infrastruktur besitzen und warten müssen.

AWS Lambda war das erste Beispiel für dieses neue Paradigma im Jahr 2015. AWS Lambda@Edge folgte 2016 und ermöglichte es dir, den gleichen Ansatz mit Funktionen zu verfolgen, die auf Amazon CloudFront - dem CDN-Dienst von AWS - laufen.

Beliebte CDNs haben nachgezogen und Dienste wie CloudFlare Workers (2017), Fastly Compute@Edge (2019) und Akamai EdgeWorkers (2019) eingeführt .

Und das war noch nicht alles! Wie wir zu Beginn dieses Artikels gesagt haben, geht es beim Edge Computing nicht nur darum, Rechenleistung an den Rand zu bringen. In den meisten Fällen brauchst du auch eine Art von Datenspeicher. Die CDNs haben sich also weiterentwickelt und neue Dienste wie Key-Value-Stores, Objektspeicher, SQL-Datenbanken, Bildgrößenanpassung, KI-Inferenz und vieles mehr bereitgestellt!

Zum Beispiel:

• Die Entwicklungsplattform von CloudFlareumfasst Edge-Services wie Workers KV für Key-Value-Speicher, D1 für relationale SQL-Datenbanken mit Point-in-Time-Recovery, R2 für Objektspeicher ohne Egress-Gebühr und Queues für asynchrone Aufgabenausführung. 
• Ähnlich verhält es sich bei Fastly mit KV Store für die Speicherung von Schlüssel-Wert-Paaren, Geheimnissen und Konfigurationsdaten und Fanout für bidirektionale asynchrone Pubs/Subs am Edge.
• Und du hast es erraten: Akamai bietet EdgeKV an.
• Amazon CloudFront hat 2023 seinen CloudFront KeyValueStore eingeführt .

Heute bieten CDNs Dienste an, von denen man normalerweise erwarten würde, dass sie nur in einer Cloud-Region (oder einem Rechenzentrum) laufen, von serverlosen Funktionen über Key-Value-Stores bis hin zu Objektspeichern, Warteschlangen und relationalen Datenbanken. Zufälligerweise waren Warteschlangen, Objektspeicher und Rechenkapazitäten die allerersten Cloud-Dienste, die 2006 angekündigt wurden und nun global verteilt am Edge debütieren.

Unter der Haube verwenden diese neuen Edge-Computing-Plattformen unterschiedliche Technologien und unterstützen verschiedene Programmiersprachen. CloudFlare nutzt beispielsweise die Chrome V8-Engine, die zunächst nur JavaScript unterstützte, aber 2018 begann, WebAssembly zu integrieren. Andererseits hat sich Fastly von Anfang an dafür entschieden, WebAssembly für die Sandboxing-Umgebung zu verwenden, um einige der Einschränkungen der Startlatenz von V8 zu vermeiden. Dadurch kann Fastly viele Programmiersprachen unterstützen, z.B. TypeScript, Rust, Go, .NET, Ruby und Swift.

Lass uns eine kurze Klammer über WebAssembly aufmachen.

WebAssembly am Rande

WebAssembly (oder kurz Wasm) ist vielleicht die interessanteste Entwicklung in diesem Bereich. Seit der Ankündigung im Jahr 2017 und der W3C-Empfehlung im Jahr 2019 sprechen viele Leute über die Ausführung von Wasm-Binärdateien im Browser, aber es gibt auch viel Potenzial für die serverseitige Ausführung, einschließlich des Edge.

Wasm ermöglicht es dir, Geschäftslogik in verschiedenen unterstützten Sprachen zu schreiben und sie in eine Binärdatei zu kompilieren, die auf Wasm-Laufzeiten wie Wasmtime von Bytecode Alliance läuft.

Zusammen mit WASI (WebAssembly System Interface) ermöglicht es dir, in verschiedenen Sprachen geschriebene Software mit einer vom W3C standardisierten Schnittstelle zusammenzustellen.

Wenn dir das bekannt vorkommt wie etwas, das in der Cloud-Welt sehr beliebt ist, dann sieh dir diesen Tweet vom Gründer von Docker aus dem Jahr 2019 an:

Die Erwartungen an Wasm + WASIsind alsosehr hoch. Ich empfehle dir, die Bytecode Alliance und ihre Bemühungen, sichere und offene Compiler, Laufzeiten und Werkzeuge für WebAssembly zu entwickeln, im Auge zu behalten. Die gemeinnützige Organisation wurde 2019 von Mozilla, Fastly, Intel und Red Hat gegründet. Zu den Mitgliedern gehören heute weitere Cloud- und Edge-Player wie Amazon, Arm, Cisco, Docker, Fermyon, Microsoft, Nginx, Shopify, Siemens und VMware.

Edge- und Cloud-Computing im Vergleich

Nun zurück zu unserer Erkundung des Edge Computing.

Einer der interessantesten und bemerkenswertesten Unterschiede zum Cloud Computing besteht darin, dass der Edge von vornherein global verteilt ist. Dein Code und die Datenspeicherung laufen nativ auf Hunderten von Edge-Servern. Das ist ein großer Unterschied zu Cloud-Architekturen, die in der Regel als zentralisierte Anwendungen in einem einzigen Rechenzentrum (oder über 2-3 Verfügbarkeitszonen innerhalb einer Cloud-Region) laufen.

Viele Anwendungen lassen sich zwar problemlos zentralisieren, aber wenn du eine Website oder ein Produkt für ein globales Publikum entwickelst, wird deine Architektur auf jeden Fall eine Art von Caching und Inhaltsverteilung beinhalten. Und mit Edge Computing geschieht das automatisch. Mit einem Klick (oder CLI-Befehl) wird deine Edge-App global verteilt und läuft so nah wie möglich an deinen Nutzern, um die Latenzzeit zu optimieren.

Hier kommt also die rhetorische Frage.

Brauchst du die Cloud noch?

Mit anderen Worten: Ist die Cloud auch im Jahr 2024 noch die beste Option für die Entwicklung und den Aufbau gut durchdachter, skalierbarer Anwendungen?

Nun, ja!

Die Realität sieht so aus, dass der Edge für die meisten Anwendungsfälle immer noch eine Art Ursprung braucht, auf den er sich verlassen kann. Der Ursprung ist der Ort, an dem die Geschäftslogik des Codes abläuft, sei es das Backend deiner Website oder andere komplexe Workloads, die zentralisiert bleiben müssen (aus Bequemlichkeit, technischen Gründen oder Kostengründen).

Werfen wir einen Blick darauf, welche Workloads (vorerst) in der Cloud bleiben werden:

• Backend-APIs + RDMS - In der Regel der Kern deiner Ursprungs- und Produktionsdatenbanken (es gibt mindestens 10 verschiedene Datenbankdienste allein auf AWS).
• Massive Speicherung - Die Cloud bietet Möglichkeiten zur Kostensenkung durch kalte Lagerung.
• Datenanalytik - Dein typisches Data Warehouse, dein Data Lake und deine Datenpipelines brauchen einen zentralen Datenspeicher, um Abfragen zu starten und Berichte zu erstellen.
• KI/ML - Effizientes und kostengünstiges Training erfordert riesige Datensätze (während die Inferenz bereits am Rande ablaufen kann).
• HPC/Simulationen - High-Performance-Computing ist von vornherein verteilt, aber normalerweise innerhalb desselben Rechenzentrums oder derselben Region, um den Netzwerk-Overhead zu reduzieren.
• CI/CD-Pipelines - Diese können überall laufen, aber es ist wahrscheinlich bequemer und billiger, die Cloud zu nutzen (einschließlich der Pipelines zur Bereitstellung deiner Edge-Services).

Zusammenfassend lässt sich sagen, dass die Cloud sich durch universelle Dienste auszeichnet, die fast jede Art von Arbeitslast unterstützen, mit praktisch unbegrenztem Speicherplatz und horizontaler Skalierbarkeit (innerhalb einer Region oder über eine kleine Anzahl von Regionen für Ausfallsicherheit und Disaster Recovery).

Umgekehrt vereinfacht der Edge globale Implementierungen, verbessert die Sicherheit und ermöglicht das Caching für Cloud-Ursprünge, während er latenzoptimierte Funktionen unterstützt, ohne die Komplexität deiner Hauptanwendung zu erhöhen.

Mit anderen Worten: Cloud Computing und Edge Computing ergänzen sich gegenseitig. Sie werden weiterhin nebeneinander existieren und unterschiedliche technische Probleme lösen.

Kostenbewusste Architekturen

Ein weiterer interessanter Aspekt sind die Kosten. Wie so oft bei Managed Services besteht der Kompromiss darin, eine Lösung von der Stange zu verwenden oder eine eigene, weltweit verteilte Lösung zu entwickeln, zu erstellen und zu warten.

Da der Edge für die globale Verteilung von Inhalten optimiert ist, reduziert er oft die Kosten für Egress-Gebühren. Allerdings muss die Edge-Datenspeicherung auf Hunderte von Edge-Servern verteilt werden, was die Speicherung und den Datenbetrieb teurer erscheinen lässt als regionale Cloud-Dienste, die Daten in der Regel nur über 2-3 Verfügbarkeitszonen replizieren.

Schauen wir uns einige Zahlen an und konzentrieren uns dabei auf die Key-Value-Speicherung für 3 Edge-Dienste (CloudFlare Workers KV, Fastly KV, CloudFront KeyValueStore) und 2 Cloud-Dienste (Redis serverless auf AWS und DynamoDB on-demand auf AWS):

* für jede KB 

** die ersten 25 GB sind kostenlos

Ein paar interessante Unterschiede und Beobachtungen:

1. CloudFlare erhebt keine Gebühren für die Datenübertragung, aber Löschvorgänge kosten wie Schreibvorgänge.
2. Fastly erhebt keine Gebühren für Löschvorgänge, aber du bist auf 250.000 Schreibvorgänge und 5 Millionen Lesevorgänge pro Monat beschränkt (es sei denn, du zahlst für ein Add-on).
3. CloudFront KeyValueStore scheint wahnsinnig optimiert für Lesevorgänge zu sein, aber Schreibvorgänge sind unglaublich teuer im Vergleich zu den anderen Optionen.
4. Redis sieht ziemlich billig aus, aber du musst bedenken, dass es $0,0038 pro KB kostet. Wenn du also 5 KB liest oder schreibst, wird es 5x teurer (was immer noch ziemlich günstig ist).
5. DynamoDB ist nicht nur ein Key-Value-Store, aber er kann definitiv auf diese Weise verwendet werden, und er scheint immer noch um eine Größenordnung billiger zu sein als die Edge Services.

Auch wenn Cloud-Dienste billiger erscheinen, ist es wichtig zu wissen, dass sie nicht standardmäßig auf globaler Ebene funktionieren. Du kannst DynamoDB Global Tables oder Amazon ElastiCache Global Datastore aktivieren (allerdings ist dies nicht mit ElastiCache serverless kompatibel, sodass du auch mehrere Cluster verwalten musst).

Wenn du z.B. DynamoDB Global Tables für 10 Regionen aktivierst, werden die Schreib- und Speicherkosten mit 10 multipliziert, d.h. sie betragen 7,60 $ pro 1 Mio. Schreibvorgänge und 3 $ für 1 GB/Monat. Das ist bereits teurer als die Edge-Alternativen und nur für 10 Regionen (im Vergleich zu den Hunderten von Edge-Servern).

Praktische Anwendungsfälle für Edge Computing

Was kann man also am Rande tun? Es gibt viele interessante Anwendungsfälle, und ich hoffe, dieser Artikel hilft dir, herauszufinden, welcher davon für dein Produkt sinnvoll ist.

Ein paar Beispiele:

• Authentifizierung: Die Implementierung von Edge-basierten CAPTCHAs, passwortloser Authentifizierung oder JWT-Validierung kann die Ursprungslast reduzieren, indem zustandslose Operationen am Edge durchgeführt werden, die keinen Datenbankzugriff oder andere Ursprungsressourcen erfordern.
• Datenerhebung: Integriere externe Datenquellen oder Datenziele und verlagere das clientseitige und serverseitige Tracking an den Rand, um schwere SDKs in den Browsern oder Leistungsengpässe auf dem Server zu vermeiden.
• Geobasierte Anreicherung: Verbessere deine Website mit Inhalten, die in deiner Nähe gespeichert sind, implementiere lokalisierte Weiterleitungen (/en -> /fr ), Geofencing oder länderspezifische Drosselung mithilfe von Geolocation-APIs.
• Personalisierung von Inhalten: Speichere und zeige kürzlich angesehene Artikel oder empfohlene Produkte am Rand an, implementiere Paywalls für Premium-Inhalte oder nutze A/B-Tests, um personalisierte, kontextbezogene Inhalte anzubieten und gleichzeitig die Komplexität am Ursprung zu minimieren.
• SEO-Optimierungen: Manipuliere HTTP-Header und HTML-Antworten direkt am Edge, um eigene Caching-Richtlinien, Content Stitching oder Ad-hoc-Komprimierungsalgorithmen zu implementieren.
• Sicherheit: Integriere benutzerdefinierte WAFs (Web Application Firewalls) oder implementiere geheime Header und benutzerdefinierte Zugriffskontrolllogik.

Oder du könntest ein ganzes Produkt oder eine Reihe von Produkten entwerfen, die fast ausschließlich am Rande des Internets funktionieren - genaudas machen wir bei Edgee.

Mitbringsel

Ich hoffe, dieser Artikel hat verdeutlicht, dass CDNs nicht mehr nur auf Caching und DDoS-Schutz beschränkt sind - sie bieten Entwicklern inzwischen eine Fülle wertvoller Dienste. The Edge ist ein neuer Weg, um Apps zu entwickeln oder neue Funktionen zu integrieren, während der Ursprung schnell und unkompliziert bleibt.

WebAssembly hat viel Potenzial, nicht nur für den Browser, sondern auch für die serverseitige und Edge-Binary-Ausführung. 

Die Cloud ist da Die Cloud wird bleiben, und die Edge ergänzt ihre Einschränkungen, indem sie die Erstellung global verteilter Anwendungen mit optimierten Latenzzeiten und Kosten ermöglicht. Meine persönliche Empfehlung ist, kostenbewusste Architekturen zu entwerfen und zu bauen, denn das ist eine Schlüsselqualifikation, um ein effektiver Entwickler oder Architekt zu werden.