POIT #086: Serverless

Witam w osiemdziesiątym szóstym odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy jest serverless.

Dziś moim gościem jest Paweł Zubkiewiczod ponad 14 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 blogger.

W tym odcinku o serverless rozmawiamy w następujących kontekstach:

  • czym jest serverless od strony architektury?
  • czym jest zagadnienie cold startu?
  • czym są funkcje lambda i podejście FaaS?
  • jak zapewnia się stanowość w aplikacjach opartych o serverless?
  • jak to podejście wypada w kontekście kosztów?
  • czy duża skalowalność nie zagraża kosztom?
  • czy brak dostępu do większości opcji konfiguracji infrastruktury nie jest ograniczeniem?
  • czy nie mamy zagrożenia typu vendor lock-in?
  • w jakich zastosowaniach serveless sprawdzi się idealnie a w jakich się nie sprawdzi?
  • czym jest manifest serverless?
  • jakie są najczęstsze pułapki i niebezpieczeństwa tego podejścia?
  • jak w serverless można monitorować aplikację?
  • jakie języki programowania możemy wykorzystywać?
  • jak wygląda rynek pracy dla specjalistów z tego obszaru?
  • jak będzie wyglądał rozwój podejścia serverless?

Rekomendowany podcast:

Subskrypcja podcastu:

Linki:

Wsparcie na Patronite:

Wierzę, że dobro wraca i że zawsze znajdą się osoby w bliższym lub dalszym gronie, którym przydaje się to co robię i które zechcą mnie wesprzeć w misji poszerzania horyzontów ludzi z branży IT.

Patronite to tak platforma, na której możesz wspierać twórców internetowych w ich działalności. Mnie możesz wesprzeć kwotą już od 5 zł miesięcznie. Chciałbym oddelegować kilka rzeczy, która wykonuję przy każdym podcaście a zaoszczędzony czas wykorzystać na przygotowanie jeszcze lepszych treści dla Ciebie. Sam jestem patronem kilku twórców internetowych i widzę, że taka pomoc daje dużą satysfakcję obu stronom.

👉Mój profil znajdziesz pod adresem: patronite.pl/porozmawiajmyoit

Pozostańmy w kontakcie:

 

Muzyka użyta w podcaście: „Endless Inspiration” Alex Stoner  (posłuchaj)

Transkrypcja podcastu

To jest 86. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o serverless.

Przypominam, że w poprzednim odcinku rozmawiałem o DataOps.

Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/86.

Jeśli jeszcze tego nie zrobiłeś, to wystaw ocenę lub recenzję podcastowi w aplikacji, w której tego słuchasz.

Chcę poszerzać horyzonty ludzi z branży IT i wierzę, że poprzez wywiady takie jak ten, publikowane jako podcasty, będę to robił z sukcesem.

Zazwyczaj pytam moich gości, jakich podcastów słuchają, ale dzisiaj to ja mam pewien podcast do polecenia. Ten podcast to Docplanner Tech Talks, prowadzony przez Przemka Paczoskiego, Team Leadera oraz Test Automation Engineer Docplanner Tech.

Jeśli nie słyszałeś o Docplannerze, to z pewnością kojarzysz serwis ZnanyLekarz, który jest obecnie jednym z największych Polskich Startupów. 

Docplanner Tech to część technologiczna firmy z siedzibami w Warszawie i Barcelonie. Celem zespołu jest zmienianie doświadczeń związanych z opieką zdrowotną, aby były bardziej przyjazne, dostępne, po prostu ludzkie. W podcaście możesz liczyć na dużą dawkę wiedzy technicznej, na przykład związanej z tematyką DevOps, z biznesowymi wątkami, między innymi o procesie połączenia dwóch spółek w jedną firmę, czy podejściu do aspektu People Experience pod kątem budowania nowych zespołów, oraz dbania o obecne. 

Podcast prowadzony jest z dużą pasją, więc polecam. 

Możesz go wyszukać w swojej aplikacji podcastowej wpisując Docplanner Tech Talks lub wejść przez link z notatki do tego odcinka.

 

Nazywam się Krzysztof Kempiński i życzę Ci miłego słuchania. 

Odpalamy!

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.

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.

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.

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. 

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.

Jeżeli mamy dobrze zaprojektowany system, to każda transakcja, którą system przetwarza, daje naszej firmie jakiś zysk.

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 przenoszalna. 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. 

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. 

