Als wir 2005 zu dritt mit t3n.de losgestartet sind, lag unsere Webpräsenz mit vielen anderen Webprojekten auf einem Debian-Rootserver bei einem großen Hosting-Provider in Süddeutschland. Damals lieferte noch der Apache-Webserver unsere Website aus und unser MySQL-Server auf der gleichen Maschine lief mit den Debian-Default-Einstellungen. Wir hielten das für eine schöne Lösung. Zumindest eine Zeit lang. Genauer gesagt: Bis irgendjemand auf die Idee kam, dass man unser tolles Printmagazin für eine begrenzte Zeit kostenlos in unserem Shop bestellbar machen könnte. Was folgte, war der erste „Totaleinschlag“ in unserer Webhosting-Geschichte: Schon nach wenigen Minuten war unser Shop nicht mehr erreichbar.

In solch einem Moment überlegt man sich natürlich, was man an der MySQL-Einstellung hätte verbessern können, ob der Apache Webserver richtig konfiguriert ist, welche Möglichkeiten es evtl. noch gegeben hätte, besser zu cachen oder einen PHP-Bytecache einzusetzen,… Einen Tag später hatten wir einen dedizierten neuen Rootserver – den größten, den unser Massenhoster damals im Programm hatte (aber immer noch eine selbst zusammengebaute Kiste mit Desktop-Gehäuse). Dennoch blieb ein Problem: Trotz neuem Server war ich immer noch der Alleinverantwortliche für den Betrieb unserer Website und musste mir überlegen, wie unsere Zukunft aussehen sollte.

Gleiches Hosting, neuer Server – auch keine Lösung

Nun hatten wir also diesen neuen, tollen Server mit AMD-Prozessor und unglaublichen 2 GB RAM – über den wir uns heute schlapp lachen würden. Da liefen zwar immer noch alle Services auf einer Maschine, aber immerhin keine anderen Webhosting-Projekte. Mit der Zeit kamen bei t3n.de dann immer mehr interne Ideen dazu. Wir starteten neue Portale wie z.B. das Portal „socialnews“ (damals noch unter dem Namen hype!) und andere Verzeichnisse wie unser Job-Portal, einen Marktplatz für Dienstleister, ein Open-Source-Verzeichnis und ein Startup-Verzeichnis. Auf einmal brauchten wir Funktionen wie Single Sign On, interne APIs, Newslettermöglichkeiten, generierte XML-Sitemaps… Wir veröffentlichten mehr Inhalte, wurden besser verlinkt und auch besser von den großen Suchmaschinen indexiert. Kurz: Alles wurde komplexer, unser Traffic stieg stetig und gleichzeitig waren wir mit unserem Rootserver immer unzufriedener. Die reine Hardware-Performance war nicht das Problem. Vielmehr machte uns das in unseren Anfängen als „toll“ befundene Billig-Konzept des Hosting-Anbieters und die damit einhergehende schlechte Gesamtverfügbarkeit zu schaffen – „schlechte Verfügbarkeit“ stand dummerweise bei der Bestellung auch nicht in der Produktbeschreibung ;-)

Als unser Server zwei Tage komplett nicht erreichbar war, weil es im Rechenzentrum einen weitreichenden Kabelbrand gab und alle Leitungen ausgetauscht werden mussten, hielten wir es für einen guten Zeitpunkt, unsere Hosting-Strategie ein wenig zu überdenken.

Zufälligerweise fiel unser Wechselbedürfnis in dieselbe Phase wie unser Umzug in ein neues Büro. Dort gab es einen „Serverraum“, wo man zumindest schonmal einen 19′-Schrank reinstellen konnte und die Anbindung war mit 35 Mbit auch ziemlich luxuriös. Hinzu kam, dass eine Webagentur im selben Gebäude ebenfalls Hosting betrieb und wir inzwischen einen Systemadministrator-Azubi in unserem Team hatten, so dass unser Hosting-Wechsel vom Billigprovider hin zum eigenen Serverraum nach einer runden Sache aussah. War es eine Zeit lang auch: Wir konnten uns eigene Server zusammenstellen, waren gleichzeitig auch schlau genug, an die grundlegendsten Redundanz-Features wie Festplatten im Raid-1 und Fallback-Netzteil (zumindest schonmal im Schrank) zu denken.

Trotz allen Aufwands, den wir mit der Zusammenstellung der Schrank-Lösung, den Servern, der ausfallsicheren Stromlösung usw. hatten, blieb am Ende die Erkenntnis, dass wir selbst bei einigermaßen guten Rahmenbedingungen und einem inzwischen auf zwei Mann gewachsenen Team (inklusive mir), niemals die mit jedem Mehrtraffic immer höher werdenden Anforderungen stemmen konnten.

