Serverless

Krzysztof Kempiński
Oct 13 · 23 min read
Image for post
Image for post

W ramach podcastu “Porozmawiajmy o IT” miałem okazję porozmawiać z Pawłem Zubkiewiczem o serverless.

Posłuchaj naszej rozmowy w wersji audio 🎧 👇

Cześć! Mój dzisiejszy gość od ponad czternastu lat, zawodowo zajmuje się wytwarzaniem oprogramowania. Ma doświadczenie w rolach programisty, analityka oraz architekta. Budował i projektował aplikacje dla dużych firm i organizacji. AWS Cloud Architect. Aktywny członek Wrocławskich społeczności IT, organizator Serverless Wrocław Meetup oraz założyciel Serverless Polska. Prelegent i bloger. Moim i Waszym gościem jest Paweł Zubkiewicz.

Cześć Pawle! Miło mi gościć Cię w podcaście.

Cześć Krzysiek, dziękuję bardzo za zaproszenie, witam wszystkich Twoich słuchaczy.

Z Pawłem będę dzisiaj rozmawiał o tym, czym jest i jak działa serverless. Zacznijmy jednak od tego standardowego pytania na wprowadzenie, czyli czy słuchasz podcastów, jeśli tak to, jakich najczęściej?

Ha! Już przy pierwszym pytaniu wyjdzie prawda, że jestem nerdem i interesuję się tylko jedną rzeczą. Głównie słucham podcastów związanych z serverless i są to siłą rzeczy podcasty w języku angielskim. Do takich najważniejszych mogę zaliczyć Serverless Chats z Jeremy Daily, w którym Jeremy co tydzień porusza tematy związane z serverless.

Później mam Real-World Serverless od Yana Cui, chyba tak się czyta poprawnie jego nazwisko. To jest bardzo ciekawy podcast, ponieważ tutaj goście opowiadają na temat swoich wdrożeń, doświadczeń ze wdrożeniami w serverless. Z tego podcastu można się dowiedzieć bardzo wiele ciekawych rzeczy. Już takich na poziomie zaawansowanym, jeśli chodzi o szczegółowe użycia.

Patrząc trochę szerzej także lubię podcast Corey Quinna, który to zajmuje się ogólnie AWS-em. Corey współpracuje jako osoba, która się specjalizuje w obniżaniu rachunków, które płacimy w chmurze AWS. On jest takim Cloud Economist. Jest to facet, który ma bardzo zabawne poczucie humoru. Jest bardzo sarkastycznym człowiekiem. Bardzo lubię słuchać jego podcasty, ponieważ one czasem przypominają standupy. To jest bardzo fajne.

Czasem też słucham różnych pomniejszych podcastów albo po prostu pojedynczych odcinków, które omawiają zagadnienia serverless, albo gościem jest ktoś, kto zajmuje się serverless na co dzień. Z Polskich podcastów czasem słucham pojedynczych rzeczy, natomiast najczęściej wracam do podcastu Magdaleny Pawłowskiej. Jest to podcast, który się nazywa Marketing MasterClass. Robię to głównie z myślą o rozwoju swojej strony serverlesspolska.pl, ponieważ tutaj muszę dbać o to, żeby nasza społeczność wokół serverless się rozwijała i różne marketingowe triki, sztuczki, które ona pokazuje, na pewno mogą się przydać.

Jasne, dzięki za te rekomendacje. To co, zaczniemy może od takich zupełnych podstaw. Gdybyś mógł powiedzieć, czym jest serverless tak w ogólności, jak również czym jest pod względem architektury i usługi.

Pewnie. Na wstępie chciałem też zaznaczyć, że w sumie nie ma żadnej dokładnej definicji serverless i to, o czym ja będę mówił, to jest pewne uogólnienie, ponieważ też nie chcę zanudzać naszych słuchaczy szczegółami. Tak więc moim zdaniem, jest to zdanie wypracowane na bazie kilku lat praktyki, serverless jest architekturą nierozerwalnie związaną z chmurą. Polega na łączeniu ze sobą usług, udostępnionych przez dostawcę chmury w taki sposób, że nasze rozwiązanie spełnia trzy podstawowe warunki.

Jest wysoko skalowalne oraz dostępne. My jako klienci nie musimy zarządzać infrastrukturą, która jest użyta przez to rozwiązanie, a koszty tego rozwiązania są rozliczane w modelu PAY-AS-YOU-GO. Może wytłumaczę dokładnie jak to rozumieć. Pierwszy punkt jest oczywisty, że mamy skalowalne i dostępne rozwiązanie.

Drugi punkt, czyli my nie musimy zarządzać infrastrukturą. O co chodzi? Chodzi o to, że my zarządzamy jedynie konfiguracja tej infrastruktury. Definiujemy sobie jakich usług chcemy użyć i jak one mają być skonfigurowane pod nasze wymagania. Natomiast to dostawca martwi się o to, żeby było wysoko dostępne, żeby się skalowały, żeby były zabezpieczone, żeby wszystko, co jest pod spodem, było zaktualizowane.

Na samym końcu, żeby w ogóle sprzęt, bo w pewnym momencie schodzimy do sprzętów w chmurze, też był sprawny i działający. Trzecie charakterystyka, która jest najmniej związana z technologią, ale paradoksalnie wywołana największą zmianę na rynku technologicznym, to jest rozliczanie w modelu PAY-AS-YOU-GO. Należy je rozumieć w takim sensie, że my, jako klienci płacimy tylko i wyłącznie za realny czas wykorzystania zasobów, a nie za to, że one są dostępne do uruchomienia.

