Kluczowe punkty

• Od kilku lat obiecywano nam, że serverless computing (serverless) otworzy nową erę bez konkretnego systemu operacyjnego do uruchamiania aplikacji. Powiedziano nam, że taka struktura rozwiąże wiele problemów ze skalowalnością. W rzeczywistości wszystko jest inne.
• Chociaż wielu postrzega technologię bezserwerową jako nowy pomysł, jej korzenie sięgają 2006 roku wraz z Zimki PaaS i Google App Engine, które wykorzystują architekturę bezserwerową.
• Istnieją cztery powody, dla których rewolucja bezserwerowa utknęła w martwym punkcie — od ograniczonej obsługi języków programowania po problemy z wydajnością.
• Przetwarzanie bezserwerowe nie jest wcale takie bezużyteczne. Daleko stąd. Nie należy ich jednak postrzegać jako bezpośredniego zamiennika serwerów. W przypadku niektórych aplikacji mogą być przydatnym narzędziem.

Serwer umarł, niech żyje serwer!

To jest okrzyk bojowy zwolenników bezserwerowej rewolucji. Szybki rzut oka na prasę branżową z ostatnich kilku lat wystarczy, aby stwierdzić, że tradycyjny model serwerowy umarł i że za kilka lat wszyscy będziemy korzystać z architektur bezserwerowych.

Jak wie każdy w branży, jak również wskazaliśmy w naszym artykule na temat stan przetwarzania bezserwerowego, To jest źle. Mimo wielu artykułów merytorycznych bezserwerowa rewolucja, to nigdy nie miało miejsca. W rzeczywistości, pokazują ostatnie badaniaże ta rewolucja znalazła się w ślepym zaułku.

Niektóre obietnice dotyczące modeli bezserwerowych z pewnością się spełniły, ale nie wszystkie. Nie każdy.

W tym artykule chcę rozważyć przyczyny tego stanu. Dlaczego brak elastyczności modeli serverless wciąż stanowi przeszkodę w ich szerszej adopcji, chociaż pozostają one przydatne w konkretnych, dobrze zdefiniowanych okolicznościach.

Co obiecywali adepci serverless computing

Zanim przejdziemy do problemów związanych z przetwarzaniem bezserwerowym, zobaczmy, co mieli do zaoferowania. Obietnice rewolucji bezserwerowej były liczne i – czasami – bardzo ambitne.

Dla tych, którzy nie znają tego terminu, oto krótka definicja. Przetwarzanie bezserwerowe definiuje architekturę, w której aplikacje (lub części aplikacji) działają na żądanie w środowiskach wykonawczych, które zazwyczaj są hostowane zdalnie. Ponadto można hostować systemy bezserwerowe. Budowa solidnych systemów bezserwerowych była głównym problemem administratorów systemów i firm SaaS w ciągu ostatnich kilku lat, ponieważ (jak twierdzi) ta architektura oferuje kilka kluczowych zalet w porównaniu z „tradycyjnym” modelem klient/serwer:

1. 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 tworzą wspólny kod, przesyłają go na platformę bezserwerową i obserwują, jak działa.
2. Zasoby w frameworkach bezserwerowych są zwykle rozliczane co minutę (a nawet sekundy). Oznacza to, że klienci płacą tylko za czas rzeczywistego wykonania kodu. Wypada to korzystnie w porównaniu z tradycyjną maszyną wirtualną w chmurze, gdzie maszyna jest przez większość czasu bezczynna, ale trzeba za nią zapłacić.
3. Rozwiązany został również problem skalowalności. Zasoby w frameworkach bezserwerowych są przydzielane dynamicznie, dzięki czemu system z łatwością radzi sobie z nagłymi skokami zapotrzebowania.

Krótko mówiąc, modele bezserwerowe zapewniają elastyczne, tanie i skalowalne rozwiązania. Dziwię się, że nie wpadliśmy na ten pomysł wcześniej.

Czy to naprawdę nowy pomysł?

