Cloud Computing erklärt: Die 11 Architekturkonzepte, die man kennen muss (4K Masterclass).

Was dieses Video behandelt

• - Die Architektur-Wand & Master-Blueprint
• - 01. Vertikale vs. Horizontale Skalierung
• - 02. Lastausgleichsarchitektur (L4 vs. L7 & Health Checks)
• - 03. Autoskalierung & Elastizität
• - 04. Serverless (FaaS & Firecracker MicroVMs)

Übersetztes Transkript

Aus der englischen Originalerzählung übersetzt. Verfügbare Audio- und Untertitel werden von YouTube gesteuert.

- Die Architektur-Wand & Master-Blueprint

0:00 Jeder Softwareentwickler stößt irgendwann an die Cloud-Architekturwand. Sie entwickeln eine Anwendung auf Ihrem Laptop, stellen sie in Produktion, und in dem Moment, in dem echte Benutzer kommen, stürzen Server ab, Datenbankverbindungen laufen über, und Ihre AWS-Rechnung sieht aus wie eine Telefonnummer. Die meisten Entwickler versuchen, Cloud-Engineering zu lösen, indem sie dreihundert verschiedene AWS-Produktakronyme auswendig lernen. Aber echtes Cloud Computing geht nicht darum, Anbieterkataloge auswendig zu lernen: es basiert auf elf grundlegenden architektonischen Primitiven.

0:34 In dieser Masterclass werden wir den gesamten Unternehmens-Blueprint durchgehen: von Skalierung und Lastausgleich bis hin zu Serverless, ereignisgesteuerter Entkopplung, Speicherhierarchien und Cloud-Netzwerken. Beherrschen Sie diese elf Konzepte, und Sie können jedes Backend auf AWS, GCP oder Azure entwerfen. Das ist The Daily Diff, unter der Haube.

- 01. Vertikale vs. Horizontale Skalierung

0:57 Konzept Nummer eins: Skalierung. Wenn Ihre Anwendung ein Verkehrswachstum erfährt, haben Sie zwei grundlegend unterschiedliche Wege, die Last zu bewältigen: vertikale Skalierung oder horizontale Skalierung. Vertikale Skalierung, oder Skalierung nach oben, bedeutet, Ihre vorhandene Maschine zu nehmen und mehr Ressourcen hinzuzufügen: von vier CPU-Kernen auf zweiunddreißig aufzurüsten oder zweiunddreißig Gigabyte RAM gegen einhundertachtundzwanzig auszutauschen. Vertikale Skalierung erfordert keine architektonischen Änderungen: Ihr Code

1:28 und Ihre Datenbank bleiben genau gleich. Aber es stößt an eine brutale Hardwaregrenze. Keine einzelne Maschine auf der Welt hat zehntausend CPU-Kerne, und Top-Tier-Instanzen haben einen exponentiellen Preisaufschlag. Horizontale Skalierung, oder Skalierung nach außen, bedeutet, Ihre Server klein und preisgünstig zu halten, aber mehrere Instanzen parallel hinter einem Router zu betreiben. Wenn eine Instanz abstürzt, absorbieren die verbleibenden Knoten den Datenverkehr mit null Ausfallzeit. Die goldene Regel der horizontalen Skalierung ist

2:01 Zustandslosigkeit: Ihre Anwendungsserver dürfen keine Benutzersitzungen, hochgeladenen Dateien oder Zustände auf ihren lokalen Festplatten speichern. Der Zustand muss in einer externen Datenbank oder einem Cache leben, wodurch jeder Knoten jede Benutzeranfrage bearbeiten kann.

- 02. Lastausgleichsarchitektur (L4 vs. L7 & Health Checks)

2:17 Konzept Nummer zwei: Lastausgleich. Horizontale Skalierung klingt auf dem Papier großartig, führt aber sofort zu einem Problem: Wenn zehntausend Benutzer Ihre Domäne aufrufen, welcher spezifische Server erhält ihren Datenverkehr? Ein Lastausgleich dient als Reverse-Proxy zwischen dem öffentlichen Internet und Ihrem privaten Backend-Cluster. Er akzeptiert eingehende TCP- oder HTTP-Verbindungen und verteilt Anfragen auf Ihre gesunden Instanzen.

