Coraz częściej i głośniej w naszej branży wybrzmiewa pojęcie Serverless. Jak to zwykle bywa gdy o czymś zaczyna być głośniej na konferencjach, blogach, tweetach i w kuluarach, to urasta to do miana buzzwordu. Większość z nas lubi posługiwać się buzzwordami, często nawet nieświadomie. Kojarzą się one często z nowoczesnymi trendi technologiami, innowacyjnymi konceptami, bądź po prostu są powiewem świeżości. Tak też jest z Serverless. Jest to stosunkowo świeża technologia, która ma za zadanie zmienić podejście i sposób w jaki wytwarzamy oprogramowanie. Można powiedzieć, że ma ona w sobie coś innowacyjnego, gdyż stoi w opozycji do tradycyjnego sposobu budowania aplikacji. Ale o tym więcej w dalszej części artykułu.
Czym wyróżnia się Serverless ?
We wcześniejszych czasach internetu, gdy chcieliśmy uruchomić jakąś aplikację webową, potrzebowaliśmy fizycznego serwera, którego trzeba było zakupić a później utrzymywać. Później pojawiła się chmura, która umożliwiła dzierżawienie serwerów wirtualnych od dostawcy. Od tego momentu firmy nie musiały już wydawać kupę kasy na budowanie serwerowni. Mimo iż można było uruchamiać dowolną liczbę serwerów i korzystać z takich rozwiązań jak automatyczne skalowanie, to i tak zazwyczaj programiści przeszacowywali z zamawianą mocą w efekcie czego słabo utylizowali uruchomione maszyny. I tutaj właśnie cały na biało wjeżdża Serverless z modelem rozliczeniowym Pay-as-you-go. Co to oznacza ? Oznacza to, że płacimy tylko i wyłącznie za wykorzystywaną moc obliczeniową. Nasza aplikacja obsługuje ruch, wykonuje obliczenia, operacje na bazie – płacimy. Aplikacja jest nieużywana – nie płacimy. Brzmi idealnie, prawda ? Co więcej, nie musimy się już martwić o estymację naszej infrastruktury. W serverless myślimy bardziej w kategoriach ile pamięci potrzebuje nasz kod (funkcja) a nie w kategorii jak duży serwer musimy kupić/wydzierżawić aby nasza aplikacja działałą stabilnie.
Koncepcja Serverless
Ok, określiliśmy sobie jak to wygląda z punktu widzenia rozliczeniowego, czyli aspekt, który bardziej interesuje biznes, niż nas ludzi IT. Jak to się ma do technologii ?
Nazwa Serverless, której na szczęście chyba nikt nie próbował jeszcze spolszczać może sugerować że rozwiązanie wyklucza użycie jakiegokolwiek serwera. Nie jest prawdą, że w podejściu tym serwery nie występują, bo występują, ale nie są one w tym wypadku naszym zmartwieniem.
Narzędzia cloudowe oparte o Serverless, pozwalają użytkownikowi wdrożyć i uruchomić napisany przez niego kod nie martwiąc się w jaki sposób i na jakiej infrastrukturze będzie on uruchamiany. Czyli inaczej mówiąc, nie martwimy się tutaj o te serwery, stąd ta przewrotna, za to ładnie brzmiąca nazwa – Serverless. No dobrze skoro nie my się martwimy o serwery, to kto w takim razie jest za nie odpowiedzialny ? A no nie kto inny jak dostawca chmury. Dostawca chmury w dynamiczny sposób przydziela zasoby serwerowe naszym procedurą. Gdy nasza funkcja zostaje wywoływana vendor uruchamia bezstanowy, efemeryczny kontener, który posiada zainstalowane środowisko uruchomieniowe, pozwalające wykonać kod naszej funkcji. Gdy funkcja kończy swoją pracę i nie następuje kolejne jej wywołanie, kontener zostaje ubity. Chargowani jesteśmy za wykorzystaną moc obliczeniową potrzebną do obsłużenia żądania.
Cechy usług Serverless ?
Aby nasz funkcja została wywołana musi nastąpić jakieś zdarzenie, wywołanie żadanie http, cron, pojawienie się nowego rekordu w bazie albo nowego pliku na storage. Mamy więc tutaj do czynienia z rozwiązaniem typu event-driven. Ok, a więc jakie usługi pozwalają nam budować taką zdarzeniową serverlessową architekturę. Musimy się zastanowić nad tym, co charakteryzuje usługę typu serverless.
Powiedzieliśmy sobie już o tym, że za taką usługę płacimy tylko wtedy gdy wykonuje ona dla nas określoną pracę. To na pewno pierwsza i najważniejsza cecha. Mówiliśmy też o tym, że nie musimy uruchamiać żadnego serwera, co oznacza również, że nie musimy go też konfigurować i utrzymywać. Krótko mówiąc nie interesuje nas tutaj infrastruktura. Określamy jedynie ile pamięci potrzebuje nasz kod, a dostawca sam dostosuje resztę parametrów. Jest jeszcze jedna dość istotna cecha usługi z segmentu serverless. Chodzi o automatyczną i wręcz nieograniczoną skalowalność. Czyli serverless to nie tylko wywołanie usługi na żądanie, ale również dostosowanie wydajności do określonego obciążenia. Jeśli usługa posiada te trzy cechy można o niej myśleć w kategoriach serverless.
Dostępne rozwiązania Serverless – FaaS
Opisaliśmy już sobie na czym polega i czym charakteryzują się rozwiązania Serverless. Czas na kilka przykładów. Aby troszeczkę namieszać Wam w głowach wprowadzę kilka skrótów, które krążą wokół serverless. Na początek FaaS czyli Function as a Service. To właśnie ten segment rozwiązań uważa się za czysty serverless. FaaS czyli uruchamianie kodu naszej funkcji sprzedawane jako usługa cloud providera. Wyobraźmy sobie, że mamy funkcję napisaną w Javie, która konwertuje doca do pdfa. Taką funkcję możemy wrzucić do chmury i uruchamiać ją w modelu Serverless – takie podejście śmiało możemy nazwać FaaS-em. Każdy z największych graczy oferuję w swoim portfolio takie rozwiązanie. Mamy m. in.:
Inne usługi pozwalające budować architekturę typu Serverless
Wspomniane zostało, że kontenery wykonujące nasze Serverlessowe funkcję są bezstanowe i ulotne. Jak więc tworzyć pełnoprawne aplikacje i systemy w architekturze serverless ? Każdy większy system oprócz przetwarzania danych musi w kolejnym kroku zapisać efekty swojej np gdzieś na storage’u bądź w bazie danych ? Mamy wykorzystać tutaj standardową relacyjną bazę, która uruchamiana jest na serwerze, który pracuje 24/7 ? Można oczywiście i w ten sposób, ale wtedy nie możemy mówić, że nasze rozwiązanie jest w pełni serverlessowe, co najwyżej quasi-serverless. Dobrze byłoby i w przypadku inny klocków używać tych, które charakteryzują się cechami wcześniej opisanymi. Oczywiście tutaj również dostawcy chmur otwierają przed szereg możliwości i udostępniają nam inne komponenty klasy Baas (Backend as a Service) czy SaaS (Software as a Service) w modelu serverless.
Rozróżnianie i klasyfikowanie komponentów z sufixem aaS to temat na oddzielny wpis, który już niebawem na blogu. Naprawdę można bardzo łatwo się w tym wszystkim pogubić :). Popularność określenia serverless prowadzi powoli do patologii, w której często usługodawcy na siłę próbują sprzedawać coś z etykietą serverless. Możesz to sobie wyobrazić tak:
Sprzedawcę ze sklepu AGD chce sprzedać Ci super nowoczesną lodówke Serverless, no bo przecież lodówka ta pracuje bez serwera, więc wszystko się zgadza :D. Na szczęście już sobie przybliżyliśmy cechy Serverless i wiem czym się on charakteryzuje.
Wracam więc do tematu. Czy istnieją rozwiązania typu baza danych czy system do messagingu w prawdziwym modelu serverlesowym ? Oczywiście, że tak. Oto przykłady wraz z krótka charakterystyką.
API Managment – usługi pozwalające budować API w chmurze. Przykładowy use case, wystawiamy RESTowe endpointy, które będą trigerować nasze Serverlessowe funkcje
Bazy danych
- AWS Dynamo DB – baza dokumentowa, klucz – wartość
- AWS Aurora Serverless – baza relacyjna
- GCP Cloud Firestore – baza dokumentowa
- MonogDB Atlas – możliwość hostowania w AWS, Azure, GCP – baza dokumentowa
- Fauna DB – ciekawe rozwiązanie posiadające wiele zastosowań. Możliwość uruchomienia DBMSu relacyjnego, grafowego czy time-series
Messaging – przesyłanie wiadomości i eventów to w dzisiejszych systemach nie tylko serverlessowych codzienność. Poniżej lista usług które
- AWS SNS – Pub/Sub messaging
- AWS SQS – queue messaging
- GCP Pub/Sub
- Azure Event Grid
Główna idea Serverless
Już wiemy, że wykorzystując Serverless, możemy zaoszczędzić na infrastrukturze, która automatycznie będzie dostosowywać się do naszych potrzeb. To argument na korzyść Serverless, który widać na pierwszy rzut oka. Jest jednak coś czego na pierwszy rzut oka nie widać, a wydaję się to być jeszcze istotniejszą korzyścią płynącą z zastosowania Serverless. Mówi się, że od pieniędzy cenniejszy jest jedynie czas. I to właśnie czas jest tutaj wskaźnikiem, który pokazuje jak wielki potencjał jest w modelu Serverless. O jakim czasie mowa ? Dwie kwestie
Pierwsza sprawa to czas zaoszczędzony na pracy programisty. Serverless zakłada, że deweloper powinien jak najmniej, a najlepiej wcale skupiać się na sprawa związanych z infrastrukturą i konfiguracją. Zadaniem dewelopera ma być dostarczanie wartości biznesowej. Zamiast poświęcać czas na rzeczy wtórne, takie jak konfiguracja serwera www, programista ma implementować funkcjonalność, które przyniosą realną korzyść jego firmie i klientom.
Druga korzyść jest efektem pierwszej zależności. Skoro deweloperzy, od teraz mogą skupić się głównie na dostarczaniu logiki biznesowej naturalnym jest to, że szybciej są w stanie dowozić nowe rozwiązania. Dzięki temu skraca się czas od pomysłu do wdrożenia czyli magiczny agilowy wskaźnik TTM (Time To Market)
Słowo końcowe
To wszystko co przygotowałam na dziś na temat Serverless. Wpis ten może Ci się wydać trochę chaotyczny, gdyż opisuje kilka aspektów serverless, jednak żadnego nie z nich nie wyczerpuje. W najbliższym czasie na pewno pojawią się na blogu kolejne wpisy uzupełniające i porządkujące wiedzę z tej dziedziny. Do usłyszenia !