Właściwie pomysł nie jest nowy. Koncepcja pozwalająca użytkownikom płacić tylko za czas rzeczywistego działania kodu istnieje od czasu jej wprowadzenia Zimki PaaS w 2006 roku, mniej więcej w tym samym czasie, Google App Engine wymyślił bardzo podobne rozwiązanie.

W rzeczywistości to, co obecnie nazywamy modelem „bezserwerowym”, jest starsze niż wiele technologii nazywanych obecnie „natywnymi w chmurze”, które zapewniają prawie to samo. Jak wspomniano, modele bezserwerowe są zasadniczo tylko rozszerzeniem modelu biznesowego SaaS, który istnieje od dziesięcioleci.

Warto również zauważyć, że model serverless nie jest architekturą FaaS, chociaż istnieje między nimi związek. FaaS jest zasadniczo zorientowaną na obliczenia częścią architektury bezserwerowej, ale nie reprezentuje całego systemu.

Więc po co ten cały szum? Cóż, w miarę jak tempo penetracji Internetu w krajach rozwijających się gwałtownie rośnie, rośnie również zapotrzebowanie na zasoby obliczeniowe. Na przykład wiele krajów z szybko rozwijającymi się sektorami e-commerce po prostu nie ma infrastruktury obliczeniowej dla aplikacji na tych platformach. W tym miejscu pojawiają się płatne platformy bezserwerowe.

Problemy z modelami bezserwerowymi

Haczyk polega na tym, że modele serverless mają… problemy. Nie zrozumcie mnie źle: nie twierdzę, że same w sobie są złe lub że w pewnych okolicznościach nie zapewniają znaczącej wartości niektórym firmom. Ale główne twierdzenie „rewolucji” – że architektura bezserwerowa szybko zastąpi architekturę tradycyjną – nigdy się nie sprawdza.

Dlatego.

Ograniczona obsługa języków 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.

Uważa się, że platformy bezserwerowe obsługują większość głównych języków. AWS Lambda i Azure Functions zapewniają również opakowanie do uruchamiania aplikacji i funkcji w nieobsługiwanych językach, chociaż często wiąże się to z kosztami wydajności. Tak więc dla większości organizacji to ograniczenie zwykle nie jest wielką sprawą. Ale o to chodzi. Jedną z zalet modeli serverless ma być to, że niejasne, rzadko używane programy mogą być używane taniej, ponieważ płacisz tylko za czas ich działania. A mało znane, rzadko używane programy są często pisane w... mało znanych, rzadko używanych językach programowania.

Podważa to jedną z kluczowych zalet modelu serverless.

Wiązanie z dostawcą

Drugim problemem związanym z platformami bezserwerowymi, a przynajmniej sposobem, w jaki są one obecnie wdrażane, jest to, że zwykle nie wyglądają one podobnie na poziomie operacyjnym. Praktycznie nie ma standaryzacji w zakresie pisania funkcji, wdrażania i zarządzania. Oznacza to, że migracja funkcji z jednej platformy na drugą jest niezwykle czasochłonna.

Najtrudniejszą częścią przejścia na model bezserwerowy nie są funkcje obliczeniowe, które zwykle są tylko fragmentami kodu, ale sposób, w jaki aplikacje komunikują się z połączonymi systemami, takimi jak obiektowa pamięć masowa, zarządzanie tożsamościami i kolejki. Funkcje można przenosić, ale reszty aplikacji nie. To dokładne przeciwieństwo obiecanych tanich i elastycznych platform.

Niektórzy twierdzą, że modele bezserwerowe są nowe i nie było czasu na standaryzację ich działania. Ale nie są one tak nowe, jak zauważyłem powyżej, a wiele innych technologii chmurowych, takich jak kontenery, stało się już znacznie wygodniejszych dzięki rozwojowi i powszechnemu przyjęciu dobrych standardów.

produktywność

Wydajność obliczeniowa platform bezserwerowych jest trudna do zmierzenia, częściowo dlatego, że dostawcy mają tendencję do utrzymywania informacji w tajemnicy. Większość twierdzi, że funkcje na zdalnych, bezserwerowych platformach działają tak samo szybko, jak na serwerach wewnętrznych, z wyjątkiem kilku nieuniknionych problemów z opóźnieniami.

