Cloud Computing

"Die Cloud" ist einfach nur der Computer von jemand anderem. Statt deine Fotos auf deiner Festplatte zu speichern, speicherst du sie auf den Festplatten von Google oder Apple. Statt einen teuren Server in den Keller zu stellen, mietest du Rechenpower bei Amazon (AWS).

Der Vorteil: Du zahlst nur, was du nutzt (wie Strom aus der Steckdose). Wenn du mehr Speicher brauchst, klickst du einen Knopf, und er ist da. Du musst keine neue Festplatte kaufen gehen.

Merksatz: IT-Dienste (Speicher, Rechenpower), die über das Internet gemietet werden.

Wir nutzen die Cloud ständig:

SaaS (Software as a Service): Netflix, Gmail, Spotify. Die App läuft nicht bei dir, sondern auf deren Servern.
IaaS (Infrastructure as a Service): Als Firma mietest du "nackte" Server bei AWS, um darauf deine eigene Software laufen zu lassen.
Storage: Dropbox, Google Drive, iCloud. Deine Dateien sind überall verfügbar, egal ob Handy oder Laptop.

Der größte Vorteil für Firmen: Skalierbarkeit. Start-up wächst über Nacht? Kein Problem, miete einfach 1000 Server dazu. Nächste Woche brauchst du sie nicht mehr? Kündige sie.

1. Public vs. Private vs. Hybrid

Public Cloud: AWS, Azure, Google Cloud. Jeder kann sich einmieten. Die Hardware wird geteilt (Multi-Tenant).
Private Cloud: Ein eigenes Rechenzentrum, das nur einer Firma gehört, aber so flexibel funktioniert wie die Cloud (Virtualisierung). Maximale Sicherheit.
Hybrid Cloud: Ein Mix. Sensible Bankdaten bleiben privat, die Webseite läuft öffentlich bei AWS.

2. Regionen & Availability Zones

Die Cloud ist nicht "im Himmel", sondern in riesigen Betonbunkern voller Server. Anbieter teilen die Welt in Regionen (z. B. "Frankfurt", "USA Ost"). Jede Region hat mehrere Availability Zones (AZ) (getrennte Gebäude). Wenn ein Bagger das Kabel zu Gebäude A durchtrennt, läuft deine App in Gebäude B weiter. Das nennt man Hochverfügbarkeit (High Availability -> HA).

1. Hypervisor und VM-Isolation

Die Magie von IaaS (wie AWS EC2). Ein physischer Server (Bare Metal) im Keller von Amazon hat evtl. 128 Prozessorkerne. Auf diesem Blech läuft ein Hypervisor (z.B. KVM oder VMware ESXi). Er gaukelt den Mietern (Tenants) vor, sie hätten einen eigenen PC. Er hackt die 128 Kerne in 30 "Virtual Machines" (VMs). Max mietet VM1 (Linux), Anna mietet VM2 (Windows). Der Hypervisor isoliert den RAM und die CPU-Zyklen hardwarenah auf Siliziumebene streng ab. Max kann Annas RAM physikalisch nicht auslesen (außer durch Spectre/Meltdown Side-Channel-Attacken, der größte Albtraum von Cloud-Providern).

2. VPC (Virtual Private Cloud)

Wenn du VMs bei AWS klickst, stehen die standardmäßig nicht nackt und gefährdet im öffentlichen Internet. Du baust zuerst eine VPC. Das ist ein streng abgeschirmtes Software Defined Network (SDN), dein lokales LAN, nur virtuell. Dort baust du Subnetze. Du packst die Datenbank in ein "Private Subnet" (keine öffentliche IP, kein Internetzugang). Das Frontend (Webserver) packst du in ein "Public Subnet". Du definierst Routing-Tables und NAT-Gateways, genau wie ein Netzwerk-Techniker mit echten Cisco-Kabeln, nur eben über API-Calls.

3. Vendor Lock-In

Der gefährlichste Business-Aspekt der Public Cloud. Wenn du deine App als simpel gekapselte Container (docker) betreibst, kannst du morgen von AWS zu Azure wechseln. Wenn du aber anfängst, proprietäre Cloud-Services zu nutzen (AWS DynamoDB statt offenem Postgres, AWS Lambda, AWS SQS), baust du deine Geschäftslogik direkt in die Amazon-Spezifikation. Verdoppelt Amazon die Preise, bist du gefangen (Vendor Lock-In). Die Migration (Umschreiben des Source Codes auf Azure-Äquivalente) würde Jahre dauern und Millionen kosten. Architekten balancieren ständig zwischen "Speed through Native Services" und "Agility through Cloud Agnostic (Kubernetes)".