Block 03 – Cloud & Skalierung¶

Lernziele¶

Du kannst IaaS, PaaS und SaaS voneinander abgrenzen und Beispiele nennen
Du kannst Vertical und Horizontal Scaling erklären und vergleichen
Du kannst erklären was Blob Storage ist und wofür er eingesetzt wird
Du kannst beschreiben was ein CDN ist und welches Problem es löst

1. Cloud-Servicemodelle¶

Vor der Cloud betrieb jedes Unternehmen seine eigene Infrastruktur: eigene Server, eigenes Rechenzentrum, eigenes Netzwerk. Das nennt man On-Premises (kurz: On-Prem).

Die Cloud hat das verändert – je nach Modell übernimmt der Cloud-Anbieter mehr oder weniger Verantwortung.

On-Premises vs. Cloud¶

flowchart LR
    subgraph On-Prem
        H[Hardware] --> OS[Betriebssystem] --> R[Runtime] --> A[Applikation]
    end
    subgraph Cloud
        CP[Cloud Provider] --> A2[Applikation]
    end

IaaS – Infrastructure as a Service¶

Der Anbieter stellt Hardware und Netzwerk bereit. Du verwaltest alles ab dem Betriebssystem selbst.

Beispiele: AWS EC2, Azure Virtual Machines, Google Compute Engine

Zuständigkeit: - Anbieter: Hardware, Netzwerk, Virtualisierung - Du: OS, Middleware, Runtime, Applikation, Daten

Im Modul 158: AWS EC2 ist IaaS – du installierst das Betriebssystem, Apache, PHP und MySQL selbst.

PaaS – Platform as a Service¶

Der Anbieter stellt eine fertige Laufzeitumgebung bereit. Du kümmerst dich nur noch um die Applikation und die Daten.

Beispiele: Heroku, AWS Elastic Beanstalk, Google App Engine

Zuständigkeit: - Anbieter: Hardware, OS, Middleware, Runtime - Du: Applikation, Daten

Vorteil: Kein Serverbetrieb nötig – du deployst einfach deinen Code. Nachteil: Weniger Kontrolle, Abhängigkeit vom Anbieter (Vendor Lock-in).

SaaS – Software as a Service¶

Der Anbieter stellt eine fertige Applikation bereit. Du nutzt sie einfach – ohne Installation, ohne Wartung.

Beispiele: Google Workspace, Microsoft 365, Salesforce, GitHub

Zuständigkeit: - Anbieter: Alles - Du: Daten und Konfiguration

Vergleich¶

	On-Prem	IaaS	PaaS	SaaS
Hardware	Du	Anbieter	Anbieter	Anbieter
Betriebssystem	Du	Du	Anbieter	Anbieter
Runtime / Middleware	Du	Du	Anbieter	Anbieter
Applikation	Du	Du	Du	Anbieter
Kontrolle	✅ Maximal	✅ Hoch	⚠️ Mittel	❌ Gering
Aufwand	❌ Hoch	⚠️ Mittel	✅ Gering	✅ Minimal

Shared Responsibility: In jedem Modell gibt es eine klare Grenze zwischen Anbieter- und Kundenzuständigkeit. Diese "Shared Responsibility" ist besonders bei Sicherheitsfragen wichtig – was der Anbieter nicht absichert, musst du selbst absichern.

2. Skalierung¶

Skalierung bedeutet, ein System an wachsende Last anzupassen. Es gibt zwei grundlegende Ansätze:

Vertical Scaling (Scale Up)¶

Du machst den bestehenden Server leistungsfähiger: mehr CPU, mehr RAM, grössere Festplatte.

flowchart LR
    S1[Server\n2 CPU / 4 GB RAM] -->|Upgrade| S2[Server\n8 CPU / 32 GB RAM]

Vorteile: - Einfach umzusetzen – kein Code muss angepasst werden - Keine Komplexität durch mehrere Server

Nachteile: - Hat ein physisches Limit (irgendwann gibt es keinen grösseren Server mehr) - Teuer bei sehr grosser Last - Single Point of Failure – fällt der Server aus, ist alles weg

Horizontal Scaling (Scale Out)¶

Du fügst mehr Server hinzu und verteilst die Last zwischen ihnen.

