Edge Computing

Die Cloud ist weit weg (Rechenzentrum in Frankfurt oder USA). Lichtgeschwindigkeit ist schnell, aber nicht unendlich. Ein Signal nach USA und zurück dauert 100ms. Zu langsam für ein selbstfahrendes Auto ("Bremse !!"). Edge Computing holt die Rechenpower näher an den Nutzer ("an den Rand" -> Edge). Der Server steht nicht in Frankfurt, sondern im 5G-Mast an der Straßenecke. Das Auto entscheidet vor Ort, ob es bremst. Nur die Statistik ("Ich habe gebremst") wird später in die Cloud geschickt.

Merksatz: Ein dezentrales Rechenmodell, bei dem Datenverarbeitung so nah wie möglich an der Datenquelle (IoT-Geräte, lokale Server) stattfindet, um Latenz zu minimieren.

CDN (Content Delivery Network): Netflix streamt Filme nicht aus USA, sondern von einem Server bei deinem Provider (Telekom). Das ist einfaches Edge Computing.
IoT: Eine smarte Fabrik. Der Roboterarm wird von einem kleinen Server in der Halle gesteuert, nicht aus der Cloud (falls Internet ausfällt).
Cloudflare Workers: Du schreibst JavaScript-Code, der auf tausenden Servern weltweit verteilt läuft ("Serverless at the Edge").

1. Data Gravity

Daten haben Masse. Es ist schwer (teuer/langsam), Petabytes an Videodaten in die Cloud zu schieben, nur um zu prüfen "Ist da ein Einbrecher?". Besser: Die Kamera wertet das Video lokal aus (Edge AI) und sendet nur das Text-Event "Einbrecher!" (wenige Bytes) in die Cloud.

2. Fog Computing

Ein Begriff von Cisco. Die Schicht zwischen Edge (Gerät) und Cloud (Rechenzentrum). Stell dir den Nebel (Fog) vor, der nah am Boden (Geräte) ist, im Gegensatz zur Wolke (Cloud) ganz oben. Architekturell oft genutzt für lokale Aggregation.

1. WASM at the Edge (WebAssembly)

Der Architektursprung im modernen Cloudflare/Fastly Ecosystem ist es, V8-Isolates und WebAssembly statt Docker-Container für Edge-Compute zu nutzen. Ein Docker-Container braucht hunderte Millisekunden zum Booten (Cold Start) – inakzeptabel an einer 5G-Node, wo der User-Request in 5ms beantwortet sein muss. WASM-Module starten in Nanosekunden (sie sind nur 50 KB groß) und laufen direkt im Memory-Space der Edge-Runtime mit brutalem Sandboxing. Das ermöglicht "Edge Functions", bei denen tausende Kunden gleichzeitig auf einem kleinen Raspberry-Pi-äquivalenten Zellmast-Rechner ihre Custom-Routing-Logik ohne gegenseitiges Blockieren ausführen können.

2. CRDTs für Edge State Resolution

Edge Computes größte Schwäche ist State. Wenn ein Node im Zug sitzt, der in den Tunnel fährt (Air-Gap), fällt die Synchronisation mit der AWS-Zentraldatenbank aus. Wie schreibt die IoT-Maschine weiter Daten, ohne beim Reconnect Konflikte (Split-Brain) zu provozieren? Die Lösung liegt in CRDTs (Conflict-free Replicated Data Types). Edge-Datenbanken wie Turso (SQLite Fork) oder Macrometa erlauben hochgradig asynchrone Schreibvoränge offline. Sobald der Edge-Mast das Glasfaser zurückbekommt, mischen die CRDT-Algorithmen das Delta mathematisch konfliktfrei in die Zentral-DB.

3. MEC (Multi-Access Edge Computing) und 5G UPF

Im Telekombereich passiert die Magie im 5G Core Network. MEC platziert Server direkt neben die Funkantenne (eNodeB) oder die Vermittlungsstelle (UPF - User Plane Function). Cloud-Provider (AWS Wavelength, Azure Edge Zones) stellen Racks direkt in Vodafone-Rechenzentren auf. Dadurch verlässt das Datenpaket eines autonomen Roboters niemals das Handynetz der Telekom gen offenes Internet. Die Latenz fällt hart auf unter 10 Millisekunden, gepaart mit militärischer Sicherheit, da der Traffic physikalisch nicht abhörbar in Dark Fiber der Carrier stecken bleibt.