Klausurzusammenfassung: Cloud Computing

1. Überblick und Prüfungslogik

Cloud Computing ist in der Klausur kein reines Definitionsfach. Typische Aufgaben verlangen, dass ein technischer oder betrieblicher Sachverhalt eingeordnet wird: Welche Verantwortung liegt beim Kunden, welche beim Provider, welche Art der Virtualisierung steckt darunter, welches Service- oder Bereitstellungsmodell passt und welche Risiken entstehen daraus?

Gliederung

1. Cloud-Grundlagen und On-Premise-Vergleich
2. Vorteile: Skalierung, On-Demand, globale Infrastruktur und Kosten
3. Herausforderungen: Kosten, Sicherheit, Governance und Know-how
4. Virtualisierung und Container
5. Service- und Bereitstellungsmodelle
6. Edge Computing
7. Docker: Container, Images, Registry und Dockerfile
8. Docker-Best-Practices und Probeklausur
9. Lerncheckliste und mögliche Klausurfragen
10. Abdeckung der Skripte

2. Cloud-Grundlagen und On-Premise-Vergleich

2.1 On-Premise

Beim On-Premise-Betrieb erwirbt ein Unternehmen Hardware und Software und betreibt diese auf eigener Infrastruktur. Damit entstehen hohe Anpassbarkeit und volle Kontrolle, aber auch volle Verantwortung für Anschaffung, Wartung, Updates, Verfügbarkeit, Sicherheit und Livegang.

Typische On-Premise-Probleme

2.2 Cloud Computing

Cloud Computing hebt den direkten Bezug zu konkreter Hardware auf. Statt physische Ressourcen selbst zu kaufen und zu betreiben, nutzt der Kunde virtuelle IT-Ressourcen über eine Management- und Automatisierungsschicht. Diese Ressourcen können Rechenleistung, Speicher, Netzwerk, Laufzeitumgebungen oder ganze Anwendungen sein.

3. Vorteile: Skalierung, On-Demand, globale Infrastruktur und Kosten

3.1 Skalierbarkeit

Skalierbarkeit beschreibt die Fähigkeit eines Anwendungssystems, seine Leistung flexibel zu erhöhen oder zu reduzieren. In der Cloud werden dafür virtuelle Ressourcen passend zur aktuellen Last konfiguriert. Dadurch werden Unterauslastung und Lastspitzen besser beherrschbar als beim starr dimensionierten On-Premise-Betrieb.

3.2 Fertige Cloud-Funktionen und Innovation

Cloud Provider stellen fertige Funktionen bereit, die in Eigenentwicklung teuer wären. Beispiele sind Bilderkennung, OCR, Sprachverarbeitung, Textanalyse, KI-Dienste, IAM, Monitoring oder Big-Data-Verarbeitung. Dadurch können Projekte komplexe Funktionen pilotieren, ohne sofort eigene Spezialteams und Infrastruktur aufzubauen.

3.3 Globale Verteilung und Latenz

Große Cloud Provider betreiben weltweit verteilte Rechen- und Speicherinfrastruktur und sind an zentrale Internetknoten angebunden. Das ermöglicht niedrige Latenzen für Anwendungsfälle wie Cloud-Gaming, virtuelle Zusammenarbeit, Telemedizin, Echtzeit-Tracking oder Echtzeit-Empfehlungen.

3.4 On-Demand-Bereitstellung

Cloud-Ressourcen können direkt über ein UI, eine API oder Automatisierung bereitgestellt werden. Dadurch entfällt der mehrstufige Beschaffungsprozess, und Ressourcen müssen nicht schon zu Projektbeginn grob überdimensioniert werden. Änderungen an Konfiguration und Kapazität bleiben später möglich.

3.5 Skaleneffekte

Provider können hohe Fixkosten für Rechenleistung, Netzwerksicherheit, DDoS-Schutz, Backups, Red Teams und Ausfallsicherheit auf viele Kunden und Dienste verteilen. Dadurch entstehen Skaleneffekte: Je mehr Dienste genutzt werden, desto stärker sinken die Stückkosten für einzelne Leistungen.