Może posłużę się tutaj pewnym przykładem. Załóżmy, że masz bloga. Ten blog jest na WordPressie. WordPress jest zainstalowany na jakimś Linuxie i masz po prostu serwer z tym Linuxem. Jeżeli w ciągu doby na Twojego bloga przyjdzie jedna osoba i obejrzy jeden artykuł na Twoim blogu, to Ty i tak musisz zapłacić za 24 godziny działania tego serwera. Bez różnicy, czy wynajmujesz ten serwer od firmy, czy masz ten serwer w domu u siebie, w szafie, to i tak byś płacił za prąd, za tą całą dobę działania. W modelu serverless i rozliczaniu PAY-AS-YOU-GO zapłacisz tylko i wyłącznie za czas pracy, który był użyty do tego, żeby wyświetlić tę jedną stronę. Czyli to może być pół sekundy, maksymalnie dwie sekundy. To jest ta kolosalna różnica pomiędzy tym, jak jest rozliczany serverless a jak są rozliczane klasyczne usługi.

Tutaj ciekawa jest ta nazwa. Sugeruje ona, że jakby serwerów żadnych nie było. Server i less. Ale pomimo tej trochę mylącej nazwy, to pojęcie jest jakoś namacalne i nadal wymagane są powiedzmy, serwery do działania tego typu usług. Z racji na to, że są wymagane serwery, jakieś usługi na tych serwerach działają, to pojawia nam się tak zwane pojęcie „zimnego startu”, cold startu. Mógłbyś nieco więcej powiedzieć, z czym to zagadnienie się wiąże?

Jasne. Jeśli chodzi o nazwę, to jest dużo dowcipów na ten temat i one niekoniecznie śmieszą osoby, które zajmują się serverless, więc może najpierw się skupię na tej części, w której chodzi o rozszyfrowanie nazwy. Serverless jest podobnie jak z wireless. To znaczy, masz w domu jakiś router Wi-Fi i sobie korzystasz bezprzewodowo z internetu na swoim tablecie, komórce czy laptopie, natomiast ten router fizycznie i tak jest przyłączony do sieci, dostawcy internetu, albo kablem internetowym, albo światłowodem. Jednak Ty na samym końcu, jako klient nie przejmujesz się tym i korzystasz z tego dobrodziejstwa, że internet jest bezprzewodowo dostarczany do Twoich urządzeń. Podobnie jest z serverless. Ktoś ładnie ubrał w słowa po angielsku znaczenie tego serverless i powiedział coś takiego „Worry less about server”. Myślę, że to jest bardzo dobre podsumowanie. Chodzi o to, że te serwery gdzieś tam są, ale my jako klienci nie musimy się tym przejmować, ponieważ to zostało przerzucone na naszego dostawcę chmury i dzięki temu my możemy się skupiać na innych rzeczach dla nas ważniejszych, niż konfiguracja sprzętu.

Jeśli chodzi o drugą część pytania, to chciałbym zaznaczyć, że lambda nie równa się serverless. To znaczy inne usługi, które nie są lambdą, też mogą być serverless. Lambda jest to usługa typu compute, która dostarcza nam moc obliczeniową, na której możemy wykonywać nasz własny kod. Jest ona skonstruowana w taki sposób, że zanim ten kod się stanie uruchomiony, to usługa lambda musi nam przydzielić jakiś kontener, do którego skopiuje nasz kod, który uprzednio żeśmy wysłali do chmury. Ten kod dopiero zostanie uruchomiony.

W zależności od tego, jakiego używamy języka, jak dużo tego kodu żeśmy umieścili i jeszcze paru innych aspektów, to może trwać jakiś skończony czas. Historycznie ten czas w ekstremalnych sytuacjach był dosyć długi, to były sekundy rzędu trzech sekund, co powodowało dosyć długi czas oczekiwania, szczególnie jeżeli jakiś człowiek czekał na odpowiedź. Natomiast generalnie już w tych czasach ten czas został mocno zminimalizowany, szczególnie jeżeli chodzi o języki skryptowe tak jak Python, Javascript.

Myślę, że w dzisiejszych czasach kwestia cold startów nie jest już tak ważna, jak to było kilka lat temu. Tutaj warto pochwalić AWS, ponieważ on wykonał mega robotę i to było coś, co zostało zrobione zupełnie bez udziału klientów. To znaczy, że ten kod, który wgrałem, powiedzmy dwa lata temu, on dziś po prostu szybciej się uruchamia. Nie musiałem nic zrobić, aby to było zoptymalizowane.

Kilka razy wspomniałeś o lambdzie, o AWS Lambdzie i bardzo często, jeśli mówimy o serverless, to właśnie wspominamy o takich pojęciach jak funkcja czy lambda i to niezależnie od providera takie pojęcie funkcjonuje. Mógłbyś nieco bardziej przybliżyć i rozjaśnić?

Pewnie, tak jak powiedziałem, funkcja lambda to nie jest to samo co serverless. Mamy generalnie wiele innych usług, jak na przykład kolejki serverless, usługi do przechowywania plików, które są w serverless, mamy również bazy dane serverlessowe. Natomiast te wszystkie usługi, one jakby nie są w centrum zainteresowania. Historycznie to było tak, że lambda dokonała tego przełomu i bardzo wiele osób, od razu słysząc „serverless”, od razu myśli „AWS Lambda” i vice versa.

