Dwa typy Serverless

W zeszłym tygodniu powiedzieliśmy sobie krótko o tym czym jest serverless z punkt widzenia chmury i co go wyróżnia. Przy czym po łebkach przelecieliśmy przez kilka opcji as a service. Dziś skoncentrujemy się na dwóch aaS o których jeszcze nie mówiliśmy a które dotyczą serverless lub, zanim zobaczycie. Będę to już mówił z punktu widzenia programisty – albo raczej z punktu projektowania systemu zgodnie z architekturą serverless (?). Sam nie wiem jak to ubrać słowa. Po prostu wykorzystując serverless jako część architektury naszego rozwiązania, lepiej? Dla mnie tak.

W serverless w zależności od źródła można wyróżnić dwa podejścia Backend as a Service (BaaS) albo Function as a Service (Faas). Opiszę twe dwa i dam po prostu swój pogląd na to (który zgadza się z jakąś tam grupą ludzi).

Backend as a Service (BaaS)

2017-11-28: może to wytłumaczy co takiego Pan kolega Martina miał na myśli, bo ten Pan kolega trochę skomplikował wszystko niepotrzebnie IMO.

Inaczej znany jako Mobile Backend as a Service (MBaaS) został wyróżniony jako część serverless w artykule hostowanym przez Martina Fowlera. Polega to na tym, że nam programistom dawane są klocki które łatwo możemy ze sobą połączyć poprzez jakieś ujednolicone API.

Normalnie jak piszemy aplikację webową, to musimy napisać nasz serwer, naszego klienta, stworzyć jakąś bazę danych, połączyć się do niej, połączyć się z jakimś innym systemem do uwierzytelniania itp. Itd. Z BaaS, nie musimy tego robić, mamy to dane. To na czym się koncentrujemy to na napisaniu klienta. Resztę daje nam API.

Dobrym przykładem tego podejścia jest Firebase – daje nam wszystko, my musimy jedynie wykorzystać te klocki. Podobnie było z Parse (do póki FB tego nie ubił). Co jednak mnie zastanawia, to także Auth0 jest traktowane jako BaaS (sam nie wiem czemu). Ogólnie trend był swojego czasu na tego typu narzędzia. Jednak nie wiem jak to teraz jest. Pisząc tego blog posta zrobiłem mały reasearch i nie mogę powiedzieć, że to dalej jest coś.

Raczej był na to hype, to dalej istnieje, ale nie nazwałbym tego serverless. Z drugiej strony, rozumiem czemu to może być tak nazwane – jest to tworzenie aplikacji bez zawracania sobie głowy takimi rzeczami jak zarządzanie serwerami itp. Czyli BaaS umożliwia nam tworzenie rozwiązań bez myślenia o tym gdzie i jak, a pozwala nam na skoncentrowaniu się na pytaniu co.

Nawet jeżeli w oficjalnych definicjach nie będzie BaaS to warto jednak wiedzieć o tym. Na razie można przedstawić definicję Martina vs Wikipedia – w jednym BaaS to serverless w drugim już nie ;)

Function as a Service (FaaS)

Tutaj zdania są wspólne, jest to serverless. Nawet do tego stopnie są wspólne, że niektórzy mówią, iż synonimem serverless jest FaaS. FaaS to nic innego jak myślenie o usłudze jako funkcji, która równie dobrze była by funkcją w naszej aplikacji. Taki SRP do potęgi.

Nawet powiem tak. Za każdym razem jak ktoś mi mówił o mikroserwisach, ja widziałem małe fragmenty kodu gdzieś porozrzucane.  Serwis do konwersji obrazka z jpg na png? Mikroserwis. Serwis do synchronizacji konkretnych danych SQL z CRM? Mikroserwis. Konwersja danych? Mikroserwis. Ogólnie wszystko to co mogło być osobnym modułem/funkcją w aplikacji może być mikroserwisem. I w moim rozumieniu to tak zawsze było. Niezależnie jak to się nazywało.

To teraz z FaaS mamy sytuację taką, że te nasze mikroserwisy możemy jeszcze bardziej rozbić lub jak mieliśmy nie super małe to po prostu zamieniamy je na FaaS i mamy architekturę serverless godną 2017 roku. Do tego stopnia, że nawet niektórzy nazywają FaaS nanoserwisami.

Ogólnie FaaS niczym się nie różni od naszej standardowej funkcji, musi ona jedynie być zgodna z jakimś tam szablonem (uzależnionym od dostawcy). Im mniejsza i szybsza tym lepiej, mniej zapłacimy za jej działanie. Przypomina mi się prezentacja z DevDay 2015 – Chad Fowler o miroserwisach

W której Chad mówił o tym, że starał się by ich mikrowserwisy nie były dłuższe niż wysokość ekranu. Coś w tym jest i funkcje moim zdaniem wpasują się w to bardzo dobrze.

To co warto wiedzieć jeszcze o FaaS to to, że są one wywoływane przez jakieś trigger. Nie ma API które mówi wywołaj mi funkcję X i Y. Ale raczej my budujemy klocki mówiąc: dane pojawiły się w bazie, odpal funkcję. Trochę inny sposób myślenia przy tym jest wymagany. I to może stanowić pewną barierę wejścia, w szczególności – zależy od naszego doświadczenia.

Podsumowanie

Pora podsumować to co było powiedziane. Istnieją dwa rodzaje serverless: Backed as a Service (BaaS) i Function as a Service (FaaS). Przy czym BaaS można zaliczyć do serverless tylko dlatego, że nie myślimy o serwerach przy tworzeniu rozwiązania – wszystko nam jest dane, my jedynie wykorzystujemy API. FaaS zaś to małe funkcje wykonujące określone zadania, przy których absolutnie nie musimy myśleć o serwerach i zasobach, jak dostawca stwierdza, że potrzebujemy większą moc przerobową to nam ją daje. Nas nie interesuje to jak to jest rozwiązane po stronie dostawcy. I nie musimy tym zarządzać.

Za tydzień popatrzymy na dostawców FaaS i co możemy z nimi zrobić. Czy do tej pory jest wszystko jasne? Coś przegapiłem i powinienem o tym wspomnieć? Jakiś kij w mrowisko? :)