3.6 Wirtschaftlichkeit und Kostenlogik

Cloud Computing verändert die Kostenstruktur. On-Premise verursacht hohe Anfangsinvestitionen und relativ nutzungsunabhängige Kosten. Cloud Computing wandelt Fixkosten in variable, nutzungsabhängige Kosten um. Diese Fixkostenvariabilisierung erhöht die Planungsflexibilität, garantiert aber keine Gesamtersparnis.

4. Herausforderungen: Kosten, Sicherheit, Governance und Know-how

4.1 Kostenmanagement

Cloud-Kosten können deutlich über Plan liegen. Ursachen sind zusätzliche Ressourcennutzung, komfortable Zusatzdienste, nicht cloud-optimierte Legacy-Anwendungen, fehlende Abschaltung ungenutzter Ressourcen und Datenkosten. Besonders gefährlich ist, dass Cloud-Ressourcen schnell erstellt, aber organisatorisch nicht immer sauber verantwortet werden.

4.2 Sicherheit

Eine häufige Ursache für Datenabfluss ist mangelhafte Rechtekonfiguration auf Cloud-Datenspeichern. Zusätzlich müssen Daten in der Cloud verschlüsselt, Zugriffe geprüft und Netzwerkgrenzen sauber definiert werden. Der Provider bietet oft starke Sicherheitswerkzeuge, aber falsche Konfiguration bleibt ein Kundenrisiko.

4.3 Fehlende zentrale IT-Governance

Cloud-Ressourcen können dezentral von Teams bereitgestellt werden. Das beschleunigt Projekte, erschwert aber zentrale Vorgaben zu Datenschutz, Datenqualität, Softwarequalität, Kostenkontrolle und Synergien zwischen Projekten. In der Klausur ist wichtig: Der Wegfall zentraler Genehmigungsprozesse ist gleichzeitig Vorteil und Risiko.

4.4 Fehlendes Know-how

Cloud Computing verlangt neues Wissen in Infrastrukturmanagement und automatisierter Softwareauslieferung. Traditionelle, veränderbare Infrastruktur erzeugt schnell Schneeflocken-Konfigurationen. Cloud-nahe Systeme arbeiten besser mit reproduzierbarer, unveränderbarer Infrastruktur und Automatisierung.

5. Virtualisierung und Container

5.1 Simulation, Emulation und Virtualisierung

5.2 Gründe für Virtualisierung

5.3 Schichten eines Computersystems

Die Skripte unterscheiden Hardware, Kernel, Betriebssystem und Anwendung. Der Kernel spricht Hardware über Treiber an, koordiniert Ressourcen und kontrolliert Zugriffsrechte. Virtualisierung greift an unterschiedlichen Stellen dieser Schichten ein.

5.4 Voll-Virtualisierung

Bei der Voll-Virtualisierung bildet ein Hypervisor physische Hardware als virtuelle Maschinen ab. Jede VM besitzt ein eigenes Gast-Betriebssystem und ein eigenes Image. Das Gast-OS muss nicht angepasst werden und geht davon aus, direkten Hardwarezugriff zu haben. Der Hypervisor fängt Hardwarebefehle ab und ordnet sie den zugewiesenen Ressourcen zu.

5.5 Para-Virtualisierung

Bei der Para-Virtualisierung weiß das Gast-OS, dass es virtualisiert läuft. Hardwareaufrufe werden nicht so getan, als gingen sie direkt an physische Hardware, sondern als API-Aufrufe an den Hypervisor geleitet. Dadurch kann die Performance steigen, allerdings muss das Gast-OS angepasst sein.

5.6 Prozessvirtualisierung und Container

Prozessvirtualisierung startet keine vollständige VM und nutzt keinen klassischen Hypervisor. Stattdessen übernimmt der Linux-Kernel mit cgroups und namespaces die Prozessisolation.

5.7 Voll-Virtualisierung vs. Prozessvirtualisierung

