Serverless Architecture

Editor's Notes

1. Opowiem o: czym jest serverless, jakie są podstawy za nim stojące, jakim architekturom sprzyja, przykład, ekosystem, zalety i wady Będzie o podstawach, ale z praktycznego punktu widzenia - gdzie stosować i jak?
2. Zanim ruszymy naszą podróż …. Czy używałeś serverless? Czy słyszałeś o serverless? Cały czas dążymy do tego aby nasze aplikacje internetowe były szybsze, lepiej skalowalne, mniej podatne na awarie, aby miały lepszą architekturę. Jeśli cofnąć się w czasie, zaczynaliśmy od zwykłych PC gdzieś w budynku firmy, przechodziliśmy przez serwery rack, następnie migrując na VPS, aby finalnie w części firm przejść na cloud, a w ostatnim czasie na kontenery. Tak naprawdę nazwa to trochę kłamstwo ;) fizyczne serwery i zarządzający nimi administratorzy ciągle tam są, ale stają się dla nas coraz większą abstrakcją. Wszystkie te warstwy mają nam zapewnić, abyśmy jako programiści nie musieli się martwić o to co pod spodem, i w drugą stronę - aby administrator nie musiał się wgryzać w niedziałający kod. Tej ewolucji towarzyszy też ewolucja w architekturze, którą zapewnie dobrze znacie. Monolity, które rozbiliśmy na serwisy, a może nawet mikroserwisy. Tą ścieżką przeszło wiele ze znanych nam startupów. Jaki będzie więc kolejny krok?
3. Serverless nie powstał z dnia na dzień, a raczej wykluwał się w ostatnich latach, aby w zeszłym roku stać się jednym z najgorętszych zwrotów w IT. Czy ktoś kojarzy Parse? No właśnie, Parse i jemu podobne usługi jak choćby Googlowski firebase. Gotowe rozwiązanie pozwalające na budowę aplikacji, zwykle mobilnych i SOA, bez potrzeby posiadania serwera. Cudowna usługa łącząca bazę danych uzupełnioną o kontrolę dostępu. Dodatkowo usługi tego typu umożliwiają często możliwość wywołania małego fragmentu kodu, który np. wyśle e-mail po rejestracji użytkownika. Takie usługi nazywamy **Backend as a Service - BaaS**. W ostatnich latach pojawiało się coraz więcej usług tego typu dostarczających bardzo zróżnicowanych usług jak np. Auth0 - zarządzanie użytkownikami. Kolejnym krokiem było oderwanie małych fragmentów kodu od bazy i rozbudowanie tego konceptu. W toku ewolucji powstały usługi pozwalające uruchamiać funkcje, znane bliżej jako **Function as a Service - FaaS.** Najpopularniejszą usługą tego typu jest AWS Lambda, ale są dostępne też funkcje Azure, funkcje w Google Cloud (closed beta) i implementacje Open-source - np. OpenWhisk od IBM.
4. W podejściu Serverless dla programisty nie liczy się nic poza kodem. Tworzony kod jest funkcją uruchamianą jako reakcja na zdefiniowane zdarzenie. Takim zdarzeniem może być scheduler, zapytanie API, wgranie pliku na dysk lub wywołanie z innej funkcji, natomiast funkcja może wykonywać praktycznie dowolny kod, choć architektonicznie powinna raczej odpowiadać czemuś co nazwać moglibyśmy nano-service, ale o tym za chwilę. Nie istnieje serwer którym musimy zarządzać i który musimy utrzymywać, aby uruchamiać funkcję. Zamieniamy działające w trybie ciągłym serwery, na tymczasowy dostęp do zasobów, potrzebny do wykonania zdefiniowanej przez nas funkcji. To tak jakby serwer pojawiał się na ułamek sekundy gdy jest potrzebny, a następnie znikał. Płacimy tylko za ten ułamek sekundy i nie musimy w żaden sposób deklarować się jakie będzie planowane obciążenie. Gdy nie potrzebujemy uruchamiać funkcji wcale - nic nie jest uruchamiane, a w kolejnej sekundzie możemy chcieć obsłużyć 1000 zapytań, aby znów nie wywoływać naszej funkcji przez dłuższy czas. Zapłacimy tylko za te milisekundy w którym nasza funkcja działała.
5. Prawie, bo Amazon pozwala na zapis 512mb w /tmp, a w Azure można podpiąc Dropbox, Google Drive, Microsoft onedrive etc.
6. Bezstanowe i nic nie współdzielą, tak jakby komputery/kontenery startowały na jedno wywołanie i były ubijane.
7. Krótkotrwałe. Nie możemy zakładać, że kontener będzie trwać dłużej niż jedno zapytanie, ale też z drugiej strony zwykle tak nie jest. Najczęściej kontener żyje jakiś czas, nie wiadomo jednak jaki.
8. W zależności od tego czy budujemy aplikację mobilną czy też webową architektura będzie nieznacznie się różnić, ale podstawowa zasada będzie taka sama. Przede wszystkim, sporą część logiki i całą prezentację przenosimy do klienta. Czy to w postaci aplikacji mobilnej czy też SOA napisanej np. za pomocą React. Niektóre elementy logiki przenosimy do zewnętrznych usług, np. autoryzacja, cache, rate-limiting. Nasza aplikacja wygląda trochę jak zbudowana z klocków - częściowo gotowych, a częściowo napisanych przez nas. Następnie traktujemy nasze funkcje serverless jako API REST:
9. Jedeno z pierwszych narzędzi wspomagających budowanie systemów w oparciu o AWS lamdba. Ułatwia budowanie, deploy, aktualizacje. Ciekawostka: pozwala uruchamiać w aws niewspierane języki, poprzez lekką obudowę w node.js
10. Najpopularniejszy framework do budowy FaaS. Jedną z ciekawszych zalet jest fakt, że o ile wspiera obecnie tylko AWS Lambda, to obiecuje wsparcie dla innych dostawców, przez co ograniczy vendor lock-in
11. Również narzędzie ułatwiające wdrożenie aplikacji na Lambda. Obecnie mniej popularny, ale rozwijany przez Gojko Adzic. Z ciekawostek: pozwala odpalać aplikacje w express jako FaaS.
12. Open source rozwiązanie od IBM do budowania własnej infrastruktury serverless. Co ciekawe, jest dostępne jako bluemix na chmurze IBM i jest o ile wiem tańsze od Amazon. Nie jestem przekonany do budowania własnej infrastruktury, ale warto wiedzieć.
13. Kolejne rozwiązanie pozwalające na budowę własnej infrastruktury.