Ewolucja sieci Web: od CGI do Websockets (i jak pomoże Ci to lepiej monitorować infrastrukturę chmurową)

W ciągu ostatnich kilku lat, websockets stały się mniej więcej standardowym komponentem we wszystkich nowoczesnych aplikacjach internetowych, ale dlaczego tak się stało i jak do tego doszliśmy? Co ważniejsze, w jaki sposób websockets mogą pomóc w skuteczniejszym monitorowaniu infrastruktury chmurowej?

Ze względu na techniczny charakter tego tematu można by bardzo głęboko zagłębić się w szczegóły. Postaram się jednak utrzymać dyskusję na stosunkowo ogólnym poziomie i skupić się na korzyściach dla użytkowników naszej infrastruktury chmurowej.

Stary sposób działania

W początkach internetu wszystko było statyczne. Jeśli zachodziła potrzeba interakcji z serwerem (poza wyrenderowaniem statycznej strony), należało uruchomić jakiś skrypt CGI. Typowym tego przykładem był zapis do newslettera. Wpisywało się swój adres e-mail, naciskało „wyślij”, a następnie pojawiała się osobna strona, która przetwarzała te dane. To z kolei był skrypt, który pobierał wprowadzone dane i przetwarzał je na serwerze.

Do lat 90. skryptowanie po stronie serwera znacząco ewoluowało. Technologia ta przeszła drogę od wykonywania prostych zadań do tworzenia w pełni dynamicznych stron. Języki programowania takie jak PHP, oraz bardziej zaawansowane technologie po stronie serwera, takie jak mod_perl, umożliwiły znacznie bardziej wyrafonowane programowanie sieciowe. Choć technologie te były znaczące, nadal opierały się na koncepcji generowania strony podczas jej ładowania. Po załadowaniu użytkownik musiał odświeżyć całą stronę, aby zaktualizować zawartość.

Wraz z rozwojem sieci wkroczyliśmy w AJAX/Web 2.0-erę lat ’00, strony internetowe stały się znacznie bardziej dynamiczne i responsywne. Nie trzeba już było odświeżać strony, aby zaktualizować zawartość na ekranie. Wystarczyło wywołać pewne akcje JavaScript. Wiele stron AJAX nadal było zasilanych przez PHP, ale dzięki wprowadzeniu JavaScript po stronie klienta mogły stać się bardziej dynamiczne.

Wprowadzenie AJAX

Wraz z wprowadzeniem AJAX coraz ważniejsza stawała się stała komunikacja między serwerem a klientem. Nagle pojedynczy użytkownik na danej stronie mógł generować znaczną liczbę wywołań API. Odbywało się to w sposób typu „pull” (pobieranie), co oznacza, że klient żądał aktualizacji z serwera w określonych odstępach czasu (lub na podstawie określonego działania).

Gdy wkroczyliśmy w lata ’10, powszechne stało się całkowite dzielenie stron internetowych na front-end (HTML/JavaScript/CSS) i back-end (Ruby on Rails, Django itp.), który często był hostowany na różnych serwerach. Front-end komunikował się z back-endem za pośrednictwem API. Front-end był mniej więcej statyczny. Przy tym trendzie wykonywanie wywołań API do serwera stało się wąskim gardłem. Jeśli trzeba było pobrać dziesięć różnych rzeczy z serwera, często oznaczało to konieczność wykonania dziesięciu różnych wywołań API, z których każde niosło ze sobą znaczne narzuty i opóźnienia.

Nowoczesny sposób

Aby rozwiązać ten problem opóźnień i narzutów, w ramach HTML5 wprowadzono websockets, które zaimplementowano we wszystkich nowoczesnych przeglądarkach. W przeciwieństwie do tradycyjnego podejścia „pull” (tj. klient pytający serwer o zmiany), websocket jest – jak sama nazwa wskazuje – gniazdem (socket), przez które serwer może „pchać” (push) zmiany do klienta. Stąd, jeśli nie ma żadnych zmian, nie ma potrzeby jakiejkolwiek komunikacji. Ponadto, ponieważ klient może komunikować się bezpośrednio z serwerem bez dodatkowego narzutu związanego z otwieraniem i zamykaniem połączeń, aplikacja staje się znacznie bardziej responsywna.

Dokładnie tak zbudowana jest nasza własna web application. Sama aplikacja to statyczna strona, która otwiera połączenie websocket z API. Po otwarciu tego gniazda aplikacja internetowa może otrzymywać z serwera powiadomienia o zmianach. Nadal wysyłamy polecenia do RESTful API, ale powiadomienia wypychamy z serwera do klienta za pomocą websocketa.

Nie tylko dla stron internetowych

Podczas gdy najbardziej oczywistym przypadkiem otrzymywania aktualizacji za pomocą websocketa jest przeglądarka, istnieją również inne przypadki. Być może piszesz narzędzie, które monitoruje zmiany w Twojej architekturze i na tej podstawie uruchamia działania. W takim przypadku możesz znacznie przyspieszyć swoją aplikację, korzystając z naszego websocketa.

W naszej bibliotece Pythona, pycloudsigma, mamy wbudowane wsparcie dla websocketów. Mamy nawet prosty przykład, jak można to wykorzystać do monitorowania aktywności websocketów za pomocą zaledwie kilku linii kodu. Oto krótka demonstracja monitor_websocket_activity.py monitorującego działania wywołane przez dane wejściowe użytkownika w aplikacji internetowej.
Aby uzyskać więcej informacji o naszych usługach, sprawdź nasze Funkcje.