Czym jest AWS Lambda? AWS Lambda jest usługą compute, która dostarcza nam moc obliczeniową. Jest to usługa, która jest zaliczana do kategorii function as a service. Jest to jakby najwyższy poziom abstrakcji konsumpcji zasobów w chmurze, Bardzo często mamy taki diagram pokazywany na różnych prezentacjach, że mamy infrastructure as a service, mamy container as a service a później na samym końcu, bo tych kategorii ludzie czasem wymyślają kilka, mamy function as a service, czyli ten najwyższy poziom abstrakcji, dzięki czemu my, jako klienci nie musimy się martwić o różne rzeczy niskopoziomowe. Korzystamy tylko i wyłącznie z mocy obliczeniowej. Taka funkcja lambda służy do uruchamiania naszego kodu po stronie dostawcy. Ten kod oczywiście musi spełniać pewne wymagania, czyli powiedzmy spełniać contract albo interfejs.

W związku z powyższym wszystkie funkcje lambda, na świecie wyglądają bardzo podobnie. Natomiast mają jakby ten sam interfejs. Różnią się tym, co robią, wykonują. Generalnie nazywamy to logiką biznesową w tych funkcjach. Tutaj warto też dodać, że taka funkcja lambda, nie jest odpowiednikiem całego systemu, który byśmy mieli w klasycznej architekturze. Więc jak wrócimy i pomyślimy o monolitach, to monolity składają się z setek, albo tysięcy plików źródłowych. Realizują właśnie często setki albo tysiące jakichś funkcjonalności. To wszystko jest razem zebrane do jednej paczki. Później mieliśmy różne architektury.

Obecnie bardzo znaną architekturą jest architektura mikroserwisów, która dzieli taki monolit na wiele niezależnych, ale współpracujących ze sobą komponentów. Używając serverless, my niejako też automatycznie używamy mikroserwisów mniej lub bardziej. Jeżeli sobie pomyślimy o funkcjach lambda, to jedna taka funkcja lambda, to jest poziom niżej niż mikroserwis. To znaczy z mojego doświadczenia, zazwyczaj mikroserwis implementujemy, tworząc jedna bądź kilka, czasem kilkanaście funkcji lambda. Mam nadzieję, że w ten sposób naszym słuchaczom będzie łatwiej sobie wyobrazić i umiejscowić, gdzie taka funkcja lambda jest w przestrzeni innych architektur i rozwiązań.

Wcześniej też wspomniałem, że funkcje lambda, one wszystkie są do siebie bardzo podobne, bo spełniają ten sam contract. Oczywiście to jest prawda i jedyne czym się różnią, to jest logika biznesowa, natomiast tutaj chcę podkreślić clue i sens istnienia tej usługi. Chodzi o to, żebyśmy my, jako programiści, pisali jak najmniej kodu, który nie dostarcza wartości biznesowej, czyli takiego boilerplate. Chodzi o to, żeby zminimalizować to, co nie daje nam wartości, albo właściwie naszym klientom, co nie buduje przewagi konkurencyjnej. Z perspektywy lat widać bardzo, że usługi AWS w ekosystemie serverless rozwijały się zgodnie z tą ideą, aby właśnie odciążyć programistę od tych zbędnych i mało wartościowych rzeczy.

Pamiętam jak w zeszłym roku na R. E. Evencie, na konferencji AWS-owej, Chris Moss, czyli taka osoba, która rozwija serverless w AWS-ie, powiedział, że lambdy powinny służyć transformacji danych, a nie transportowi. To znaczy transform not transport.

To jest też taka zmiana, którą w ostatnich latach widać w AWS-ie, że odchodzimy od tej koncepcji, że funkcja lambda jest klejem łączącym różne usługi, który pozwalał na integrację z różnymi usługami, a dąży się do tego, że funkcja lambda ma implementować głównie przede wszystkim, a najlepiej tylko i wyłącznie właśnie tę logikę biznesową, to w ogóle, po co budujemy jakiś system i realizuje się ten trend przez to, że wiele usług, które kiedyś były możliwe do integracji tylko i wyłącznie przez funkcje lambda, teraz integrują się bezpośrednio ze sobą z pominięciem funkcji lambda. Dzięki temu my musimy pisać mnie kodu.

Jak teraz to opowiadałeś, to pojawiła mi się taka analogia właśnie tych lambd AWS-owych do funkcji używanych w funkcyjnym paradygmacie oprogramowania, takich czystych funkcji, które mają służyć transformacji danych. To są z definicji bezstanowe. W przypadku serverless tez mówimy o takiej bezstanowości uruchamianej funkcji. Jak wobec tego zapewnia się stanowość, też persystencję?

Stanowość zapewnia się, korzystając z innych usług. Generalnie u providerów chmurowych i w AWS mamy dosyć dużą pozycję usług. Jest bardzo dużo usług i każda usługa robi głównie jedną rzecz, jest w tym bardzo dobra. W związku z powyższym mamy usługę AWS Lambda, która dostarcza nam moc obliczeniową, natomiast jeżeli chcemy zapisywać stan, to musimy skorzystać z jakiejś bazy danych, to może być na przykład DynamoDB, to może być również jakaś relacyjna baza danych, na przykład MySQL.

