Eine Kanzlei mit zu viel Post öffnet keine größeren Briefkästen, sondern stellt einfach zwei Schalter nebeneinander. Genau so antwortet die Cloud auf wachsende Last.

Das Bild ausgemalt: Am einen Schalter staut sich die Schlange, also baut man den Schalter zu einem größeren Schalter um, an dem mehr Menschen gleichzeitig bedient werden. Der Umbau braucht Zeit, und währenddessen ist der Schalter zu. Schöner ist es, einen zweiten, gleichen Schalter zu öffnen, der sofort arbeiten kann. Und fällt ein Schalter aus, bleibt der andere besetzt.

Fachlich ist das vertikales Skalieren: Die bestehende Instanz, also eine virtuelle Maschine wie EC2, wird durch eine leistungsstärkere ersetzt. Horizontales Skalieren heißt stattdessen, zusätzliche Instanzen derselben Art daneben zu schalten und die Anfragen auf sie zu verteilen. Der Schalterausfall ist ein Single Point of Failure, eine Komponente, deren Ausfall alles stoppt.

In der Praxis: Mehr gleichzeitige Anfragen sprechen für horizontal, denn Lastverteilung wächst nach Bedarf, und die Abrechnung folgt der Nutzung. Größere einzelne Anfragen, etwa eine Datenbank mit hohem Speicherbedarf, sprechen für vertikal. Kubernetes hält dabei die gewünschte Anzahl laufender Container-Instanzen automatisch ein.

Das Bild hat eine Grenze: Ein Schalterteam braucht nur Menschen, Instanzen brauchen einen Lastverteiler, der die Anfragen auf die Instanzen verteilt, und geteilte Zustände wie Datenbanken. Und vertikal stößt man an die größte angebotene Instanzgröße, während horizontales Ergänzen nahezu unbegrenzt bleibt.

Horizontales Skalieren heißt nicht teurer, sondern redundanter: Mehr Instanzen schützen vor Ausfall, eine große Instanz bleibt ein einziger Schwachpunkt.

📌 Horizontale Skalierung · Vertikale Skalierung · Redundanz

📚 Cloud von Grund auf · Tag 6 von 30
#aws #devops #CloudHosting

Der erste Docker-Build dauert Minuten, der zweite nur Sekunden – solange niemand die Anweisungsreihenfolge ändert. Dabei entscheidet oft allein die Reihenfolge im Dockerfile, ob der Cache greift oder nicht.

Das kennt jeder, der einmal ein Dockerfile (das Baurezept für ein Container-Image) geschrieben hat. Wer die Reihenfolge nicht versteht, wartet bei jeder kleinen Änderung wieder so lange wie beim ersten Mal.

Der Build-Cache ist ein Speicher für fertige Schichten. Ein Docker-Image besteht aus Schichten: Jede Anweisung wie FROM, RUN oder COPY erzeugt genau eine, die auf der vorherigen aufbaut. Beim Neubau prüft Docker jede Anweisung von oben nach unten und übernimmt unveränderte Schichten unverändert. Sobald sich eine Anweisung ändert, sind alle folgenden Schichten ungültig und werden neu gebaut – auch wenn sie selbst gleich geblieben sind.

Ein typisches Dockerfile für eine Node-Anwendung kopiert zuerst nur package.json, führt npm install aus und kopiert danach erst den Quellcode. Der Cache-Schlüssel einer Anweisung umfasst den Anweisungstext und den Inhalt kopierter Dateien: Ein geändertes package.json macht die Installations-Schicht ungültig, ein geänderter Quelltext nur die Kopier-Schicht. Eine reine Codeänderung baut also nur die letzte Schicht neu.

Verwechselt wird der Cache gern mit einem bloßen Zeitmesser. Er prüft keine Ähnlichkeit, sondern exakte Schlüssel. Steht COPY ganz oben, macht jede kleine Codeänderung die teure Installations-Schicht ungültig – und der Build dauert jedes Mal wie beim ersten Mal. Deshalb gilt: selten Geändertes wie das Basis-Image (das Image, auf dem das eigene aufbaut, etwa in der FROM-Anweisung) an den Anfang, häufig Geändertes wie den Quellcode an das Ende.

Der Build-Cache belohnt keine schönen Dockerfiles, sondern stabile Anweisungsreihen.

📌 Schichten · Cache-Schlüssel · Reihenfolge

