Cloud

Was „die Cloud“ physisch ist

Hinter jeder Cloud stehen Rechenzentren mit zehntausenden Servern, eigener Stromversorgung und Kühlung. Die großen Anbieter gliedern sie in zwei Ebenen:

Auf den Servern läuft Virtualisierung: Deine „Maschine“ ist eine virtuelle, die sich die Hardware mit anderen Kunden teilt. Alles wird über eine API gesteuert – eine neue Maschine ist ein HTTP-Aufruf, kein Bestellformular.

IaaS, PaaS, Serverless, SaaS

Die Modelle unterscheiden sich darin, ab welcher Schicht der Anbieter übernimmt. Wähle eines:

Wichtig ist das Prinzip der geteilten Verantwortung: Der Anbieter sichert, was er betreibt – Gebäude, Hardware, je nach Modell auch Betriebssystem und Laufzeit. Was du konfigurierst, bleibt deine Aufgabe: Zugriffsrechte, offene Ports, öffentlich lesbare Speicher, Patches deiner eigenen Software. Ein großer Teil der Sicherheitsvorfälle in der Cloud geht auf solche Fehlkonfigurationen zurück, nicht auf Lücken beim Anbieter.

Elastizität: zahlen, was man braucht

Ein eigenes Rechenzentrum muss für die höchste Last gebaut werden – und steht den Rest der Zeit halb leer. In der Cloud kann die Kapazität der Last folgen. Ein Onlineshop über einen Tag, mit Abendspitze:

Daran sieht man die Abwägung: Feste Kapazität für die Spitze ist sicher, aber teuer. Autoscaling spart, reagiert aber mit Verzögerung – bei steilen Anstiegen fehlt kurz Kapazität, weshalb man Reserven einplant oder vorausschauend skaliert. Serverless folgt der Last fast perfekt und kostet im Leerlauf nichts, ist pro Recheneinheit aber teurer: ideal für unregelmäßige Last, teuer für Dauerlast.

Auch die Cloud ist nicht automatisch günstiger. Bei gleichmäßiger, gut planbarer Last kann eigene oder langfristig gemietete Hardware billiger sein. Deshalb gibt es Rabattmodelle für feste Zusagen – und eine eigene Disziplin, die sich nur um Cloudkosten kümmert (FinOps).

Ausfälle einplanen

In der Cloud fallen Server ständig aus – bei zehntausenden Maschinen ist das Alltag. Hochverfügbarkeit entsteht durch die Verteilung: mehrere Instanzen, über mehrere Zonen, im Extremfall über mehrere Regionen. Probier aus, was welcher Ausfall anrichtet:

Jede Stufe kostet: Mehrere Zonen bedeuten Datenreplikation und etwas Latenz zwischen den Zonen, mehrere Regionen bedeuten die Probleme verteilter Systeme im großen Maßstab – Daten über hunderte Kilometer konsistent zu halten, ist schwer und teuer. Für die meisten Anwendungen sind mehrere Zonen in einer Region der übliche Kompromiss.

Für Entwickler übersetzt

Damit eine Anwendung gut in der Cloud läuft, sollte sie sich an ein paar Regeln halten, die als Twelve-Factor App bekannt geworden sind: Konfiguration aus der Umgebung statt aus Dateien im Archiv, keine Daten auf der lokalen Platte, schnell starten, sauber beenden, Logs auf die Standardausgabe.

# application.yml – Werte kommen aus Umgebungsvariablen der Plattform
spring:
  datasource:
    url: ${DB_URL}
    password: ${DB_PASSWORD}       # besser: aus einem Secret-Manager
management:
  endpoint.health.probes.enabled: true   # /actuator/health/liveness und /readiness

// Serverless: eine Funktion statt eines Servers (AWS Lambda)
public class BildVerkleinern implements RequestHandler<S3Event, String> {
    @Override
    public String handleRequest(S3Event ereignis, Context ctx) {
        // läuft nur, wenn ein Bild hochgeladen wird – und kostet nur dann
        return verkleinere(ereignis);
    }
}

Ein Java-spezifisches Thema ist der Kaltstart: Wird eine Serverless-Funktion nach einer Pause aufgerufen, muss zuerst eine JVM starten, Klassen laden und das Framework hochfahren – das kann bei Spring-Anwendungen Sekunden dauern. Dafür gibt es Gegenmittel:

Infrastruktur selbst wird heute meist als Code beschrieben (Infrastructure as Code), etwa mit Terraform oder den Werkzeugen der Anbieter: Netze, Datenbanken und Rechte stehen versioniert im Repository und werden von der Pipeline ausgerollt.

Häufige Irrtümer

Verwandte Begriffe