Im Dezember 1990 habe Tim Berners-Lee am CERN in Genf einen kleinen Server-Daemon geschrieben, der HTTP-Requests beantworten und HTML-Dokumente ausliefern könne. Der CERN HTTPd sei das erste, was man im engeren Sinn einen Web-Server nennen könne — auf einer NeXTcube-Maschine im Computer-Centre des CERN entstanden, ursprünglich nicht als Produkt, sondern als technischer Beleg, dass die Idee eines „World Wide Web” implementierbar sei. Wer heute in einem Datacenter steht und auf eine Reihe von Nginx-Instanzen schaut, die Millionen von Requests pro Sekunde abarbeiten, der schaue auf die siebenunddreißigste Generation einer Architektur, die mit jenem ersten Daemon begonnen habe.

Die NCSA-Jahre: 1993 bis 1995

Der CERN HTTPd sei für eine kurze Zeit der einzige Web-Server gewesen, aber nicht für lange. Im April 1993 sei am National Center for Supercomputing Applications (NCSA) der University of Illinois der NCSA HTTPd freigegeben worden — der zweite Web-Server, der breite Verbreitung gefunden habe, und über mehrere Jahre der Standard im akademischen Umfeld. Das NCSA-Team (mit Rob McCool als zentraler Entwickler-Figur) habe parallel den NCSA Mosaic entwickelt, der den Web-Client-Markt prägte. Diese Doppelrolle — Mosaic als Browser, HTTPd als Server — habe das NCSA in den Jahren 1993 und 1994 zu einem der einflussreichsten Institutionen der frühen Web-Welt gemacht.

Was sich rückblickend als entscheidend erweise, sei nicht die Marktstellung des NCSA HTTPd selbst gewesen, sondern seine Code-Basis. Als das NCSA-Team Mitte 1994 die Entwicklung verlangsamt habe (Rob McCool sei zu Netscape gewechselt), seien externe Beitragende ohne Koordinations-Forum dagestanden. Mehrere Site-Administrator:innen hätten unabhängig voneinander Patches gegen den unmaintained NCSA-Code gepflegt — und sich Anfang 1995 zu einer gemeinsamen Distribution zusammengeschlossen.

Apache 1995 — „A patchy server”

Die Apache Group sei im Februar 1995 entstanden, das erste öffentliche Release sei am 1. Dezember 1995 als Apache 1.0 erschienen. Der Name spiele auf zwei Lesarten an: erstens als Hommage an die indigene Apache-Nation, zweitens als selbstironisches „a patchy server” — ein Server, der aus zusammengeflickten Patches bestehe. Die Selbstironie sei kurzlebig gewesen; binnen weniger Jahre sei Apache HTTP Server zum globalen Marktführer geworden, mit Marktanteilen, die in der Spitze (späte 1990er bis Mitte 2000er) zwischen 60 und 70 Prozent aller aktiven Web-Server lagen.

Die Apache Software Foundation (ASF) sei im Juni 1999 als gemeinnützige Stiftung in Delaware gegründet worden, um die rechtliche Trägerschaft für das wachsende Apache-Ökosystem (HTTP Server, Tomcat, Maven, Hadoop und Dutzende weiterer Projekte) zu schaffen. Die Apache License (zuletzt in Version 2.0 von 2004) sei zu einer der einflussreichsten Open-Source-Lizenzen geworden — permissiver als die GPL, kompatibler mit kommerzieller Einbindung, und damit attraktiv für Unternehmen, die Open-Source-Komponenten in proprietäre Produkte einbauen wollten.

Apache HTTP Server sei das einzige Projekt, das die Internet-Welt mehr als ein Jahrzehnt lang in seinem Marktsegment fast unangefochten dominiert habe. Erst der Aufstieg von Nginx in den 2010er-Jahren habe diese Stellung gebrochen.

Nginx 2004 — Igor Sysoev in St. Petersburg