Jasne. Mówimy tutaj o tym, że trzeba świadomie podchodzić do takich rzeczy, podejmować decyzje rozważając różne rzeczy, które wokół tej decyzji mogą krążyć, albo przewidywać konsekwencje. Wobec tego chcę Cię zapytać, czy są z góry określone, albo znane Tobie przypadki użycia, albo zastosowania, które mógłbyś powiedzieć, że serverless sprawdzi się tam idealnie, bardzo dobrze, a w innych niekoniecznie byłby to najlepszy wybór. 

To jest świetnie pytanie, bardzo inżynierskie i niesamowicie się cieszę, że mi je zadałeś. Z miłą chęcią na nie odpowiem bardzo konkretnie. Nie zamierzam się wymigiwać wyświechtanym sformułowaniem „to zależy”. Dlaczego tak będzie? Ponad pół roku temu zacząłem w swoich prywatnych notatkach odnotowywać takie sytuacje, gdzie ludzie, bazując na swoich doświadczeniach we wdrażaniu systemu, mówili o tym, gdzie znaleźli ścianę, ograniczenie, którego się nie dało przejść. 

Zwracam uwagę od dłuższego czasu na te ograniczenia, po to, żeby konkretnie umieć ludziom udzielić odpowiedzi na takie pytanie. Zacznijmy od tego, gdzie serverless się sprawdzi. Teraz bardzo konkretnie. Serverless sprawdzi się w praktycznie każdej aplikacji biznesowej, czyli jak masz jakąś aplikację WEBową, albo mobilną, mówimy oczywiście o backendzie dla tej aplikacji mobilnej. Albo jakąś platformę sprzedażową, z której korzysta pięć, pięćset albo nawet pięćdziesiąt tysięcy osób, to serverless jest idealny. Idziesz w serverless implementacją jak w dym, na moją odpowiedzialność i na pewno się nie zawiedziesz. 

Drugi przypadek użycia, bardzo popularny, to jest asynchroniczne przetwarzanie. Mowa tu o requestach lub przetwarzaniu danych. To jest generalnie bardzo popularny przypadek użycia. Mogę podać przykład, że w Stanach Zjednoczonych jest tak Pan, który w całości działa na chmurze AWS i on przetwarza transakcje swoich klientów, transakcje finansowe najczęściej dokonywane kartą kredytową. Oni mówią, że przetwarzają około tysiąca transakcji finansowych na sekundę i szukają pewnych nadużyć, które mogą spotkać klientów w tym banku przez jakieś niedopatrzenia, lub celowe działanie firm trzecich, gdzie klienci płacą. Ich techniczne spostrzeżenia, inżynierów w tym banku były takie, że udało im się obniżyć koszty działania tego rozwiązania wyszukującego właśnie takie złe transakcje, od siedmiu do dziesięciu razy w stosunku do serwerowego odpowiednika, który wcześniej realizował tę samą funkcjonalność. To pokazuje jak fajnie się sprawdza serverless przy przetwarzaniu danych takim asynchronicznym.

Może podam takie konkretne ograniczenia, bo prawdopodobnie słuchacze bardzo są tym zainteresowani. Jeżeli Twój system musi mieć czas odpowiedzi poniżej 50 milisekund, albo w ogóle oczekuje odpowiedzi na poziomie pojedynczych milisekund, to serverless na zdecydowania się nie nada. Na ogół czasu odpowiedzi w serverless są rzędu setek milisekund, na przykład AWS Lambda odpowiada w takich przedziałach, szczególnie jeśli mamy również ją połączoną z APA gateway. 

Tak więc przykładem tego i nawet sam AWs o tym mówi, że w Amazonie, sklepie, oni mają hale, w których trzymają te produkty i w tych halach pracują ludzie, ale również pracują roboty. Teraz do robotyki serverless się jeszcze nie nadaje, ponieważ tam oczekiwanie jest takie, że serwery będą pracowały na poziomie pojedynczych milisekund. Będą dokonywały obliczeń, ponieważ chodzi także o bezpieczeństwo ludzi, którzy tam pracują. Tutaj serverless nie ma zastosowania. Z podobnych powodów streaming gier video, wymagania, jeżeli chodzi o latencje, są zbyt wysokie wobec serverless. 