📚 Cloud von Grund auf · Tag 5 von 30
#docker #devops #CloudHosting

Zehn Sekunden Codeänderung, dann wartet man fünf Minuten auf denselben Build. Schuld ist meist eine einzige Zeile an der falschen Stelle im Dockerfile.

Gemeint ist der Aufbau eines Container-Images aus einer Beschreibungsdatei, dem Dockerfile. Das Image ist die unveränderliche Vorlage, aus der Container gestartet werden. Jede Anweisung darin – etwa COPY zum Kopieren von Dateien oder RUN zum Ausführen eines Befehls – erzeugt eine eigene Schicht, und der Build-Cache entscheidet, welche davon neu berechnet werden muss.

Zuerst liest das Build-Werkzeug das Dockerfile von oben nach unten und prüft jede Anweisung gegen den Cache. Sind Anweisungstext und Inhalt kopierter Dateien unverändert, wird die vorhandene Schicht wiederverwendet. Das Ergebnis ist sofort da, ohne Rechenarbeit.

Dann stößt das Werkzeug auf die erste geänderte Anweisung, etwa ein neues COPY mit anderem Quellcode. Diese Schicht wird neu gebaut. Der Cache-Schlüssel umfasst dabei beide Teile: Anweisungstext und Dateiinhalte.

Danach sind alle folgenden Schichten ungültig, auch wenn sie selbst gleich geblieben sind. Steht die teure Installation der Abhängigkeiten unterhalb des Quellcode-Kopierens, muss sie bei jeder Codeänderung erneut laufen – der Build dauert dann wieder so lange wie beim ersten Mal.

Zuletzt dreht man die Reihenfolge um: erst die Abhängigkeitsliste wie package.json kopieren und installieren, danach erst den Quellcode. Eine reine Codeänderung baut dann nur noch die letzte Schicht neu, aus Minuten werden Sekunden. Eine .dockerignore-Datei hält zudem unnötige Dateien aus dem Build-Kontext fern.

Der Cache ist kein Automatik-Glück, sondern folgt der Reihenfolge der Anweisungen. Seltenes nach oben, Häufiges nach unten: Diese eine Sortierung entscheidet über die Dauer jedes Neubaus.

📌 Schichten · Cache-Schlüssel · Reihenfolge

📚 Cloud von Grund auf · Tag 5 von 30
#docker #devops #CloudHosting

Viele Einsteiger warten bei jeder kleinen Codeänderung erneut auf die komplette Paketinstallation. Dabei reicht eine andere Reihenfolge der Befehle, damit fast alles aus dem Cache kommt.

Nach dem Ändern einer einzigen Quellcodezeile läuft der komplette Build von vorn. Pakete werden wieder heruntergeladen, obwohl sie schon im vorherigen Build steckten.

Ein Dockerfile ist eine Schritt-für-Schritt-Anleitung, wie ein Image gebaut wird. Jeder Befehl erzeugt eine Schicht, also einen festen Layer im Image. Docker nutzt einen Build-Cache: Eine Schicht wird nur neu gebaut, wenn sich ihr Befehl oder die hineinkopierten Dateien geändert haben. Der Cache wird von oben nach unten geprüft – ab der ersten veränderten Schicht muss alles Folgende neu gebaut werden, auch wenn die Befehle gleich bleiben.

Ein typisches Dockerfile beginnt mit COPY des kompletten Quellcodes und installiert danach erst die Pakete mit RUN apt-get install. Jede noch so kleine Codeänderung trifft die erste Schicht und invalidiert alle folgenden. Die Paketinstallation läuft bei jedem Build erneut. Dreht man die Reihenfolge um – erst Pakete installieren, dann den Code kopieren – bleibt die teure Installation im Cache, wenn nur eine Codezeile geändert wird.

So prüft man es: Beim zweiten Build ohne Änderungen sollte Docker jeden Schritt aus dem Cache beantworten. Nach einer Codezeilen-Änderung dürfen nur die Schichten ab dem COPY neu laufen.

Erst das Seltene, dann das Häufige gehört ins Dockerfile. Häufig Geändertes gehört ans Ende des Dockerfiles, nicht an den Anfang.

📌 Build-Cache · Schichten · Befehlsreihenfolge

📚 Cloud von Grund auf · Tag 5 von 30
#docker #devops #CloudHosting

Ein Container läuft nicht einfach irgendwie – er bekommt Ressourcen zugesichert und begrenzt. Wer beides verwechselt, wundert sich später über abrupte Neustarts.

