Kluczowe punkty
- Od kilku lat obiecuje się nam, że obliczenia bezserwerowe (serverless) otworzą nową erę bez konkretnych systemów operacyjnych do uruchamiania aplikacji. Mówiono nam, że taka struktura rozwiąże wiele problemów z skalowalnością. W rzeczywistości jest zupełnie inaczej.
- Chociaż wielu traktuje technologię bezserwerową jako nowy pomysł, jej korzenie sięgają 2006 roku, kiedy powstały Zimki PaaS i Google App Engine — w obu przypadkach używana jest architektura bezserwerowa.
- Istnieją cztery powody, dla których rewolucja bezserwerowa utknęła w martwym punkcie: od ograniczonego wsparcia języków programowania po problemy z wydajnością.
- Obliczenia bezserwerowe nie są całkowicie bezwartościowe. Wręcz przeciwnie. Jednak nie powinny być postrzegane jako bezpośredni zamiennik serwerów. Dla niektórych aplikacji mogą być wygodnym narzędziem.
Serwer umarł, niech żyje serwer!
Tak brzmi okrzyk bojowy zwolenników rewolucji bezserwerowej. Wystarczy przeszukać branżową prasę z ostatnich kilku lat, aby łatwo dojść do wniosku, że tradycyjny model serwerowy umarł i że za kilka lat wszyscy będziemy korzystać z architektur bezserwerowych.
Jak wiadomo każdemu w branży, i jak również zaznaczyliśmy w naszym artykule o , to nieprawda. Pomimo wielu artykułów o zaletach , ona nigdy nie miała miejsca. W rzeczywistości, , że ta rewolucja mogła utknąć w martwym punkcie.
Niektóre z obietnic dotyczących modeli bezserwerowych zostały niewątpliwie zrealizowane, ale nie wszystkie. Daleko nie wszystkie.
W tym artykule chcę omówić przyczyny takiego stanu. Dlaczego brak elastyczności modeli bezserwerowych wciąż stanowi przeszkodę dla ich szerszego wdrożenia, mimo że pozostają one przydatne w określonych, jasno określonych okolicznościach.
Co obiecywali zwolennicy obliczeń bezserwerowych
Zanim przejdziemy do problemów z obliczeniami bezserwerowymi, przyjrzyjmy się, co miały one zapewnić. były liczne i — czasami — bardzo ambitne.
Dla tych, którzy nie są zaznajomieni z terminem, oto krótkie określenie. Obliczenia bezserwerowe definiują architekturę, w której aplikacje (lub ich części) działają na żądanie w środowiskach wykonawczych, które zwykle są hostowane zdalnie. Ponadto systemy bezserwerowe można hostować lokalnie. W ciągu ostatnich kilku lat tworzenie niezawodnych systemów bezserwerowych było główną troską administratorów systemów oraz firm SaaS, ponieważ (jak się twierdzi) ta architektura oferuje szereg kluczowych zalet w porównaniu do „tradycyjnego” modelu klient-serwer:
- Modele bezserwerowe nie wymagają, aby użytkownicy utrzymywali własne systemy operacyjne ani nawet tworzyli aplikacje zgodne z określonymi systemami operacyjnymi. Zamiast tego programiści tworzą ogólny kod, przesyłają go na bezserwerową platformę i obserwują jego wykonanie.
- Zasoby w bezserwerowych frameworkach są zazwyczaj rozliczane na minuty (lub nawet sekundy). Oznacza to, że klienci płacą tylko za czas, w którym ich kod rzeczywiście jest wykonywany. To znacząco różni się od tradycyjnych maszyn wirtualnych w chmurze, gdzie maszyna przez większość czasu pozostaje bezczynna, ale trzeba za nią płacić.
- Problem skalowalności również został rozwiązany. Zasoby w bezserwerowych frameworkach są przydzielane dynamicznie, dzięki czemu system łatwo radzi sobie z nagłymi wzrostami zapotrzebowania.
Krótko mówiąc, modele bezserwerowe zapewniają elastyczne, tanie i skalowalne rozwiązania. Zdumiała, że nie wpadliśmy na ten pomysł wcześniej.
Czy to naprawdę nowy pomysł?
W rzeczywistości pomysł nie jest nowy. Koncepcja, która pozwala użytkownikom płacić tylko za czas, w którym kod naprawdę działa, istnieje od chwili wprowadzenia jej w ramach w 2006 roku, i mniej więcej w tym samym czasie Google App Engine zaproponował bardzo podobne rozwiązanie.
To, co obecnie nazywamy modelem „bezserwerowym”, jest starsze od wielu technologii, które dziś określamy jako „natywne w chmurze”, i które oferują niemal to samo. Jak już wspomniano, modele bezserwerowe są w zasadzie jedynie kontynuacją modelu biznesowego SaaS, który istnieje już od kilku dziesięcioleci.
Należy również przyznać, że model bezserwerowy nie jest architekturą FaaS, chociaż istnieje między nimi związek. FaaS to w zasadzie zorientowana na obliczenia część architektury bezserwerowej, ale nie stanowi całości systemu.
Do czego więc cała ta wrzawa? Cóż, ponieważ szybkość penetracji internetu w krajach rozwijających się wciąż rośnie, równocześnie zwiększa się zapotrzebowanie na zasoby obliczeniowe. Na przykład w wielu krajach z szybko rozwijającymi się sektorami e-commerce po prostu brakuje infrastruktury obliczeniowej dla aplikacji na tych platformach. Tu właśnie pojawiają się płatne platformy bezserwerowe.
Problemy modeli bezserwerowych
Problem w tym, że modele bezserwerowe mają… problemy. Nie zrozumcie mnie źle: nie twierdzę, że są same w sobie złe lub nie zapewniają istotnej wartości dla niektórych firm w niektórych okolicznościach. Ale główne twierdzenie o „rewolucji” — że architektura bezserwerowa szybko zastąpi tradycyjną — nigdy się nie zrealizuje.
Oto dlaczego.
Ograniczona obsługa języków programowania
Większość platform bezserwerowych pozwala uruchamiać tylko te aplikacje, które są napisane w określonych językach. To poważnie ogranicza elastyczność i adaptacyjność tych systemów.
Uważa się, że platformy bezserwerowe obsługują większość podstawowych języków. AWS Lambda i Azure Functions oferują również powłokę do uruchamiania aplikacji i funkcji w nieobsługiwanych językach, chociaż często wiąże się to z kosztami wydajności. Dla większości organizacji zazwyczaj to ograniczenie nie ma dużego znaczenia. Ale oto w czym rzecz. Zakłada się, że jednym z zalet modeli bezserwerowych jest to, że mało znane, rzadko używane programy można uruchamiać taniej, ponieważ płacisz tylko za czas ich wykonania. A mało znane, rzadko używane programy często pisane są w… mało znanych, rzadko używanych językach programowania.
To podważa jedną z kluczowych zalet modelu bezserwerowego.
Uzależnienie od dostawcy
Drugą kwestią dotyczącą platform bezserwerowych, lub przynajmniej ich obecnej realizacji, jest to, że zazwyczaj różnią się one od siebie 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ą zajmuje niezwykle dużo czasu.
Najtrudniejszą częścią przejścia na model bezserwerowy nie są funkcje obliczeniowe, które zazwyczaj są po prostu fragmentami kodu, ale to, jak aplikacje są powiązane z systemami zewnętrznymi, takimi jak przechowywanie obiektów, zarządzanie tożsamością i kolejki. Funkcje można przenieść, ale reszty aplikacji już nie. To całkowita odwrotność obiecywanych tanich i elastycznych platform.
Niektórzy twierdzą, że modele bezserwerowe pojawiły się niedawno i nie było czasu na ich standaryzację. Jednak nie są one tak nowe, jak już wspomniałem, a wiele innych technologii chmurowych, takich jak kontenery, stało się znacznie bardziej przyjaznych dzięki opracowaniu i powszechnemu wdrożeniu dobrych standardów.
Wydajność
Wydajność obliczeniowa platform bezserwerowych jest trudna do zmierzenia, częściowo dlatego, że dostawcy starają się ukryć informacje. Większość twierdzi, że funkcje na zdalnych, bezserwerowych platformach działają tak samo szybko, jak na serwerach lokalnych, z wyjątkiem kilku nieuniknionych problemów z opóźnieniem.
Jednak pojedyncze fakty sugerują coś przeciwnego. Funkcje, które wcześniej nie były uruchamiane na określonej platformie lub nie były uruchamiane przez pewien czas, wymagają pewnego czasu na inicjalizację. Prawdopodobnie jest to związane z tym, że ich kod został przeniesiony na jakiś mniej dostępny nośnik danych, chociaż – jak w przypadku benchmarków – większość dostawców nie powie wam o przeniesieniu danych.
Oczywiście istnieje kilka sposobów, aby to obejść. Jednym z nich jest optymalizacja funkcji dla każdego języka chmurowego, na którym działa wasza platforma bezserwerowa, ale to częściowo podważa twierdzenie, że te platformy są „elastyczne”.
Innym podejściem jest zapewnienie regularnego wykonywania programów krytycznych dla wydajności, aby pozostały one „świeże”. To drugie podejście nieco stoi w sprzeczności z twierdzeniem, że platformy bezserwerowe są bardziej opłacalne, ponieważ płacisz tylko za czas działania swoich programów. Dostawcy chmury wprowadzili nowe sposoby na skrócenie zimnych uruchomień, ale wiele z nich wymaga „skalowania do jednego”, co podważa początkową wartość FaaS.
Problem „zimnego uruchomienia” można częściowo rozwiązać poprzez uruchamianie systemów bezserwerowych we własnym zakresie, ale wiąże się to z dodatkowymi kosztami i pozostaje niszową opcją dla dobrze wyposażonych zespołów.
Nie możesz uruchamiać całych aplikacji
W końcu być może najważniejszym powodem, dla którego architektury bezserwerowe nie zastąpią tradycyjnych modeli w najbliższym czasie, jest to, że nie można na nich (z reguły) uruchamiać całych aplikacji.
Mówiąc dokładniej, jest to nieopłacalne z punktu widzenia kosztów. Twój udany monolit prawdopodobnie nie jest wart przekształcania w zestaw czterdziestu funkcji, powiązanych ośmioma bramkami, czterdziestoma kolejkami i tuzinami instancji baz danych. Z tego powodu bezserwerowość lepiej nadaje się do nowych projektów. Praktycznie żadna istniejąca aplikacja (architektura) nie może zostać przeniesiona. Możesz migrować, ale będziesz musiał zaczynać od zera.
Oznacza to, że w przytłaczającej większości przypadków platformy bezserwerowe są wykorzystywane jako uzupełnienie wewnętrznych serwerów do wykonywania zadań wymagających dużych obliczeń. To bardzo różni je od dwóch innych form technologii chmurowych — kontenerów i maszyn wirtualnych, które oferują spójną metodę wykonywania zdalnych obliczeń. Ilustruje to jedną z trudności przejścia od mikroserwisów do systemów bezserwerowych.
Oczywiście, nie zawsze stanowi to problem. Możliwość okresowego korzystania z ogromnych zasobów obliczeniowych, bez konieczności zakupu własnego sprzętu, może przynieść realne i długoterminowe korzyści dla wielu organizacji. Jednak gdy niektóre aplikacje są na serwerach lokalnych, a inne na architekturach bezserwerowych, zarządzanie staje się znacznie bardziej skomplikowane.
Niech żyje rewolucja?
Pomimo wszystkich tych skarg nie jestem przeciwny rozwiązaniom bezserwerowym jako takim. Na słowo honoru. Po prostu deweloperzy 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 poradami i zasobami dotyczących i zdecyduj, jak najlepiej zastosować ten model.
Źródło: habr.com