Kolejnym ograniczeniem są karty graficzne. Na chwilę obecną, do funkcji lambda nie możemy podpiąć karty graficznej. W związku z powyższym, jeżeli Twoje wymagania są takie, że chciałbyś korzystać z obliczeń dokonywanych na GPU, to tego się na chwilę obecną nie da się zrealizować AWS. Inny przykład z życia wzięty to jest przykład, o którym mówił Yan Cui, w którymś ze swoim podcastów. To jest sytuacja, kiedy w ich systemie chcieli się zeskalować od dwustu użytkowników do miliona dwustu tysięcy użytkowników w 30 sekund. To było w aplikacji DAZN. To jest sportowy odpowiednik Netflixa. Opowiadała o przypadku, kiedy ludzie na 30 sekund przed rozpoczęciem meczu piłki nożnej logowali się masowo do ich systemu i chcieli włączyć streaming. Stąd jest taka duża skala, skok tych użytkowników. 

Ogólnie chcę też podkreślić, że dużo ograniczeń znika. Na przykład do pewnego czasu, do funkcji lambda nie można było podpiąć dysku sieciowego. W chwili obecnej jest już to możliwe. Taki dysk sieciowy może być podpięty, ten sam do wielu funkcji lambda równocześnie, dysk ma nieograniczoną pojemność, więc my już nie jesteśmy ograniczeni pojemnością 500 Mega, jak to było do niedawna, tylko na tym dysku możemy składować pliki dowolnej wielkości. Ta sama funkcjonalność otworzyła bardzo dużo nowych przypadków użycia, gdzie możemy zastosować serverless. część z nich są to przypadki, które łączą się z machine learningiem, więc to też jest bardzo ciekawa dziedzina, gdzie serverless i machine learning, dwa baseworldy się fajnie łączą i działają. Natomiast w tym momencie chciałbym podkreślić i zaapelować do osób, które może parę lat temu miały styczność z serverless i wtedy serverless nie spełniało ich wymagań, aby zrobili review i takie review, żeby robili co pewien czas, ponieważ AWS bardzo mocno i dużo rzeczy zmienia w platformie i udostępnia nowe funkcjonalności, które odblokowują nowe przypadki użycia i zastosowania właśnie tej platformy. 

Ogólnie chcę też podkreślić, że dużo ograniczeń znika. Na przykład do pewnego czasu, do funkcji lambda nie można było podpiąć dysku sieciowego. W chwili obecnej jest już to możliwe.

Cieszę się, że powiedziałeś, że ta świadomość serverless rośnie. Jak gdyby przejawem tej rosnącej świadomości jest tak zwany manifest serverless. Powiedz proszę, czym jest ten manifest i jakie najważniejsze przykazania z niego wypływają?

Manifest to zbiór pewnych przykazań albo pryncypiów architektonicznych. osobiście wydaje mi się, że był mocno zainspirowany Agile Manifesto. Tych pryncypiów jest tam dziesięć. Nie pamiętam osobiście wszystkich. Jest kilka moim zdaniem najważniejszych, pierwszy z nich mówi o tym, żeby programować tylko to, co daje Ci przewagę konkurencyjną. Wielokrotnie to powtarzałem dzisiaj na podcaście i nie tylko na podcaście to powtarzam. To, co nie daje Ci przewagi konkurencyjnej, co nie jest Twoją logiką biznesową, po prostu bierz z rynku. 

Moim zdaniem to ma sens i to jest clue usługi lambda, że my implementujemy tylko to, co daje wartość naszym klientom, a resztę najlepiej zoutsourceować, czyli brać jakieś gotowe biblioteki, gotowe usługi, nie zajmować się tym. Oni mówią, pewnie nie każdy się z tym zgodzi, że własny kod, to jest koszt. Należy go utrzymywać na minimum. To może być dosyć ciężkie do zrozumienia dla wielu osób, ponieważ przez lata wszyscy nam mówili o tym, że kod to jest własność intelektualna, to jest to, co buduje wartość firmy, a tutaj jest totalne przeciwieństwo. 

Przypomniało mi się właśnie, że w historii IT też było parę głośnych przypadków, kiedy ktoś po prostu poszedł do więzienia za to, że udostępnił czyjś kod, ponieważ to było coś opatentowanego albo po prostu jakiś tajny kod danej firmy. Takie sytuacje zdarzały się w Stanach Zjednoczonych. Tutaj mamy zupełnie nowe podejście, które bazuje na tym, żeby pisać jak najmniej, a wykorzystywać już gotowe rozwiązania. 