2:47 Lastausgleicher arbeiten auf zwei primären Netzwerkschichten. Layer-4-Netzwerklastausgleicher arbeiten auf der Transportschicht und routen rohe TCP- und UDP-Pakete basierend auf IP-Adresse und Port mit Mikrosekunden-Latenz und Millionen von Anfragen pro Sekunde. Layer-7-Anwendungslastausgleicher inspizieren das HTTP-Protokoll selbst: Lesen von URL-Pfaden, Anfrage-Headern, Cookies und HTTP- Methoden. Dies ermöglicht pfadbasiertes Routing: Senden von Slash-Api- Anfragen an Ihren Backend-Cluster und Slash-Static-Anfragen an einen

3:25 Objektspeicher. Entscheidend ist, dass Lastausgleicher aktive Gesundheitsprüfungen durchführen. Alle paar Sekunden pingt der Balancer einen Health-Endpoint auf jeder Instanz an. Wenn eine Instanz drei aufeinanderfolgende Fünfhundert-Fehler wirft oder nicht reagiert, wird sie automatisch aus dem Pool entfernt, ohne dass eine einzige Anfrage verloren geht.

- 03. Autoskalierung & Elastizität

3:45 Konzept Nummer drei: Autoskalierung. Wenn Ihre Web-App um drei Uhr morgens zwei Server benötigt, aber während eines Launches am Mittag zwanzig Server, ist das manuelle Klicken von Knöpfen in der Cloud-Konsole ein garantierter Weg zu Ausfallzeiten und Bankrott. Autoskalierung bringt dynamische Elastizität in horizontale Serverpools. Eine Auto-Scaling-Gruppe überwacht Leistungsmetriken wie die durchschnittliche CPU-Auslastung, Netzwerk-I/O oder die Tiefe des Warteschlangenrückstands. Wenn die durchschnittliche CPU einen definierten Schwellenwert überschreitet – sagen wir,

4:19 siebzig Prozent für drei aufeinanderfolgende Minuten – startet der Autoskaler automatisch neue virtuelle Maschinen, registriert sie bei Ihrem Lastausgleich und beginnt mit dem Routing des Datenverkehrs. Ebenso wichtig ist das Herunterskalieren: Wenn die Verkehrswelle abebbt, beendet der Autoskaler überschüssige Instanzen, damit Sie nicht mehr für ungenutzte Rechenleistung bezahlen. Um ein „Flapping“ zu verhindern – bei dem Server schnell erstellt und in einer endlosen Schleife zerstört werden – konfigurieren Cloud-Architekten Abkühlphasen. Konzept Nummer vier: Serverless.

- 04. Serverless (FaaS & Firecracker MicroVMs)

4:53 Jahrelang priesen Marketingteams Serverless als magischen Code, der im Himmel läuft. In Wirklichkeit verwendet Serverless immer noch Server – aber Sie besitzen, patchen oder bezahlen sie nicht, wenn kein Code läuft. Mit Function-as-a-Service wie AWS Lambda oder Google Cloud Functions schreiben Sie eine eigenständige Handler-Funktion. Wenn eine HTTP-Anfrage, ein S3-Datei-Upload oder eine Datenbankänderung auftritt, bootet die Cloud-Laufzeit eine kurzlebige

5:23 Mikro-Virtual-Machine wie Firecracker in unter fünf Millisekunden. Ihr Code wird ausgeführt, gibt eine Antwort zurück und wird heruntergefahren. Wenn drei Monate lang niemand Ihre Website besucht, beträgt Ihre Rechenrechnung genau null Dollar und null Cent. Wenn eine Million Benutzer sie gleichzeitig aufrufen, startet der Anbieter eine Million gleichzeitiger MicroVMs. Die technischen Kompromisse sind real: Kaltstart- Latenz beim Starten neuer Laufzeiten, eine harte Fünfzehn-Minuten-Ausführungsgrenze bei Lambda und strikte Zustandslosigkeit.

5:55 Serverless ist unschlagbar für Ereignispipelines und sporadische APIs, aber schlecht für persistente WebSockets oder mehrstündige Trainingsläufe.

- 05. Ereignisgesteuerte Architektur (EDA & Entkopplung)

