Cloud Computing – Theorie

Agiles Arbeiten – Kanban-Board

Methodik

Kanban ist eine Methode des agilen Arbeitens. Aufgaben wandern als Karten von links nach rechts durch ein Board mit definierten Spalten. Durch ein WIP-Limit (Work in Progress) wird verhindert, dass zu viele Aufgaben gleichzeitig bearbeitet werden – das fördert den Wissenstransfer und reduziert Engpässe.

📥 To-Do

Aufgaben, die noch nicht begonnen wurden. Gesammelt, priorisiert, wartet auf Bearbeitung.

⚙ In Arbeit

WIP-Limit: z.B. 10 Mitarbeiter → maximal 5 aktive Aufgaben. Verhindert Überlastung und erzwingt Wissenstransfer.

🔍 Review

Abgeschlossene Aufgaben werden hier abgelegt und von einer zweiten Person geprüft, bevor sie als fertig gelten.

✓ Done

Aufgabe wurde nach erfolgreichem Review abgeschlossen und gilt als vollständig erledigt.

ℹ Das WIP-Limit ist das Kernprinzip von Kanban: weniger gleichzeitige Arbeit → höhere Durchlaufgeschwindigkeit und bessere Qualität.

Definition Cloud Computing

NIST

      NIST-Definition: Cloud Computing ist ein Modell, das es erlaubt, bei Bedarf jederzeit und überall über ein Netzwerk auf einem geteilten Pool von konfigurierbaren Rechen-Ressourcen zuzugreifen. Diese sind schnell, mit minimalem Management-Aufwand und ohne direkte Mitwirkung des Service-Providers verfügbar.
    

Cloud Computing baut auf verschiedenen Rechenparadigmen auf, die sich in Architektur und Verteilung unterscheiden:

1 CPU	Mehrere CPUs (PC)	Cluster Computing	Grid Computing
Einzelner Prozessor in einem System	Mehrere CPUs in einem physischen System (SMP)	Verteilte Systeme mit gleicher CPU-Architektur	Verteilte Systeme mit verschiedenen CPU-Architekturen

Cloud Computing kann als Weiterentwicklung dieser Paradigmen verstanden werden: viele verteilte Ressourcen werden als homogener Pool abstrahiert und über das Netzwerk verfügbar gemacht.

Bildliche Darstellung der Cloud-Definition

Schaubild: Nutzer greifen über das Netzwerk auf einen gemeinsamen Ressourcenpool zu, der dynamisch bereitgestellt und gemessen wird.

Schaubild
[Nutzer: Web, App, API]
          |
          v
      [Netzwerk / Internet]
          |
          v
  [Cloud Control Plane]
   |   |    |    |    |
  Compute  Storage  DB  Netzwerk  Security
          |
          v
 [Geteilter Ressourcenpool (Multi-Tenant)]
          |
          v
 [On-Demand + Rapid Elasticity + Measured Service]

Die 5 Eigenschaften (NIST)

Prüfungsrelevant

Das NIST-Modell definiert fünf wesentliche Eigenschaften, die ein System aufweisen muss, um als Cloud Computing zu gelten:

Symbolbild (Merkhilfe): 👋 + ⏱️ + ◁ ◆ ◇ ■ □ ●
👋 = selbst machbar (On Demand), ⏱️ = zeitlich schnell/genau (Rapid Elasticity), ◁ ◆ ◇ ■ □ ● = viele verschiedene Services und freie Skalierung.

01

On Demand
Ressourcen bei Bedarf, ohne menschlichen Eingriff des Anbieters

02

Broad Network Access
Zugriff über das Netzwerk von beliebigen Geräten

03

Resource Pooling
Ressourcen werden mehreren Kunden geteilt (Multi-Tenancy)

04

Rapid Elasticity
Schnelles Skalieren nach oben und unten, auf- und abrufbar

05