In Kubernetes wird beim Start jedes Containers festgelegt, wie viel CPU und Speicher ihm garantiert und wie viel er höchstens verbrauchen darf. Das betrifft jede Web-Anwendung, jeden Job, jeden Dienst im Cluster – einem Cluster, einer Gruppe von Rechnern, die Container gemeinsam betreiben.

Zuerst definiert man die Requests: die Mengen an CPU und Speicher, die der Scheduler, die Komponente, die Container auf Knoten verteilt, fest einplant und garantiert. CPU misst man in Millicores: 1000m sind ein voller Kern, 500m die Hälfte. Speicher steht in Bytes, etwa mit dem Suffix Mi für Mebibyte.

Dann prüft der Scheduler anhand der Requests, ob ein Knoten noch Platz hat. Er kennt die Limits bei der Platzierung nicht. Fehlen Requests, bucht er Knoten über, weil er den Bedarf nicht kennt – Engpässe treten dann erst zur Laufzeit auf.

Danach läuft der Container und darf über seinen Request hinaus wachsen, solange Ressourcen frei sind. Ein Beispiel: Request 100m CPU und 128Mi Speicher, Limit 500m und 256Mi. Kurzzeitig darf er also auf das Fünffache der zugesicherten CPU wachsen.

Zuletzt greifen die Limits zur Laufzeit. Überschreitet der Container sein Speicher-Limit, beendet ihn der Kernel sofort per OOM-Kill und Kubernetes startet ihn neu. Am CPU-Limit wird er nicht beendet, sondern gedrosselt: Er läuft langsamer, arbeitet aber weiter. Pods ganz ohne Werte erhalten die Klasse BestEffort und werden bei Speicherknappheit zuerst verdrängt.

Requests sind das Versprechen an den Scheduler, Limits die Grenze im Betrieb. Wer Limits als Requests deutet, plant Knoten falsch voll; wer beides weglässt, überlässt die Verteilung dem Zufall.

📌 Request · Limit · OOM-Kill

📚 Cloud von Grund auf · Tag 4 von 30
#kubernetes #devops #CloudHosting

Pods und Services klingen ähnlich, gehören aber zu verschiedenen Welten. Der eine ist ein Arbeiter, der kommt und geht – der andere ist das Schild am Gebäude.

Verwechselt werden beide, weil sie im Alltag zusammen auftreten. Immer wenn eine Anwendung Pods startet, steht ein Service davor.

Ein Pod ist die kleinste Einheit in Kubernetes und enthält einen oder mehrere Container, die sich Netzwerk und Speicher teilen. Ein Deployment hält eine gewünschte Anzahl gleicher Pods am Laufen. Pods sind bewusst kurzlebig: Bei jedem Update, bei Knotenausfall oder Neustart ersetzt Kubernetes alte Pods durch neue – und jeder neue Pod erhält eine neue Cluster-IP. Ein Webshop-Deployment verwaltet etwa drei Pods, von denen jeder Neustart mit einer frischen IP startet.

Ein Service ist dagegen eine feste Adresse für diese wechselnde Gruppe. Er besitzt eine eigene IP-Adresse und einen DNS-Namen (DNS übersetzt Namen in IP-Adressen) innerhalb des Clusters, die sich nicht ändern, solange der Service existiert. Der Service wählt seine Pods über ein Label-Selektor-Kriterium aus: Alle Pods mit einem bestimmten Label gehören zur Gruppe. Der Service „frontend“ verteilt alle Aufrufe von „frontend“ immer auf einen der gerade laufenden Pods – egal, wer gerade neu gestartet wurde.

Der Pod liefert die Arbeit, der Service liefert die Erreichbarkeit. Pod-IPs bleiben hinter dem Service verborgen; fällt ein Pod aus, wandern seine Anfragen automatisch zu den verbleibenden.

Faustregel: Pods nie direkt adressieren, sondern immer über den Service – eine Pod-IP in einer Konfiguration ist nach dem nächsten Neustart unbrauchbar.

Der Service heißt nicht Lastverteiler für Container, sondern feste Anlaufstelle vor kurzlebigen Pods.

📌 Pod · Service · Label-Selektor

📚 Cloud von Grund auf · Tag 4 von 30
#kubernetes #CloudHosting #devops