Oni mówią o tym w manifeście, aby nie używać serwerów, wirtualnych maszyn, kontenerów, chyba, że inaczej się nie da. To, co jest najważniejsze w tym manifeście, to jest to, co z niego wypłynęło, czyli podejście serverless first. Czyli generalnie, jeżeli w firmie mamy nowy system do zaimplementowania, to podążając tym podejściem serverless first, z założenia w Bi-Fold zakładamy, że będziemy go implementować w serverless. Robimy sobie powiedzmy, burzę mózgów i próbujemy znaleźć dowolne przeciwwskazania, dlaczego w serverless nie da się tego zaimplementować. Musimy korzystać z kart graficznych, ale jeżeli nie znajdziemy takich powodów, to wtedy implementujemy rozwiązanie w serverless.

Chciałbym Cię jeszcze zapytać o temat, który trochę nam się tutaj przewijał w trakcie rozmowy, w różnych wątkach, ale myślę, że dobrze by to było podsumować. Jakie problemy, pułapki, czy niebezpieczeństwa z użytkowania serverless, takie najczęściej występujące zauważasz?

Wiesz co, jedną z takich rzeczy, o której na pewno warto wspomnieć, to są wszystkie pułapki związane z implementacją systemów rozproszonych. Tutaj musimy się cofnąć właściwie do lat 70-tych poprzedniego wieku, ponieważ tutaj nie ma właściwie nic nowego. Mówimy o takich mitach, że latencja jest równa zero, że sieć jest zawsze dostępna i nie ma z nią problemów, że mamy kontrolę nad siecią i tak dalej. 

Jeżeli ktoś nie miał doświadczenia z implementowaniem mikroserwisów, które są systemami rozproszonymi, to pracując w chmurze, gdzie wszystko jest rozproszone i wszystkie te serwisy łączą się ze sobą po sieci, możesz się zdziwić, że czasami ma tak zwany długi ogon, czasem któraś funkcja lambda, zamiast wywołać się w dwieście milisekund, to będzie trwała cztery sekundy i będzie to dla niego niezrozumiałe, dlaczego tak się dzieje i w ogóle nie będzie wiedział jak podejść do takiego problemu. To jakby nie jest pułapka serverless, tylko tak wygląda programowanie w systemach rozproszonych. 

Inna rzecz, która jak gdyby nie jest problemem serverless, ale wpływa mocno na codzienne implementowanie i dostarczanie aplikacji, to jest szeroko rozumiana wiedza i ekspertyza na temat chmury. Moim zdaniem, jeżeli ktoś mocno ograniczoną wiedzę na temat usług, z których korzysta jego rozwiązanie serverless, to dosyć szybko napotka jakieś problemy. Tutaj jak z każdą nową rzeczą w życiu, po prostu trzeba się tego nauczyć i trzeba po prostu dać sobie pole do błędów, do nauki, do tego, że na samym początku pewne funkcjonalności będziemy dłużej implementowali, niż jakbyśmy to robili w starych dobrze znanych rozwiązaniach. Tutaj nie ma nic złego w tym wszystkim, tylko zwracam uwagę, że ta wiedza jest niezbędna i trzeba ją nabrać, najlepiej poprzez praktykę i naukę. 

Rzecz, która wiąże się z praktyka i nauką, to jest to, że niektóre usługi zaczynają się troszkę inaczej zachowywać, w sposób nieoczekiwany, w momencie, kiedy mamy bardzo duże wolumeny transakcji. Natomiast kiedy dochodzimy, to jest ten przykład, który wcześniej podałem o tym skalowaniu do miliona dwustu tysięcy użytkowników, więc gdzieś są te ograniczenia przy dużej skali, ale to początkujący użytkownicy na nie nie natknął się. Więc to też nie jest jakąś pułapką, to może być bardziej zaskoczeniem. Jeżeli ktoś ma tego typu problemy, to jest naprawdę pewnie już specjalista albo i ekspertem w tej dziedzinie, więc to tylko pogratulować moim zdaniem. To są rzeczy z usługami. 