Wir hatten keinen Einfluss darauf, dass ein Baustellen-Bagger fünf Kilometer weiter ausgerechnet die für uns zuständige Glasfaserleitung kappte und wir für fünf Stunden offline waren. Wir hatten keinen Einfluss darauf, dass die Klimaanlage beim Bau des Gebäudes für einen Serverraum völlig unterdimensiniert wurde und es hätte auch keinen Sinn gemacht, für uns eine eigene Lösung zu implementieren. Hinzu kam, dass unser Vermieter irgendwann auch noch auf die Idee kam, dass es sinnvoll sein könnte, den Serverstellplatz nicht mehr wie anfänglich pauschal, sondern zuzüglich des verbrauchten Stroms zu berechnen. Der nachträglich eingeführte Stromzähler machte dann auch die noch so optimistische Effizienz-Schätzung zunichte. Wir mussten uns mal wieder etwas Neues überlegen. Hinzu kam, dass wir täglich an Traffic zulegten und merkten, dass wir von dedizierten Servern auf eine Virtualisierungstechnik wechseln mussten, da uns Flexibilität fehlte, unsere vorhandenen Hardware-Ressourcen optimal zu nutzen.

Noch bevor das überhaupt richtig bei unseren Lesern ankam, war uns klar, dass wir virtualisieren müssen, um mit unserem Hosting flexibler zu werden. Wir wollten einfach nur noch für einen physikalischen Server zuständig sein und darauf alle Projekte virtualisieren. Also haben wir uns den größten Dual-Xeon-Server besorgt, den wir damals kurzfristig auftreiben konnten und auf Basis des Virtualisierungssystems Xen ein Hostsystem aufgesetzt. Wir waren so richtig begeistert von unserer Virtualisierungsidee, dass wir ziemlich viel virtualisiert haben. Im Nachhinein wahrscheinlich etwas zu viel.

Mit dem Wechsel auf Virtualisierung und ein Rack im professionellen Rechenzentrum (RZ), hatten wir schonmal einen wichtigen Schritt getan. Ausfallsicherheit und Anbindung, sowie das Preis/Leistungsverhältnis waren einfach spitzenmäßig. Zudem waren wir in guter Nachbarschaft (ja, es gibt noch RZs, in denen die Server mit Klarnamen beschriftet werden) und das Rechenzentrum war auch nur 3 km von unserem damaligen Büro entfernt, so dass man im Notfall auch schnell da war.

Wir betrieben also diese wunderbare virtuelle Serverwelt und waren damit auch wirklich gut zufrieden. Bis der Tag kam, an dem wir uns fragten, wie wir denn eigentlich das Hostsystem, also den Xen-Server am Besten im laufenden Betrieb updaten, ohne Gefahr zu laufen, dass danach alles down ist. Jeder, der mal einen Webserver betrieben hat, weiß, dass es keine gute Idee ist, im Livebetrieb umfangreichere Upgrades durchzuführen und durch die strikte Virtualisierung waren wir schon bei der kleinsten Änderung am Xen-Server dazu gezwungen, alle virtuellen Maschinen vorher auszuschalten und konnten dann nur beten, dass sie wieder hochfahren bzw. der Xen-Server nach einem Upgrade überhaupt noch funktionstüchtig war.

Kurz: Auch diese Hosting-Lösung war langfristig zum Scheitern verurteilt. Zudem verursachte unser selbst aufgesetzter Xen-Server unter Debian immer mehr merkwürdige Kernelprobleme und wir hatten kein adäquates Testsystem, um Änderungen sicher zu testen. Man hätte nun einen baugleichen zweiten Server kaufen können und diesen neben dem Live-Server platzieren können. Dummerweise hatten wir beim Kauf des Servers nicht darauf geachtet, dass das verbaute Mainboard nur bis 8 GB Speicher aufrüstbar ist und wir mit unserem ganzen Virtualisierungsideen und neuen Projekten plus stetig wachsendem Traffic damit vorne und hinten nicht hinkamen.

Uns wurde also klar, dass wir eine Lösung für das Management unseres Xen-Servers brauchten. Von der Technik waren wir nach wie vor voll überzeugt und obwohl wir mit unserer inzwischen gesammelten Erfahrung natürlich einiges anders machen wollten, brauchten wir am Ende einfach einen stabilen Xen-Hostserver als Basis. Also waren wir mal wieder am Suchen. Der Billighoster von damals hatte neue Server im Programm (immer noch Desktop-Hardware), doch der Kabelbrand von damals saß uns noch fest im Kopf. Bei anderen Hostern gab es inzwischen sogar Angebote gemanagter Virtualisierungslösungen. Nach näherer Betrachtung gab es aber bei allen fertigen Paketen immer irgendeinen Haken. Nach wochenlanger Recherche und einigen Tests, waren wir auf einmal auf der Suche nach einem Individualhoster, einem Spezialisten für unsere Anforderungen.