Measured Service
Messbare Ressourcennutzung – pay-per-use, transparent für Anbieter und Nutzer

Beispiel-Services einer Cloud

ℹ Hover oder Klick zeigt die Kurzbeschreibung. Klick kopiert den Servicenamen.

Geschichte & Meilensteine

1999

Salesforce – erstes SaaS-Unternehmen, Software komplett über den Browser

2002

Amazon Web Services – erste interne Webservices von Amazon

2006

AWS öffentlich – EC2 (Elastic Compute Cloud) und S3 (Simple Storage Service) werden gelauncht

2008

Microsoft Azure – Microsofts Cloud-Plattform geht in die Beta

2009

Google Cloud – Google App Engine und erste Cloud-Dienste

2010

OpenStack – Open-Source Cloud-Plattform (NASA + Rackspace)

2011

IBM SmartCloud – IBM betritt den Enterprise-Cloud-Markt

ℹ Übersicht aller Cloud-Anbieter und Preisvergleiche: cloudorado.com

Service-Modelle: IaaS / PaaS / SaaS

Prüfungsrelevant

SaaS – Software as a Service PaaS – Platform as a Service IaaS – Infrastructure as a Service

IaaS: Der Anbieter liefert Infrastruktur (VM, Speicher, Netzwerk). Der Kunde verwaltet OS, Middleware, Runtime und Applikation.

PaaS: Der Anbieter liefert zusätzlich Plattform/Runtime. Der Kunde fokussiert auf Code und Daten.

SaaS: Der Anbieter liefert die komplette Anwendung. Der Kunde nutzt und konfiguriert sie nur fachlich.

Je nach Modell verantwortet der Cloud-Anbieter mehr oder weniger Schichten des Systems. Die Abgrenzung erfolgt nach dem sogenannten Schichtenmodell:

Ebene	Bezeichnung	Cloud-Modell	Verantwortung
User Interface	Darstellung	SaaS	Anbieter liefert fertiges UI
Interaktion	API (Extern)	SaaS	Externe Schnittstelle inklusive
Logik	Anwendung	SaaS	Anbieter stellt Plattform bereit
Information	Daten, Metadaten	SaaS	Daten-Management oft inklusive
Konnektivität	Integration	PaaS	Middleware & Schnittstellen
Steuerung	API (Intern)	IaaS	Steuerung der Ressourcen
Logik-Hardware	Virtualisierung	IaaS	Hypervisor, Container-Runtime
Physis	Hardware	IaaS	Immer beim Anbieter
Location	Rechenzentrum	IaaS	Immer beim Anbieter

⚠ Faustregel: Je weiter oben im Schichtenmodell, desto mehr übernimmt der Anbieter → SaaS = maximale Abstraktion. Je weiter unten, desto mehr Kontrolle hat der Nutzer → IaaS = maximale Eigenverantwortung.

Zuständigkeiten: On-Prem / IaaS / PaaS / SaaS

Prüfungsrelevant

Säule	On-Prem	IaaS	PaaS	SaaS
Applikation	Kunde	Kunde	Kunde	Anbieter
Sicherheit	Kunde	Gemeinsam	Gemeinsam	Gemeinsam
Datenbank	Kunde	Kunde	Gemeinsam	Anbieter
OS	Kunde	Kunde	Anbieter	Anbieter
Virtualisierung	Kunde	Anbieter	Anbieter	Anbieter
Server	Kunde	Anbieter	Anbieter	Anbieter
Speicher	Kunde	Anbieter	Anbieter	Anbieter
Netzwerk	Kunde	Anbieter	Anbieter	Anbieter
Rechenzentrum	Kunde	Anbieter	Anbieter	Anbieter

⚠ Merksatz: Von On-Prem zu SaaS wandert die technische Verantwortung schrittweise vom Kunden zum Anbieter.

Deployment-Modelle

Public Cloud

Öffentliche Cloud