6. Service- und Bereitstellungsmodelle

6.1 Abstraktion und Kontrolle

Cloud-Servicemodelle unterscheiden sich darin, welche Anteile einer Anwendung vom Provider verantwortet werden. Mit steigendem Abstraktionsgrad sinkt die Kontrolle des Kunden über Hardware und Betrieb, gleichzeitig gibt der Kunde Aufgaben wie Patching, Failover, Updates und Skalierung ab.

6.2 Servicemodelle

6.3 Bereitstellungsmodelle

Bereitstellungsmodelle beantworten, wo und wie Cloud-Dienstleistungen erbracht werden. Die zentrale Abwägung lautet: Wie viel Kontrolle und Datensouveränität wird benötigt, und wie stark sollen Skalierung, globale Infrastruktur und Providerbetrieb genutzt werden?

7. Edge Computing

Edge Computing verarbeitet Daten so nah wie möglich am Entstehungsort. Das Skript unterscheidet Edge Devices, Far Edge, Edge Computing und anschließend Private oder Public Cloud. Edge ersetzt Cloud Computing nicht, sondern ergänzt es dort, wo Latenz, Bandbreite, Datenschutz oder Offlinefähigkeit kritisch sind.

8. Docker: Container, Images, Registry und Dockerfile

8.1 Grundidee

Docker ist ein Werkzeug, mit dem Anwendungen gebaut, verteilt und betrieben werden können. Es nutzt Prozessvirtualisierung auf Basis von cgroups und namespaces und ist de facto Standard für Container. Die Container-Analogie aus der Schifffahrt ist wichtig: Standardisierung senkt manuellen Aufwand, erhöht Planbarkeit und erlaubt spezialisierte Infrastruktur.

8.2 Image vs. Container und Copy-on-Write

Ein Docker Image ist read-only und portabel. Beim Start erzeugt Docker daraus einen Container mit einer zusätzlichen beschreibbaren Schicht. Änderungen werden nach dem Copy-on-Write-Prinzip in diese temporäre Schicht kopiert und dort verändert. Nach dem Beenden des Containers wird diese Schicht gelöscht, wenn keine Persistenz konfiguriert wurde.

8.3 Docker-Befehlssyntax

8.4 Docker Images, Layer und Registry

Docker Images sind geschichtet. Jede Änderung erzeugt eine neue Schicht mit eigener Prüfsumme. Identische Schichten müssen nur einmal gespeichert und übertragen werden. Beim Build nutzt Docker den Build-Cache: Wenn sich eine Schicht nicht verändert hat, müssen sie und die darüberliegenden stabilen Schichten nicht neu gebaut werden.

8.5 Docker-Tags

8.6 Dockerfile-Aufbau

Ein Dockerfile ist eine Textdatei ohne Dateiendung. Es beschreibt, wie ein Docker Image gebaut wird. Die Skripte unterscheiden drei Blöcke: Baseimage, Anpassungen und Konfiguration der Ausführung.

9. Docker-Best-Practices und Probeklausur

9.1 Baseimage und Tags

Das Baseimage soll nur den notwendigen Funktionsumfang enthalten. Schlanke Images reduzieren Speicherbedarf, Übertragungszeit und Angriffsfläche. Offizielle Images sind zu bevorzugen, weil sie gepflegt und dokumentiert werden.

9.2 Geheimnisse und Umgebungsvariablen

Umgebungsvariablen eignen sich zur Laufzeitkonfiguration, etwa für Endpunkte, Profile oder Feature-Schalter. Sensible Daten dürfen nicht dauerhaft über ENV ins Image geschrieben werden, da Image-Historie und Metadaten auslesbar sein können. Wenn Umgebungsvariablen zur Laufzeit nötig sind, werden sie beim Start übergeben.

9.3 Layer-Reihenfolge und Build-Cache

Dockerfile-Befehle sollen nach Änderungsfrequenz sortiert werden: selten geänderte Schritte nach oben, häufig geänderte Schritte nach unten. Wird früh im Dockerfile eine häufig wechselnde Datei kopiert, invalidiert Docker den Cache für alle folgenden Schichten.

