Bezserwerowa rewolucja jakby nieco ostatnio przyhamowała.

Wieszczony zmierzch przetwarzania bezserwerowego

Od kilku lat niektórzy przewidują, że przetwarzanie bezserwerowe zapoczątkuje nową erę, bez systemu operacyjnego do wykonywania aplikacji a przez to z rozwiązanymi wieloma problemami dotyczącymi skalowalności. Korzenie technologii sięgają aż do 2006 roku (Zimki PaaS i Google App Engine). Niektóre z obietnic złożonych dla modeli bezserwerowych bez wątpienia zostały zrealizowane, ale nie wszystkie. W roku 2020 możemy co najwyżej stwierdzić, że rewolucja przyhamowała i są ku temu co najmniej cztery powody.

Obietnice były szumne

Modele bezserwerowe są bardzo przydatne w określonych, dobrze zdefiniowanych okolicznościach, wydaje się jednak, że brak zwinności i elastyczności tych systemów nadal stanowi przeszkodę dla ich szerszego zastosowania. Przetwarzanie bezserwerowe odnosi się do architektury, w której aplikacje (lub ich części) działają na żądanie w środowiskach wykonawczych, które są zwykle hostowane zdalnie. Oczywiście możliwe jest również hostowanie systemów bezserwerowych we własnym zakresie.

Modele bezserwerowe nie wymagają od użytkowników utrzymywania własnych systemów operacyjnych ani nawet tworzenia aplikacji zgodnych z określonymi systemami operacyjnymi. Zamiast tego programiści mogą tworzyć kod ogólny, a następnie przesyłać go do struktury bezserwerowej i oglądać, jak działa. Zasoby używane w platformach bezserwerowych są zwykle opłacane według minuty (lub nawet sekundy). Oznacza to, że klienci płacą tylko za czas, w którym faktycznie wykonują kod. Główną atrakcją jest również skalowalność. Zasoby w platformach bezserwerowych można przypisywać dynamicznie, co oznacza, że są one w stanie radzić sobie z nagłymi skokami popytu.

Ograniczone języki programowania

Większość platform bezserwerowych umożliwia uruchamianie tylko aplikacji napisanych w określonych językach. To poważnie ogranicza elastyczność i zdolność adaptacji tych systemów.

Owszem, większość platform bezserwerowych obsługuje większość popularnych języków. AWS Lambda i Azure Functions zapewniają również funkcjonalność opakowania (wrapping), która umożliwia uruchamianie aplikacji i funkcji w nieobsługiwanych językach, chociaż często wiąże się to z kosztami wydajności. Ale przecież jedną z zalet modeli bezserwerowych jest to, że rzadko używane programy mogą być wykorzystywane taniej, ponieważ płacisz tylko za czas ich wykonywania. A takie rzadko używane programy są często pisane… tak, w rzadziej używanych językach programowania. Podważa to jedną z kluczowych zalet modelu bezserwerowego.

Sprawdź oferty pracy na TeamQuest

Blokada dostawcy

Drugi problem związany z platformami bezserwerowymi polega na tym, że niewiele platform jest do siebie podobnych na poziomie operacyjnym. Istnieje niewielka standaryzacja między platformami a to oznacza, że migracja funkcji z jednej platformy specyficznej dla dostawcy na inną jest niezwykle czasochłonna.

Najtrudniejszą częścią migracji do bezserwerowej nie są funkcje obliczeniowe - które zazwyczaj są tylko fragmentami kodu - ale sposób, w jaki aplikacje są splątane z połączonymi systemami, takimi jak przechowywanie obiektów, zarządzanie tożsamością i kolejki. Funkcje można przenosić, ale reszta aplikacji nie jest tak przenośna. To przeciwieństwo tanich, zwinnych platform, które nam obiecano.

Wydajność

Wydajność obliczeniowa platform bezserwerowych może być trudna do zmierzenia, częściowo dlatego, że firmy sprzedające te usługi mają żywotny interes w ukrywaniu tych informacji. Funkcje, które wcześniej nie były uruchamiane na określonej platformie lub nie były uruchamiane przez jakiś czas, wymagają trochę czasu na zainicjowanie – przynajmniej tak wynika z wielu anegdot, jakie można odnaleźć w sieci. Dzieje się tak prawdopodobnie dlatego, że ich kod został przeniesiony na mniej dostępny nośnik pamięci, chociaż - podobnie jak w przypadku statystyk wydajności - większość dostawców komputerów bezserwerowych nie ujawni, jeśli tak rzeczywiście jest.

Dostawcy usług w chmurze wprowadzili nowe sposoby ograniczania zimnych startów, ale wielu z nich wymaga modelu „skali do jednego”, który podważa początkową wartość FaaS. Z kolei uruchomienie systemów bezserwerowych we własnym zakresie wiąże się z własnymi kosztami i pozostaje niszową opcją.

Nie możesz uruchomić całych aplikacji

Wreszcie, być może najważniejszy powód, dla którego architektury bezserwerowe nie zamierzają w najbliższym czasie zastąpić tradycyjnych modeli: generalnie nie można uruchamiać całych aplikacji na systemach bezserwerowych. Oznacza to, że w zdecydowanej większości przypadków platformy bezserwerowe są używane jako dodatek do serwerów wewnętrznych do wykonywania zadań wymagających dużej ilości zasobów obliczeniowych.

Oczywiście niekoniecznie jest to problem. Możliwość sporadycznego korzystania z ogromnych zasobów obliczeniowych bez płacenia za sprzęt niezbędny do osiągnięcia tego we własnym zakresie może przynieść realne i trwałe korzyści w wielu organizacjach. Jednak zarządzanie sposobem, w jaki działają aplikacje, z częściami tego na serwerach wewnętrznych i innymi częściami działającymi na bezserwerowych architekturach chmury, może przynieść kolejny poziom złożoności wdrażania tych aplikacji.