Jeżeli chodzi o podejście ludzi, to właśnie pułapką jest to, że ktoś nie będzie chciał się rozwijać i uczyć tych usług, to z takim podejściem niestety mu się nie uda. Jeżeli ktoś by chciał zasymulować całą chmurę na swoim lokalnym komputerze, tak jak powiedzmy, to się daje zrobić, pracując z aplikacjami monolitycznymi, to tutaj niestety się, tak nie da, Ten proces developmentu jest trochę inny i wymaga tego, żebyśmy byli bardziej powiązani z tą chmurą, testowali w niej bezpośrednio, a nie na swoim komputerze. 

Nawiasem mówiąc, jest to bardzo fajne, bo wreszcie znika ta standardowa odpowiedź programisty „A u mnie działa”. Więc nie ma więcej „U mnie”, jest po prostu chmura i albo działa, albo nie działa. Myślę, że warto dodać na koniec, że szacowanie kosztów jest ciężkie, ale jest to ciężkie generalnie w chmurze. Serverless być może jeszcze cięższe niż ogólnie w chmurze, ale to dlatego, że zależy od wolumenu, ruchu. Jak rozmawiamy z klientami, to właściwie jest taki ping-pong na ogół, klient się pyta, ile to będzie kosztowało, a my się pytamy, ile będzie użytkowników i co będą dokładnie robić. Klient nie wie, my nie wiemy i wtedy ciężko jest to oszacować. Można to po prostu wziąć i sprawdzić pisząc jakiś proof of concept, który zazwyczaj jest ekstremalnie tani, albo wręcz darmowy i wtedy możemy to sobie sprawdzić i później na bazie tego policzyć te koszty. 

Musimy się cofnąć właściwie do lat 70-tych poprzedniego wieku, ponieważ tutaj nie ma właściwie nic nowego. Mówimy o takich mitach, że latencja jest równa zero, że sieć jest zawsze dostępna i nie ma z nią problemów, że mamy kontrolę nad siecią i tak dalej.

Powiedziałeś, że analizowałeś tę swoją aplikację, która bardzo szybko wyciągnęła dolary z Twojego konta, właśnie do tego wątku chciałbym trochę nawiązać. Mam pytanie od strony developerskiej, trochę DevOpsowej, nawet kiedy mamy taką aplikację działającą według tej klasycznej architektury, jak to na początku nazwałeś, to gdzieś tam na serwerze generują się jakieś logi, możemy sobie w jakiś sposób sprawdzać, dywagować co tam się mogło wydarzyć, natomiast jak to zrobić w przypadku serverless? W jaki sposób się monitoruje aplikacje, w jaki sposób się bada, sprawdza, czy ona nadal działa poprawnie?

Tak jak wspominaliśmy i tak jak powiedziałeś, nie mamy dostępu do serwera, ten serwer nie istnieje. Mamy tylko kontener, który istnieje kilkanaście, kilkadziesiąt minut, więc nawet jeżeli coś zapiszemy na nim, to prędzej czy później zniknie, ponieważ taki kontener jest usuwany przez usługę AWS Lambda. W związku z powyższym funkcje lambda wysyłają swoje logi bezpośrednio do takiej usługi, która się nazywa CloudWatch. Ta usługa służy między innymi do tego, aby te logi gromadzić z różnych miejsc, tak samo ja mam w projektach serwerowych Tomcata, który zapisuje logi lokalnie na dysku i te logi z dysku wirtualnej maszyny są kopiowane do CloudWatcha. Więc CloudWatch służy z jednej strony do gromadzenia logów, ale również do tego, żeby je przeszukiwać, żeby jakieś metryki można było tworzyć i również dodawać alarmy. To jest podstawowa usługa. 

Mamy również inną usługę, która się nazywa AWS X-Ray. Ta usługa służy do tego, jak sama nazwa wskazuje, aby prześwietlać funkcje lambda, to jak została wykonana. Ona również pozwala nam wyrysować automatycznie coś na kształt mapy, czyli to, jak jedna funkcja zwraca wynik do jakiejś innej funkcji, albo przesyła ten wynik na kolejkę, ta kolejka z kolei wywołuje inną funkcję i tworzy nam się taki przebieg. Ogólnie rzecz biorąc, aplikacje serverless monitorujemy, podążając za takim podejściem, które po polsku się nazywa „Obserwowalność”. Ta obserwowalność się składa z trzech podstawowych kategorii, o których powiedziałem, czyli mamy logi, metryki, czyli na bazie tego, jakie mamy pewne zużycia, albo czasy reakcji, możemy ocenić, czy system działa poprawnie, czy nie, i mamy w końcu trzeci filar, czyli śledzenie przepływów. 