Von beliebigen Personen nutzbar. Infrastruktur gehört dem Anbieter. Keine internen/exklusiven Anwendungen – alles öffentlich zugänglich.

Private Cloud

Anbieter und Nutzer sind im selben Unternehmen. Vollständige Kontrolle über Daten und Infrastruktur. Keine geteilten Ressourcen mit Dritten.

Hybrid Cloud

Mehrere eigenständige Cloud-Infrastrukturen mit einheitlichen Schnittstellen. Bsp: Private Cloud ↔ Azure. Erfordert klare Strategie: was wird wo gespeichert.

Virtual Private Cloud

Virtuelle Private Cloud

Private Cloud auf fremder Hardware. Logisch isoliert, physisch geteilt. Kombination aus Kontrolle und externer Infrastruktur.

Skycloud

Cloud aus mehreren Cloud-Anbietern nach verschiedenen Kriterien. Maximale Redundanz und Anbieterunabhängigkeit. Siehe eigener Abschnitt.

Typische Hybrid-Cloud-Anwendungen:

1) Sensible Daten in Private Cloud, skalierbares Frontend in Public Cloud.

2) Backup/Disaster-Recovery in Public Cloud bei On-Prem-Primärsystem.

3) Lastspitzen per Cloud Bursting in Public Cloud abfangen.

Unterschied: On-Premise vs Virtual Private Cloud

Kriterium	On-Premise	Virtual Private Cloud (VPC)
Hardware-Standort	Eigene Räume/Rechenzentrum	Beim Cloud-Anbieter
Isolation	Physisch exklusiv	Logisch isoliert (virtuelles Netzwerk)
Skalierung	Langsam (Beschaffung)	Schnell (on demand)
Betriebsaufwand	Hoch (Strom, Kühlung, Hardware)	Geringer, Fokus auf Konfiguration
Kostenmodell	CAPEX-lastig	OPEX / Pay-per-use

Skycloud

Cloud of Clouds

Skycloud bezeichnet die gleichzeitige Verwendung mehrerer Cloud-Anbieter über ein gemeinsames Automatisierungssystem – typischerweise ein Ansible-Skript.

Ziel ist es, Daten und Dienste in mehreren Clouds parallel verfügbar zu halten. Fällt ein Anbieter aus, übernehmen die anderen automatisch (Failover). Die Auswahl der Cloud-Anbieter kann nach verschiedenen Kriterien erfolgen: Kosten, Latenz, Datenschutz, geografische Region.

Skycloud ist damit die konsequenteste Umsetzung von Anbieterunabhängigkeit und Ausfallsicherheit im Cloud-Bereich.

Vergleich	Skycloud-Lösung	Mehrere CSP ohne Skycloud-Ansatz
Steuerung	Zentral orchestriert	Getrennte Einzellösungen
Failover	Geplant und automatisiert	Oft manuell
Portabilität	Hohe Anbieterunabhängigkeit	Häufig lock-in pro Teilsystem
Betrieb	Einheitliche Betriebslogik	Uneinheitliche Betriebsprozesse

USPs einer Skycloud-Lösung: 1) Provider-Unabhängigkeit, 2) höhere Ausfallsicherheit, 3) bessere Verhandlungsmacht bei Preisen, 4) regulatorische Flexibilität (Daten je Region/CSP).

Vor- und Nachteile der Cloud

✓ Vorteile	✗ Nachteile
Skalierbarkeit – Ressourcen bei Bedarf hoch- und runterskalieren	Datenhoheit – Daten liegen beim Anbieter, rechtliche Risiken
Automatisierbarkeit – Infrastruktur als Code, automatische Skalierung	Latenz – Netzwerkabhängigkeit kann zu Verzögerungen führen
Verfügbarkeit – SLAs mit 99,9%+ Uptime durch redundante Rechenzentren	Energieverbrauch – große Rechenzentren verbrauchen enorme Mengen Strom
Hardware-Wartung entfällt – keine eigene Server-Hardware nötig	Vendor Lock-in – Abhängigkeit vom Anbieter und dessen Preispolitik
Reduzierte Hardware-Kosten – CAPEX wird zu OPEX	Kosten – bei dauerhafter Nutzung langfristig teurer als on-premise
Geringerer Energieverbrauch – effizientere Auslastung durch Shared Resources