Możemy też zapisać sobie wyniki naszych obliczeń, których dokona nasza funkcja lambda, na przykład w formacie JSON i zapisać je w AWS S3, to jest taka usługa, która służy do przechowywania plików w chmurze. Kolejna rzecz, która może być dla naszych słuchaczy interesująca, to jest sesja użytkownika. W systemach klasycznych jest bardzo często przechowywana po stronie serwera, natomiast tutaj nie mamy tego serwera, zaraz powiem, jak to jest rozwiązane technicznie. Odpowiednikiem sesji jest takie rozwiązanie jak JWT, czyli JSON Web Token. Klient wysyłający request musi zawsze zawrzeć ten token, po to, aby nasz backend był w stanie zweryfikować, że po pierwsze ten klient może uruchomić, albo zażądać dostępu do tego zasobu, z którym próbuje się połączyć, i też, żebyśmy mogli rozpoznać tego klienta.

Teraz może w paru słowach ogólnie, jak działa AWS Lambda. Usługa AWS Lambda ma jakiś zbiór gotowych, pustych, działających kontenerów. W tych kontenerach jest zainstalowany Amazon Linux 2 od niedawna. Funkcja lambda bierze taki kontener, kiedy nadchodzi zdarzenie. Zdarzeniem może być to, że jakiś klient się łączy do naszego endpointa REST-owego, który jest spięty z funkcją lambda. Żeby odpowiedzieć do klienta, zwrócić mu jakąś odpowiedź, to musi się wykonać funkcja lambda. Teraz ten klient dostanie odpowiedź w momencie, kiedy kod, który został umieszczony w kontenerze, zostanie wykonany. Oczywiście funkcja lambda, jako usługa zapewnia to, że do kodu naszego zostaną przekazane jakieś parametry.

Przykładowo właśnie w takim requeście HTTP mogą być zawarte różne parametry, więc one zostaną przekazane do naszej funkcji lambda. Nasz kod się wykona i my to zwrócimy do naszego klienta. W związku z powyższym, że takich kontenerów jest bardzo dużo i nigdy nie mamy gwarancji, że dany klient zostanie obsłużony przez ten sam kontener, to my nie możemy w funkcji lambda zapisywać stanu. Ten stan musi być umieszczony gdzieś indziej. Jeżeli potrzebujemy ten stan zapisywać, bo są takie przypadki, że niestety musimy, to właśnie najlepiej się posłużyć bazą danych DynamoDB, która jest diabelnie szybka i w przypadku takich działań związanych bezpośrednio z użytkownikiem, że ktoś na przykład mamy stronę WWW, która jest serverlessowa i człowiek czeka na odpowiedź, to wtedy możemy się posłużyć DynamoDB, aby zminimalizować opóźnienia.

Jasne, rozumiem. Jak się czyta gdzieś o serverless to też często zostawia się to pojęcie z kosztami. Jestem ciekaw, jak wypada podejście serverless właśnie w kontekście finansowym, zarówno myślę o kosztach krótkoterminowych, wynikających właśnie z tego, co mówiłeś, czyli użytkowania danej usługi, płacenia za ten czas, czy te zasoby spożytkowane w momencie wykorzystania usługi, jak i takich bardziej długoterminowych oszczędnościach, wynikających z tego, że nie trzeba inwestować we własną infrastrukturę, serwerownię, trzeba nawet utrzymywać i płacić za tą strukturę, nawet jeśli nie wykonuje ona żadnych obliczeń.

To jest bardzo fajne pytanie, bo ono tak naprawdę pozwoli odpowiedzieć, na ile serverless jest użyteczne. Natomiast nie byłbym sobą, gdybym nie chciał odpowiedzieć na to pytanie bardzo kompleksowo, dlatego na samym początku krótki wstęp teoretyczny na temat TCO. Jest to skrót, który często się pojawia w świecie serverless i jest to skrót od Total Cost of Ownership. To jest koncepcja wymyślona przez Gartnera. Myślę, że na początku lat 90-tych ubiegłego wieku, która służy do tego, aby być w stanie policzyć koszty całego systemu IT. W te koszty możemy umownie zaliczyć infrastrukturę, czyli sprzęt. Lata 90-te ubiegłego wieku, wtedy nie było jeszcze chmury i generalnie wszyscy mieli własne serwerownie i kupowali sprzęt. Musieli mieć okablowanie i inne takie rzeczy, pomieszczenia, więc to podejście to liczyło.

Później rozwój, czyli programiści, całe koszty tworzenia nowego oprogramowania.

Na końcu utrzymanie, czyli znowu mamy ludzi, którzy są od administracji systemami, sprzęt, na którym te systemy muszą działać, plus backupy, Disaster Recovery i to wszystko bardzo skrótowo i ogólnie zalicza się do TCO. Teraz jeżeli my sobie porównamy TCO systemów w klasycznej architekturze, czyli opartej o serwery, z TCO systemów, które są rozwijane w serverless, to zauważymy bardzo poważne różnice.

Posłużę się takimi badaniami z ubiegłego roku, które przygotował Deloitte. On badanie stworzył w taki sposób, że wziął sobie dwa przykładowe systemy, jeden był z bankowości, a drugi z transportu i je zaimplementował w klasycznej serwerowej architekturze oraz w architekturze serverless. Teraz z tego, co pamiętam, wynik tego badania był zaskakujący pod paroma aspektami.

Po pierwsze rozwiązanie serverless udało się dostarczyć czterokrotnie szybciej niż równoważne rozwiązanie serwerowe. Tutaj mamy dużo, dużo krótszy time to market. Druga kwestia to właśnie koszty liczone w modelu TCO. One były od 45 do 80% niższe niż w rozwiązaniu serwerowym. Tutaj te badania pokazują ogromną różnicę.

Chciałbym zwrócić też uwagę na jedną rzecz, że z mojego prywatnego doświadczenia, oczywiście to się pokrywa, nawet rozwiązania z serverless są jeszcze tańsze niż to 80%, natomiast chciałem też zwrócić uwagę, że często się spotykam, że osoby ignorują to podejście TCO i sobie patrzą na cenniki.