Tak jak powiedziałem, jeżeli mamy kilka funkcji, to te dane przebiegają pomiędzy tymi funkcjami. Co więcej, pełne aplikacje serverless składają się z wielu mikroserwisów, a każdy z tych mikroserwisów składa się z funkcji. Te przepływy pomiędzy różnymi mikroserwisami oraz różnymi usługami, z których korzystamy od naszego dostawcy, możemy sobie wyrysować właśnie za pomocą usługi X-Ray. Na bazie tego wszystkiego możemy sobie zdefiniować alarmy, czyli możemy powiedzieć, że jeżeli czasy reakcji jakichś funkcji lambda wzrosną, to mamy zostać poinformowani albo jeżeli mamy jakiś Rest Endpoint i on zaczyna zwracać nam cztery setki, albo pięćsetki, to też dostaniemy jakiś alarm. Do tego też możemy rysować pewne diagramy i z całej tej całości, w tym podejściu obserwowalności, my po prostu bazując na tych wszystkich informacjach, musimy się nauczyć, jak w praktyce działa ta nasza aplikacja i jak się ten system zachowuje w momencie, kiedy działa poprawnie. Teraz odstępstwa od tego normalnego stanu powinny być jakimiś wskaźnikami tego, że coś się dzieje źle. Myślę, że każdemu, kto zaczyna z serverless, radzę, żeby się skupił na bardzo dobrym logowaniu i zapisywaniu informacji, co się dzieje w kodzie, jakie dane są przechwytywane. Dzięki temu będzie łatwiej się nauczyć jak ta funkcja lambda działa, a zbiegiem czasu dokładać dodatkowe rzeczy, jak metryki, śledzenia przepływów.

Powiedziałeś, że to, że mamy ograniczony zakres technologii, z których możemy korzystać, opierając swoje rozwiązania serverless, to może być w jakiś sposób taki mechanizm nas broniący. Wobec tego chciałem Cię zapytać, jakie języki możemy wykorzystać, jakie języki możemy brać pod uwagę po to, aby napisać nasze funkcje?

Od dłuższego czasu istnieje możliwość ustawienia tak zwanych custom runtime. Czyli de facto możemy wykorzystać dowolny język programowania, musimy mieć tylko środowisko uruchomieniowe dla niego. Przypuszczam, że dla wszystkich popularnych i tych mało popularnych języków istnieją już gotowe runtime’y opublikowane na GitHubie, z których możemy bardzo łatwo skorzystać, jeżeli mamy potrzebę pisać w mniej popularnym języku. Wiem, że jedna z osób, które u mnie są na szkoleniu, pisze funkcje lambda w języku C, który jest raczej niepopularny, jeżeli chodzi o rozwiązania serverless. 

Natomiast to, co jest dostępne bezpośrednio od AWS, jeżeli chodzi o AWS Lambda, to są to języki skryptowe, takie jak Python, JavaScript, które są najbardziej popularne w środowisku serverlessowym. Myślę, że od kilku lat Java Script, czyli runtime.js wiedzie prym. Mamy też Go, ale też mamy rozwiązania powiedzmy bardziej enterprise, powiedzmy jak Java oraz CSHacked, czy generalnie .NET. Obserwuję, że powoli właśnie ich popularność rośnie. To jest spowodowane dwoma niezależnymi czynnikami. 

Pierwszy z nich moim zdaniem to jest to, że duże przedsiębiorstwa, ten cały korpo świat, albo enterprise, on powoli przekonuje się do chmury, ale również do serverless z powodu tych wszystkich zalet, o których mówiliśmy, czyli przede wszystkim mniejszych kosztów, oraz krótszemu czasowi dostarczania rozwiązań. Dużo mniejsze wymagają, jeżeli chodzi o utrzymanie tych rozwiązań. W związku z tym enterprise zaczyna korzystać z serverless. Taki enterprise zazwyczaj ma programistów Javy albo technologii Microsoftu. Czasem ciężko jest przekonwertować się tym osobom na języki skryptowe. Dlatego widać coraz większa popularność Javy. Oczywiście ona jest dużo mniejsza niż Python czy JavaScript, ale widać jakiś trend rosnący. 