⚠ Energieverbrauch erscheint auf beiden Seiten: Cloud-Rechenzentren sind effizienter pro Workload (Vorteil), verbrauchen aber in absoluten Zahlen enorme Mengen Strom (Nachteil).

Praxispartner: Prozess mit Cloud-Verbesserung

Beispielprozess: Dokumentenfreigabe zwischen Innendienst und Außendienst.

Problem ohne Cloud: Dateien liegen lokal, Versionen sind verteilt, Außendienst hat keinen Echtzeitzugriff.

Verbesserung durch Cloud: Zentrales Objekt-Storage + rollenbasierter Zugriff + Versionierung + Webzugriff. Ergebnis: schnellere Freigaben, weniger Medienbrüche, nachvollziehbare Änderungen.

REST-Schnittstellen

API

REST (Representational State Transfer) ist ein Architekturstil für Web-basierte Schnittstellen. Zwei Applikationen tauschen Informationen über standardisierte HTTP-Methoden aus:

GET – Daten lesen POST – Daten erstellen PUT – Daten ersetzen PATCH – Daten aktualisieren DELETE – Daten löschen

Eine REST-konforme Schnittstelle muss 5 Bedingungen erfüllen:

1.

URI – jede Ressource hat eine eindeutige, stabile Adresse

2.

Client-Server-Architektur – klare Trennung zwischen Frontend und Backend

3.

Zustandslosigkeit (Stateless) – jeder Request enthält alle nötigen Informationen, kein Session-State auf dem Server

4.

Schichten-Modell – Client weiß nicht, ob er direkt mit dem Server spricht oder mit einem Proxy/Load-Balancer

5.

Cacheability – Responses können gecacht werden, außer der Client erlaubt es explizit nicht

URLs & curl – Grundlagen

Aufbau einer URL:

https://api.training-example.net/help https://api.training-example.net/time?city=example-town&format=json

Protokoll

Hostname/Domain

Pfad

Query-Parameter (mit & trennen)

Die wichtigsten curl-Befehle:

bash – curl Grundbefehle
# GET-Request
curl -X GET https://...

# GET mit Query-Parametern (WICHTIG: -G verwenden!)
curl -G "https://..." \
  --data-urlencode "name=Wert" \
  --data-urlencode "email=..."

# POST mit JSON-Body
curl -X POST -H "Content-Type: application/json" \
  -d '{"key":"value"}' https://...

⚠ -G ist entscheidend! Ohne -G landen die Daten im Request-Body (→ wird als POST interpretiert). Mit -G werden sie als Query-Parameter an die URL angehängt (→ GET).

Beispiel: Registrierung an einer Trainings-API (anonymisiert)

bash – API Registrierung
curl -G "https://api.training-example.net/register" \
  --data-urlencode "name=Teilnehmer Beispiel" \
  --data-urlencode "email=student@example.edu" \
  --data-urlencode "login=user123" \
  --data-urlencode "course_id=COURSE_TOKEN"

ℹ --data-urlencode kodiert automatisch Sonderzeichen und Leerzeichen im Wert (z.B. Philipp Walz → Philipp%20Walz). Immer verwenden wenn der Wert Leerzeichen oder Sonderzeichen enthalten kann.

AWS Preiskalkulator

Der AWS Pricing Calculator erlaubt die Schätzung von Kosten für AWS-Dienste, bevor man sie einsetzt. Dienste können einzeln hinzugefügt und konfiguriert werden.

🔗 calculator.aws – Übersicht ➕ Dienst hinzufügen