Über das Sun Startup Essentials Programm sind wir dann auf unbelievable machine (kurz *um) aufmerksam geworden – eine kleine Hosting-Schmiede aus Berlin. So richtig habe ich am Anfang nicht begriffen, was die eigentlich machen und irgendwie schien mir eine Individuallösung anfänglich auch als viel zu unkalkulierbar. Nach den ersten Gesprächen mit den *um-Jungs kristallisierte sich aber relativ schnell heraus, dass wir uns mit unbelievable machine einen Partner ins Boot holen könnten, der uns das ganze Management der Hardware-Lösung und auch die Verwaltung unseres Xen-Servers komplett abnehmen würde.

Jetzt sind wir inzwischen etwas über ein Jahr dort Kunde. Ich nenne Sie gerne die „Raketenforscher unter den Hostern“, weil sie als Hosting-Dienstleister von der Hardware über das RZ bis hin zur Anbindung einfach extrem anspruchsvoll sind und sich da eine Truppe an Experten gefunden hat, die es schafft, State-Of-The-Art-Hosting-Technologie so auf praxistaugliche Lösungen runterzubrechen, dass das Ganze für kleine Kunden wie uns am Ende dennoch bezahlbar ist.

Wir haben zum Beispiel ein Sun-Blade in einem der von *um betriebenen Bladecenter mit ausreichend Leistung durch Dual-Intel-Nehalem-Prozessor, SAS-RAID und 24 GB Arbeitsspeicher, auf dem *um für uns einen Citrix Xen-Server betreibt. Das Rechenzentrum in Berlin, in dem *um seine Hosting-Lösungen betreibt, ist das professionellste RZ, das ich je betreten habe und alles ist so extrem redundant ausgelegt, dass ich es für unsere Anforderungen für fast gnadenlos überdimensioniert halte – aber schaden kann die zusätzliche Professionalität ja auch nicht. Zumindest so lange das Preis/Leisungsverhältnis stimmt. Das Thema Xen-Server-Hostsystem haben wir inkl. Backups komplett an *um ausgelagert. Wir kümmern uns nur noch um unsere virtuellen Maschinen. Als weitere Pakete nutzen wir aktuell noch die Shared-Firewall-Lösung und den 24/7-Restart/Reset-Service.

Gerade der Restart/Reset-Service hat mir schon so manchen Ärger erspart. Ab einem gewissen Punkt tut es einfach richtig weh, wenn man mit einer groß gewachsenen Website auf einmal offline und dummerweise als technischer Ansprechpartner alleinverantwortlich für alles ist.

Langfristig ist es einfach eine Illusion, als Einzelperson immer voll verfügbar zu sein und im Notfall jedes Serverproblem zeitnah lösen zu können. Ich hatte dieses Jahr die Situation, dass ich mit meinem zu diesem Zeitpunkt 15 Monate alten Sohn an der Supermarktkasse stand, den Wocheneinkauf einpacken/bezahlen sollte, er schon unruhig wurde, weil er endlich was zu Essen auf dem Tisch haben wollte und in diesem wundervollen Moment der Erwartungen mich dieses schlimmste aller Monitoring-SMS erreichte: „t3n.de not reachable“. Natürlich hätte ich laut schreien, meinen Sohn schnappen und aus dem Supermarkt zum nächsten Internetanschluss rennen können, aber stattdessen habe ich einfach nichts dergleichen getan und auf meine Hosting-Lösung vertraut.

Natürlich schau ich mir auch heute trotzdem noch zeitnah an, wo der Fehler lag, aber falls ich im Notfall nicht reagieren kann, versucht der *um-Bereitschaftsdienst den Fehler selbständig zu beheben. 24 Stunden am Tag, 7 Tage die Woche. Wir haben am Anfang gemeinsam eine Dokumentation unserer Hosting-Architektur erarbeitet, so dass die grundlegendsten Fehlerquellen von jedem *um-Mitarbeiter eigenständig behoben werden können. Dafür bezahlen wir eine monatliche Pauschale und den Aufwand für jeden Notfalleinsatz – auch abhängig vom Tag und der Uhrzeit. Bisher eine absolute faire Lösung, die ich auf keinen Fall mehr missen möchte. Für mich ist das ein absolutes Plus an Lebensqualität.

