Ein Nutzer in Berlin tippt eine URL in seinen Browser. Weniger als 200 Millisekunden später erscheint die Website auf seinem Bildschirm. In dieser kurzen Zeitspanne ist eine komplexe Kette von Ereignissen abgelaufen: DNS-Auflösung, TCP-Verbindungsaufbau, TLS-Handshake, HTTP-Request, Datenbankabfrage, Template-Rendering, Response-Übertragung. Dutzende Server und Netzwerkkomponenten haben zusammengewirkt, um diese eine Seite auszuliefern.
Teil 1 dieser Serie hat die Hosting-Landschaft kartografiert: Shared Hosting, VPS, Dedicated Server, Cloud. Dieser Teil erklärt, was unter der Haube passiert. Das Verständnis der technischen Grundlagen ist keine akademische Übung. Es hilft, die Grenzen verschiedener Hosting-Modelle zu verstehen, Performance-Probleme zu diagnostizieren und fundierte Architekturentscheidungen zu treffen.
Vom Request zum Response: Der Lebenszyklus einer Anfrage
Jede Interaktion mit einer gehosteten Anwendung beginnt mit einer Anfrage und endet mit einer Antwort. Der Weg dazwischen führt durch mehrere Schichten, und jede Schicht kann zum Flaschenhals werden.
DNS: Die Telefonbuch-Funktion des Internets
Der Browser kennt nur die Domain, etwa 'example.com'. Um die Verbindung herzustellen, braucht er eine IP-Adresse. Das Domain Name System (DNS) liefert diese Übersetzung. Eine Kette von DNS-Servern wird befragt, bis die IP-Adresse gefunden ist. Dieser Vorgang dauert typischerweise 20 bis 100 Millisekunden, kann aber bei schlecht konfigurierten Setups auch mehrere Sekunden in Anspruch nehmen.
DNS-Einträge werden für eine festgelegte Zeit (Time-to-Live, TTL) zwischengespeichert. Das beschleunigt Folgeanfragen, kann aber bei Server-Wechseln zu Problemen führen: Alte IP-Adressen kursieren noch Stunden oder Tage im Netz, obwohl der Server längst umgezogen ist. Cloud-Anbieter nutzen kurze TTLs (oft nur 60 Sekunden), um schnelle Umschaltungen zu ermöglichen, etwa für automatisches Failover. Bei geplanten Server-Migrationen empfiehlt es sich, die TTL mindestens 24 Stunden vorher auf 300 Sekunden oder weniger zu reduzieren und nach der Migration wieder auf 3600 Sekunden oder mehr zu erhöhen.
TCP und TLS: Der sichere Kanal
Mit der IP-Adresse kann der Browser eine TCP-Verbindung aufbauen. Der sogenannte Three-Way-Handshake (SYN, SYN-ACK, ACK) etabliert die Verbindung. Bei HTTPS folgt ein TLS-Handshake, der die Verschlüsselung aushandelt und Zertifikate austauscht. Diese Schritte kosten Zeit, besonders bei großer geographischer Distanz zwischen Client und Server.
Ein Nutzer in Berlin, der einen Server in Virginia anfragt, wartet allein durch die Lichtgeschwindigkeit im Glasfaserkabel 80 bis 100 Millisekunden pro Hin-und-Rück-Trip. Ein Server bei Hetzner in Falkenstein oder IONOS in Frankfurt antwortet dagegen in unter 20 Millisekunden. Für latenzempfindliche Anwendungen ist die Serverstandort-Wahl entscheidend.
Moderne Protokolle wie HTTP/2 und HTTP/3 optimieren diesen Prozess. HTTP/2 ermöglicht mehrere parallele Requests über eine einzige TCP-Verbindung. HTTP/3 (basierend auf QUIC) geht noch weiter und integriert den TLS-Handshake in den Verbindungsaufbau, was den initialen Latenz-Overhead deutlich reduziert. Die meisten Cloud-Anbieter unterstützen diese Protokolle mittlerweile standardmäßig.
Die Anwendungsschicht: Wo die eigentliche Arbeit passiert
Der HTTP-Request erreicht den Webserver (Apache, Nginx, IIS oder ähnliche). Von dort wird er an die Anwendung weitergeleitet: ein PHP-Skript, eine Node.js-Anwendung, ein Python-Framework. Die Anwendung interpretiert die Anfrage, fragt möglicherweise eine Datenbank ab, verarbeitet die Daten und generiert eine HTML-Antwort. Dieser Schritt ist oft der langsamste in der Kette und der, über den der Entwickler die meiste Kontrolle hat.
Die Antwort nimmt den umgekehrten Weg: zurück durch den Webserver, durch die verschlüsselte Verbindung, über das Internet zum Browser. Dort wird das HTML geparst, CSS angewendet, JavaScript ausgeführt. Bilder, Schriften und andere Ressourcen werden in separaten Requests nachgeladen. Moderne Websites lösen oft 50 bis 100 solcher Requests aus, bevor die Seite vollständig geladen ist.
Die Gesamtzeit vom Klick bis zur vollständig gerenderten Seite nennt sich Time to Interactive (TTI). Google verwendet diese Metrik als Ranking-Faktor. Eine TTI unter zwei Sekunden gilt als gut, über vier Sekunden als problematisch. Jede Phase des Request-Lifecycles bietet Optimierungspotenzial: schnellere DNS-Server, geografisch nähere Hosting-Standorte, effizientere Anwendungslogik.
Virtualisierung: Die Grundlage moderner Hosting-Architekturen
Virtualisierung ist die technische Basis, auf der fast alle modernen Hosting-Modelle aufbauen. Die Idee: Ein physischer Server wird in mehrere virtuelle Maschinen aufgeteilt, die jeweils wie eigenständige Computer funktionieren. Jede VM hat ihr eigenes Betriebssystem, ihre eigenen Prozesse, ihren eigenen Speicherbereich.
Der Hypervisor: Der unsichtbare Dirigent
Ein Hypervisor ist die Software-Schicht, die Virtualisierung ermöglicht. Er sitzt zwischen der physischen Hardware und den virtuellen Maschinen und verwaltet die Ressourcenverteilung. Es gibt zwei Typen: Typ-1-Hypervisoren (auch 'bare metal' genannt) laufen direkt auf der Hardware, ohne darunterliegendes Betriebssystem. VMware ESXi, Microsoft Hyper-V und der Linux-basierte KVM gehören zu dieser Kategorie. Typ-2-Hypervisoren laufen als Anwendung auf einem Betriebssystem, etwa VirtualBox oder VMware Workstation. Cloud-Anbieter und professionelle Hosting-Provider nutzen ausschließlich Typ-1-Hypervisoren.
AWS hat mit der Nitro-Architektur einen eigenen Weg eingeschlagen. Nitro verlagert Virtualisierungs-Aufgaben auf dedizierte Hardware-Karten, was die Performance verbessert und die Angriffsfläche reduziert. Die meiste Rechenleistung des physischen Servers steht tatsächlich dem Kunden zur Verfügung, nicht dem Hypervisor. Hetzner setzt auf KVM, IONOS nutzt eine eigene Virtualisierungsplattform.
Overcommitment: Mehr verkaufen, als vorhanden ist
Beim Shared Hosting und oft auch bei günstigen VPS-Angeboten praktizieren Anbieter Overcommitment: Sie verkaufen mehr Ressourcen, als physisch vorhanden sind. Das funktioniert, weil nie alle Kunden gleichzeitig ihre volle Kapazität nutzen. Ein Server mit 128 GB RAM kann durchaus VMs für insgesamt 200 GB verkaufen, solange die tatsächliche Nutzung im Rahmen bleibt.
Das Risiko: Wenn mehrere Kunden gleichzeitig Lastspitzen haben, reichen die Ressourcen nicht. Die VMs konkurrieren um CPU-Zeit und Speicher, die Performance bricht ein. Bei seriösen Anbietern ist Overcommitment moderat und durch Monitoring abgesichert. Bei Billiganbietern kann es zum echten Problem werden. Hetzner wirbt explizit mit 'dedicated resources' bei ihren Cloud-VMs, was Overcommitment ausschließt. Anzeichen für überlastete Shared-Umgebungen sind stark schwankende Response-Zeiten ohne eigene Lastspitzen, CPU-Steal-Time über 5 Prozent (sichtbar in htop oder vmstat) und regelmäßige Performance-Einbrüche zu bestimmten Uhrzeiten.
Container: Leichtgewichtige Virtualisierung
Container haben in den letzten Jahren die Art und Weise verändert, wie Anwendungen entwickelt und deployed werden. Docker, 2013 eingeführt, hat die Technologie massentauglich gemacht. Heute sind Container der De-facto-Standard für Cloud-native Anwendungen.
Die Grundidee: Eine Anwendung wird zusammen mit allen Abhängigkeiten in ein standardisiertes Paket (Container-Image) verpackt. Dieses Image läuft auf jedem System identisch, ob auf dem Entwickler-Laptop, im Testserver oder in der Produktionsumgebung. Das klassische 'Bei mir funktioniert es' gehört damit der Vergangenheit an.
VMs vs. Container: Der fundamentale Unterschied
Eine virtuelle Maschine emuliert einen kompletten Computer mit eigenem Betriebssystem. Das Betriebssystem allein belegt mehrere Gigabyte und braucht Sekunden bis Minuten zum Starten. Ein Container hingegen teilt sich den Kernel des Host-Betriebssystems. Er enthält nur die Anwendung und ihre direkten Abhängigkeiten. Container starten in Millisekunden und belegen typischerweise nur Megabytes statt Gigabytes.
Die Isolation ist bei Containern weniger streng als bei VMs. Alle Container auf einem Host teilen sich denselben Kernel. Ein Kernel-Bug oder eine Privilege-Escalation könnte theoretisch aus einem Container ausbrechen. In der Praxis sind moderne Container-Runtimes (wie containerd oder CRI-O) stark abgesichert, und Technologien wie seccomp, AppArmor und cgroups begrenzen, was ein Container tun kann.
Kubernetes: Der Container-Orchestrierer
Container allein lösen ein Deployment-Problem: Wie packe ich meine Anwendung so, dass sie überall gleich läuft? Kubernetes löst ein größeres Problem: Wie verwalte ich Hunderte oder Tausende von Containern über mehrere Server hinweg?
Kubernetes (oft K8s abgekürzt) übernimmt das Scheduling (welcher Container läuft auf welchem Server), das Scaling (wie viele Instanzen eines Containers laufen), das Networking (wie finden Container einander), und das Self-Healing (was passiert, wenn ein Container abstürzt). Die großen Cloud-Anbieter bieten verwaltete Kubernetes-Dienste an: Amazon EKS, Google GKE, Azure AKS. In Deutschland bieten IONOS und Hetzner ebenfalls managed Kubernetes an.
Der Kubernetes-Markt wächst von 1,8 Milliarden Dollar (2022) auf prognostizierte 7,8 Milliarden Dollar (2030), was einem jährlichen Wachstum von über 23 Prozent entspricht. Gartner erwartet, dass bis 2027 über 75 Prozent aller AI- und ML-Deployments auf Container-Technologie laufen werden. Die Lernkurve ist steil, aber für komplexe, verteilte Anwendungen ist Kubernetes zum Standard geworden.
Kubernetes lohnt sich vor allem bei Microservices-Architekturen mit vielen Containern, wenn das Team bereits K8s-Erfahrung mitbringt und hohe Skalierungsanforderungen bestehen. Für monolithische Anwendungen, wenige Services, kleine Teams oder stabile Last ohne Skalierungsbedarf ist der Overhead dagegen kaum zu rechtfertigen.
Skalierung: Wie Systeme mit Last umgehen
Skalierung beschreibt die Fähigkeit eines Systems, mit steigender Last umzugehen. Es gibt zwei grundlegende Strategien, die oft kombiniert werden.
Vertikale Skalierung: Größere Maschinen
Die einfachste Form der Skalierung: Mehr CPU, mehr RAM, schnellere Festplatten. Ein Server, der heute mit 4 GB RAM kämpft, bekommt morgen 16 GB. Bei physischer Hardware erfordert das Ausfallzeit und möglicherweise den Kauf neuer Komponenten. Bei Cloud-VMs ist es oft ein Neustart mit einer größeren Instanz.
Die Grenzen der vertikalen Skalierung sind schnell erreicht. Es gibt physikalische Limits für CPU-Kerne und RAM pro Server. Sehr große Instanzen werden überproportional teuer. Und ein einzelner Server bleibt ein Single Point of Failure: Fällt er aus, ist die gesamte Anwendung offline.
Horizontale Skalierung: Mehr Maschinen
Bei der horizontalen Skalierung werden Anfragen auf mehrere Server verteilt. Ein Load Balancer sitzt vor den Servern und leitet jeden Request an einen verfügbaren Server weiter. Steigt die Last, kommen weitere Server hinzu. Fällt ein Server aus, übernehmen die anderen.
Horizontale Skalierung erfordert, dass die Anwendung dafür ausgelegt ist. Zustand (Sessions, Caches) darf nicht nur lokal auf einem Server liegen, sondern muss zentral gespeichert werden (Redis, Memcached, Datenbank). Die Anwendung muss mit mehreren gleichzeitigen Instanzen umgehen können. Nicht jede Legacy-Anwendung ist dafür geeignet.
Auto-Scaling: Der Cloud-Vorteil
Cloud-Plattformen bieten automatische Skalierung: Regeln definieren, wann neue Server hinzugefügt oder entfernt werden. 'Wenn die CPU-Auslastung über 70 Prozent liegt, starte eine weitere Instanz.' 'Wenn weniger als 10 Requests pro Sekunde ankommen, fahre auf eine Instanz herunter.'
Diese Elastizität ist das zentrale Versprechen der Cloud und gleichzeitig eine Kostenfalle: Ohne Limits kann Auto-Scaling bei Lastspitzen (oder DDoS-Angriffen) die Rechnung explodieren lassen. Sinnvolle Maximal-Limits, Alerting bei ungewöhnlichem Scaling-Verhalten und Kosten-Alerts sind unverzichtbar. Erfahrene Teams konfigurieren Scale-In langsamer als Scale-Out (Hysterese), um Flapping zu vermeiden.
CDN und Caching: Näher am Nutzer
Ein Content Delivery Network (CDN) ist ein globales Netzwerk von Servern, die Inhalte näher am Endnutzer zwischenspeichern. Statt dass jede Anfrage den Weg zum Ursprungsserver in Frankfurt machen muss, liefert ein Edge-Server in Singapur die Inhalte für Nutzer in Asien.
Was CDNs leisten
CDNs reduzieren Latenz (der Edge-Server ist geographisch näher), entlasten den Ursprungsserver (weniger Requests kommen durch) und erhöhen die Ausfallsicherheit (wenn der Ursprungsserver kurz offline ist, liefert der Cache noch Inhalte). Große CDN-Anbieter wie Cloudflare, Akamai oder AWS CloudFront betreiben Hunderte von Edge-Standorten weltweit.
Die Konfiguration erfordert Sorgfalt. Welche Inhalte werden wie lange gecached? Statische Dateien (Bilder, CSS, JavaScript) können stundenlang oder tagelang im Cache bleiben. Dynamische Inhalte (Nutzerdaten, Warenkörbe) dürfen nicht oder nur sehr kurz gecached werden. Fehler in der Cache-Konfiguration führen entweder zu veralteten Inhalten oder zu unnötiger Last auf dem Ursprungsserver.
Für deutsche Websites bieten sich mehrere CDN-Anbieter an: Cloudflare ermöglicht einen kostenlosen Einstieg und betreibt einen deutschen PoP in Frankfurt. Bunny CDN ist EU-fokussiert und DSGVO-konform mit günstigem Pricing. KeyCDN als Schweizer Anbieter setzt ebenfalls auf europäische Infrastruktur.
Anwendungscaches: Schnellere Datenbankabfragen
Neben CDNs gibt es Caches auf Anwendungsebene. Redis und Memcached sind die populärsten In-Memory-Datenbanken für diesen Zweck. Häufig abgefragte Daten werden im RAM vorgehalten, was Datenbankabfragen vermeidet, die Millisekunden bis Sekunden dauern können.
Die Kunst liegt in der Cache-Invalidierung: Wann werden veraltete Daten aus dem Cache entfernt? Zu früh verschenkt Performance, zu spät zeigt der Nutzer veraltete Informationen. Es gibt keine universelle Lösung. Jede Anwendung muss ihre eigene Cache-Strategie entwickeln.
There are only two hard things in Computer Science: cache invalidation and naming things. (Es gibt nur zwei schwierige Dinge in der Informatik: Cache-Invalidierung und Dinge benennen.)"
— Phil Karlton
Hochverfügbarkeit: Was 99,9 Prozent wirklich bedeuten
Hosting-Anbieter werben mit Verfügbarkeitszusagen: 99,9 Prozent, 99,99 Prozent, manchmal sogar 99,999 Prozent. Diese Zahlen klingen ähnlich, bedeuten aber drastisch unterschiedliche Ausfallzeiten.
Die Mathematik der Neunen
99 Prozent Verfügbarkeit erlaubt 3,65 Tage Ausfall pro Jahr. 99,9 Prozent (drei Neunen) reduziert das auf 8,76 Stunden. 99,99 Prozent (vier Neunen) bedeutet maximal 52 Minuten Ausfall pro Jahr. 99,999 Prozent (fünf Neunen) erlaubt nur noch 5 Minuten. Jede zusätzliche Neun ist exponentiell schwieriger und teurer zu erreichen.
Wie Hochverfügbarkeit funktioniert
Echte Hochverfügbarkeit erfordert Redundanz auf jeder Ebene: mehrere Server, mehrere Netzwerkpfade, mehrere Rechenzentren. Load Balancer verteilen den Traffic und erkennen, wenn ein Server nicht mehr reagiert. Datenbanken werden repliziert, sodass bei Ausfall eines Knotens ein anderer übernehmen kann.
Die Cloud-Regionen von AWS, Azure und GCP sind intern in 'Availability Zones' unterteilt, die physisch getrennte Rechenzentren mit unabhängiger Stromversorgung und Kühlung darstellen. AWS betreibt in Frankfurt (eu-central-1) drei solcher Zonen. Hetzner bietet Standorte in Falkenstein, Nürnberg und Helsinki.
Für kritische Anwendungen reicht eine Region nicht. Multi-Region-Deployments verteilen die Anwendung über mehrere geographische Standorte. Wenn Frankfurt ausfällt (Stromausfall, Naturkatastrophe, Netzwerkproblem), übernimmt Dublin oder Paris. Diese Architektur ist komplex und teuer, aber für einige Anwendungen unverzichtbar.
Das Kleingedruckte der SLAs
Service Level Agreements (SLAs) definieren, was der Anbieter garantiert und was passiert, wenn die Garantie nicht eingehalten wird. Typischerweise: Gutschriften auf die nächste Rechnung. Die Formulierungen sind wichtig. Zählen geplante Wartungsfenster als Ausfall? Was ist mit Problemen, die nur einzelne Dienste betreffen?
AWS und Azure haben in der Vergangenheit SLA-Formulierungen so eng gefasst, dass selbst mehrstündige Ausfälle keine Kompensation auslösten. Es lohnt sich, das Kleingedruckte zu lesen: Welche Dienste sind abgedeckt? Wie wird Verfügbarkeit gemessen? Sind geplante Wartungsfenster ausgenommen? Für geschäftskritische Anwendungen ist die eigene Redundanz-Strategie wichtiger als die SLA-Versprechen des Anbieters.
Serverless: Die nächste Abstraktionsebene
Serverless Computing ist eine weitere Abstraktionsebene über Containern und VMs. Der Entwickler schreibt eine Funktion (ein paar Zeilen Code), lädt sie hoch, und die Plattform kümmert sich um alles andere: Ausführung, Skalierung, Infrastruktur. Die Abrechnung erfolgt pro Aufruf, nicht pro Stunde.
Function as a Service (FaaS)
AWS Lambda (2014 eingeführt), Azure Functions und Google Cloud Functions sind die bekanntesten FaaS-Angebote. Eine Lambda-Funktion wird durch ein Event ausgelöst (HTTP-Request, Datei-Upload, Nachricht in einer Queue) und läuft nur so lange, wie die Verarbeitung dauert. Danach wird sie beendet, und es fallen keine Kosten mehr an.
Der Serverless-Markt soll bis 2029 auf 44,7 Milliarden Dollar wachsen. Die Vorteile liegen auf der Hand: keine Infrastruktur-Verwaltung, automatische Skalierung von null auf Tausende paralleler Ausführungen, Pay-per-Use ohne Leerlaufkosten. Für Event-getriebene Workloads, APIs mit unvorhersehbarem Traffic oder Backend-Logik für mobile Apps ist Serverless oft ideal.
Die Grenzen von Serverless
Serverless hat Einschränkungen. Cold Starts sind ein bekanntes Problem: Wenn eine Funktion längere Zeit nicht aufgerufen wurde, muss die Plattform erst eine neue Instanz starten. Das kann Hunderte Millisekunden bis Sekunden dauern. Für latenzempfindliche Anwendungen ist das problematisch.
Ausführungslimits begrenzen, wie lange eine Funktion laufen darf (bei AWS Lambda maximal 15 Minuten) und wie viel Speicher sie nutzen kann. Zustand zwischen Aufrufen zu halten ist umständlich, da Funktionen per Design zustandslos sind. Und die Abhängigkeit vom Anbieter ist bei Serverless besonders stark: Eine Lambda-Funktion auf Azure Functions zu migrieren erfordert oft mehr als nur Code-Anpassungen.
Serverless eignet sich ideal für Event-Verarbeitung, APIs mit unregelmäßigem Traffic, Webhooks, Batch-Jobs und Backends für mobile Apps. Weniger geeignet ist der Ansatz bei Dauerlast, latenzempfindlichen Anwendungen, lange laufenden Prozessen oder Anwendungen, die viel lokalen Zustand benötigen.
Ausblick
Die technischen Grundlagen des Hostings haben sich in den letzten zwei Jahrzehnten dramatisch weiterentwickelt. Virtualisierung, Container, Orchestrierung und Serverless haben neue Möglichkeiten eröffnet, aber auch neue Komplexität geschaffen. Die fundamentalen Prinzipien bleiben konstant: Requests müssen beantwortet, Daten gespeichert, Systeme skaliert werden.
Der nächste Teil dieser Serie wird praktisch. Welches Hosting passt zu welchem Anwendungsfall? Wie unterscheiden sich AWS, Azure und Google Cloud in der Praxis? Wann lohnt sich ein deutscher Anbieter, wann die globale Cloud? Konkrete Entscheidungshilfen für reale Szenarien.
Ich arbeite seit Jahren mit den verschiedenen Hosting-Technologien und habe dabei eines gelernt: Die beste Technologie ist die, die das Team beherrscht. Kubernetes ist mächtig, aber für ein Zwei-Personen-Startup oft Overkill. Serverless ist elegant, aber der Vendor-Lock-in ist real. Container sind flexibel, aber ohne Orchestrierung schwer zu managen.
Mein Rat: Beginnen Sie einfach. Ein VPS mit Docker Compose trägt weiter, als viele denken. Skalieren Sie die Komplexität erst, wenn die Anforderungen es erfordern. Wer heute schon Kubernetes einsetzt, weil man es 'später sowieso braucht', zahlt Jahre früher den Preis der Komplexität.
Für deutsche und österreichische Unternehmen empfehle ich, europäische Anbieter zumindest als Backup-Option zu evaluieren. Hetzner, IONOS und OVHcloud bieten mittlerweile alle wichtigen Technologien: Container, Kubernetes, Load Balancer, Object Storage. Die Preise sind oft deutlich günstiger als bei den US-Hyperscalern. Die DSGVO-Konformität ist unkomplizierter, weil keine Datenübertragung in Drittländer stattfindet.
Quellenverzeichnis
[1] AWS (2025): 'Nitro System.' Dokumentation zur AWS-Hardware-Architektur.
[2] Docker (2025): 'What is a Container?' Einführung in Container-Technologie.
[3] Kubernetes.io (2025): 'What is Kubernetes?' Offizielle Kubernetes-Dokumentation.
[4] Gartner (2025): 'Container Management Magic Quadrant.' Analyse des Kubernetes-Marktes.
[5] Cloudflare (2025): 'What is a CDN?' Einführung in Content Delivery Networks.
[6] AWS/Azure/GCP (2025): Service Level Agreements. Offizielle SLA-Dokumente der großen Cloud-Anbieter.
[7] MarketsandMarkets (2025): 'Serverless Computing Market.' Marktanalyse und Prognosen bis 2029.
[8] Markets N Research (2025): 'Global Kubernetes Market Size.' Marktanalyse und Wachstumsprognosen bis 2030.