Die meisten Docker-Neulinge wundern sich, warum jeder Build Minuten dauert. Dabei entscheidet oft weniger die Größe des Projekts über die Bauzeit, sondern die Reihenfolge der Zeilen im Dockerfile.

Ein Dockerfile ist eine Textdatei mit Anweisungen wie FROM, COPY und RUN, aus denen docker build ein Image erzeugt – eine portable, gepackte Umgebung für eine Anwendung. Wer die Schichten versteht, baut deutlich schneller.

📦 Jede Dockerfile-Anweisung erzeugt ihre eigene Schicht.
Eine Schicht (Layer) ist das Dateisystem-Änderungsprotokoll genau einer Anweisung; das fertige Image entsteht als Stapel dieser Schichten übereinander. Die Anweisungen werden von oben nach unten abgearbeitet. Beispiel: erst FROM, dann COPY der Paketliste, dann RUN zur Installation der Abhängigkeiten, erst danach COPY des Quellcodes.

🔑 Der Build-Cache prüft jede Anweisung von oben nach unten.
Der Build-Cache ist ein Zwischenspeicher früherer Schichten; Docker vergleicht Anweisung und Eingaben mit der gecachten Version. Ist eine Schicht unverändert, wird sie samt aller darunterliegenden wiederverwendet. Ab der ersten geänderten Anweisung wird alles Folgende neu gebaut.

📈 Häufig Geändertes gehört ans Ende des Dockerfiles.
Klassischer Einsteigerirrtum: Quellcode früh per COPY übernehmen. Dann läuft bei jeder Codeänderung auch die teure Abhängigkeitsinstallation erneut, obwohl sich nichts daran geändert hat. Steht die COPY-Zeile für den Code dagegen ganz unten, bleibt der Cache für die Installation intakt.

Die Reihenfolge heißt nicht Geschmackssache, sondern Cache-Strategie: selten Geändertes zuerst, häufig Geändertes zuletzt – Basis-Image und Abhängigkeiten vor dem eigenen Quellcode.

📌 Schichten · Build-Cache · Anweisungsreihenfolge

📚 Cloud von Grund auf · Tag 4 von 30
#docker #devops #CloudHosting

Viele Dockerfiles beginnen damit, das gesamte Projekt per COPY zu kopieren. Dabei zerstört jede Quellcode-Änderung den gesamten Build-Cache.

Wer ein Dockerfile schreibt, begegnet sofort dem Build-Cache. Wer ihn nicht kennt, wartet bei jedem Neubau Minuten statt Sekunden.

Ein Dockerfile ist eine Liste von Anweisungen, die mit docker build zu einem Image (einer startfertigen Vorlage für Container) verarbeitet wird. Jede Anweisung erzeugt eine Schicht, also das Änderungsprotokoll dieser einen Zeile im Dateisystem. Das Image ist ein Stapel dieser Schichten; docker run startet daraus den Container.

Der Cache prüft beim Neubau jede Anweisung von oben nach unten. Ist eine Zeile unverändert, wird ihre Schicht samt aller darunterliegenden wiederverwendet. Ab der ersten geänderten Zeile wird alles Folgende neu gebaut, auch wenn es sich gar nicht verändert hat.

Konkret: Zuerst FROM, also die Wahl des Basis-Images als Startpunkt, dann COPY der Paketliste, dann RUN zur Installation der Abhängigkeiten, erst danach COPY des Quellcodes und der Startbefehl. Ändert sich nur der Quellcode, bleibt die teure Installation im Cache. Steht die Quellcode-Zeile dagegen oben, läuft RUN bei jeder kleinen Änderung erneut.

Verwechselt wird der Cache gern mit dem Build-Kontext, also dem Verzeichnis, das dem Build als Quelle dient. Der Kontext bestimmt, welche Dateien überhaupt an COPY übergeben werden; der Cache bestimmt, welche Schichten wiederverwendet werden. Eine .dockerignore-Datei hält Unnötiges wie .git aus dem Kontext fern und beschleunigt den Build zusätzlich.

Der Build-Cache belohnt nicht die schönste Zeile, sondern die stabilste Reihenfolge: Selten Geändertes nach oben, Häufig Geändertes nach unten.

📌 Layer · Build-Cache · Reihenfolge im Dockerfile

📚 Cloud von Grund auf · Tag 4 von 30
#docker #devops #CloudHosting