Mindestens einmal im Jahr setzen wir uns übrigens zusammen und besprechen unsere Hosting-Entwicklung, Probleme und Verbesserungsideen. Da der Traffic ständig wächst und neue Projekte dazukommen, ist das für mich ein unglaublich wichtiger Termin, der natürlich durch zahlreiche Besprechungen über das Jahr hinweg ergänzt wird.

Auch wenn heutzutage jeder „Cloudhosting“ schreit und ich ebenfalls ein großer Cloud-Fan bin, sehe ich uns mit unserer Hosting-Infrastruktur noch weit von der Cloud entfernt. Wir haben umfangreiche Tests mit den Amazon AWS Services gemacht, betreiben heute parallel zu unserer t3n.de-Hosting-Infrastruktur mehrere Jiffyboxen für interne Projekte, die wir nicht mit unserem Live-Betrieb von t3n.de auf einem Server betreiben wollen und ich habe mir auch schon cloudcontrol, heroku und alternative Virtualisierungslösungen zum Citrix Xen-Server wie z.B. KVM, OpenStack usw. angeschaut. Das sind alles tolle Entwicklung und ich bin mir sicher, dass wir mit t3n.de auch hier demnächst vorne mit dabei sein werden, aber solange wir dann immer noch für den Betrieb unserer Kernkomponenten (Webserver,MySQL-Server,MessageQueue,…) selbst verantwortlich sind, werde ich erstmal nichts ändern, sondern meine Zeit lieber in die Optimierung unserer Software-Lösungen stecken.

Meine Meinung ist, dass sich die Sicht von professionellen Webhosting-Kunden verändern wird. Wir werden endlich den lang prophezeiten Wandel vom Server- zum Application-Hosting sehen. Wo der Kunde früher zufrieden war, dass er sich nicht mehr um das Management seiner Serverhardware kümmern musste, wird er sich in Zukunft fragen, warum er sich um die Konfiguration eines MySQL-Servers kümmern sollte, wo doch 2.000 andere Kunden beim gleichen Provider ähnliche Anforderungen haben und man einfach einen zentral vom Provider verwalteten MySQL-Cluster per MySQL-Proxy nutzen könnte.

Wir werden einen Wandel sehen vom monatlichen Fixpreis-Hosting hin zu nutzungsbasierter Abrechnung, wo man neben einer niedrigen Grundpauschale nur das zahlt, was man wirklich an Ressourcen in Anspruch nimmt. Es werden sich Standards etablieren, die den relativ einfachen Wechsel von einem Application-Provider zum anderen ermöglichen und sei es, dass einfach beide Provider technisch ähnliche Lösungen bereitstellen.

Die nötige technologische Basis für all diese Dinge steht in Form von immer besser werdenden Open-Source-Lösungen schon lange in den Startlöchern. Themen wie Skalierbarkeit, Hochverfügbarkeit und realistisches Kosten/Nutzen-Verhältnis werden als gegeben vorausgesetzt. Gleichzeitig machen wir uns aber auch wieder etwas abhängiger von anonymen Lösungen von Riesenkonzernen ohne Telefonnummer und globalen Spezialanbietern.

Bei aller Euphorie sollte man am Ende nie vergessen, dass auch das Thema Hosting am Ende mit Menschen zu tun hat. Bei Amazon AWS kann ich nicht anrufen und fragen, was die zu dem Aufbau meiner virtuellen Maschinen sagen. Wenn ich zu cloudcontrol wechseln wollen würde, könnte ich zur Zeit keine MessageQueue, keinen Solr-Server und keine Cronjobs betreiben. Außerdem stehen die Server hinter cloudcontrol wieder im Amazon AWS Rechenzentrum in Irland. Für eine Microsite sicher gut, aber die tolle Responsetime und Kalkulierbarkeit unseres im RZ in Berlin stehenden Servers ist auch nicht nachteilig. Jiffybox finde ich für kleine Projekte toll, ist aber auch nur eine halbe Cloud-Lösung, da man sich selbst um Kernfragen wie Skalierbarkeit und Performance kümmern muss, indem man zum Beispiel mehrere Jiffyboxen zu Cluster-Systemen kombiniert und sich um die nachhaltige Konfiguration/Überwachung wie bei echten Servern selbst kümmern muss.

Jede Hosting-Lösung ist nur so gut, wie die Menschen die dahinter stehen. Egal ob Cloud, eigener Serverraum oder managed Xen-Server. Egal wie gut man ist, welche tollen Technologien man einsetzt oder wie zuverlässig die Hosting-Lösung ist – wer schonmal einen Webserver betrieben hat weiß:

Es brennt immer etwas an. Sei bereit.