Biorą cennik serwerów wirtualnych, to jest usługa AWS EC2 i patrzą, ile ich będzie kosztował serwer, za kilka godzin działania, patrzą na lambdę, liczą ile ta lambda by ich kosztowała, jakby działała przez dwie godziny non stop i nagle wychodzi, że ta funkcja lambda jest dużo droższa niż serwer. To jest bardzo naiwne liczenie, ponieważ nie bierze pod uwagę tego, że funkcja lambda jest wysoko skalowalna oraz jest wysoko dostępna. Co to oznacza? Że jeżeli byśmy chcieli zapewnić taką samą dostępność, czyli odporność na awarie w przypadku serwerów, to musielibyśmy mieć przynajmniej dwa serwery, które byłyby zlokalizowane fizycznie w innych Data Center. W danym regionie AWS mamy najczęściej minimum trzy serwerownie i są to zupełnie osobne budynki, oddzielone od siebie o minimum kilkanaście, albo kilkadziesiąt kilometrów.

W związku z powyższym, jeżeli w jednym z takich budynków coś by się stało, na przykład powódź, wybudzi, cokolwiek, to mamy inne budynki w regionie, w których nasze serwery by działały. W związku z powyższym już na samym początku okazuje się, że nie możemy porównywać jednego serwera z lambdą, tylko musielibyśmy porównywać dwa serwery z lambdą. Natomiast jeżeli mamy już dwa serwery, to musimy mieć najczęściej Loud Balancer. To jest urządzenie, oczywiście w chmurze, wirtualne, co nie zmienia faktu, że też generuje dodatkowe koszty. Następnie prawdopodobnie byśmy też musieli mieć NAT gateway. Jest to rozwiązanie, które pozwoli nam na to, aby nasze serwery miały dostęp do internetu, a internet nie miał dostępu do naszych serwerów. Nagle ten koszt samej EC2 się dubluje albo nawet trochę więcej niż dwukrotność.

W związku z powyższym koszt się zwiększa. Każdy, kto projektował architekturę, w oparciu o VPC, czyli Virtual Private Cloud, czyli wirtualne sieci w AWS, w których właśnie umieszczane są te serwery. Myślę, że ma tego świadomość, ile tam trzeba wykonać pracy. Natomiast AWS Lambda jest pozbawiona tych niskopoziomowych rzeczy. To wszystko bierze na siebie dostawca. My, jako klienci nie musimy tego implementować, nie musimy tego konfigurować i możemy wygodnie z tego korzystać.

Rozmawiając o kosztach, za przykład niech posłuży prosty przykład, który uzmysłowi słuchaczom, ile kosztuje lambda. Mamy u klienta rozwiązanie, które miesięcznie wywołuje milion razy funkcję lambda. Ta funkcja coś tam sobie robi przez krótki okres czasu. Teraz koszt tych wszystkich wywołań funkcji lambda, to jest około jeden dolar miesięcznie, za milion wywołań funkcji lambda. Do tej funkcji lambda mamy też skonfigurowaną bazę danych DynamoDB, do której dokonujemy zapisów i odczytów. Koszt tej bazy to jest, jakieś dwa do trzech dolarów miesięcznie. Teraz to wszystko razem kosztuje kilka dolarów miesięcznie, to rozwiązanie. To pokazuje, jak niskie są koszty.

Chciałbym dodać, może nie powinienem się chwalić, to rozwiązanie nie jest napisane w jakiś super zoptymalizowany sposób, ponieważ koszty tego rozwiązania są na tyle niskie, że po prostu mój czas pracy nad tym, aby zoptymalizować to rozwiązanie, byłby dużo droższy niż oszczędność, którą to przyniosło. Myślę, że całkiem nieźle odpowiadam na Twoje pytanie. Chciałbym jeszcze powiedzieć, że te koszty w serverless jest dużo łatwiej śledzić, ponieważ dostajemy od naszego dostawcy dokładny billing, podobnie jak dostajemy billing od operatora telefonii komórkowej i my możemy sobie sprawdzić dokładnie ile pojedynczy request kosztował, jedno żądanie, jedno wywołanie funkcji lambda. Możemy sobie optymalizować i zobaczyć, powiedzmy mamy trzydzieści funkcji lambda, jedna funkcja lambda jest dużo droższa niż inne w rachunku miesięcznym, to możemy spróbować zoptymalizować tę funkcję. Podsumowując, moim zdaniem, serverless jest znacznie tańszy, niż rozwiązania serwerowe.

To są bardzo konkretne zyski, o których mówisz. Przechodząc już z zysków finansowych, na takie bardziej technologiczne, czy performancowe, chciałby przejść do skalowalności, bo to jest też taki istotny aspekt serverless, który jest zawsze powoływany. Z jednej strony jest to podstawa, można powiedzieć, podejście serverless, ale z drugiej strony też jakieś tam zagrożenie dla kosztów. Jeśli to skalowanie spowoduje, że nagle będziemy uruchamiać tych lambd bardzo, bardzo wiele. Nie wiem, jakie masz podejście, obserwacje w tym kontekście?

