Transcription

Siemaneczko, witam bardzo serdecznie. W dzisiejszym odcinku chciałbym powiedzieć Wam o serverlessie. Zacznę przede wszystkim od definicji serverlessa, bo serverless jak przystało na buzzworda ma tyle definicji ile osób się wypowiada na temat tej technologii. Więc zacznę od swojej bardzo prostej definicji, a później omówię Wam plusy, minusy tego rozwiązania oraz projekty, w których moim zdaniem użycie serwerlessa ma sens, a w których niekoniecznie. Ale Artur, przecież w serverless są serwery. Nie Ty pierwszy wpadłeś na ten żart, nie pierwszy raz słyszę to i na każdej konferencji się zawsze przynajmniej jedna mądra osoba krzyczy ten argument. Nie bądź jak ta osoba. Pierwszy warunek to jest to, że przede wszystkim nie interesuje nas system i sprzęt, czyli piszemy kod i tutaj nieważne czy to jest funkcja javascriptowa, czy to jest funkcja w php, czy to jest jakiś fragment kodu w go, po prostu piszemy kod i wrzucamy go do tej takiej czarnej skrzyneczki, którą w tym przypadku jest serwerless. I nie interesuje nas czy jest pod spodem zainstalowany np. Centos, czy Ubuntu w wersji 18, czy to jest w ogóle jakiś system Microsoftu. Nie interesuje nas czy tam jest skonfigurowany jakiś firewall. Po prostu skupiamy się tylko i wyłącznie na kodzie, który chcemy wdrożyć do usługi serwerlessowej, która po prostu jest dla nas taką abstrakcją. Oczywiście jest ona pod spodem zarządzana przez usługodawcę, ale nas z punktu widzenia użytkowników serwerlessa w żaden sposób to nie interesuje. Drugi warunek to jest, że płacimy za konkretne użycie, konkretną liczbę razy jaką połączyliśmy się z naszą usługą serwerlessową. Np. jeżeli mamy serwer tradycyjny i chcemy mieć na nim 16 giga RAMu i np. potężny dysk, jakiś potężny procesor to płacimy 150 dolarów miesięcznie i czy się stoi, czy się leży 150 dolarów się należy. A w serwerlessie jest tak, że po prostu deplojujemy naszą funkcję np. do AWS-a, lampda czy do jakiejś usługi z ażura. Tam po prostu wrzucamy naszą funkcję i jeżeli ta funkcja zostanie wywołana 1000 razy to zapłacimy za te 1000 wywołań. Oczywiście cennik usług serwerlessowych nie jest taki prosty, że za 1000 wywołań zapłacimy tyle. Oczywiście zależy to od wielu różnych czynników, m.in. np. jak długo chodzi nasza lampda, jak mocno ona korzysta z różnych zasobów. To już zależy od różnych dostawców rozwiązań serwerlessowych. O tym nie będzie w ogóle ten odcinek. Ten odcinek jest bardziej o tym, żeby powiedzieć Wam mniej więcej czym jest serwerless z punktu widzenia, tak na chłopski rozum, do czego to się przydaje, a do czego nie. Ale odbiegłem od tematu i idę do kolejnego warunku, który musi być spełniony i jest on bardzo ważny w serwerlessie. To jest to, że serwerless musi się nam samoistnie skalować. Czyli po prostu my wrzucamy naszą funkcję np. na lampdę czy tam do tego Microsoft Azure, wrzucamy kawałek naszego kodu i teraz nas nie interesuje czy np. jutro tą lampdę wywoła jednocześnie w danym momencie 10 tysięcy osób. A jednak jeżeli mamy własny serwer, jeżeli wszystko konfigurujemy samemu, taką usługę, no to jednak może nas to interesować, bo może się okazać, że nasz serwer tradycyjny nie jest gotowy do przyjęcia tak dużej liczby użytkowników jednocześnie. Więc tutaj musimy mieć te trzy warunki spełnione, żebyśmy w ogóle mogli mówić o tym, że korzystamy z serwerlessa, czyli nie interesuje nas system i sprzęt, to jest schowane za pewnego rodzaju abstrakcją, później płacimy za użycie, czyli nie mamy jakichś stałych miesięcznych opłat, nie mamy jakichś planów, skalowanie jest po prostu nazwijmy to wliczone w cenę i po prostu nie musimy się tym przejmować. Dobra, ale skąd w ogóle wziąć serwerlessa, tak? No serwerless to nie jest raczej coś, co możemy zainstalować na swoim serwerze, musimy mieć jakiegoś usługodawcę, no i najpopularniejszy jest Azure, jest AWS, tam macie lampdę. Kolejna rzecz to Google Functions, kolejna rzecz, z której ja na przykład korzystałem i która bardzo mi się podoba to jest Cite, Cite pod spodem korzysta z AWS-a albo Google-a, więc jest tak naprawdę w pewnego rodzaju trochę takim raperem, więc, raperem, nie raperem, który jakby pod spodem łączy się z tymi usługami. No i takim samym jakby narzędziem jest też framework serwerless, który pozwala nam po prostu pisać kod bez zastanawiania się, czy pod spodem to będzie zdeplojowane na AWS-ie, czy na Google Functions, czy na Azure, a oczywiście ma to zaletę taką, że nasz kod serwerlessowy, który piszemy na przykład w Javascript-cie nie jest jakby zaszyty na stałe z danym konkretnym rozwiązaniem, czyli na przykład, jeżeli dzisiaj AWS mówi, że od jutra będzie kosztować 10 razy więcej, no to nie musicie w popłochu przenosić wszystkiego ręcznie z AWS-a na Google Functions, ale możecie po prostu sobie skorzystać z frameworka serwerless i ustawić sobie adapter, czy tam jakąś konfigurację, która powoduje to, że Wasz kod zostanie wrzucony na przykład na Google Functions, więc ja tutaj bym zalecał korzystanie z Zajta albo serwerless framework, no chyba, że jesteście już mocno, mocno po prostu wbici w AWS-a albo w Azure-a, tam macie miliony różnych usług i to jest jedyne miejsce, z którego fajnie Wam się korzysta, no to oczywiście nie będę tutaj zachęcał do korzystania z innych rozwiązań. Jakie są plusy serwerless? No przede wszystkim możesz się skupić na kodowaniu, tak, czyli jeżeli jesteś front-end deweloperem, nie masz pojęcia jak się konfiguruje w firewalle, nie masz pojęcia jak się ustawia nginx-a, nie chcesz konfigurować SSL-a i różnych takich rzeczy, no to oczywiście serwerless wydaje mi się takim dobrym rozwiązaniem na początek, którym możesz po prostu wypchnąć swój kod, nawet wyklikać to z poziomu przeglądarki i po prostu zdeployować sobie jakąś funkcję i wywoływać ją ze swojego kodu. Kolejna rzecz, no to łatwa skalowalność, tak, czyli jeżeli wiesz, że na przykład może się zdarzyć, że dzisiaj z Twojej usługi korzysta tysiąc osób, a jutro na przykład to będzie 10 tysięcy albo i więcej, no to wtedy też jakby plusem skorzystania z serwerless-a jest to, że tą skalowalnością po prostu nie musicie się przejmować, bo ta skalowalność po prostu będzie odzwierciedlona na Waszym rachunku. Za usługi. Kolejna rzecz, no to pay-per-use, czyli na przykład jeżeli mamy jakąś usługę, którą potrzebujemy raz w czas, no to nie musimy konfigurować serwera i płacić za tą usługę, nie wiem, miesięcznie, nawet te 5 dolców, tylko możemy ją wywołać raz dziennie, czy tam raz w tygodniu, czy ile razy nam to tam jest potrzebne i jesteśmy w stanie zapłacić tylko za określoną liczbę wywołania tej usługi, więc to też jest niesamowity, ale pamiętajcie, że jak są plusy, to są też minusy. No i minus, no to jest przede wszystkim nowy paradygmat do nauki. Paradygmat mam tu na myśli takie podejście, tak, jeżeli wcześniej po prostu wrzucaliście coś na serwer, no to jakby sprawnie poruszacie się w tym obszarze, a tutaj jednak macie Lambdę, bo Lambdę, przepraszam, usługę serwerlesową, która działa w nieco inny sposób niż zwykły serwer, więc za każdym razem jak ją uruchamiacie, jak tak naprawdę zwracacie się do waszej usługi serwerlesowej, to musicie pamiętać o tym, że ta usługa za każdym razem może zostać odpalona na zupełnie innym sprzęcie, na zupełnie innym serwerze, na zupełnie innym regionie i nie macie tam stanu, więc na przykład jeżeli jesteście przyzwyczajeni do tego, że możecie łatwo sobie na przykład utrzymywać połączenie między poszczególnymi zapytaniami do serwera, jeżeli mocno na tym polegacie, no to w serwerlesie pewnie też da się to zrobić, ale nie jest to takie proste jak przy takim serwerze tradycyjnym, więc trzeba po prostu trochę przeskoczyć z myśleniem i jakby zaadoptować się do nowej sytuacji. Kolejna rzecz, no to limit czasu działania funkcji, czyli po prostu jak macie własny serwerek, no to tam coś w tle może się wykonywać cały dzień, oczywiście jeżeli jest taka potrzeba, a tu jednak przy takich standardowych serwerlesowych rozwiązaniach od AWS czy Azure czy Google Functions, to jednak macie pewien limit czasu działania Waszej funkcji i jeżeli ta funkcja po prostu działa dłużej, no to zostanie ubita i to też jest jakby kolejny narzut na Wasz kod, żeby obsługiwać jakby takie lambdy, które się nie wykonały. A kiedy tak naprawdę serwerless to dobre rozwiązanie? No przede wszystkim myślę, że serwerless nadaje się świetnie do takich produktów bądź usług, gdzie możemy mieć duże skoki w natężeniu ruchu. Czyli na przykład jeżeli wiecie, że nie wiem, Wasz klient we wtorek kupuje reklamę w Super Bowlu albo przed milionerami albo przed wiadomościami w TVP i najprawdopodobniej dużo ludzi wejdzie szybko na Waszą stronę, no to wtedy warto jest pomyśleć sobie jak obsłużyć te nagłe skoki ruchu. No i oczywiście jeżeli nie chcecie korzystać z serwerlessa, chcecie korzystać ze swoich jakichś tradycyjnych rozwiązań, no to trzeba to obsłużyć w jakiś sposób i oczywiście to zajmuje czas i pieniądze, a tutaj przy takiej usłudze serwerlessowej może się to okazać dobrym i tańszym rozwiązaniem. Kolejna rzecz to jakieś różne proof of concept i eksperymenty. Jeżeli macie jakieś urządzenie, do którego chcecie zrzucać jakieś dane, no to jednak jeżeli chcecie postawić serwer, zabezpieczyć go w jakiś sposób, skonfigurować, no to na to wszystko musicie poświęcić jakiś czas, a po prostu stworzenie takiej usługi serwerlessowej, zdeployowanie jej na jakimś serwerze często może zająć, no nie wiem, dosłownie parę minut. Możecie sprawdzić, czy to działa, czy to spełnia Wasze jakieś tam założenia, czy spełnia to Wasz eksperyment i później się zastanawiać, czy tak naprawdę ta lampda Wam jest potrzebna, czy nie. Później druga rzecz, no to jednak jak masz różne serwery, no to jednak kupowanie, zamawianie ich w zależności od tego od kogo, no to zwykle troszeczkę trwa, w takich jakichś hostingowniach tradycyjnych to w ogóle może się okazać, że jakiś VPS to wystawiają Ci go na przykład po godzinie i nie możesz go nagle na przykład anulować i zamówić sobie innego, a tutaj jednak przy takich podejściach serwerlessowych jest to po prostu prostsze. No i kolejna rzecz, jeżeli nie umiesz Winuxa i tutaj mam na myśli to, że po prostu nie wiesz jak skonfigurować serwer, nie wiesz jak skonfigurować Nginx, Apache, nie wiesz po prostu jak wrzucić swój kodzik na serwer i później go wywołać, a w serwerlessie po prostu możesz napisać coś tam deploy, now deploy, coś takiego i po prostu dostajesz w odpowiedzi endpoint, który jest gotowy do użycia, więc może się to okazać także dobrym rozwiązaniem. No i kolejne oczywiście, jeżeli jesteś ekspertem AWS-a albo Azure-a, jeżeli masz dużo usług, sprawnie się poruszasz w tym ekosystemie, wiesz jak tam wszystko w tych panelach skonfigurować, wyklikać, to się może okazać, że tak naprawdę wszystko jesteś w stanie zrobić sobie z okna przeglądarki, skonfigurować lampdy, wystawić je jako GraphQL, zabezpieczyć je jakimś systemem zabezpieczającym typu Cognito albo jakimś innym i po prostu to jest twoje naturalne środowisko, więc nie ma sensu wtedy grzebać, babrać w konsoli jakiegoś serwera, to jest oczywiste. Kiedy natomiast jest to złe rozwiązanie? No oczywiście, jeżeli musicie postawić jakiś sklep dla wujka Józka albo prostą wizytówkę komuś zdeployować, no to myślę, że nie ma sensu kombinować nad jakąś lampdą, tylko w większości przypadków po prostu Ci wystarczy jakiś serwer za 5 dolarów i po prostu wrzucisz tam coś, co masz do zrobienia i zapomnisz o tym, a konfigurowanie do tego różnych lampd może dla Ciebie jest super, ale jak wujek Stasiek czy tam wujek Józek później będzie chciał ten projekt przekazać komuś, bo Ty już go nie będziesz chciał robić, bo będziesz miał za dużo pieniędzy, będziesz za dużo zarabiał jako developer, to po prostu nie ma sensu kombinować na siłę. Po prostu jest prosty serwer za patchem z jakimś tam nginxem i jest większe prawdopodobieństwo, że kogoś znajdziesz, kto po prostu będzie w stanie to przejąć. Później jest to złe rozwiązanie, jeżeli macie zadania, które długo trwają. Jeżeli macie zadania, które na przykład skrapują jakieś portale i wyciągają z nich dane, no to moim zdaniem nie jest to dobre rozwiązanie na użycie lampdy, bo czasami skrapowanie jakiegoś portalu trwa po prostu długo. Jakby taka lampda czy taka usługa działająca w Microsoft Azure może być po prostu skillowana, bo się wykonuje za długo. Kolejne rozwiązanie, jakie wymyśliłem, żeby były trzy punkty, to dużo danych i mało RAMu. Jeżeli mamy jakiś kodzik, który sobie operuje na bardzo dużej ilości danych, na przykład w jakichś plikach CSV albo w jakichś modelach machine learningowych, to się może okazać, że Twoja lampda tak naprawdę potrzebuje stosunkowo mało RAMu, ale potrzebuje dostępu do dużego zbioru, dużej kolekcji danych i wtedy wydaje mi się, że może nie być to dobre rozwiązanie. Więc to wszystko, co przygotowałem dla Was na dzisiaj, to tyle, co chciałem Wam powiedzieć o serverlessie. Mam nadzieję, że troszeczkę wyjaśniłem, mam nadzieję, że wiecie już do czego można to stosować, a do czego nie. Dajcie znać w komentarzu, czy materiał był dla Was pomocny i czy robiliście już coś związanego z serverlessem. Dziękuję za uwagę, pozdrawiam.