Co to jest serverless?

28 grudnia 2019 · 5 minut czytania

Mniej więcej 10 lat temu zacząłem pracować jako programista. Przez ten okres diametralnie zmieniło się to, w jaki sposób tworzymy oprogramowanie. Mimo że kod piszemy w tych samych lub podobnych językach programowania, to zmieniło się m.in. to jak projektujemy systemy czy jak bardzo uwzględniamy głos użytkowników w decyzjach produktowych. A przede wszystkim, rynek, w którym funkcjonują nasze produkty, stał się dużo bardziej konkurencyjny.

Z technicznej perspektywy przeszliśmy od tworzenia wielkich monolitycznych aplikacji, przez architektury zorientowane na usługi do mikrousług. Z uruchamiania aplikacji na serwerze hostingowym, przez wirtualne maszyny do kontenerów w chmurze. W każdym z tych kroków chodziło o to, żeby zwiększyć produktywność programistów a tym samym szybkość tego, jak możemy ulepszać produkt. Stąd wziął się serverless. Jest kolejnym krokiem w dostarczaniu niezawodnych i produktywnych narzędzi programistom. Jest ewolucją, nie rewolucją. Nie jest ani początkiem, ani końcem, i za kolejne 10 lat serverless będzie po prostu (nową) chmurą. Jednocześnie…

…serverless nic nie znaczy

Co łączy toster, walec, psa i kosmos? Nic, poza tym, że te wszystkie rzeczy są serverless. Podobnie jak inne buzzwordy, serverless z czasem zyskał wiele znaczeń i aktualnie wiele rzeczy “nie ma serwera”. Powoduje to, że dla osób, które dopiero zapoznają się z tym terminem, ciężko zrozumieć co on oznacza. Dodatkowo termin ten nie mówi, czym to coś jest, tylko czym nie jest (podobnie było z NoSQL). Ten wpis podsumowuje to, co dzisiaj oznacza serverless i w jakich kontekstach jest używany.

W ramach ciekawostki historycznej. Zgodnie z prezentacją Serverless is dead Chrisa Munnsa pierwsze użycie “serverless” datuje się na 2010 rok.

Google Trends: serverless https://trends.google.com/trends/explore?date=2014-01-01%202020-01-02&q=serverless

Usługi serverless

W kontekście chmury termin zaczął być popularny w 2015 r. po tym, jak AWS uruchomił usługę Lambda (listopad 2014 r.) i API Gateway (lipiec 2015 r). Te dwie usługi pozwoliły wystawić endpoint HTTP do internetu bez użycia serwerów. Tym samym serverless zaczęto używać jako termin opisujący usługi chmurowe, za które płacimy, tylko jeżeli są używane, są auto skalowalne i nie wymagają od nas zarządzania serwerami.

Płacimy tylko, jeżeli używamy

Jeżeli nasz kod nie jest wywoływany, to nic nie płacimy. To podejście umożliwia dużo lepsze zrozumienie i tym samym planowanie kosztów infrastruktury. Wcześniej, korzystając z usług chmurowych, w jakimś stopniu musieliśmy zaplanować, ile zasobów potrzebujemy i brać pod uwagę nagłe zmiany w zapotrzebowaniu spowodowane np. nagłym wzrostem ruchu do naszej aplikacji. Teraz, ten problem został w większości rozwiązany za nas.

Costs Koszty usług serverless w porównaniu z tradycyjnymi usługami chmurowymi. https://www.trek10.com/blog/business-case-for-serverless/

W przypadku usług obliczeniowych (ang. compute) jest to dość oczywiste — kod się nie wykonuje, więc nie płacimy. W przypadku usług innego typu koszty mogą zależeć od innych czynników, np. w przypadku baz danych powinniśmy płacić za liczbę zapytań o dane i dodatkowo za dane, które już zapisaliśmy w tej bazie danych.

Model, w którym płacimy faktycznie za zasoby, które wykorzystujemy, jest głównym czynnikiem, który odróżniał AWS Lambdę i API Gateway od innych usług obliczeniowych i moim zdaniem, głównym, który odpowiada za sukces usług typu serverless. W większości przypadków oznacza on też, że całkowity koszt posiadania (ang. total cost of ownership, TCO) jest mniejszy.

Automatyczne skalowanie