flowchart LR
    LB[Load Balancer] --> S1[Server 1]
    LB --> S2[Server 2]
    LB --> S3[Server 3]

Vorteile: - Theoretisch unbegrenzt skalierbar - Ausfallsicherheit – fällt ein Server aus, übernehmen die anderen - Günstiger bei sehr grosser Last (viele kleine Server statt ein riesiger)

Nachteile: - Applikation muss für mehrere Server ausgelegt sein (stateless) - Mehr Komplexität (Load Balancer, Session-Management)

Wann was?¶

Situation	Empfehlung
Einfache Applikation, temporär mehr Last	Vertical Scaling
Langfristiges Wachstum, hohe Verfügbarkeit	Horizontal Scaling
WordPress auf einem Server	Vertical Scaling (einfacher)
Grosser Online-Shop, Millionen Nutzer	Horizontal Scaling

3. Blob Storage¶

Blob Storage (Binary Large Object) ist ein Cloud-Speicherdienst für unstrukturierte Dateien: Bilder, Videos, PDFs, Backups, Logs.

Im Gegensatz zu einer Datenbank (strukturiert) oder einem Dateisystem (hierarchisch) ist Blob Storage flach organisiert: Objekte liegen in sogenannten Buckets (Containern) und werden über eine URL oder einen Key adressiert.

https://mein-bucket.s3.amazonaws.com/uploads/bild.jpg

Bekannte Dienste: - AWS S3 (Simple Storage Service) - Azure Blob Storage - Backblaze B2 - Google Cloud Storage

Einsatzzwecke: - Medien-Uploads (Bilder, Videos auf Websites) - Backups (wie im Modul 158 mit rclone + Backblaze B2) - Statische Websites - Log-Archivierung

Vorteile gegenüber lokalem Speicher: - Nahezu unbegrenzte Kapazität - Redundanz – Daten werden automatisch mehrfach gespeichert - Weltweit erreichbar - Günstig für grosse Datenmengen

Zugriff auf Blob Storage – warum keine Serveradresse?¶

Bei einem klassischen Dateiserver gibst du eine IP-Adresse oder einen Hostnamen an:

rsync -av /backup/ user@192.168.1.10:/backups/

Bei Blob Storage gibst du nur Bucket-Name und Objekt-Key an – keine IP, kein Hostname:

rclone copy /backup/ backblaze:mein-bucket/backups/

Warum? Blob Storage ist abstrahiert. Du weisst nicht und musst nicht wissen, auf welchem physischen Server deine Daten liegen. Der Anbieter verwaltet das intern – deine Daten könnten auf 10 verschiedenen Servern in 3 Ländern verteilt sein. Du adressierst nur den logischen Ort (Bucket + Key), der Rest ist Sache des Anbieters.

Das ist dasselbe Prinzip wie bei DNS: Du kennst google.com, nicht 142.250.185.46.

API Keys für den Bucket-Zugriff¶

Blob Storage wird über eine REST API angesprochen – genau das was du in Block 2 gelernt hast. rclone macht nichts anderes als HTTP-Requests an diese API zu senden.

Für den Zugriff brauchst du keine Benutzername/Passwort-Kombination, sondern einen API Key – bestehend aus zwei Teilen:

Teil	Beschreibung	Beispiel
Key ID	Öffentliche Identifikation	`001abc123def456`
Application Key	Geheimes "Passwort"	`K001xyz...`

Warum API Keys statt Passwörter? - Können jederzeit widerrufen werden ohne das Hauptpasswort zu ändern - Können auf bestimmte Berechtigungen eingeschränkt werden (z.B. nur Lesen, nur ein Bucket) - Können pro Applikation/Skript vergeben werden – Backupskript hat seinen eigenen Key

# rclone speichert die Keys in ~/.config/rclone/rclone.conf
# Das Backup-Skript verwendet diese Konfiguration automatisch
rclone copy /backup/ backblaze:mein-bucket/

Sicherheitsprinzip Least Privilege: Der API Key für das Backup-Skript sollte nur Schreibrechte auf den Backup-Bucket haben – nicht auf alle Buckets, nicht Löschen, nicht Konfiguration ändern. So begrenzt du den Schaden wenn der Key in falsche Hände gerät.