Drugi czynnik jest taki, że AWS bardzo mocno pracuje, aby właśnie zminimalizować cold starty dla tych języków, które są kompilowane. Ponieważ duży wpływ jest tego, czy mamy do czynienia z językiem skryptowym, czy kompilowanym na to, jaki będzie cold start. Historycznie Java i .NET miały najdłuższe cold starty, ale z biegiem lat one są coraz mniejsze. Myślę, że doszliśmy do takiego poziomu, kiedy jesteśmy nawet w stanie napisać za pomocą Javy funkcje lambda, które będą odpowiadały na bezpośrednie żądania klienta. W sensie człowieka. Te czasy cold startów i uruchomienia takiej funkcji napisanej w Javie są na tyle krótkie, że są to czasy akceptowalne.

Chcę Cię zapytać o rynek pracy, który jest związany z serverless. Czy serverless to jest taka specjalizacja wśród specjalizacji, chodzi mi o to, czy ludzie od serverless to specjaliści od chmury, którzy mają jeszcze węższą specjalizację? Czy obserwujesz oferty pracy, które są właśnie bezpośrednio adresowane do inżynierów serverless, czy nie ma jeszcze takiej świadomości, raczej poszukuje się ludzi od chmury, którzy później takie zadania serverlessowe wykonują?

Wiesz co, uogólniając, jestem zdania takiego, że w chmurze pracują osoby, które wywodzą się z dwóch środowisk. Albo byli i są programistami, albo byli bardziej po tej stronie utrzymania, czyli byli administratorami, osobami odpowiedzialnym za sprzęt. Myślę, że ten podział w chmurze jest trochę mniejszy, ale nadal zauważalny. Osoby, które zajmują się serverless, to jednak moim zdaniem to jest specjalizacja tej części osób, które zajmowały się programowaniem. 

Są różne usługi dostępne w AWS-ie i możemy z powodzeniem budować i utrzymywać systemy, które korzystają z serwerów wirtualnych, ale ciągle serwerów, a serverless jest pewną specjalizacją, chociaż korzysta z innych usług. Jeżeli spojrzymy z perspektywy usług, to są inne usługi niż w tych serwer full rozwiązaniach. Jeśli chodzi o rynek i to, jak dużo jest zapytań, ofert pracy, to muszę powiedzieć, że na Slacku Serverless Polska napisałem takiego prostego bota, który sobie wchodzi na jedną ze stron polskich, na których są publikowane oferty pracy. 

Myślę, że raz na tydzień się pojawia od jednej do trzech ofert pracy, gdzie słowo „Serverless” jest wymienione. To nie jest oszałamiająca ilość, ale też musimy pamiętać, że technologia jest mało powszechna i nie wszyscy wiedzą czym jest serverless. A z kolei ci, którzy wiedza, też niekoniecznie muszą w ofertach pisać bezpośrednio, że szukają programisty serverless, ponieważ jest ich na rynku tak mało, że właściwie z automatu zamknęliby sobie możliwość zatrudnienia osób, które dopiero chciałyby się rozwijać w kierunku serverless. Prawdopodobnie te ogłoszenia o pracę są trochę bardziej ogólne, natomiast nawet na polskim rynku, ostatnio dużo ofert serverlessowych, jedna z większych firm oferowała. Taka dosyć duża, więc nie będę wymieniał z nazwy, więc to jest dosyć popularne, albo staje się coraz bardziej popularne.

Teraz mam pytanie związane z przyszłością. Jak według Ciebie będzie wyglądał rozwój i podejście do serverless w najbliższej przyszłości? Jakie trendy obserwujesz, które według Ciebie będą znaczące w przyszłości w tym temacie?

Patrząc na to z perspektywy kilku lat, widzę, że AWS mocno postawił na serverless, obrał kurs w tym kierunku i konsekwentnie rozwija swoje usługi właśnie biorąc pod uwagę serverless. Myślę, że to będzie trwało. Pewne rzeczy będą się zmieniały. Jeszcze raz chcę wspomnieć, że na początku lambda była uznawana za taki klej, glue, który łączył ze sobą różne usługi i ona była nie tylko od tego, żeby implementować logikę biznesową, ale również do integracji, do tego, żeby przesyłać informacje pomiędzy systemami. Natomiast tak jak wspomniałem w zeszłym roku, Chris Moss powiedział „Transform not transport”, myślę, że to jest nowszy, mocniejszy trend, który widać już w rozwoju niektórych usług, zmianach, w nowych funkcjonalnościach, które są dodawane. 