6:05 Konzept Nummer fünf: Ereignisgesteuerte Architektur oder EDA. In traditionellen Architekturen kommunizieren Dienste synchron. Ihr Checkout-Dienst ruft Zahlung auf, Zahlung ruft Inventar auf, Inventar ruft Betrug auf, und Betrug ruft E-Mail auf. Dies erzeugt die synchrone Kaskade des Untergangs. Wenn der Drittanbieter für E-Mails einen Netzwerk-Hiccup hat und zehn Sekunden zur Antwort benötigt, läuft die gesamte Checkout-Anfrage Ihres Kunden mit einem Fehler ab. In einer ereignisgesteuerten Architektur sind Dienste vollständig entkoppelt.

6:37 Wenn ein Kunde auf „Kaufen“ klickt, ruft der Checkout-Dienst keine nachgeschalteten Dienste auf. Er veröffentlicht einfach ein Ereignis namens „OrderPlaced“ an einen zentralen Event Bus wie Amazon EventBridge oder ein SNS-Topic. Der Checkout ist in fünfzig Millisekunden abgeschlossen. Nachgeschaltete Worker für Zahlung, Bestandsreduzierung und E-Mail-Bestätigungen ziehen Nachrichten unabhängig aus ihren eigenen dedizierten SQS-Warteschlangen. Wenn der E-Mail-Dienst eine Stunde lang ausfällt, warten Nachrichten sicher gepuffert in der Warteschlange, ohne dass eine einzige Bestellung verloren geht.

- 06. Container-Orchestrierung (Docker & Kubernetes)

7:13 Konzept Nummer sechs: Container-Orchestrierung. Docker löste das Verpackungsproblem: Es umschließt Ihren Anwendungscode, Systembibliotheken, Konfiguration und Laufzeit in ein unveränderliches Image, das identisch auf Ihrem MacBook und in der Cloud läuft. Aber das Verpacken eines Containers ist einfach. Fünfhundert Container auf fünfzig physischen virtuellen Maschinen zu betreiben, ist der Punkt, an dem das Engineering versagt. Deshalb existieren Container-Orchestrierer wie Kubernetes und AWS ECS.

7:41 Ein Orchestrierer bietet eine Steuerungsebene: einen API-Server, einen etcd-Zustandsspeicher und einen intelligenten Scheduler. Sie deklarieren Ihren gewünschten Zustand: Ich möchte zehn Replikate meines Auth- Dienstes mit jeweils zwei Gigabyte RAM. Der Scheduler inspiziert den Cluster, platziert Pods auf Knoten mit freiem Speicher, konfiguriert interne Netzwerke und gleicht die Realität kontinuierlich ab. Wenn ein Knoten einen Hardwarefehler erleidet, erkennt Kubernetes den Verlust und plant alle verdrängten Pods sofort auf

- 07. Die 4 Säulen des Cloud-Speichers (S3, EBS, DBs & Redis)

8:16 gesunde Knoten neu. Konzept Nummer sieben: Die Cloud-Speicherhierarchie. Anfänger behandeln Cloud-Speicher oft als einen einzigen Bucket, in den man Dateien kippt. In der Produktionsarchitektur ist Speicher in vier verschiedene Säulen unterteilt, basierend auf Zugriffsmustern und Latenz. Zuerst ist Objektspeicher, wie Amazon S3 oder Google Cloud Storage. Sie greifen über HTTP-REST-APIs auf Dateien zu, indem Sie einfache PUT- und GET-Aufrufe verwenden. Er bietet unendliche horizontale Kapazität zu zwei Cent pro Gigabyte pro Monat,

8:49 was ihn ideal für Videos, Benutzer-Uploads, Logs und Backups macht. Zweitens ist Blockspeicher, wie Amazon EBS. Dies sind virtuelle Festplatten, die direkt an eine bestimmte virtuelle Maschine über Hochgeschwindigkeitsverbindungen angeschlossen sind. Sie formatieren sich in Standard-Dateisysteme wie ext4 und unterstützen schnellen zufälligen Lese- und Schreibzugriff, der von Datenbank- Engines benötigt wird. Drittens sind Verwaltete Datenbanken: relationale Engines wie PostgreSQL auf RDS, die ACID-Transaktionen und komplexe Joins bereitstellen,

9:21 und NoSQL-Engines wie DynamoDB, die einstellige Millisekunden-Latenz bei massiver Skalierung liefern. Und viertens sind In-Memory-Caches wie Redis. Das Lesen von Daten aus dem RAM dauert Mikrosekunden statt Millisekunden. Caches sitzen vor Ihrer Datenbank, schützen sie vor wiederholtem Lesezugriff und verwalten flüchtige Benutzersitzungstoken.