Ein Container ist ein Mieter im Mehrfamilienhaus: Das Fundament gehört allen, die Einrichtung ist privat. Eine virtuelle Maschine baut dagegen ein eigenes Haus mit eigenem Keller. Genauer: mit einem kompletten Betriebssystem.

Alle Mieter teilen sich dasselbe Gebäude, dieselbe Heizung und Wasserleitung. Jede Wohnung ist trotzdem abgeschlossen; der Nachbar sieht nichts hinein. Zieht ein Mieter aus, hinterlässt er nur seine Möbel, kein ganzes Haus.

Das gemeinsame Gebäude ist der Kernel, also der Kern des Betriebssystems, der Prozesse, Speicher und Hardwarezugriff verwaltet. Die abgeschlossene Wohnung ist der Prozessraum: Jeder Container sieht nur eigene Prozesse, eigenes Dateisystem und eigenes Netzwerk. Die privaten Möbel sind das Container-Image, die unveränderliche Vorlage mit Anwendung, Laufzeitbibliotheken und Konfigurationsdateien.

Ein Dockerfile beschreibt Schritt für Schritt, wie ein Image gebaut wird. Solch ein Image ist meist nur wenige Megabytes bis wenige hundert Megabytes groß, während ein VM-Abbild mit vollem Betriebssystem mehrere Gigabyte umfasst. Deshalb startet ein Container in Sekunden, während eine virtuelle Maschine erst ihr eigenes Betriebssystem bootet – bei AWS heißt dieser Dienst EC2.

Das Bild hat eine Grenze: Ein Mieter kann fast beliebig wirtschaften, ein Container braucht den passenden Kernel. Container setzen auf Linux auf und teilen sich dessen Kernel-Funktionen. Ein Linux-Container läuft deshalb nicht direkt auf einem Windows-Host ohne Linux-Kernel.

Container sind also keine „leichteren VMs“: Eine VM kapselt Hardware, ein Container kapselt nur die Anwendung.

📌 Kernel · Container-Image · Prozessraum

📚 Cloud von Grund auf · Tag 3 von 30
#docker #CloudHosting #Linux

Ein Server fällt aus, und die Anwendung läuft einfach weiter. Viele Einsteiger halten das für Zufall oder Glück – dahinter steckt ein Baustein, der ständig mitprüft.

Viele denken, ein Load Balancer verteile Anfragen einfach stur reihum auf mehrere Server. Das klingt plausibel, weil Verteilen ja der Name des Bausteins ist. Wenn aber ein Server kaputt ist, landen weiter Anfragen bei ihm – und die Nutzer sehen Fehler.

Tatsächlich verteilt ein Load Balancer nur an Server, die gesund sind. Gesundheitsprüfungen (Health Checks) sind regelmäßige automatische Anfragen, etwa alle paar Sekunden an einen Prüfpfad wie /health. Erst nach mehreren erfolgreichen Prüfungen gilt ein Server als gesund. Ein Server, dessen Prüfungen fehlschlagen, wird automatisch aus der Verteilung genommen.

Der Irrtum entsteht, weil das Verteilen sichtbar ist, das Prüfen nicht. Von außen sieht man nur einen einzigen Ansprechpunkt, der Anfragen weiterreicht.

Ein Beispiel: Drei Server hinter einem Load Balancer, Verteilung per Round Robin – die Anfragen wandern reihum, jeder Server erhält etwa gleich viele. Ein Server antwortet auf /health nicht mehr; nach mehreren Fehlversuchen fliegt er aus der Verteilung. Die Nutzer merken nichts, solange mindestens ein gesunder Server bleibt.

Woran man es erkennt: Der Load Balancer leitet Verkehr nur an gesunde Instanzen weiter. Health-Check-Pfad und Schwellen müssen dabei zum Dienst passen, sonst gelten kaputte Server zu spät als krank.

Ein Load Balancer heißt nicht „Anfragenverteiler nach festem Schema“, sondern „Verteiler mit Gesundheitsprüfung“. Er entscheidet bei jeder Anfrage neu, wer sie bekommen darf.

📌 Load Balancer · Health Checks · Round Robin

📚 Cloud von Grund auf · Tag 3 von 30
#CloudHosting #devops #sre

Die meisten Dateien landen in der Cloud auf einem von zwei ganz verschiedenen Wegen. Dabei entscheidet die Wahl des Wegs, wie schnell eine Anwendung läuft und wie teuer das Speichern wird.