9.4 Non-root-Ausführung

Standardmäßig laufen Dockerfile-Befehle und Containerprozesse als root. Das ist riskant, weil Containerprozesse echte Prozesse auf dem Host sind und ein Ausbruch schwerwiegende Folgen haben kann. Deshalb sollte ein eigener Benutzer mit begrenzten Rechten angelegt und über USER verwendet werden.

9.5 Muster-Dockerfile für die Probeklausur

Die Probeklausur verlangt ein Dockerfile für eine Spring-Boot-Anwendung mit target/app.jar, Port 8000, Buildzeit-Argument statt Laufzeit-ENV, eigenem Arbeitsverzeichnis und Non-root-Ausführung.

FROM openjdk:16-jdk-alpine
COPY target/ .
ENV stage=prod
EXPOSE 8000
CMD ["java", "-jar", "app.jar"]

FROM openjdk:16-jdk-alpine

RUN mkdir -p /app
WORKDIR /app

ARG stage=prod
COPY target/app.jar app.jar

RUN addgroup -S javagr && adduser -S java -G javagr
USER java

EXPOSE 8000
CMD ["java", "-jar", "app.jar"]

9.6 Typische Dockerfile-Bewertung

10. Lerncheckliste und mögliche Klausurfragen

Lerncheckliste

• Ich kann On-Premise und Cloud anhand von Eigentum, Kontrolle, Verantwortung, Kosten und Anpassbarkeit unterscheiden.
• Ich kann vertikale und horizontale Skalierung erklären und passende Einsatzgrenzen nennen.
• Ich kann Cloud-Kosten nicht nur über Monatsgebühren, sondern mit versteckten Kosten, Skalierung und Governance bewerten.
• Ich kann Simulation, Emulation und Virtualisierung sauber abgrenzen.
• Ich kann Voll-, Para- und Prozessvirtualisierung erklären.
• Ich kann cgroups und namespaces als Grundlage von Containern beschreiben.
• Ich kann IaaS, CaaS, PaaS, FaaS und SaaS nach Kontrolle, Abstraktion und Lock-in einordnen.
• Ich kann Private, Public, Hybrid, Multi und Virtual Private Cloud mit Vor- und Nachteilen vergleichen.
• Ich kann Edge Computing von Private Cloud und Public Cloud abgrenzen.
• Ich kann Docker Image, Container, Registry, Dockerfile und Daemon erklären.
• Ich kann Docker-Kommandos für Container und Images sicher lesen und schreiben.
• Ich kann ein Dockerfile mit FROM, COPY, ARG, ENV, WORKDIR, RUN, USER, EXPOSE und CMD erstellen und begründen.

Mögliche Klausurfragen

1. Vergleichen Sie On-Premise und Cloud Computing für ein Startup und ein etabliertes internationales Unternehmen.
2. Erklären Sie, warum Cloud Computing nicht automatisch günstiger ist als On-Premise.
3. Unterscheiden Sie vertikale und horizontale Skalierung und nennen Sie Architekturfolgen.
4. Grenzen Sie Simulation, Emulation und Virtualisierung voneinander ab.
5. Vergleichen Sie Voll-Virtualisierung und Prozessvirtualisierung hinsichtlich Overhead, Isolation, Imagegröße und Skalierung.
6. Ordnen Sie einen Anwendungsfall einem geeigneten Servicemodell zu und begründen Sie den Lock-in.
7. Entwickeln Sie eine Cloud-Migrationsstrategie über Private, Hybrid, Virtual Private, Public oder Multi Cloud.
8. Erklären Sie, wann Edge Computing sinnvoller ist als reine Cloud-Verarbeitung.
9. Beschreiben Sie den Ablauf von docker container run hello-world vom Client bis zur Registry.
10. Erstellen und verbessern Sie ein Dockerfile für eine Spring-Boot-Anwendung.

Kurze Musterantworten

11. Abdeckung der Skripte