Willkommen zu einer neuen Reihe, die ich einfach mal “Cloud-Geschichten” genannt habe. Wie viele Teile es werden, ist mir zu dieser Zeit noch nicht klar, aber da ich inzwischen einiges an Material gesammelt habe, werden es sicherlich mehr als einer. Letztlich möchte ich den Weg skizzieren, der mich einerseits in die Cloud geführt hat, und zwar anhand eines konkreten Beispiels, andererseits aber auch wieder aus der Cloud heraus. Zumindest teilweise.
Das konkrete Beispiel stellt meine minimale Web-Site geschke.net dar, die ich irgendwie neu aufbauen wollte – tatsächlich stand am Anfang des Weges noch nicht vollständig fest, wohin er mich führen sollte.
Anekdoten aus schwarz-weißer Vorzeit
Begeben wir uns nun in die Anfangszeit des World Wide Web, denn am Anfang gab es statische Web-Seiten. Meinen ersten Kontakt mit dem WWW hatte ich 1993, was nun auch schon gute 25 Jahre her ist. Ich kann mich noch recht gut an die Unix-Workstations im CIP-Pool der Informatik der RWTH Aachen erinnern, genau genommen waren es SUN und HP Workstations mit für damalige Verhältnisse ziemlich großem Monitor und einer fantastisch hohen Auflösung. Die Angabe, wie hoch “hoch” damals wirklich war, dürfte man auf diversen Retro-Computing-Webseiten finden, auf jeden Fall war es ein nicht zu unterschätzender Unterschied zu VGA mit ursprünglich maximal 640×480 Pixeln auf einem 14- oder 15-Zoll-Röhrenmonitor. Anfangs war es eine ziemlich fremde Welt, die mich durchaus einigen Respekt zollen ließ, denn diese Maschinen liefen unter einem bis dato eher fremden Betriebssystem namens Unix, in dem Fall HP-UX oder SunOS bzw. Solaris. Das wurde dann dargestellt auf 20- oder 21-Zoll-Röhrenmonitoren, deren Gewicht einen stabilen Schreibtisch verlangte. Als ob die Hardware an sich nicht schon interessant genug gewesen wäre, gab es natürlich noch die Software. Und damit auch ein damals recht neues Produkt – oder vielleicht besser Konzept, das World Wide Web, abgekürzt WWW. Zuvor hatte ich mich ein wenig mit Mailboxen beschäftigt, jedoch nur als Anwender, ich hatte mich eingewählt und Nachrichten verschickt, habe Programme herunter geladen, meist handelt es sich um Shareware, die zwar irgendwann bezahlt werden wollte, aber dazu kam es so gut wie nie, und vielleicht hatte ich sogar auch Informationen zu irgend welchen Themen beziehen können, tatsächlich weiß ich dies gar nicht mehr so genau. Diese neue WWW-Welt bot jedoch kombiniert alles unter einer Oberfläche, dem Web-Browser.
Somit konnte man sich per Mausklick durch die weiter werdende Welt bewegen. Oder auch auf die Web-Seiten, die von der eigenen Uni gehostet wurden, beispielsweise, um nachzusehen, ob die Anzahl der Modem-Einwahlports schon erweitert worden war oder mit welcher Bandbreite die gesamte Institution inzwischen an das Internet angeschlossen war. Oder ähnliche Informationen, alles war nur einen kurzen Klick entfernt. Die Workstations boten einen weiteren Vorteil, sie liefen 24 Stunden am Tag, ihr Betriebssystem war dafür ausgelegt, was einem die Möglichkeit einbrachte, Server-Software darauf laufen zu lassen. Ich vermute, dass den Home-Directories NFS zugrunde lag, so dass man auf jeder der im Netzwerk angeschlossenen Workstations arbeiten konnte und dieselben Dateien in seinem Verzeichnis vorfand, mit denen man zuvor auf einer anderen Workstation gearbeitet hatte. Noch dazu bot der eingesetzte Web-Server die Möglichkeit, ein bestimmtes Verzeichnis im Home-Directory zu aktivieren, so dass die darin befindlichen Dateien fortan im WWW verfügbar waren. Also beispielsweise musste ein Verzeichnis namens public_html erstellt werden, darin wurden die HTML-Dateien platziert, die unter einer URL wie http://irgendwas.example.com/~username/ erreichbar waren, wobei “username” der Login-Kennung entsprach.
Erste statische Web-Seiten
Insofern war auch meine erste HTML-Seite – und damit mein erster Internet-Auftritt schnell zusammen gezimmert, auch wenn dort damals zunächst nicht mehr als vielleicht mein Name mitsamt E-Mail-Adresse zu sehen war – der Grundstein war gelegt. Das mag sich nach Geschichten aus der Internet-Steinzeit oder Anekdoten aus Opas Kriegstagen anhören, doch das genannte Verfahren, HTML-Seiten in einem Verzeichnis innerhalb des Home-Directories zu platzieren, wird auch heute noch verwendet, insbesondere bei günstigen Massen-Hostern. Nicht zuletzt besitzt beispielsweise der Apache Web-Server nach wie vor ein Modul, mit dem die User-Directories angesprochen bzw. genutzt werden können. Verschwunden ist jedoch das Tilde-Zeichen (~) aus den URLs, schließlich besitzt heutzutage jedes Haustier oder auch IoT-Device einen eigenen Domainnamen, von dem ein entsprechendes Mapping auf die genannten Verzeichnisse erfolgt.
Noch mehr statische Web-Seiten
Springen wir ein paar Jahre weiter, inzwischen war ich als studentische Hilfskraft bei der Uni Köln bzw. dem Zentralarchiv für empirische Sozialforschung gelandet. Nach einigen Fingerübungen in der Perl-Programmierung und Server-Administration bestand mein erstes größeres Projekt tatsächlich aus der Generierung von statischen Seiten. Und zwar ziemlich vielen Seiten. Kurz gesagt wurden viele, viele Dateien, die in einem “Großrechner-Format” vorlagen, zunächst mit Perl geparst und die heraus gefilterten Daten in eine SQL-Datenbank geschrieben, es handelte sich um mSQL, nicht etwa MySQL. Anhand dieser Grundlagen wurden HTML-Dateien erstellt, mit deren Hilfe die User einen einfacheren Zugang zu den gewünschten Informationen erhalten konnten. Die Dateien waren zwar statisch, aber untereinander exzessiv “hyperlinked”, getaggt, also durch Keywords erreichbar usw..
Perl war damals ebenfalls aufgrund den mächtigen Funktionen zur String-Verarbeitung die Programmiersprache der Wahl, um ein wenig Interaktivität in bis dato statische Web-Seiten zu bringen – das Stichwort dazu hieß CGI oder sperriger Common Gateway Interface. Damit war es etwa möglich, Eingaben von Formularen zu verarbeiten und dem User eine passende Ausgabe, soll heißen, HTML-Seite zu generieren. Nichtsdestotrotz waren die meisten HTML-Seiten nach wie vor statisch, denn CGI mit Perl war als durchaus aufwändig zu bezeichnen. Es gab jedoch erste Anwendungen wie Foren und natürlich Myriaden von Feedback-Formularen, damit der User mit einer Web-Site interagieren konnte. JavaScript hingegen steckte noch in der client-seitigen Baby-Phase, die durch bunte Laufschriften und blinkenden Buchstaben schreiend auf sich aufmerksam machte. Auch Online-Umfragen erfreuten sich steigender Beliebtheit, insofern lag die Idee nahe, davon auch einigen Interessenten zu erzählen.
PHP ist eine serverseitig interpretierte, in HTML eingebettete Skriptsprache…1
Ein wenig später betrat PHP die Bühne, oder vielmehr trat PHP in meinen Fokus. Von dieser Zeit an waren nicht nur meine kleinen Web-Seiten nicht mehr statisch, sondern in den meisten Projekten oder Jobs, in denen ich gearbeitet hatte, wurde PHP oder eine ähnliche Technologie verwendet, um Web-Seiten on-the-fly zu generieren. Im einfachsten Fall handelte es sich um das Einbinden von Header und Footer, deren Dateien an geeigneter Stelle eingebunden wurden, was den Aufwand bei Änderungen verringerte, aber natürlich wurde es auch mit der Zeit wesentlich komplexer und beinhaltete das Beziehen von Informationen aus mehreren Datenquellen, die Generierung von user-spezifischen Ausgaben, die Nutzung von APIs verschiedener Anbieter usw.. Nicht zu vergessen diverse Verfahren, um die ganze serverseitige Arbeit zu beschleunigen, Caching von Datensätzen, Listen etc., Caching von fertig generierten Teilen, Partials, Snippets, oder sogar Caching vollständiger Seiten, falls möglich, bzw. ergänzt durch User-spezifische Ausgaben usw.. Letztlich sind die Konzepte aber dieselben wie vor 20 Jahren – von irgendwo her werden Daten geholt, diese werden verarbeitet, verändert, ergänzt, und anschließend erfolgt die Ausgabe. Ob die Ausgabe nun HTML-Seiten sind oder die Single Page Application JSON oder gar GraphQL verlangt – geschenkt. Eingabe, Verarbeitung, Ausgabe. Manche Informatik-Prinzipien sind eben allgemeingültig.
Diese “dynamischen Web-Seiten”, wie sie in der Anfangszeit gerne genannt wurden, funktionieren ja auch prima, inzwischen lassen sich Content Management Systeme (CMS) in nahezu jedem Billigst-Hoster-Angebot einrichten, und bei der Nutzung eigener (virtueller) Maschinen sind erst recht keine Grenzen gesetzt. Andererseits steigt damit die Komplexität und der Aufwand auch auf Admin-Ebene, das System will aktuell gehalten werden, ist immer wieder Angriffen ausgesetzt, somit stellt sich die Frage, ob es sinnvoll ist, für jede noch so kleine Website ein mehr oder minder ausgewachsenes CMS einzusetzen. Ebenso sieht man in der letzten Zeit viele One-Page-Sites, mit denen ich persönlich zwar auf Kriegsfuß stehe, aber nach wie vor scheint diese Art der Präsentation durchaus beliebt zu sein.
Back to the roots – es wird wieder statisch!
Dennoch war es der Zufall, der mich wieder zu statischen Web-Seiten brachte, oder vielmehr statischen Web-Seiten in der modernen Variante der Web-Site-Generatoren. Ohne Namen nennen zu wollen, dürfte die Initialzündung eine Schulung zum Thema Kubernetes im September des Jahres gewesen sein. Es ging unter anderem um Skalierung, und in Bezug auf dieses Thema sind statische Seiten beinahe die beste Erfindung seit geschnitten Brot, und zwar aus zwei Gründen.
Erstens sind statische Seiten statisch. Klingt logisch, aber das bedeutet, dass sie schnell (auslieferbar) sind. Der Web-Server hat mit keinerlei CPU-Last zur Aufbereitung der Inhalte zu kämpfen, denn diese liegen bereits vor. Somit beschränken sich die Aufgaben des Web-Servers in Dateioperationen – d.h. nachsehen, ob die angeforderte Datei vorhanden ist, und wenn ja, auf den entsprechenden Port schieben. Bereits im nicht optimierten Zustand schafft so ein Web-Server ein Vielfaches an Requests pro Zeiteinheit im Vergleich zu serverseitig generierten “dynamischen” Webseiten.
Zweitens lassen sich statische Webseiten, einmal generiert, hervorragend verteilen und cachen. Das sind zunächst zwei Paar Schuhe, mit verteilen meine ich die Nutzung mehrerer Server und das damit verbundene Loadbalancing. In der kleinsten Ausführung stehen mehrere Server quasi nebeneinander, alle beinhalten sie dieselben Dateien, ein Loadbalancer sorgt für die Lastverteilung, so dass die Requests an allen eingesetzten Servern ankommen und verarbeitet werden. Noch dazu ist z.B. keinerlei Session-Handling notwendig, jeder Server ist gleichberechtigt, es ist irrelevant, von wem die Anfrage beantwortet wird. Insgesamt ergibt sich somit eine schöne, horizontal skalierbare Shared-Nothing-Architektur. Denkt man dies ein wenig weiter, verteilt man in mehreren Rechenzentren, Ländern, Kontinenten, Galaxien… Darüber hinaus können statische Dateien wunderbar gecached werden. Beispielsweise mittels Content Delivery Networks (CDN), so dass der User eine zwischengespeicherte Version einer Seite erhält, die von einem Server ausgeliefert wird, der möglichst nah zum User platziert ist – je kürzer die Wege, desto geringere Latenzzeiten, und wenn das ganze mit guter Bandbreite einher geht, verkürzt dies die Wartezeit für den User durchaus spürbar. Wie dieses Caching erfolgt, ob im Memory oder wiederum auf Speichermedien, ist hier nicht das Thema, jedenfalls ist die Nutzung von CDNs mit statischen Seiten sehr einfach, da nur bei Veränderung eine vom Cache eine neue Version angeforderte werden muss, bzw. die geänderten Seiten könnten auch in den Cache gepusht werden. Eine Nummer kleine wäre die Verwendung von Web-Server eigenem Caching, so können viel angefragte Inhalte aus dem Memory ausgeliefert werden und müssen nicht jedes Mal neu vom Speichermedium geladen werden.
Der einzige Nachteil von statische Webseiten – sie sind statisch. Also wirklich unveränderlich. Das heißt, dass jegliche Form von Interaktivität entfällt, nicht einmal ein simples Feedback- oder Kontaktformular ist sinnvoll möglich, statt dessen blendet man gerne dazu eine Mailadresse ein… Ganz wie vor 25 Jahren bei meiner ersten Web-Seite. Natürlich lassen sich per JavaScript ganze Web-Applikationen schreiben, die sehr dynamisch aussehen, aber hierbei findet die Interaktion auf einer anderen Ebene statt. Vielmehr geht es darum, dass alle Inhalte, die ein Client anfordert, bereits auf dem Server (vor)generiert sein müssen. Somit ist keine direkte Reaktion auf User-Eingaben möglich. Insofern ist es wie immer – die Anforderungen bestimmen, welche Technologie sinnvoll nutzbar ist. Bei einer Suchmaschine wären statische Seiten ziemlich kontraproduktiv, beim Web-Auftritt eines ortsansässigen Handwerkers, der um Kontaktaufnahme per Telefon bittet, könnte man schon eher darüber nachdenken, auch wenn für das Hosting höchstwahrscheinlich auch ein Raspberry Pi mehr als ausreichend wäre. Bei einem Shop-System könnte es eine Hybrid-Lösung geben, denn während Produkt-Informationen sicherlich vorgeneriert sein könnten, müssten Warenkorb und der Bestellprozess auf Eingaben eines Users reagieren können. Hingegen könnte es für gewisse Anlässe Vorschalt-Seiten geben, d.h. statisch generierte Seiten, die den Benutzer in Empfang nehmen, über das Produkt, das Unternehmen, die Gründer etc. informieren und in mehreren Schritten beispielsweise auf den Shop, den Download o.ä. leiten. Beispielsweise sinnvoll, wenn mal wieder TV-Werbung geschaltet ist – oder noch schlimmer, das Startup einen Auftritt bei #DHDL (“Die Höhle der Löwen“) ergattern konnte.
Go, Hugo, Go!
Immerhin gibt es inzwischen neuere Entwicklungen, die die Erstellung und Verwaltung statischer Webseiten im Vergleich zu handgeklöppelten Perl-Skripten um einiges erleichtern. Glücklicherweise sind heutzutage die damals mehr oder minder beliebten, aber extrem gruseligen HTML-Editoren wie Microsoft Frontpage oder Netobjects Fusion nahezu verschwunden. Statt dessen gibt es nun statische Webseiten-Generatoren, die bekanntesten dürften zur Zeit Hugo (Go) und Jekyll (Ruby) sein. Wer Spaß, Lust und ein paar Monate Zeit hat – Tendenz steigend – kann ja mal einen Blick auf eine Liste von statischen Website-Generatoren werfen und alle Initiativen einem genaueren Test unterziehen. Für meine kleine Site habe ich mich ad hoc für Hugo entschieden. Als Grund könnte ich angeben, dass ich die zugrunde liegende Programmiersprache Go lieber mag als Ruby, oder dass mir die Gotemplate-Syntax direkt sympathisch erschien, jedoch scheint die Template-Engine Liquid, die von Jekyll benutzt wird, tatsächlich noch näher an der gewohnten Twig-Syntax orientiert zu sein. Kurzum – es war mehr eine Entscheidung aus dem Bauch heraus als rein aufgrund rationaler Kriterien. Beide Website-Generatoren sind sich letztlich recht ähnlich und bieten mehr als genug Funktionalität für meine erste kleine Test-Site.
Die Funktionalität lässt sich in etwa wie folgt zusammenfassen: Inhalte werden im Markdown-Format geschrieben, die Dateien entsprechend des späteren Seiten-Aufbaus strukturiert, globale Einstellungen finden in einer Konfigurationsdatei Platz, hinzu kommen ein oder mehrere Themes, die das Design der Seiten bestimmen. Nachdem die Entwicklung abgeschlossen ist (Hugo bietet für diesen Developer-Modus einen eigenen, eingebauten Web-Server, der die Änderungen sofort an den Browser weitergibt), werden die Seiten mit einem einzigen Kommandozeilen-Aufruf generiert, Hugo platziert daraufhin alle notwendigen Dateien, d.h. neben den HTML-Dateien auch Bilder, CSS-, JavaScript-Files etc., in einem Verzeichnis, per Default namens “public” innerhalb des Projektverzeichnisses. Dieses Verzeichnis bzw. die Inhalte davon müssen zum Deployment nur noch einem Webserver zugänglich gemacht werden – fertig.
Cloud (Symbolbild) – (c) 2018 by Ralf Geschke
Oder aber man verwendet die viel beschworene “Cloud”. Denn die versammelte Cloud-Riege bietet selbstverständlich entsprechende Dienste zur Speicherung, Verteilung und zum Abruf der Dateien an. Im Detail gibt es jedoch entscheidende Unterschiede, dazu mehr in einem späteren Teil.
Ausblick
Da ich ab und wann ganz gerne neue Technologien und deren Möglichkeiten ausprobiere, Amazon AWS, Google Cloud Platform oder Microsoft Azure schon wieder viel zu sehr Mainstream ist, habe ich mich ein wenig näher mit der Alibaba Cloud beschäftigt. Für heute soll es genügen mit dieser Geschichte vom Zyklus von statischen Webseiten, dynamischen Webseiten wieder hin zu statischen Webseiten, die jedoch – soviel sei verraten – durch ein wenig Dynamik später noch ergänzt werden. Im nächsten Teil werde ich erstmal meinen Weg bzw. die ersten Schritte durch die Alibaba Cloud schildern, immer mit dem Ziel vor Augen, auch native Cloud-Dienste nutzen zu wollen, d.h. nicht etwa nur einen virtuellen Server mitsamt Web-Server zu verwenden – das wäre ja viel zu klassisch und irgendwie langweilig.