Wer eine virtuelle Maschine startet, also einen nachgebildeten Rechner mit eigenem Betriebssystem wie Linux oder Windows, trifft die Entscheidung sofort: Das System braucht ein Laufwerk. Wer den Unterschied nicht kennt, mountet den Objektspeicher wie ein Netzlaufwerk und wundert sich, warum zeichenweises Bearbeiten nicht funktioniert.

Objektspeicher wie S3 legt Daten als Objekte mit Schlüssel und Metadaten in Buckets ab. Jede Datei wird als abgeschlossenes Ganzes unter einem eindeutigen Schlüssel gespeichert, etwa einem langen Dateinamen; einzelne Bytes lassen sich nicht ändern, sondern nur das ganze Objekt neu schreiben. Blockspeicher wie EBS zerlegt Daten in gleich große Blöcke und blendet sie der virtuellen Maschine als Festplatte ein, auf der das Betriebssystem ein Dateisystem anlegt und Dateien beliebig ändert.

Konkret: Eine EC2-Instanz, so heißt die virtuelle Maschine bei AWS, bootet von ihrem EBS-Laufwerk; dort liegen Betriebssystem und installierte Software, weil viele kleine Dateien schnelle Lese- und Schreibzugriffe brauchen. Ein Upload-Verzeichnis mit Bildern und Videos gehört dagegen in einen S3-Bucket, weil dort unbegrenzt viele Objekte dauerhaft ohne Laufwerksgröße abgelegt werden. Auch Backups und Protokolldateien gehören dorthin. Speicherkosten fallen dabei auch ohne laufende Anwendung an, solange die Daten existieren.

Verwechselt wird der Objektspeicher oft mit einem Netzlaufwerk oder einer Datenbank. Er ist für das Speichern und Abrufen ganzer Dateien gebaut, nicht für zeichenweises Bearbeiten.

📌 Objektspeicher · Blockspeicher · Zuordnung der Daten

📚 Cloud von Grund auf · Tag 2 von 30
#aws #CloudHosting #Backup

Viele halten eine virtuelle Maschine für ein Programm wie jedes andere. Dabei bootet sie wie ein eigener Rechner – mit eigenem Betriebssystem.

Viele stellen sich eine VM als Anwendung im Betriebssystem des Hosts vor, so wie ein Browser oder ein Spiel. Das klingt plausibel, weil sie doch irgendwo als Datei auf einem Server liegt.

Tatsächlich ist eine virtuelle Maschine ein abgeschlossener Rechner im Rechner. Sie startet von ihrem zugewiesenen virtuellen Laufwerk ein eigenes Betriebssystem, etwa Linux oder Windows, das die geteilte Hardware nicht sieht. Ein Hypervisor, also eine Software-Schicht, die die physische Hardware verwaltet, teilt CPU, Speicher und Netzwerk auf viele VMs auf. Dabei gibt er ihnen keine vorgetäuschte fremde Hardware wie eine Emulation, sondern leitet deren Befehle weitgehend direkt auf die echte CPU um, was deutlich schneller ist.

Der Irrtum entsteht, weil man von außen nur eine Konsole oder ein Fenster sieht. Wie ein Programm aussieht, ist es aber nicht: Innen läuft ein vollständiger Rechner mit eigenem Kernel, also dem Kern des Betriebssystems.

Auf einem einzigen physischen Server laufen so Dutzende VMs nebeneinander, jede mit eigenem Betriebssystem, das unabhängig bootet, gepatcht und neu gestartet wird. Genau das macht die Cloud möglich: Viele Kunden nutzen dieselben physischen Rechner und Netze, getrennt nur durch Virtualisierung. Bei AWS heißt der Dienst für VMs EC2 – startet man eine Instanz, bezahlt man deren Laufzeit nach Nutzung.

Woran man es erkennt: Eine VM hat ein eigenes Betriebssystem mit eigenem Kernel und eigenen Festplatten. Ein Container dagegen teilt sich den Kernel des Hosts und startet deshalb schneller und kleiner.

Eine VM heißt nicht Programm im gemeinsamen Betriebssystem, sondern eigenständiger Rechner auf geteilter Hardware.

📌 Hypervisor teilt Hardware · VM bootet eigenes OS · EC2 als VM-Dienst

📚 Cloud von Grund auf · Tag 2 von 30
#aws #CloudHosting