- 08. Hochverfügbarkeit & Die Neunen (Multi-AZ Failover)

9:44 Konzept Nummer acht: Hochverfügbarkeit oder HA. Verfügbarkeit beantwortet eine Frage: Wie viel Prozent der Zeit ist Ihre Anwendung betriebsbereit und für Benutzer erreichbar? In Unternehmensverträgen wird die Verfügbarkeit in Neunen gemessen. Zwei Neunen, oder neunundneunzig Prozent Verfügbarkeit, erlauben über dreieinhalb Tage Ausfallzeit pro Jahr. Vier Neunen reduzieren die erlaubte Ausfallzeit auf zweiundfünfzig Minuten, und fünf Neunen erlauben kaum fünf Minuten Gesamtausfallzeit pro

10:15 Jahr. Um Hochverfügbarkeit zu erreichen, müssen Sie einzelne Fehlerquellen über Fehlerdomänen hinweg eliminieren. In der Cloud bedeutet das, die Bereitstellung über mehrere Availability Zones hinweg. Eine Availability Zone ist kein einzelnes Rack: Es sind ein oder mehrere separate physische Rechenzentren, die kilometerweit voneinander entfernt sind, mit unabhängiger Stromversorgung und Kühlung. Durch den Betrieb aktiver Instanzen in Zone A und Zone B mit synchroner Datenbankreplikation führt ein Blitzeinschlag oder ein Glasfaserkabelbruch, der eine gesamte physische Einrichtung außer Betrieb setzt, zu einem automatisierten Failover.

10:50 in dreißig Sekunden ohne menschliches Eingreifen.

- 09. Durabilität vs. Verfügbarkeit (Warum 11 Neunen keine Uptime ist)

10:53 Konzept Nummer neun: Dauerhaftigkeit versus Verfügbarkeit. Dies ist die häufigste konzeptionelle Falle in Cloud-Architektur-Interviews Interviews. Ingenieure verwenden die Wörter häufig synonym, aber sie messen völlig unterschiedliche Eigenschaften. Verfügbarkeit misst die Betriebszeit: Kann ich in dieser Sekunde einen API-Aufruf tätigen, um meine Daten zu lesen oder zu schreiben? Daten genau in dieser Sekunde? Dauerhaftigkeit misst die Erhaltung: Werden meine Daten ohne dauerhaften Bitrot, Korruption oder Zerstörung über zehn Jahre hinweg überleben? Bitrot, Korruption oder Zerstörung über zehn Jahre?

11:24 Schauen Sie sich Amazon S3 Standard an. Sein Service Level Agreement bietet neunundneunzig Komma neun Prozent Verfügbarkeit, was ungefähr dreiundvierzig Minuten Ausfallzeit pro Monat erlaubt wo eine API-Anfrage einen fünfhundert-Fehler zurückgeben könnte. Aber S3 verspricht elf Neuner an Dauerhaftigkeit: neunundneunzig Komma neun neun neun neun neun neun neun neun neun Prozent. Wenn Sie zehn Millionen Dateien in S3 speichern, können Sie statistisch erwarten, dass Sie durchschnittlich eine Datei alle zehntausend Jahre verlieren.

11:56 Durchschnittlich eine Datei alle zehntausend Jahre. S3 erreicht dies, indem es Objekte mit Erasure-Coding versieht und Chunks über mindestens drei geografisch getrennte Rechenzentren repliziert. mindestens drei geografisch getrennten Rechenzentren. Während eines größeren regionalen Netzwerkausfalls könnte S3 vorübergehend nicht verfügbar sein, nicht verfügbar, aber Ihre Daten werden niemals zerstört.

- 10. Infrastructure as Code (Terraform vs. Console Drift)

12:14 Konzept Nummer zehn: Infrastruktur als Code, oder IaC. In den Anfängen des Cloud Computing meldeten sich Ingenieure bei der AWS Web-Management-Konsole an und klickten sich manuell durch, um virtuelle Maschinen zu erstellen, Subnetze zu konfigurieren und Sicherheitsgruppen anzuhängen. Die Branche nennt dies ClickOps, und in der Produktion ist es ein absolutes Desaster. Manuelle Konsolenänderungen haben keine Audit-Trail, keinen Rollback-Mechanismus Mechanismus und verursachen unweigerlich eine Konfigurationsdrift zwischen Staging- und Produktionsumgebungen. Mit Infrastruktur-als-Code-Tools