Wiesz co, w tym pytaniu jest jakby zawarta też odpowiedź. Ja się nie do końca z nią zgadzam. Już tłumaczę dlaczego. Faktycznie, jest ta zależność, że im więcej mamy requestów, żądań do naszych usług serwerowych, im większy mamy volumen, tym więcej będzie nas to kosztowało. Odnosząc się do tradycyjnych architektur, jeżeli mieliśmy kilka serwerów i tam nie było autoskalowania, to nie mogliśmy przejść powyżej tych kilku serwerów. Natomiast tutaj w lambdzie, ta skalowalność jest na tyle duża, że faktycznie przez krótki okres czasu może się wyskalować bardzo mocno i wtedy automatycznie nasze koszty wzrosną. Natomiast ja nie jestem do końca pewien, czy to jest dobre, czy złe. Bo jeżeli ktoś ma sensownie zaprojektowany swój system i IT wspiera działania biznesowe w mądry sposób, to, to będzie plusem.

Za przykład niech posłuży historia Lego. Lego ma serverlessową aplikację, która służy do sprzedaży klocków, innymi słowy sklep internetowy mają napisane w serverless. Bodajże w 2017 roku oni jeszcze mieli swój sklep internetowy, oparty na tradycyjnej architekturze serwerowej. Po prostu w jakiś Black Friday, czy Cyber Monday, ich sklep nie wytrzymał ruchu i padł. W tym momencie, kiedy pod największym ruchem klientów, oni nie byli ich w stanie obsłużyć, bo serwery przestały działać i system nie działał. Oni mieli ogromne straty. To było przyczyną główna do tego, że zmodernizowali swoje rozwiązania i zaczęli szukać czegoś lepszego, niż mieli do tej pory. Wybrali właśnie serverless.

Jeżeli my mamy dobrze zaprojektowany system, to każda transakcja, którą system przetwarza, ona daje naszej firmie jakiś zysk. Jeżeli w zwykły dzień, na przykład Lego nie wiem ile, sprzedaje tych klocków, ale załóżmy, że to jest 500 paczek klocków, to na każdej paczce jest jakiś oczywiście zysk, na każdym zestawie. To się wszystko opłaca. Nagle, jeżeli przychodzi Cyber Monday i system jest w stanie się wyskalować do kilku tysięcy transakcji, sprzedaży zestawów klocków, to wtedy to jest super, że to skalowanie działa. Faktycznie, to rozwiązanie, ta technologia pozwoli obsłużyć bardzo dużą ilość klientów.

Natomiast jest jeszcze drugi aspekt. Może być wrogi element trzeci, ktoś chce dokonać ataku na nasz system. Normalnie mówimy o atakach DoS albo DDoS, czyli Distributed Denial of Service, a w serverless one tak lekko żartobliwie została zmieniona nazwa na Denial od Wallet. Czyli po prostu technologia jest się w stanie skalować, a nasz portfel i nasze zasoby finansowe już nie są w stanie się skalować tak szybko, jak funkcja lambda. W związku z powyższym musimy dbać o to, aby sobie monitorować nasze koszty. Są rozwiązania, które pozwalają tworzyć różne alarmy, monity. To są rozwiązania, które też pozwalają tworzyć forecasty, czyli możemy przewidywać, jak ten ruch będzie się rozwijał w przyszłości na bazie jakiegoś historycznego okresu. Możemy po prostu być ostrzeżeni, jeżeli ten ruch, który mamy w chwili obecnej, będzie na podobnym poziomie, albo będzie rósł, to w pewnym momencie przekroczymy zdefiniowany przez nas wcześniej budżet, czyli limit pieniędzy, które chcielibyśmy wydać i w związku z powyższym możemy podjąć jakąś akcję, czyli na przykład zablokować pewne requesty, które przychodzą, jeżeli podejrzewamy, że po prostu jesteśmy ofiarą ataku.

Jasne. To faktycznie ma sens, jeżeli nasz biznes skaluje się w tym samym tempie co technologia, to wówczas nie ma tutaj żadnych zagrożeń, bo zarabiamy, więc automatycznie pokrywamy też z tego zarobku koszty naszej struktury, czy działania naszego oprogramowania. Ma to sens.

Chciałbym natomiast wrócić do tego, co powiedziałeś, że gdzieś tam pod spodem spojrzeć na samo dno tego stosu technologicznego, to jest jakiś Linux, który jest w jakimś kontenerze uruchamiany. Chciałbym Cię zapytać, że to, że nie mamy kontroli nad tymi serwerami, że to jest poza nami, że mamy dostęp do jakiegoś z góry definiowanego zestawu technologii, bo to też nie jest tak, że możemy sobie dowolny język użyć, jest jakiś zestaw, z którego możemy sobie wybrać. Czy to powoduje, że to jest plus dla nas, ponieważ nie musimy się jako programiści tym martwić, zajmować, czy może być to minus, bo nie mamy aż tak pełnych możliwości wyboru, czy dostosowania tego?

Wiesz co, dla mnie to jest akurat ogromnym plusem, że mamy ustandaryzowane narzędzie. Powstaje wokół tego standardu wiele różnych frameworków, wiele dobrych praktyk, które mogę wykorzystać w swojej pracy i dzięki temu bardziej się skupić nie na samej technologii, a na tym, co chce dostarczyć. Czyli na wartości dla mojego klienta, na budowaniu przewagi konkurencyjnej. Czyli jeżeli jestem firmą, która chce być firmą księgową, albo fakturowania, to klientów fakturowni nie interesuje to, jaka jest technologia pod spodem, ich interesuje to, żeby faktury się dobrze liczyły, zgodnie z prawem Polskim. Skupienie się na funkcjonalnościach księgowych, to jest core biznesu, a nie to, czy pod spodem są serwery, kontenery, czy funkcje lambda. Ta standaryzacja pozwala mi skupić się na logice biznesowej. Pozwala skrócić czas, który jest potrzebny na dostarczenie funkcjonalności, zaimplementowanie jakiegoś rozwiązania. Na marginesie ta prędkość działania w serverless jest niesamowita.