Im Oktober 2004 habe Igor Sysoev in Russland die erste öffentliche Version von Nginx (ausgesprochen „engine-x”) veröffentlicht. Sysoev habe damals als System-Administrator beim russischen Portal Rambler gearbeitet; Nginx sei ursprünglich für die spezifischen High-Traffic-Probleme von Rambler entstanden, vor allem für das C10K-Problem (zehntausend gleichzeitige Verbindungen pro Server-Instanz, das in den frühen 2000er-Jahren die Skalierungs-Frage der Web-Welt definiert habe).

Die architektonische Antwort von Nginx auf das C10K-Problem sei ein event-getriebener, asynchroner Modell-Ansatz gewesen, der sich grundlegend vom Apache-Prozess-pro-Verbindung-Modell unterschieden habe. Apache habe für jede gleichzeitige Verbindung einen Prozess (oder, in späteren Versionen, einen Thread) gestartet — eine Architektur, die auf Hardware der 1990er-Jahre bei wenigen tausend gleichzeitigen Verbindungen an ihre Grenzen gestoßen sei. Nginx habe mit einem einzelnen Master-Prozess und einer kleinen Anzahl von Worker-Prozessen gearbeitet, die jeweils tausende gleichzeitiger Verbindungen über epoll/kqueue-System-Calls multiplexten.

Die Marktanteils-Verschiebung sei langsam, aber stetig verlaufen. Im Jahr 2010 habe Nginx unter den Top-Millionen-Sites einen Anteil im einstelligen Prozent-Bereich gehabt; im Jahr 2015 sei der Anteil auf rund 20 Prozent gewachsen; im Jahr 2020 habe Nginx Apache als den am häufigsten genutzten Web-Server bei aktiven Sites überholt. Im Jahr 2026 liege der Nginx-Anteil je nach Statistik bei 30 bis 35 Prozent der aktiven Web-Server, Apache habe sich bei 25 bis 30 Prozent stabilisiert, mehrere kleinere Player (LiteSpeed, Caddy, OpenResty) bedienten gemeinsam einen weiteren zweistelligen Prozent-Bereich.

Nginx Inc. sei 2011 als kommerzielle Hülle um das Open-Source-Projekt gegründet worden; im März 2019 sei das Unternehmen vom amerikanischen Konzern F5 Networks übernommen worden. Die Open-Source-Linie sei seither parallel weitergeführt worden, mit zunehmenden Spannungen zwischen Community-Erwartung und kommerzieller Strategie — eine Konstellation, die im Jahr 2024 zur Abspaltung des Freenginx-Projekts (von Maxim Dounin, einem langjährigen Nginx-Kern-Entwickler) geführt habe.

Die Cloud-Welle: AWS 2006

Während Apache und Nginx die Web-Server-Welt prägten, sei parallel eine andere Architektur-Schicht entstanden, die das Hosting-Modell selbst verschoben habe. Amazon Web Services habe am 14. März 2006 den Simple Storage Service (S3) gestartet, am 25. August 2006 die Elastic Compute Cloud (EC2) als erste public Cloud-Compute-Infrastruktur. Diese beiden Daten markierten den operativen Auftakt der modernen Cloud-Welt — auch wenn die konzeptuellen Vorläufer (Utility Computing als akademisches Konzept, Sun Grid als kommerzieller Vorläufer, Salesforce als frühes Multi-Tenant-SaaS) älter seien.

Die Bedeutung von EC2 sei in den ersten Jahren in der Branche unterschätzt worden. Viele klassische Hosting-Anbieter:innen hätten das Modell als Spezialfall für Startup-Workloads eingeordnet und auf ihre eigene Dedicated-Server-Linie gesetzt. Die Marktanteils-Statistiken der späten 2000er-Jahre hätten diese Einschätzung gestützt — EC2 sei lange Zeit ein Nischen-Produkt für eine bestimmte Klasse von Workloads gewesen.