Die meisten denken bei Cloud-Kosten an die Monatsmiete für Server. Dabei zahlt man in der Cloud nur für das, was tatsächlich läuft.

Cloud-Provider rechnen Nutzung automatisch ab und weisen sie transparent aus – Kunden sehen also, wofür sie zahlen. Das betrifft jede Entscheidung: Wer eine Ressource startet, eine Datei speichert oder Daten verschickt, löst jeweils eine andere Kostenart aus.

Zuerst startet jemand eine Instanz – eine gemietete virtuelle Maschine im Rechenzentrum des Providers. Ab der ersten Minute zahlt sie, pro Zeiteinheit. Wer um drei Uhr nachts mit wenigen Klicks eine Maschine startet und sie nach einer Stunde wieder löscht, zahlt nur diese Stunde. Bei gemieteter Festhardware würde der Vertrag monatlich abgerechnet, ob sie läuft oder nicht.

Dann wachsen die Speicherkosten, sobald Daten abgelegt werden. Gespeicherte Datenmenge wird berechnet, und zwar auch dann, wenn keine Anwendung läuft. Alte Backups, vergessene Snapshots – gespeicherte Abbilder von Festplatten – und nicht gelöschte Testdaten stehen monatlich auf der Rechnung, solange sie existieren.

Danach kommt der Datenverkehr dazu: Eingehender Verkehr aus dem Internet ist bei AWS in der Regel kostenfrei. Ausgehender Verkehr ins Internet und zwischen Regionen wird dagegen berechnet. Auch Verkehr zwischen Availability Zones – getrennte Rechenzentren innerhalb derselben Region – kostet und sollte deshalb eingeplant werden.

Zuletzt entscheidet die Freigabe: Nicht mehr benötigte Ressourcen werden gelöscht und verursachen keine Kosten mehr. Wer vergisst abzubauen, zahlt unbemerkt weiter.

Gemessen wird also nicht der Bedarf, sondern die Laufzeit. Cloud-Kosten heißen nicht Miete, sondern Meter.

📌 Laufzeit · Speicher · Datenverkehr

📚 Cloud von Grund auf · Tag 2 von 30
#CloudHosting #devops #aws

Die meisten denken, die Cloud stehe „irgendwo im Internet“. Dabei läuft sie in echten Gebäuden mit Stromanschluss, Kühlung und Netzleitung.

Die Verwechslung liegt nahe, weil man Region und Availability Zone nie zu sehen bekommt. Beide klingen nach Geografie, meinen aber unterschiedliche Ebenen der Ausfallsicherheit.

Eine Region ist ein geografisches Gebiet, etwa ein Landesteil oder ein Ballungsraum, in dem ein Anbieter mehrere Rechenzentren betreibt. Sie ist die oberste Einheit, die man bei der Anmeldung wählt. Wer Ressourcen in Frankfurt anlegt, entscheidet damit über den physischen Standort: Daten bleiben im gewählten Land, und Nutzer in der Nähe profitieren von kurzer Latenz, also geringer Verzögerung bei der Datenübertragung.

Eine Availability Zone, kurz AZ, ist der Baustein innerhalb der Region: eines oder mehrere Rechenzentren mit eigener Stromversorgung und eigener Netzanbindung. Die Zonen einer Region sind so platziert, dass sie unabhängig versorgt sind, aber nah genug beieinander liegen, um schnell miteinander zu kommunizieren. Ein Beispiel: Ein Subnetz, also ein Adressbereich im Netz der Cloud, liegt immer in genau einer AZ.

Die Region beantwortet „Wo auf der Welt?“, die AZ beantwortet „Wie unabhängig ist mein Ausfallschutz?“. Eine Anwendung, die nur in einer AZ läuft, hat einen Single Point of Failure – fällt diese Zone aus, ist alles weg.

Faustregel: Region nach Vorgaben wählen (Compliance, Nähe der Nutzer), Ressourcen dann auf mindestens zwei Availability Zones verteilen.

Der Ausfallschutz liegt also nicht in der Region, sondern in der Zahl genutzter Zonen.

📌 Region · Availability Zone · Single Point of Failure

📚 Cloud von Grund auf · Tag 2 von 30
#aws #CloudHosting #devops

„Ein Server im Internet“ – für viele reicht das als Cloud. Genau dieser Irrtum führt zu Rechnungen für Maschinen, die niemand nutzt.