Na początku swojej kariery, tutaj taka dygresja, byłem programistą Javy, później byłem analitykiem, tak jak zresztą na samym początku powiedziałeś i od czterech lat zajmuję się chmurą. W momencie, kiedy poznałem serverless znowu mam frajdę z programowania, ponieważ bardzo dużo tej żmudnej roboty nie ma w serverless. Dzięki temu znowu fajnie jest programować. Mówię autentycznie. Lubię programować, pomimo tego, że mam tytuł architekta i projektuje rozwiązania. Druga rzecz, o której też chciałem wspomnieć, żartując w odpowiedzi na Twoje pytanie, że nie wiem, dlaczego ludzie mają taką obsesję na temat serwerów i dostępu do nich.

Jak ktoś ostatnio na Twitterze napisał, że dzięki serverless on zapomniał, jak się używa SSH. W sumie też zapomniałem, jak się używa SSH. O co chodzi, patrzę na serwery, jako ogromną listę problemów, które one dostarczają. Przede wszystkim taki serwer trzeba zabezpieczyć, trzeba wziąć pod uwagę, że jego hardware może się popsuć i w chmurze też się hardware psuje i czasem trzeba takie serwery zastopować i uruchomić ponownie, żeby ta wirtualna maszyna została uruchomiona na nowym sprzęcie. Trzeba aktualizować te serwery, trzeba patchować je, tak, żeby to wszystko było bezpiecznie.

Później, tak jak mówiłeś o dostępie, jak w końcu komuś damy ten dostęp do serwera, to on może tam wejść i coś w nim namieszać, pozmieniać i się okaże, że ten serwer i aplikacja, która jest na nim zainstalowana, nie będzie działał poprawnie. Jak dla mnie to serwery są bardzo problemogennym rozwiązaniem i wolę korzystać z funkcji lambda, które są statyczne. Też mnie nie narażają w tak dużym stopniu na zmiany, które są związane z aktualizacją jakichś run time’ów, czy języków oprogramowania. Tutaj przede wszystkim patrzę na Pythona.

Powiedziałeś, że jest kilku dostawców usług typu serverless. Chciałbym Cię zapytać jak obecnie to wypada w kontekście vendor lock-in. Chodzi mi o to, czy wybierając jakiegoś usługodawcę, nie będziemy z nim związani, a zmiana takiego providera w przyszłości może być problematyczna technicznie i finansowo. Co prawda te funkcje, o których rozmawiamy, one są w jakiś sposób niezależną platformą, to jest kod, który może być w łatwy sposób przeniesiony, ale już samo środowisko uruchomienia, nie tak łatwo może dać się przenieść. Czy mamy jakieś potencjalne ryzyko vendor lock-inu decydując się na danego provider według Ciebie?

Tak, to prawda. To ryzyko zawsze istnieje. Chcę tu mocno podkreślić, że moim zdaniem, temat vendor lock-inu jest dosyć mocno nadmuchany i nie wiem dlaczego, ale ludzie bardzo emocjonalnie podchodzą do tej dyskusji. Nie będę próbował odpowiedzieć, dlaczego i szerzyć żadnych teorii spiskowych. Chciałbym odpowiedzieć rzeczowo, że możemy walczyć z vendor lock-in’em, możemy stosować pewne rozwiązania w trakcie programowania, między innymi architekturę heksagonalną, która ma kilka nazw. Jest to architektura sześciokątna albo architektura portów i adapterów.

Właśnie korzystając z różnych usług w tym środowisku jednego dostawcy, czyli powiedzmy mamy funkcje lambda w AWS, mamy bazy danych DynamoDB, mamy jakieś kolejki SQS, chcemy w końcu rozpoznawać co się znajduje na zdjęciach, więc używamy sobie usługi AWS rekognition. Do każdej z tych usług nie podłączamy się bezpośrednio, tylko piszemy zgodnie z myślą architektury portów i adapterów pewien adapter. W związku z powyższym, jeżeli będziemy chcieli się przenieść na inną chmurę, to nie musimy zmieniać całej aplikacji, tylko musimy napisać adaptery do usług, które będą na tej chmurze, na którą chcemy się przenieść. Tutaj założenie jest takie, że każda z tych chmur dostarcza mniej więcej takich samych serwisów, usług. Pomiędzy Azure i AWS, to zdecydowanie jest prawdą.

Natomiast chciałem też jeszcze powiedzieć, że jak zajmuję się serverless od czterech lat, to jeszcze nigdy nie słyszałem w żadnym podcaście, ani na żadnej konferencji, aby ktokolwiek przenosił swoje rozwiązanie z jednej chmury na drugą. Być może takie coś się zdarzyło, być może ktoś to zrobił po to, żeby udowodnić, że się da, natomiast moim zdaniem jest to czysto hipotetyczna sytuacja i ona bardzo przypomina te dyskusje, które 10–15 lat temu się odbywały w związku z bazami danych, z podmianą baz danych, dzięki frameworkom ORM.

Na przykład hibernate w Java oferował możliwość tego, żeby zmienić bazę danych na jakąś inną i to będzie działać bez problemu. Jak dla mnie, ta cała dyskusja o tym vendor lock-inie jest dosyć niepotrzebna. Ona też się tyczy ogólnie chmury, a nie samego serverless i wydaje mi się, że bardzo dużo osób patrzy na vendor lock-in jakby to było więzienie. To nie jest więzienie. Vendor lock-in to jest po prostu koszt liczony w czasie i pieniądzach, zmiany jednej platformy na drugą.