Przed pojawieniem się usługi Lambda, automatyczne skalowanie w większości przypadków opierało się na skonfigurowaniu grupy auto skalującej (ang. auto scaling group), która w zależności od skonfigurowanej metryki uruchamiała lub usuwała serwery. W przypadku Lambdy nie było to potrzebne, ponieważ każde, pojedyncze żądanie jest obsługiwane przez osobną instancję funkcji, i to AWS odpowiada za to, żeby tę funkcję uruchomić a po obsłużeniu żądania usunąć. Pozwala to w większości przypadków całkowicie nie przejmować się tym czy nasza aplikacja jest w stanie obsłużyć dany ruch.

Brak zarządzania serwerami

Z braku zarządzania serwerami wynika to, że zapotrzebowanie na moc obliczeniową definiujemy inaczej niż konfiguracja serwera. W przypadku Lambdy jest to po prostu liczba megabajtów pamięci, których nasz kod potrzebuje (może w przyszłości nawet tego nie będziemy musieli definiować?). W przypadku usług bazodanowych może to być liczba zapytań o dane i ilość przechowywanych danych. Z kolei w przypadku kolejek może to być liczba wysłanych i odebranych wiadomości. Chodzi o wyrażanie zapotrzebowania na infrastrukturę w sposób odpowiadający temu, jak z niej korzystamy, a nie na jakich serwerach jest ona uruchomiona.

Ta pozornie niewielka różnica w połączeniu z automatycznym skalowaniem i z opisanym wcześniej modelem płacenia powoduje, że z dużo większą dokładnością możemy zrozumieć, jak korzystamy z infrastruktury, bardzo upraszcza planowanie zasobów, które będziemy potrzebowali w przyszłości, a koszty infrastruktury skalują się liniowo z tym, jak z naszej aplikacji korzystają użytkownicy.

Architektury serverless

Korzystając z usług chmurowych typu serverless, zaczęliśmy budować architektury serverless, czyli architektury, w których każdy element (m.in. funkcja, endpoint HTTP, baza danych, kolejka, przechowywanie plików, CDN) jest usługą typu serverless. Kod, który piszą programiści, staje się “klejem” (ang. glue code), który spaja te usługi i w głównej mierze jest kodem, który realizuje logikę biznesową.

Zaczynając pracę z architekturami serverless, będziemy naśladować to, czego wcześniej nauczyliśmy się w budowaniu typowych 3-warstwowych aplikacji (interfejs użytkownika, logika biznesowa uruchomiona na serwerze i baza danych). Z czasem zauważymy, że to, co wcześniej pisaliśmy jako kod, można zastąpić kilkoma linijkami konfiguracji, zaoszczędzając tym samym czas programisty. Pozwala to dużo bardziej skupić się na logice biznesowej i na dostarczaniu wartości użytkownikom naszych aplikacji czy produktów.

Sposób myślenia serverless

All the code that you ever write is business logic AWS re:Invent 2018 - Keynote with Dr. Werner Vogels

I tu przechodzimy do kluczowej części, czyli sposobu myślenia (mindset). Nasi użytkownicy mają gdzieś to czy sami po raz setny w swojej karierze skonfigurowaliśmy serwer HTTP czy grupę auto skalującą. Nie interesuje ich jaki silnik bazy danych używamy czy jakim nowym protokołem komunikujemy się między usługami. Woleliby, żebyśmy zamiast tego zajęli się tym, czego jesteśmy (lub powinniśmy być) najbliżej, czyli rozwiązywaniem ich problemów. Z biznesowego punktu widzenia, im mniej czasu spędzimy na konfigurowaniu się infrastrukturą tym lepiej, ponieważ możemy więcej czasu poświęcić na budowanie konkurencyjnego produktu.

Nasi użytkownicy mają gdzieś to czy sami po raz setny w swojej karierze skonfigurowaliśmy serwer HTTP

Jakkolwiek radykalnie to brzmi, to nie chodzi mi o bezmyślne korzystanie z usług chmurowych, ignorując ich ograniczenia i nie myśląc o konsekwencjach. Aby korzystać z jakiejkolwiek technologii w efektywny sposób, musimy ją znać. To, co proponują dostawcy chmury to po prostu ułatwienie życia programistom i uwolnienie ich od czynności, które są powtarzalne i wtórne.

Podsumowując, w serverless chodzi o to, aby zmaksymalizować korzystanie z usług chmurowych, które już istnieją, zamiast tworzyć je od nowa. To, co jest istotne dla użytkowników to logika biznesowa naszego produktu. Dla nich technologia jest wtórna.