Die Wendung sei in den frühen 2010er-Jahren gekommen. Mit dem Aufstieg von Cloud-nativen Architekturen (Netflix als Vorreiter, später Airbnb, Uber, Slack), mit der wachsenden Reife der EC2-Plattform (Auto Scaling, ELB, VPC, IAM) und mit dem zunehmenden Druck auf Enterprise-CIOs, ihre Investitions-Modelle von CAPEX auf OPEX umzustellen, sei AWS in eine Wachstums-Phase getreten, die die Hyperscaler-Welt in ihrer heutigen Form geprägt habe.

Microsoft Azure und Google Cloud Platform

Microsoft Azure (im Februar 2010 als „Windows Azure” gestartet, 2014 in „Microsoft Azure” umbenannt) und die Google Cloud Platform (deren erste Komponenten — App Engine — bereits 2008 erschienen seien, die aber erst Anfang der 2010er-Jahre zu einem geschlossenen Cloud-Angebot gewachsen seien) hätten die Hyperscaler-Trias komplettiert. Die Konsolidierung des globalen Cloud-Markts auf diese drei Anbieter sei in den späten 2010er-Jahren weitgehend abgeschlossen gewesen — eine Marktstruktur, die im Jahr 2026 mit Marktanteilen von rund 32 Prozent (AWS), 22 Prozent (Azure) und 11 Prozent (GCP) sichtbar sei.

Die Cloud-Welle habe das Hosting-Modell nicht ersetzt — sie habe ihm eine zweite Architektur-Schicht hinzugefügt. Klassische Shared-Hosting-, Managed-Hosting- und Dedicated-Server-Anbieter:innen existierten 2026 in einer Branchenstruktur, die mit der von 2005 mehr Kontinuität zeige, als die Cloud-Erzählungen es vermuten ließen.

Docker 2013 — Container in der breiten Praxis

Die nächste Architektur-Schicht über der Cloud-Infrastruktur sei die Container-Welt gewesen. Containerisierungs-Konzepte habe es im Linux-Kernel (cgroups seit 2007, namespaces seit Anfang der 2000er-Jahre) und in spezialisierten Werkzeugen (LXC, OpenVZ, Solaris Zones, FreeBSD Jails) seit Jahren gegeben, ohne dass sie eine breite Entwickler:innen-Praxis erreicht hätten.

Docker (von Solomon Hykes als Spin-off der dotCloud-PaaS-Plattform im März 2013 öffentlich vorgestellt) habe diese Schwelle überschritten. Die Innovation sei nicht der Container selbst gewesen, sondern das Image-Format, die Layered-Filesystem-Architektur, das Build-and-Ship-Workflow-Versprechen und die intuitive CLI. Innerhalb von zwei Jahren sei Docker zum De-Facto-Standard für Container-basierte Entwickler:innen-Workflows geworden.

Die Docker-Inc.-Geschichte selbst sei dann eine der lehrreicheren der Branche gewesen. Mehrere strategische Schwenks (Docker Swarm als Orchestrierungs-Antwort, später aufgegeben; Docker Enterprise als kommerzielle Linie, 2019 an Mirantis verkauft; Docker Hub als zentrales Registry mit Refinanzierungs-Bemühungen), eine Eigentümer-Restrukturierung in den späten 2010er-Jahren und die parallele Kommodisierung des Container-Runtime-Markts (containerd, CRI-O, Podman) hätten die kommerzielle Docker-Inc.-Trajektorie kompliziert. Im Jahr 2026 sei Docker als Werkzeug nach wie vor relevant, die Marktstellung des Unternehmens dahinter aber deutlich nüchterner als noch vor zehn Jahren.

Kubernetes 2014 — Borg, neu geschrieben