Wer eine Anwendung erstmals ins Internet stellt, mietet oft einen dedizierten Server, also einen fest zugewiesenen physischen Rechner. Der Vertrag läuft monatlich, ob die Maschine arbeitet oder leer läuft.

Hinter dem Symptom stehen die fünf Merkmale der Cloud, wie sie das US-Institut NIST in SP 800-145 definiert. Cloud Computing ist demnach bedarfsgerechter Netzzugriff auf einen gemeinsamen Pool konfigurierbarer Rechenressourcen, schnell bereitgestellt und wieder freigegeben. Fehlt eines der Merkmale, liegt Servermiete oder Hosting vor, keine echte Cloud.

Selbstbedienung heißt: Ressourcen über eine Weboberfläche oder Programmierschnittstelle (API) bestellen, ohne Vertrieb. Breiter Netzzugriff: erreichbar über Standardprotokolle wie HTTPS, nicht nur von einer festen Leitung. Pooling: viele Kunden teilen sich dieselben physischen Rechner und Speicher, getrennt nur durch Virtualisierung, also durch Software statt eigener Hardware. Elastizität: bei Lastanstieg starten zusätzliche Maschinen, bei Ruhe verschwinden sie. Gemessener Dienst: Nutzung wird automatisch erfasst und ausgewiesen.

Um drei Uhr nachts wird in der Konsole mit wenigen Klicks eine virtuelle Maschine gestartet und nach einer Stunde wieder gelöscht. Bezahlt wird genau diese eine Stunde Laufzeit. Der dedizierte Server wird stattdessen monatlich abgerechnet, ob er läuft oder nicht.

So prüft man es: Ein Angebot an den fünf Merkmalen messen und nachfragen, was bei einer nicht mehr gebrauchten Ressource passiert. Echt ist die Cloud erst, wenn Freigeben sofort und ohne Restkosten möglich ist.

Cloud ist nicht Server im Internet, sondern ein Pool, aus dem man sich bedient und zurückgibt.

📌 NIST SP 800-145 · fünf Merkmale · nutzungsbasierte Abrechnung

📚 Cloud von Grund auf · Tag 1 von 30
#CloudHosting #devops

Die meisten denken bei Cloud an einen gemieteten Server irgendwo im Internet. Dabei ist der Kern ein gemeinsamer Vorrat an Rechenleistung, aus dem viele Kunden gleichzeitig bedient werden.

Nur wer den Pool und die Selbstbedienung versteht, erkennt, warum Cloud kein Server-Mieten ist. Denn genau diese zwei Merkmale machen Bereitstellung in Minuten und nutzungsbasierte Abrechnung erst möglich.

📦 Cloud bedeutet, Ressourcen aus einem geteilten Vorrat anzufordern, nicht einen festen Rechner zu mieten. NIST SP 800-145 beschreibt das als bedarfsgerechten Netzzugriff auf einen Pool konfigurierbarer Rechenressourcen. Rechenleistung, Speicher und Netzwerk liegen also nicht als einzelne Geräte bereit, sondern als gemeinsamer Bestand. Die Trennung der Kunden geschieht durch Virtualisierung, also Software, die jedem Kunden einen abgegrenzten Anteil an der Hardware zuteilt.

🔑 Selbstbedienung heißt: Ressourcen per Weboberfläche oder Programmierschnittstelle (API, eine Schnittstelle, über die Software automatisch Befehle sendet) bestellen, ohne Vertrieb oder Menschen. Ein Skript oder ein Klick genügt, um einen virtuellen Rechner zu starten oder zu löschen. Deshalb dauert die Bereitstellung Minuten statt Tage, und es entsteht keine langfristige Bindung an feste Hardware.

📈 Abgerechnet wird nach Nutzung, etwa nach der Laufzeit einer Instanz, also eines gestarteten virtuellen Rechners, der gespeicherten Datenmenge oder den übertragenen Daten. Was nicht mehr gebraucht wird, wird freigegeben und kostet nichts mehr. Gemietete Festhardware wird dagegen abgerechnet, ob sie läuft oder nicht.

Cloud Computing heißt nicht „ein Server im Internet“, sondern Rechenleistung, Speicher und Netzwerk aus einem Pool per Schnittstelle anfordern und nach Nutzung zurückgeben.

📌 Ressourcen-Pool · Selbstbedienung · nutzungsbasierte Abrechnung

📚 Cloud von Grund auf · Tag 1 von 30
#CloudHosting #devops