Jednak niektóre dowody sugerują coś innego. Funkcje, które nie były wcześniej uruchamiane na określonej platformie lub nie były uruchamiane przez jakiś czas, wymagają trochę czasu na zainicjowanie. Jest to prawdopodobnie spowodowane tym, że ich kod został przeniesiony na mniej łatwo dostępny nośnik pamięci, chociaż - podobnie jak w przypadku testów porównawczych - większość dostawców nie powie ci o przenoszeniu danych.

Oczywiście można to obejść na kilka sposobów. Jednym z nich jest optymalizacja funkcji dla dowolnego języka chmury, na którym działa Twoja platforma bezserwerowa, ale to nieco podważa twierdzenie, że te platformy są „zwinne”.

Innym podejściem jest upewnienie się, że programy o krytycznym znaczeniu dla wydajności są uruchamiane regularnie, aby były „świeże”. To drugie podejście jest oczywiście trochę sprzeczne z twierdzeniem, że platformy bezserwerowe są bardziej opłacalne, ponieważ płacisz tylko za czas działania programów. Dostawcy chmury wprowadzili nowe sposoby na ograniczenie zimnych startów, ale wielu z nich wymaga „skalowania do jednego” (skala do jednego), co podważa pierwotną wartość FaaS.

Problem zimnego startu można częściowo rozwiązać, uruchamiając we własnym zakresie systemy bezserwerowe, ale wiąże się to z kosztami i pozostaje niszową opcją dla dobrze wyposażonych zespołów.

Nie można uruchamiać całych aplikacji

Wreszcie, być może najważniejszym powodem, dla którego architektury bezserwerowe nie zastąpią w najbliższym czasie tradycyjnych modeli, jest to, że (ogólnie) nie mogą uruchamiać całych aplikacji.

Mówiąc dokładniej, jest to niepraktyczne z punktu widzenia kosztów. Twój odnoszący sukcesy monolit prawdopodobnie nie powinien zostać przekształcony w zestaw czterech tuzinów funkcji powiązanych ze sobą przez osiem bramek, czterdzieści kolejek i tuzin instancji bazy danych. Z tego powodu serwer bez serwera lepiej nadaje się do nowych rozwiązań. Praktycznie żadna istniejąca aplikacja (architektura) nie może zostać przeniesiona. Możesz migrować, ale musisz zacząć od zera.

Oznacza to, że w zdecydowanej większości przypadków platformy bezserwerowe są wykorzystywane jako uzupełnienie serwerów zaplecza do wykonywania zadań wymagających dużej mocy obliczeniowej. Różni się to bardzo od pozostałych dwóch form przetwarzania w chmurze, kontenerów i maszyn wirtualnych, które oferują holistyczny sposób wykonywania zdalnych obliczeń. Ilustruje to jedno z wyzwań związanych z migracją z mikrousług do systemów bezserwerowych.

Oczywiście nie zawsze jest to problem. Możliwość okresowego korzystania z ogromnych zasobów obliczeniowych bez kupowania własnego sprzętu może przynieść realne i trwałe korzyści wielu organizacjom. Ale jeśli niektóre aplikacje znajdują się na serwerach wewnętrznych, a inne na bezserwerowych architekturach chmurowych, zarządzanie wkracza na nowy poziom złożoności.

Niech żyje rewolucja?

Pomimo tych wszystkich skarg, nie jestem przeciwnikiem rozwiązań bezserwerowych jako takich. Szczerze mówiąc. Po prostu programiści muszą zrozumieć – zwłaszcza jeśli po raz pierwszy badają modele bezserwerowe – że ta technologia nie jest bezpośrednim zamiennikiem serwerów. Zamiast tego zapoznaj się z naszymi wskazówkami i zasobami tworzenie aplikacji bezserwerowych i zdecydować, jak najlepiej zastosować ten model.

Źródło: www.habr.com