Taka migracja jest projektem IT, który będzie nas kosztował i będzie ileś trwał. Teraz jak o tym rozmawiamy, to moim zdaniem należy zadać sobie pytanie, dlaczego ktoś chciałby w ogóle się przenieść z jednego dostawcy do drugiego. Najczęściej odpowiedzią na to pytanie są „Ceny”. Teraz nigdy w historii nie zdarzyło się, aby AWS podniósł ceny. Natomiast wiem, że Azure podniósł ceny niektórych swoich usług i też niedawno Google podniósł ceny usługi map, tak więc takie sytuacje się zdarzają.

Drugi powód, dlaczego ktoś chciałby sobie zostawić taką możliwość migracji na jedną chmurę, to są wymagania prawne. Nie jestem prawnikiem, więc to bez sensu, żebyśmy eksplorowali tą ścieżkę. Na to pytanie lepiej się skonsultować z kimś, kto się zna na przepisach prawnych. Jakie są konsekwencje tego, że będziemy przygotowywali swoją aplikację, pod to, aby była ona łatwo, albo łatwiej przenaszalna. Na to pytanie mogę odpowiedzieć, bo jestem inżynierem. Według mojej oceny to pisanie aplikacji w architekturze heksagonalnej jest oczywiście narzutem. Sam bym ten narzut ocenił na maksymalnie 20% pracy więcej.

Natomiast jestem zdecydowanym orędownikiem i zachęcam do korzystania z architektury heksagonalnej w serverlees, ponieważ ona się spłaca. Dzięki temu mamy lepszy kod, który jest łatwiejszy do utrzymania i nawet nie myśląc o tym, żeby się migrować do innej chmury, moim zdaniem warto korzystać z tego stylu, ponieważ on też ułatwia testowanie naszych rozwiązań i zapewnia jakiś fajny ład i kod jest fajniejszy, bardziej elegancki. Jeszcze raz bym tutaj ten narzut dał na 20%.

Natomiast jeżeli ktoś by chciał się bardziej przenieść, dokonać tej migracji, to będzie musiał napisać te adaptery dla takiej, czy innej chmury docelowej, na którą musi się przenieść. To będzie trwało pod względem takim, że trzeba to zaprogramować. Będzie to też trwało, bo trzeba się nauczyć tej nowej chmury, więc albo ci sami deweloperzy będą musieli się nauczyć nowej chmury, ale będą mieli wiedzę domenową z tego systemu, który napisali wcześniej dla pierwszej chmury, albo po prostu bierzemy ekspertów programistów od tej chmury docelowej, ale oni z kolei będą się musieli nauczyć naszej aplikacji, tego, co napisaliśmy dla pierwszej chmury. Tutaj więc też będzie jakiś koszt i moim zdaniem duży narzut na to, żeby zrozumieć aplikację i domenę tego systemu, albo po prostu drugą chmurę i drugiego dostawcę.

Podsumowując moim zdaniem, jeżeli nie mamy wymogów prawnych, to tak naprawdę cała dyskusja sprowadza się do tego, czy ewentualnie chcemy płacić więcej, czy mu możemy pozwolić sobie na to, żeby płacić więcej, ale dzięki temu, mamy krótszy czas dostarczania rozwiązań do naszych klientów.

Time to market jest krótszy i rozwój aplikacji jest szybszy, ponieważ nie musimy implementować drugi raz tego samego. Rozmawiając wcześniej o Lego i tej skalowalności, jak ona się przekłada na portfel, jeżeli nasz system jest bardzo dobrze zaimplementowany biznesowo i dostarcza wartość i zarabia na siebie, to bardzo często, lepiej trochę więcej potencjalnie zapłacić, ale po prostu budować tę swoją przewagę konkurencyjną. Przynajmniej ja w to mocno wierzę. Na koniec chciałem dodać, że vendor lock-in, to nie jest jedyny typ lock-inu, który istnieje. Mamy też lock-iny, które się dotyczą produktów. Nie ma co ukrywać, bardzo dużo rozwiązań w chwili obecnej korzysta z kubernetesa. On bardzo często jest przedstawiany, kontenery jako konkurencja wobec serverless i moim zdaniem dzięki Kubernetes możemy się łatwo przenosić pomiędzy różnymi dostawcami, natomiast mamy lock-in, jeżeli chodzi o oprogramowanie, platformę Kubernetes. Tuta mamy jakby trade off, że mamy większa dowolność, jeśli chodzi o dostawców, ale jesteśmy uzależnieni od jednego konkretnego oprogramowania i de facto w jakiś sposób od Google’a, który jest autorem tego.

Inny przykład, też pamiętam z Polski. W którymś mieście oprogramowanie, które było wykorzystywane przez tramwaje, było tak napisane, że wymagało Windowsa XP. Migracja na jakiś nowszy system operacyjny albo Linuxa wiązała się z ogromnym kosztem. Trzeba było przepisać tę aplikację, żeby działała z tym nowszym systemem operacyjnym. To jest zawsze jakiś trade off i tych lock-inów jest dużo. Możemy na wybór języka oprogramowania spojrzeć też jako na lock-in, który daje nam pewne benefity i też nas ogranicza pod innymi względami.

👉 Czytaj dalej na: https://porozmawiajmyoit.pl/poit-086-serverless/

kkempin’s dev blog

Dev and life blog.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store