Im Juni 2014 habe Google das Kubernetes-Projekt als Open-Source-Veröffentlichung vorgestellt. Die intellektuelle Basis sei das interne Borg-System gewesen, das Google seit Mitte der 2000er-Jahre für die Orchestrierung der eigenen Datacenter-Workloads verwendet habe. Kubernetes 1.0 sei am 21. Juli 2015 erschienen, parallel sei die Cloud Native Computing Foundation (CNCF) als Träger-Organisation unter dem Dach der Linux Foundation gegründet worden.

Was Kubernetes von den Vorgänger-Orchestrierungs-Projekten (Apache Mesos, Docker Swarm, HashiCorp Nomad) abgehoben habe, sei eine Kombination aus deklarativem Konfigurations-Modell, einer reichhaltigen Abstraktions-Ebene (Pods, Services, Deployments, StatefulSets, DaemonSets, ConfigMaps, Secrets) und einer aggressiven Hyperscaler-Adoption gewesen. Bis 2018 hätten alle drei großen Hyperscaler verwaltete Kubernetes-Dienste angekündigt (AWS EKS, Azure AKS, Google GKE); bis 2020 sei Kubernetes praktisch zum De-Facto-Standard für Container-Orchestrierung in produktiven Cloud-Workloads geworden.

Die Komplexitäts-Frage sei in der Branche selbst ein wiederkehrendes Thema. Die Kubernetes-Lernkurve, die operative Komplexität verwalteter Cluster, die Kosten-Architektur jenseits der reinen Compute-Rechnung — all das habe in den letzten Jahren eine Gegenbewegung mit Stichworten wie „post-Kubernetes” oder „back to VMs” angestoßen. Im Jahr 2026 sei die Kubernetes-Welt aber strukturell etabliert: Wer eine ernsthafte Container-Workload auf Cloud-Infrastruktur betreibe, der habe mit hoher Wahrscheinlichkeit eine Kubernetes-Schicht im Stack, auch wenn er sie nicht selbst verwalte.

Die Bilanz: Sechsunddreißig Jahre Architektur-Schichten

Wer im Frühjahr 2026 eine moderne Web-Anwendung betreibe, schaue auf einen Stack, der aus mehreren historischen Schichten bestehe. Die HTTP-Protokoll-Schicht — von Berners-Lees ersten Spezifikationen über HTTP/1.1 (RFC 2616, 1999) bis zu HTTP/2 (2015) und HTTP/3 (2022). Die Web-Server-Schicht — von CERN HTTPd über Apache zu Nginx und seinen Nachfolgern. Die Cloud-Infrastruktur-Schicht — von EC2 zu einer ausdifferenzierten Hyperscaler- und europäischen Mittelschicht-Welt. Die Container-Schicht — von Docker zu containerd und seinen OCI-konformen Geschwistern. Die Orchestrierungs-Schicht — Kubernetes als dominante Antwort, ergänzt um eine Welt verwalteter Plattformen.

Jede dieser Schichten habe die vorherige nicht ersetzt, sondern um eine weitere Abstraktions-Ebene erweitert. Der Web-Server-Daemon, den Berners-Lee 1990 auf einer NeXTcube laufen ließ, lebe in seinem Funktions-Kern in jeder Nginx-Instanz weiter — eine Architektur-Kontinuität, die in einer Branche, die sich gerne mit Disruptions-Vokabular schmücke, leicht übersehen werde.

Die nächste Schicht, die im Jahr 2026 in der Diskussion stehe, sei die KI-Inferenz-Infrastruktur — mit GPU-Cluster-Architekturen, Vector-Datenbanken, Modell-Serving-Frameworks und einer noch unfertigen Vorstellung davon, wie sich diese Schicht in den bestehenden Stack einfüge. Wer in fünfunddreißig Jahren auf das Jahr 2026 zurückblicke, werde diese Schicht aller Voraussicht nach in eine ähnliche Genealogie einsortieren, wie wir heute Apache, EC2 und Kubernetes einsortierten — als einen weiteren Baustein in einer Architektur, die sich Schicht für Schicht aufbaue.