To na pewno będzie coraz bardziej się rozwijało w kierunku takim, aby my, czyli programiści, żebyśmy nie musieli pisać zbędnego kodu, a żebyśmy mogli się skupić na logice biznesowej, implementacji feature’ów na budowanie tej przewagi konkurencyjnej, na realizacji tego, co po prostu sprawia przyjemność naszym klientom i użytkownikom. Oprócz tego myślę, że takie rozwiązania function as cordless, czyli też integracje z pominięciem funkcji lambda, gdzie my, jako programiści już de facto nie będziemy programować, a będziemy zajmowali się konfiguracją usług, tak, aby te usługi razem zintegrowane, realizowały nasze wymagania, cele. 

Ciekawa przyszłość przed nami. Ok, Paweł, bardzo Ci dziękuję za ciekawą rozmowę, za pokazanie tych wielu aspektów tego zagadnienia, jakim jest serverless. Muszę powiedzieć, że sam się wiele dowiedziałem, także bardzo dziękuje. Powiedz, proszę, na końcu, gdzie Cię można znaleźć w internecie, w jaki sposób się z Tobą skontaktować.

Również Tobie bardzo dziękuję. Jestem szczęśliwy, kiedy mogę porozmawiać o serverless i nakłonić nowe osoby do tego, żeby zaczęły go używać i spróbowały, ponieważ jestem przekonany, że to jest bardzo fajna architektura, bardzo dobre rozwiązanie i też tak jak wspominałem, przywraca fan z pracy, jeżeli jesteś programistą, a to moim zdaniem jest bardzo ważny faktor w naszym życiu, żeby się cieszyć z tego, co robimy. Mnie możecie znaleźć w internecie. Najlepiej, jeżeli zaczniecie od strony serverlesspolska.pl. Jest to strona, którą stworzyłem i prowadzę, gdzie pisze o serverless, umieszczam różne tutoriale jak rozpocząć serverless, jak również informacje dla osób zaawansowanych, dotyczące bezpieczeństwa, albo użycia jakiś konkretnych usług w połączeniu z funkcją lambda. Oprócz tego znajdziecie mnie na LinkedInie, na Twitterze, szukajcie pod Paweł Zubkiewicz, albo P. Zubkiewicz. To są linki, którymi się posługuje.

Świetnie. Oczywiście wszystkie linki, o których wspomniałeś, zawrę w notatce do tego odcinka. Z mojej strony jeszcze raz bardzo dziękuję. 

Do usłyszenia, cześć!

Dziękuję, cześć!

To na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Serverless to jedno z tych podejść do architektury rozwiązań informatycznych, który będzie z pewnością mocno rozwijało się w najbliższym czasie. Warto więc wiedzieć, czym jest, a może również spróbować się z nim zaprzyjaźnić, bo specjalistów na rynku od tego podejścia bardzo brakuje.

Jeśli doceniasz to, co robię, wesprzyj mnie na Patronite. To taka platforma, na której możesz wspierać twórców internetowych. Mnie możesz wesprzeć kwotą już od 5 zł miesięcznie. Wejdź na porozmawiajmyoit.pl/wspieram i sprawdź szczegóły.

Jeśli masz jakieś pytania, pisz śmiało na krzysztof@porozmawiajmyoit.pl. 

Nazywam się Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o serverless.

Zapraszam do kolejnego odcinka już za tydzień.

Cześć!

+ Pokaż całą transkrypcję
– Schowaj transkrypcję
mm
Krzysztof Kempiński
krzysztof@porozmawiajmyoit.pl

Jestem ekspertem w branży IT, w której działam od 2005 roku. Zawodowo zajmuję się web-developmentem i zarządzaniem działami IT. Dodatkowo prowadzę podcast, kanał na YouTube i blog programistyczny. Moją misją jest inspirowanie ludzi do poszerzania swoich horyzontów poprzez publikowanie wywiadów o trendach, technologiach i zjawiskach występujących w IT.