Web-Evolution: von CGI zu Websockets (und wie es Ihnen hilft, Ihre Cloud-Infrastruktur besser zu überwachen)

In den letzten Jahren Websockets sind mehr oder weniger zu einer Standardkomponente in allen modernen Webanwendungen geworden, aber warum ist das so und wie sind wir hierher gekommen? Und was noch wichtiger ist: Wie können Websockets Ihnen helfen, Ihre Cloud-Infrastruktur effektiver zu überwachen?

Aufgrund der technischen Natur dieses Themas ist es möglich, sehr tief in die Details einzutauchen. Aber ich werde versuchen, die Dinge auf einer relativ hohen Ebene zu halten und mich auf die Vorteile für unsere Cloud-Infrastruktur-Nutzer zu konzentrieren.

Die alte Herangehensweise

In den Anfangstagen des Webs war alles statisch. Wenn man mit einem Server interagieren musste (über das Rendern einer statischen Seite hinaus), musste man eine Art CGI-Skript ausführen. Ein typisches Beispiel dafür war etwa die Anmeldung für eine Mailingliste. Sie geben Ihre E-Mail-Adresse ein und drücken auf „Absenden“, woraufhin eine separate Seite angezeigt wird, die die Daten verarbeitet. Dies wiederum war ein Skript, das die Eingabe entgegennahm und auf dem Server verarbeitete.

In den 90er Jahren hatte sich das serverseitige Scripting erheblich weiterentwickelt. Die Technologie hatte sich von der Ausführung einfacher Aufgaben zur Erstellung vollständig dynamischer Seiten entwickelt. Programmiersprachen wie PHP, und fortschrittlichere serverseitige Technologien wie mod_perl, ermöglichten eine weitaus anspruchsvollere Webprogrammierung. Obwohl diese Technologien bedeutend waren, drehten sie sich immer noch um das Konzept der Seitengenerierung beim Laden. Einmal geladen, musste man die gesamte Seite neu laden, um den Inhalt zu aktualisieren.

Mit der Weiterentwicklung des Webs traten wir in die AJAX/Web 2.0-Ära der ’00er Jahre ein, Webseiten wurden viel dynamischer und reaktionsschneller. Man musste die Seite nicht mehr neu laden, um den Inhalt auf dem Bildschirm zu aktualisieren. Alles, was man tun musste, war, einige JavaScript-Aktionen auszulösen. Viele AJAX-Seiten wurden immer noch mit PHP betrieben, konnten aber durch die Einführung von clientseitigem JavaScript dynamischer gestaltet werden.

Einführung von AJAX

Mit der Einführung von AJAX wurde die kontinuierliche Kommunikation zwischen Server und Client immer wichtiger. Plötzlich konnte eine erhebliche Anzahl von API-Aufrufen von einem einzelnen Benutzer auf einer bestimmten Seite generiert werden. Wir tun dies im „Pull“-Verfahren, was bedeutet, dass der Client in einem bestimmten Intervall (oder basierend auf einer Aktion) Aktualisierungen vom Server anfordert.

Als wir in die ’10er Jahre eintraten, war es üblich, dass Webseiten vollständig zwischen dem Frontend (HTML/JavaScript/CSS) und dem Backend (Ruby on Rails, Django usw.) aufgeteilt waren, die oft auf verschiedenen Servern gehostet wurden. Die Kommunikation des Frontends mit dem Backend erfolgte über eine API. Das Frontend war mehr oder weniger statisch. Mit diesem Trend wurde das Tätigen von API-Aufrufen an den Server zu einem erheblichen Engpass. Wenn man zehn verschiedene Dinge vom Server abrufen musste, bedeutete dies oft, dass man zehn verschiedene API-Aufrufe durchführen musste, wobei jeder Aufruf einen erheblichen Overhead und Latenzzeiten mit sich brachte.

Der moderne Weg

Um dieses Problem von Latenz und Overhead zu lösen, wurden Websockets als Teil von HTML5 eingeführt und in allen modernen Browsern implementiert. Im Gegensatz zum traditionellen „Pull“-Ansatz (d. h. der Client fragt den Server nach Änderungen) ist ein Websocket, wie der Name schon sagt, ein Socket, über den der Server Änderungen an den Client „pushen“ kann. Wenn es also keine Änderungen gibt, ist auch keine Kommunikation erforderlich. Da der Client außerdem direkt mit dem Server kommunizieren kann, ohne den zusätzlichen Overhead des Öffnens und Schließens von Verbindungen, wird die Anwendung viel reaktionsschneller.

Genau so ist unsere eigene Webanwendung aufgebaut. Die eigentliche Anwendung ist eine statische Seite, die eine Websocket-Verbindung zur API öffnet. Sobald dieser Socket geöffnet ist, kann die Webanwendung Benachrichtigungen über Änderungen vom Server empfangen. Wir senden weiterhin Befehle an die RESTful API, aber wir pushen Benachrichtigungen über den Websocket vom Server an den Client.

Nicht nur für Webseiten

Während der offensichtlichste Fall für den Empfang von Updates über einen Websocket ein Browser ist, gibt es auch andere Fälle. Vielleicht schreiben Sie ein Tool, das Änderungen an Ihrer Architektur überwacht und darauf basierend Aktionen auslöst. In diesem Fall können Sie Ihre Anwendung erheblich beschleunigen, indem Sie unseren Websocket nutzen.

In unserer Python-Bibliothek, pycloudsigma, haben wir eine integrierte Unterstützung für Websockets. Wir haben sogar ein einfaches Beispiel dafür, wie Sie dies nutzen können, um Websocket-Aktivitäten mit nur wenigen Zeilen Code zu überwachen. Hier ist eine kurze Demo von monitor_websocket_activity.py, das die durch die Benutzereingabe in der Web-App ausgelösten Aktionen überwacht.
Für weitere Informationen zu unseren Dienstleistungen werfen Sie einen Blick auf unsere Features.