Datenschutz: Weiss ich wo meine Daten liegen?¶

Bei Blob Storage gibst du keine Serveradresse an – du weisst also nicht auf welchem physischen Server, in welchem Land, deine Daten gespeichert werden. Das ist nicht nur ein technisches Detail, sondern ein Datenschutzproblem.

Warum ist der Speicherort relevant?

In der Schweiz und der EU gilt die DSGVO (Datenschutz-Grundverordnung). Personenbezogene Daten (z.B. Kundendaten, E-Mail-Adressen) dürfen nicht einfach auf Servern in beliebigen Ländern gespeichert werden – insbesondere nicht in Ländern ohne angemessenes Datenschutzniveau.

Backblaze B2 hat Rechenzentren in den USA und in Amsterdam. Für den Schulbetrieb im Modul 158 ist das kein Problem – die Backups enthalten keine personenbezogenen Daten. In einem echten Produktionssystem müsste man das sorgfältig prüfen.

Lösung 1: Region wählen

Viele Anbieter erlauben es, eine Region zu wählen:

Backblaze B2: us-west (USA) oder eu-central (Amsterdam)
AWS S3:       eu-central-1 (Frankfurt), eu-west-1 (Irland), ...

Damit weisst du zumindest in welchem Land die Daten liegen.

Lösung 2: Client-seitige Verschlüsselung

Wenn du Daten vor dem Upload verschlüsselst, kann der Anbieter sie nicht lesen – selbst wenn er Zugriff auf die Festplatten hätte. Das nennt sich Client-seitige Verschlüsselung (im Gegensatz zur serverseitigen Verschlüsselung, die der Anbieter kontrolliert).

# rclone unterstützt eingebaute Verschlüsselung via crypt-Remote
# Alle Daten werden lokal verschlüsselt bevor sie hochgeladen werden
rclone copy /backup/ backblaze-crypt:backups/

Löst das alle Datenschutzprobleme?

Weitgehend ja – aber nicht vollständig:

Problem	Client-seitige Verschlüsselung
Anbieter kann Daten lesen	✅ Gelöst
Datenleck beim Anbieter	✅ Gelöst (Daten sind unlesbar)
Speicherort unbekannt	⚠️ Nicht gelöst (Metadaten wie Dateinamen, Grösse können sichtbar sein)
Rechtliche Anforderungen DSGVO	⚠️ Teilweise – je nach Anbieter und Vertrag
Schlüsselverwaltung	❌ Neues Problem – wer verwahrt den Schlüssel?

Fazit: Für Backups ohne personenbezogene Daten (wie im Modul 158) reicht ein vertrauenswürdiger Anbieter mit europäischem Rechenzentrum. Bei sensiblen Daten ist Client-seitige Verschlüsselung ein wichtiger zusätzlicher Schutz – aber kein Freifahrtschein für beliebige Anbieter.

rsync vs. rclone – was ist ein Standard?¶

rsync ist ein etabliertes Unix-Tool aus den 1990ern mit eigenem Protokoll. Es ist kein offizieller Internetstandard, aber de-facto-Standard für Server-zu-Server-Synchronisation.

rclone ist kein Standard – es ist ein Open-Source-Tool das die APIs verschiedener Cloud-Anbieter implementiert. Es "übersetzt" deine Befehle in die jeweiligen REST API-Aufrufe des Anbieters.

	rsync	rclone
Protokoll	Eigenes rsync-Protokoll über SSH	REST API des jeweiligen Anbieters
Ziel	Server mit SSH-Zugang	Cloud Storage (S3, B2, GDrive, ...)
Authentifizierung	SSH-Key oder Passwort	API Key
Standard?	De-facto-Standard	Kein Standard, weit verbreitet
Im Modul 158	❌	✅ (Backup zu Backblaze B2)

4. CDN – Content Delivery Network¶

Ein CDN ist ein weltweites Netzwerk von Servern, die statische Inhalte (Bilder, CSS, JS) näher beim Endbenutzer zwischenspeichern.

