Der Kern einer Backend-Umgebung besteht darin, Daten zuverlässig an Nutzer zu übermitteln. Dafür sind drei zentrale Elemente unverzichtbar: Webserver, WAS und Datenbank. Diese drei haben sich weiterentwickelt, um Probleme zu lösen, die im Verlauf der Entwicklung des Webs entstanden sind. Fortgeschrittene Technologien wie Monitoring, Load Balancing, Caching, CI/CD-Pipelines und Kubernetes sind vergleichbar mit einem Haus, das jederzeit einstürzen kann, wenn nicht zuerst das Verständnis dieser drei Elemente vorhanden ist.
Erstens: die Rolle des Webservers
Die Hauptaufgabe eines Webservers war die eines Dateiservers, der Dateien ausliefert; bekannte Webserver sind etwa Nginx, Apache, IIS und Caddy. Solche Webserver konzentrieren sich auf ihre Grundfunktion, statische Dateien bereitzustellen, und sind dafür hochgradig optimiert.
Zweitens: das Aufkommen und die Rolle von WAS (Web Application Server)
Ein WAS arbeitet so, dass es bei einer bestimmten Anfrage ein zuvor festgelegtes Programm ausführt und das von diesem Programm erzeugte Ergebnis an den Nutzer ausgibt. Diese Arbeitsweise kann man als die eigentliche Geburtsstunde des Backends bezeichnen: der Moment, in dem ein Server nicht mehr nur Dateien ausgibt, sondern beginnt zu denken, zu rechnen und Logik zu verarbeiten. Ein Webserver liefert immer dieselbe statische Seite zurück, ein WAS hingegen dynamische Seiten.
Drittens: die Notwendigkeit und Rolle der Datenbank
Eine Datenbank übernimmt die Aufgabe, Daten dauerhaft zu speichern, sicher zu verwalten und gleichzeitige Zugriffe zu kontrollieren.
Darüber hinaus sind für die Backend-Planung weitere Themen sehr hilfreich, darunter das Design von RESTful APIs (ressourcenorientiertes URL-Design, die Bedeutung von HTTP wie GET, POST, PUT, DELETE usw., die Verwendung von Statuscodes sowie API-Designprinzipien auf Basis des REST-Architekturstils), Authentifizierung (grundlegendes Verständnis von Benutzerauthentifizierung und Autorisierung wie sitzungsbasierter Authentifizierung sowie die Festlegung von Richtlinien für die Benutzerverwaltung) und Fehlerbehandlung (Konzepte für die Behandlung unverzichtbarer Ausnahmefälle zur Sicherstellung der Systemstabilität).
8 Kommentare
Die Leute glauben wohl, dass Backends auf der Welt nur Webprotokolle verwenden.
Wenn von den drei Kernelementen des Backends die Rede ist und dann ein Webserver auftaucht, wird mir ganz schwindelig.
ALB oder ein CDN übernehmen doch bereits all die Aufgaben, die man sich sonst vom Webserver wünschen würde. Ich verstehe daher nicht, warum man unbedingt daran festhalten sollte. Habt ihr vielleicht konkrete Sicherheitsfälle erlebt, die sich tatsächlich nur deshalb abwehren ließen, weil ein Webserver vorhanden war?
Wenn das ALB funktional den Webserver ersetzt und Benutzer nicht direkt auf das Backend wie etwa den WAS zugreifen können, dann kann man davon ausgehen, dass die bestehende Sicherheitsumgebung die Anforderungen erfüllt. Und viele Services laufen nach wie vor in einer On-Premises-Umgebung.
Unter Sicherheitsaspekten denke ich nach wie vor, dass eine Trennung von Web Server und WAS-Server notwendig ist. Auch in einer Cloud-native-Umgebung ändert sich daran nichts. Backends wie ein WAS sollten sich nicht auf einer Ebene befinden, zu der Nutzer direkt eine Verbindung herstellen können.
Ist es immer noch sinnvoll, die Konzepte von Webserver und WAS zu kennen?
In der Zeit, als Java EE, PHP und CGI populär waren, war das eine angemessene Unterscheidung. Heute bringen jedoch die meisten gängigen Sprachen bereits einen eigenen HTTP-Server mit, und mit dem Aufkommen und der alltäglichen Nutzung von Konzepten wie ALB, API Gateway, CDN und Object Storage haben sich die Zeiten geändert.
Ohne den historischen Kontext erscheinen mir die Konzepte von Web Server und WAS, die sich stark von der heutigen Realität unterscheiden, inzwischen eher unpassend und für Einsteiger eher verwirrend als hilfreich.
Im Fintech-Bereich gibt es aufgrund der Sicherheitsanforderungen nach wie vor viele Umgebungen, in denen Web und WAS getrennt sind. Da man nie weiß, in welcher Umgebung man landet, halte ich es für richtig, auf alles vorbereitet zu sein, haha.
Auch in der heutigen Cloud-Umgebung wird dies verwendet, um für die Verarbeitung großer Datenmengen mehrere WAS innerhalb einer einzelnen Instanz effizient zu balancieren.
Wenn es nur wenige Netzwerkanfragen gibt, ist es vielleicht nicht nötig.
Ich stimme zu. Es wäre wohl praktischer, die 12-Factor-App-Prinzipien und Cloud-native-Muster zu vermitteln. Das Konzept selbst ist einfach zu veraltet.