12:48 als Code-Tools wie Terraform, OpenTofu, Pulumi oder AWS CDK definieren Sie Ihre gesamte Cloud-Architektur in deklarativen Konfigurationsdateien, die in Git gespeichert sind. Jede Änderung an einem offenen Port oder einer Datenbankreplik geht durch einen Pull-Request und Peer-Review. Das Ausführen von `terraform plan` zeigt den genauen API-Diff an, bevor etwas berührt wird, und das Hochfahren einer identischen Replik Ihres Produktions-Stacks Stacks dauert vier Minuten statt vier Wochen.

- 11. Cloud-Netzwerke (VPC, Subnetze, NAT & Sicherheitsgruppen)

13:20 Konzept Nummer elf: Cloud Networking und Virtual Private Clouds. Wenn Sie Server in der Cloud bereitstellen, sind sie nicht ungeschützt im reinen öffentlichen Internet. Sie leben innerhalb einer softwaredefinierten, isolierten Grenze, genannt eine VPC. Innerhalb Ihrer VPC weisen Sie einen privaten IP-Adressraum zu, wie zehn-Punkt-null-Punkt-null-Punkt-null Schrägstrich sechzehn, und teilen ihn in öffentliche und private Subnetze. Ein öffentliches Subnetz hat eine direkte Route zu einem Internet-Gateway.

13:51 Es enthält öffentlich zugängliche Assets wie Ihre Application Load Balancers und NAT Gateways. Es ist der einzige Teil Ihres Netzwerks, der öffentliche IP-Adressen besitzt. Adressen. Ihre Anwendungsserver und Produktionsdatenbanken leben streng in privaten Subnetzen ohne öffentliche IPs und ohne eingehende Routen aus dem Internet. Wenn Ihre Backend-Server Sicherheitsupdates herunterladen müssen, Ihr ausgehender Datenverkehr wird über das NAT-Gateway im öffentlichen Subnetz geleitet. Jede Instanz ist von Sicherheitsgruppen umgeben: zustandsbehaftete virtuelle Firewalls, die das Prinzip der geringsten Rechte durchsetzen.

- 12. Der komplette Unternehmens-Blueprint & Urteil

14:28 Ihre Datenbanksicherheitsgruppe akzeptiert nur Verbindungen auf Port 5432 ausschließlich von der Sicherheitsgruppe Ihrer Anwendungsserver, wodurch ein Eindringen von außen mathematisch unmöglich wird. Wenn man herauszoomt, verbinden sich diese elf Primitive zu einem kohärenten System. Ihr DNS leitet zu einem Load Balancer in einem öffentlichen Subnetz, Autoscaling-Gruppen bewältigen Verkehrsspitzen über mehrere Availability Zones hinweg, Event-Busse entkoppeln Backend-Worker, und Ihr gesamter Stack wird mit Infrastructure as Code aus Git bereitgestellt.

15:02 Das Urteil der heutigen Meisterklasse: SHIP IT. Hören Sie auf, hunderte von Cloud-Marketing-Akronymen auswendig zu lernen. Meistern Sie diese elf Architekturmuster, entkoppeln Sie Ihren Zustand, und bauen Sie Systeme, die nicht ausfallen können. Erzählen Sie mir, welches Cloud-Konzept Ihnen die größten Kopfschmerzen bereitete, als Sie zum ersten Mal anfingen im Kommentarbereich zu bauen. Und um das vollständige Architektur-Cheat Sheet zu erhalten, abonnieren Sie den Newsletter unter the daily diff dot dev,

15:28 Link unten. Und das ist der Diff für heute. Ich bin Niko von Axrisi. Verantwortungsbewusst zusammenführen.

Quellen

1. AWS Well-Architected Framework (Reliability & Performance Pillars)aws.amazon.com
2. Kubernetes Architecture & Control Plane Conceptskubernetes.io
3. Martin Fowler: What is Event-Driven Architecture?martinfowler.com
4. Amazon S3 Data Durability & Availability Technical Whitepaperaws.amazon.com
5. HashiCorp: Declarative Infrastructure as Code with Terraformwww.terraform.io