flowchart LR
    O[Origin Server\nZürich] -->|Kopie| C1[CDN Node\nNew York]
    O -->|Kopie| C2[CDN Node\nTokyo]
    O -->|Kopie| C3[CDN Node\nFrankfurt]
    U1[User USA] --> C1
    U2[User Japan] --> C2
    U3[User Schweiz] --> C3

Das Problem das CDNs lösen: Ohne CDN muss jede Anfrage zum Origin Server – auch wenn der User in Japan ist und der Server in Zürich steht. Das erzeugt hohe Latenz (Verzögerung).

Mit CDN: - Statische Inhalte werden auf CDN-Nodes weltweit gecacht - Der User erhält die Datei vom nächstgelegenen Node - Der Origin Server wird entlastet

Bekannte CDN-Anbieter: Cloudflare, AWS CloudFront, Fastly

Was eignet sich für CDN? - ✅ Bilder, CSS, JavaScript, Fonts - ✅ Statische HTML-Seiten - ❌ Dynamische Inhalte (Datenbankabfragen, personalisierten Content)

CDN ausserhalb von Webseiten¶

CDNs werden längst nicht nur für Websites eingesetzt – sie sind eine grundlegende Infrastruktur des modernen Internets:

Einsatzbereich	Beschreibung	Beispiel
Software-Updates	Betriebssystem- und App-Updates werden über CDN ausgeliefert – sonst würden Millionen Geräte gleichzeitig einen einzigen Server anfragen	Windows Update, Apple Software Update
Video-Streaming	Videodateien sind riesig – ohne CDN wäre Netflix oder YouTube bei globaler Nutzung unmöglich	Netflix, YouTube, Twitch
Online-Gaming	Game-Clients, Patches und Assets werden über CDN verteilt	Steam, Epic Games Store
Mobile Apps	App-Downloads und In-App-Inhalte (Bilder, Sounds) kommen vom CDN	App Store, Google Play
APIs	Auch API-Antworten können gecacht werden, wenn sie sich nicht zu oft ändern	Wetterdaten, Börsenkurse
DDoS-Schutz	CDNs absorbieren riesige Mengen an Anfragen – ein Angriff trifft nicht mehr den Origin Server direkt	Cloudflare

Beispiel: Wenn Microsoft ein Windows-Update veröffentlicht und 500 Millionen Geräte es gleichzeitig herunterladen wollen, wäre ein einzelner Server sofort überlastet. Das CDN verteilt diese Last auf tausende Nodes weltweit – jedes Gerät lädt vom nächstgelegenen Node herunter.

Das zeigt: Ein CDN ist im Kern eine Lösung für zwei universelle Probleme – Latenz und Skalierung – die überall auftauchen wo viele Nutzer weltweit auf dieselben Inhalte zugreifen.

Testfragen¶

Was ist der Unterschied zwischen IaaS, PaaS und SaaS? Nenne je ein Beispiel.
AWS EC2 ist ein IaaS-Dienst. Was musst du selbst verwalten, was übernimmt AWS?
Erkläre den Unterschied zwischen Vertical und Horizontal Scaling. Wann setzt du welches ein?
Was ist ein Single Point of Failure und welche Skalierungsstrategie löst dieses Problem?
Was ist Blob Storage und wie unterscheidet er sich von einer Datenbank?
Im Modul 158 verwendest du Backblaze B2 für Backups. Zu welchem Servicemodell gehört Backblaze B2 (IaaS/PaaS/SaaS)?
Was ist ein CDN und welches Problem löst es? Was eignet sich für CDN-Caching, was nicht?
Warum gibst du beim Zugriff auf Blob Storage keine IP-Adresse an? Was steckt konzeptuell dahinter?
Was ist der Unterschied zwischen rsync und rclone?
Was ist ein API Key und warum ist es besser, pro Applikation einen eigenen Key zu erstellen statt einen einzigen zu verwenden?
Warum kann der Speicherort von Daten in der Cloud ein Datenschutzproblem sein?
Was ist der Unterschied zwischen client-seitiger und server-seitiger Verschlüsselung? Welche schützt besser gegen einen Datenleck beim Anbieter?
Nenne zwei Einsatzbereiche von CDNs ausserhalb von Webseiten und erkläre warum ein CDN dort sinnvoll ist.