Każdy buzzword w świecie nowych technologii owiany jest mgiełką tajemnicy, za którą podąża ekscytacja developerów, którzy pracują właśnie z tą najnowszą technologią. Często utrudnia to zrozumienie sedna nowego rozwiązania i oddzielenie konkretów od marketingowego mydlenia oczu. Na ogół osoby z wieloletnim doświadczeniem w branży sceptycznie podchodzą do szumu medialnego i buzzowordów, niestety taka zachowawcza postawa znakomicie ułatwia przegapienie wartościowych rozwiązań dla Twojej firmy.
Serverless to przykład takiego buzzword, jest o nim bardzo głośnio ostatnimi czasu. Wszystko zaczęło się w 2014 roku, kiedy to Amazon Web Services przedstawił nową usługę w swojej chmurze: AWS Lambda. Scharakteryzował ją, jako usługę obliczeniową (podobnie jak uprzednio maszyny wirtualne) wskazując jej zalety:
- Brak serwerów do zarządzania
- Ciągłe skalowanie i balansowanie obciążenia
- Automatyczne przełączanie awaryjne
- Opłaty tylko za zużyty czas działania – brak opłat za bezczynność systemu.
Jeśli nie jesteś osobą znającą się na inżynierii oprogramowania lub próbujesz wytłumaczyć, co to jest serverless osobie nietechnicznej, powyższa lista może brzmieć jak nerdowski bełkot. I nawet fakt, że koszty Lambdy były rozliczane, co do 100 milisekund w czasie, gdy EC2 (serwery wirtualne) w 2014r. były rozliczane z dokładnością, co do godziny (PRZEŁOM!) niewiele Ci powie o realnych zaletach tego rozwiązania dla Twojego biznesu.
Zatem co oznacza serverless dla biznesu i jakie korzyści może przynieść Twojej firmie?
- Krótszy czas wejścia na rynek (time-to-market)
- Zwiększona efektywność (więcej za mniej)
- Twoje koszty stałe stały się kosztami operacyjnymi
- Mniej marnotrawstwa
- Większa elastyczność
- Efektywniejszy proces rozwoju i testowania
Wyjaśnijmy.
1. Krótszy czas wejścia na rynek (time-to-market)
Dla wielu firm ścieżka dostarczania aplikacji na rynek jest długa. Wraz z planowaniem produktu, projektowaniem i rozwojem, musisz także pomyśleć o potrzebnej infrastrukturze, konfiguracji, dostępności zasobów oraz skalowalności na wypadek nieprzewidzianych skoków obciążenia, które mogą się pojawić znienacka w dobie virali i marketingu wirusowego.
W świecie serverless nie musisz się już martwić o wynajem i zakup infrastruktury, jej konfigurację i planowanie dostępności zasobów. Kroki te zostały usunięte z procesu rozwoju produktu i są teraz obowiązkiem dostawcy platformy serverless. Od teraz musisz ”tylko” myśleć o tym, jak prawidłowo zaprojektować, zbudować i wdrożyć swoją aplikacją na platformie dostawcy. To znacznie skraca czas wejścia na rynek, ponieważ cykl rozwoju jest krótszy.
2. Zwiększona efektywność (więcej za mniej)
Klasyczne rozwiązania (czyli nie serverless) działają non-stop. Czy ich używasz czy nie, muszą być włączone. Nigdy nie wiesz, kiedy Twojego klienta najdzie ochota, aby wejść do Twojego sklepu internetowego i zakupić Twój ekstra produkt, prawda? Jeśli nie masz sklepu internetowego – nieważne, ten przykład jest w miarę uniwersalny, więc na chwilę wyobraź sobie, że masz taki sklep 😉
Obłożenie Twojego serwera, na którym działa Twój sklep (w praktyce to jest zawsze kilka maszyn a nie jedna, ale tutaj upraszczamy) można przedstawić na wykresie w czasie. Średnie wykorzystanie serwera, czyli jego efektywność w ciągu dnia może wyglądać jak na poniższym rysunku.
Jest świetnie, widziałeś zapewne wiele takich diagramów. W ciągu dnia jest duży ruch a w nocy mniejszy bo ludzie śpią.
W czym zatem problem?
Bez względu na to czy Twoje serwery właśnie zarabiają dla Ciebie pieniądze (klienci kupują) czy stoją włączone bezczynnie (brak klientów) płacisz za nie tyle samo! (Jeśli masz własną serwerownie to płacisz mniej za prąd, gdy stoją bezczynnie, ale to słabe pocieszenie). Przedstawmy te same dane z powyższego diagramu trochę inaczej. Odwróćmy perspektywę i skupmy się na stratach, jakie generuje serwer w czasie.
Obecnie, niezależnie od tego, czy wynajmujesz serwery wirtualne, czy jesteś właścicielem serwerowni, marnujesz zasoby. Płacisz za zarezerwowany czas bez względu na to, czy Twoje aplikacje są używane, czy nie. Płacisz za całą czarną ramkę symbolizującą jeden serwer. No oko Twoja strata (żółtopomarańczowy obszar) to jakieś 50%.
Serverless zmienia zasady „gry”. Od teraz płacisz tylko za czas, w którym Twoja aplikacja była aktywnie używana przez Twoich klientów! Efektywność wzrasta do 100%.
Zniknęła ramka z góry, ponieważ AWS Lambda jest automatycznie skalowalna przez dostawcę. Dostosuje się samodzielnie do ruchu w danym momencie. W ramach potrzeby przeskaluje się powyżej możliwości jednego serwera (ramka symbolizowała właśnie jeden serwer).
Szczerze mówiąc, ten diagram trochę traci sens, ponieważ bez różnicy czy mamy jedno żądanie czy 10 milionów, zawsze efektywność kosztowa wynosi 100%. 🤔
Pomyśl, jaką byś miał stratę budując system dla miliona użytkowników a obsługiwał tylko jednego?
3. Twoje koszty stałe stały się kosztami operacyjnymi
Wyobraź sobie, że Twoja firma ma 10 milionów żądań użytkowników dziennie. Każde żądanie użytkownika wykonuje również kilka połączeń wewnętrznych, łącznie do 30 milionów żądań.
Aby obsłużyć ten wolumen, obecnie musisz wynająć flotę wirtualnych serwerów w chmurze lub zbudować własne centrum danych (serwerownia). Przyjmijmy, że koszty infrastruktury wynoszą miesięcznie kilkadziesiąt tysięcy złoty. Jeśli doliczymy do tego koszty zespołu inżynierów do konfiguracji i obsługi infrastruktury, kosztów centrum danych, konserwacji itd., to będą one znacznie większe.
Jak zawsze polecam poczytać o Total Cost of Ownership u Gartnera. Koszty obsługi i administracji serwerami są znaczące. Oczywiście Twoi inżynierzy powiedzą Ci, że wszystko można zautomatyzować i to wcale nie jest tak dużo roboty. Bynajmniej, z serwerami jest zawsze mnóstwo roboty (wiem, bo mam ich 4500 u jednego klienta). Nawet jak wszystko zautomatyzujesz i ogarniesz (co nie zrobi się za darmo oczywiście) to i tak może na Ciebie spaść jakaś gównoburza w postaci dziury bezpieczeństwa w procesorach Intela czy inna podobna niespodzianka zapewniająca zabawę na kilka dni. Administracja to tylko jeden z obszarów gdzie serwery generują koszty.
W świecie serverless koszty zostały powiązane z realnie wykonaną pracą, tak zwanymi żądaniami. Każde działanie Twojego klienta tworzy jakieś techniczne żądania np. pobierz dane z bazy danych, wygeneruj raport itp. wszystkie obsługiwane są przez Lambdę.
Średnia cena AWS Lambda to niecałe 20 centów na milion żądań (uproszczenie). Wydaje się to być wyjątkowo tanio, ale AWS Lambda jest tylko usługą obliczeniową (wykonuje kod i nic poza tym), więc będziesz również potrzebował przechowywania danych, usług powiadamiania i tak dalej. Dodatkowo architektury serverless różnią się do klasycznych, co powoduje wzrost liczby wewnętrznych połączeń. W sumie serverlessowy odpowiednik Twojego systemu może generować około 60 milionów żądań dziennie. To dużo, ale koszt usług obliczeniowych wraz z przechowywaniem danych i innymi usługami, które mogą być potrzebne, spadnie do tysięcy złoty miesięcznie, czyli jeden rząd mniej.
Twoje koszty stałe (CAPEX) stały się właśnie kosztami operacyjnymi (OPEX). Koszty stałe to te, które nie są powiązane z wynikami. Serwerownie, budynki, ochrona, bezpieczeństwo, sprzęt oraz ludzie.
Różnica polega na tym, że w pierwszym modelu bez względu na to, jakie było obłożenie systemu i wynik końcowy, koszt stałe były… stałe. Serwery to zawsze koszty stałe. Nie wierzysz mi, to zastanów się czy Twoja firma kupowała Reserved Instances od AWS na 3 lata w przyszłość?
W serverless koszty zależą od realnego użycia (model pay-as-you-go - opisałem go dokładnie w innych artykułach) i są to zawsze koszty operacyjne.
Nie jestem księgowym, ale posłużę się analogicznym przykładem. Dla mnie leasing samochodu to koszt stały, bo go ponosisz bez względu na to czy korzystasz z auta czy nie. Taksówki to koszt operacyjny, uzależniony od realnego użycia.
4. Mniej marnotrawstwa
Podczas opracowywania wielu produktów niektóre funkcje są wielokrotnie tworzone na nowo. Na przykład przetwarzanie płatności, uwierzytelnianie użytkownika, zarządzanie hasłami, powiadomienia.
Korzystanie z usług serverless i cloud native znacząco eliminuje potrzeby budowy „na nowo” technicznych komponentów, które już lata temu zostały zbudowane i nie wpływają znacząco na nasz produkt końcowy - takie utowarowienie w IT.
Utowarowienie jest to zjawisko, w którym produkty i usługi tracą w oczach klientów swoją wyjątkowość, a różnice między markami zacierają się. Jedyną cechą umożliwiającą ich odróżnienie jest cena.
Żródło: http://www.mojsposobmyslenia.pl/utowarowienie-nie-taki-biznes-chcesz-prowadzic/
Odpowiedz szczerze: jakie znaczenie dla Twojego klienta ma to w jakiej bazie danych trzymasz jego dane? W jaki sposób zarządzasz użytkownikami? Czego używasz do wysyłania maili?
Moim zdaniem: Żadne.
W nowym podejściu, z jednej strony korzystamy z usług oferowanych przez dostawcę chmury, a z drugiej strony serverless promuje ponowne wykorzystanie zbudowanych wewnątrz w firmie komponentów-usług ponieważ jest rozwijany w architekturze mikroserwisów. Komponent obsługujący produkt „A”, można wykorzystać w linii produktów „C”.
Podsumowując, nie marnujemy zasobów ludzkich na ponowne wymyślanie koła i montowanie go w naszej biznesowej maszynie.
5. Większa elastyczność
Przedsiębiorstwa, a zwłaszcza startupy, muszą zmieniać swoje produkty, pomysły i kierunek rozwoju, aby utrzymać się na rynku. Tego typu zmiany często wymagają przebudowy systemów IT i oferowanych usług. Obecnie wiele aplikacji jest budowanych, jako tzw. monolity lub umieszczane w kontenerach i uruchamiane w chmurze. Taki sposób wytwarzania oprogramowania jest mało elastyczny. Nawet niewielka zmiana oferowanego produktu może spowodować kosztowne restrukturyzacje lub wymagać całkowitego przepisania systemu.
Serverless zwiększa elastyczność Twojego biznesu. Systemy serverless natywnie wykorzystują architekturę mikrosystemów, która zaleca rozdzielenie aplikacji na wiele małych niezależnych usług (komponentów aplikacyjnych). W ten sposób zwiększasz elastyczność swojej firmy. W przypadku, gdy chcesz zmodyfikować swój produkt, przestawić firmę na inny rynek, to zmieniasz tylko wybrane mikroserwisy, a nie całe monolity. Jest to dużo tańsze, szybsze i bezpieczniejsze. Co więcej, możesz równocześnie wspierać stary produkt i nowy. Wspólne usługi będą się same skalowały tak, aby obsłużyć zwiększony ruchu wynikający z dwóch linii produktowych.
Na poniższym rysunku, mikroserwis B obsługuje ruch związany z dwoma produktami. Mikroserwisy D i E zostały dodane później, aby obsługiwać drugi produkt (zółte strzałki), już po tym jak produkt pierwszy był uruchomiony (zielone strzałki). Pomimo tego, że mikroserwis B obsługuje sumę ruchu z obu produktów nie ma problemu z wydajnością, ponieważ skaluje się niezależnie od pozostałych mikroserwisów. Jest to wielka zaleta optymalizująca koszty, niemożliwa do osiągnięcia w świecie monolitów.
6. Efektywniejszy proces rozwoju i testowania
Budowanie aplikacji składającej się z wielu niezależnych usług pomoże Ci osiągnąć
- Łatwiejsze zarządzanie projektami IT
- Łatwiejsze testowanie
- Dostarczanie projektów w czasie i budżecie
Łatwiejsze zarządzanie projektami IT
Rozwijanie aplikacji, jako zbioru niezależnych usług ułatwia prowadzenie projektów. Funkcjonalności pozostają zamknięte w osobnych komponentach i nie przenikają się nawzajem. Ograniczasz scope creep (pełzający zakres) i chronisz się przed nowymi błędami dodanymi w trakcie rozwoju. To jest standardowy problem w monolitach „tu dodajesz, a tam przestaje działać” – zjawisko na tyle popularne, że aż wymyślono testy regresyjne aby mu przeciwdziałać.
Łatwiejsze testowanie
Projektowanie aplikacji, jako zbioru wielu pojedynczych usług-komponentów ułatwia ich testowanie. Zwykle podczas programowania musisz także skonfigurować wiele środowisk (dev, test, prod) i zapłacić za nie. W serverless tworzenie wielu środowisk jest darmowe i łatwe, ponieważ płacisz tylko za realnie użyte zasoby (np. jak nie testujesz to nie płacisz). Serverless wykorzystuje podejście infrastruktura-jako-kod, dzięki czemu tworzenie (i kasowanie) środowisk jest szybkie i trywialnie proste.
Dostarczanie projektów w czasie i budżecie
Mniejsze komponenty łatwiej jest zaprojektować i oszacować ich pracochłonność. Twoje szacunki i estymaty są bardziej pewne. Dzięki czemu Twoje projekty stają się bardziej przewidywalne i są dostarczane w czasie i budżecie.
Bądźmy szczerzy. Serverless to nie panaceum na całe zło.
Zastanówmy się jakie są potencjalne skutki uboczne korzystania z serverless?
Serverless oferuje szereg korzyści dla biznesu. Niemniej jednak nie ma jednego idealnego podejścia, technologii ani strategii, które byłyby rozwiązaniem w każdej sytuacji. Serverless ma również swoje wady i problemy, które mogą sprawić, że będzie on nieodpowiedni dla Twojej firmy lub konkretnego projektu.
1. Vendor lock-in
Uruchamianie aplikacji w modelu serverless może ściśle powiązać Twoją aplikację z infrastrukturą dostawcy chmury. Popularnie z angielskiego ten problem nazywamy vendor lock-in. Nawet, jeśli logika biznesowa nie zależy od samej usługi, to nadal wymaga bezpośredniego osadzenia na platformie dostawcy. Z powodu różnic pomiędzy rozwiązaniami serverless oferowanymi przez różnych dostawców chmury, potencjalne przeniesienie aplikacji na inne platformy może wiązać się ze znacznym kosztem i czasem potrzebnym na modyfikację kodu Twojego rozwiązania. Przed vendor lock-in można się chronić stosując odpowiednie zabiegi na etapie projektowania rozwiązania (architektura heksagonalna, domain driver design).
W tym miejscu należy też jasno powiedzieć, że vendor lock-in jest bardzo rozdmuchanym problemem. Za to stwierdzenie pewnie bardzo mi się oberwie. Istnieją firmy, które przegapiły rozwój chmury, ich cały biznes opiera się na tradycyjnych rozwiązaniach, fizycznym sprzęcie i serwerowniach. To najczęściej pracownicy tych firm straszą i przestrzegają przed złą chmurą i trójką krwiopijców (Amazon, Google, Microsoft). Założę się, że Ci sami ludzie w swojej karierze doradzali wybór baz Oracla i .Net – wtedy vendor lock-in im nie przeszkadzał. 😡
Ja osobiście nie zamierzam nikogo namawiać do adopcji chmury. Każda organizacja musi podjąć tę decyzję samodzielnie, rozważając za i przeciw. Natomiast jak już ją podejmie to nie powinna się ciągle obracać za siebie. Trzeba patrzeć w przyszłość i planować jak najlepiej wykorzystać możliwości, które oferuje chmura w swoim biznesie.
I jeszcze na koniec. Z tego, co mi wiadomo, nie ma żadnych dowodów na jakiekolwiek działania vendor lock-in ze strony dostawców. Wręcz przeciwnie, przykładowo w AWS, wirtualne serwery EC2, co roku są odświeżane, to znaczy, że nowe typy maszyn są tańsze niż ubiegłoroczne i oferują średnio 20% wydajności więcej za niższą cenę! Jak do mnie to dobry deal a nie vendor lock-in. 👍
2. Utrzymanie wielu małych usług może być kłopotliwe
Obsługa i projektowanie systemów rozproszonych jest trudniejsza niż systemów monolitycznych. I nawet, jeśli to tylko subiektywna kwestia, to fakty są takie, że na rynku znajdziesz 20 razy więcej ludzi z doświadczeniem w monolitach niż tych, którzy się znają na systemach rozproszonych. Wynika to z tego gdzie, jako branża byliśmy 10, 15, 20 lat temu.
Efektywnie, na początku, mniej osób w Twojej firmie będzie w stanie rozwikłać problemy w aplikacjach serverless, ponieważ nie dysponują odpowiednim doświadczeniem. Można temu zarazić po przez szkolenia oraz propagowanie rozwiązań serverless w systemach niekrytycznych, tak, aby kadra nabrała doświadczenia bez nadmiernego stresu.
Należy pamiętać, że pomimo tego iż serverless wydaje się być zupełnie innym podejściem, nie pojawił się u nas z kosmosu. Opiera się na rozwiązaniach, które istnieją w IT od lat (m.in. kontenery) i każda doświadczona osoba, chętna do rozwoju, powinna szybko się odnaleźć w tej klasie rozwiązań.
3. Zimny start
Ostatni z najczęściej wymienianych problemów w kontekście serverless to zimny start. Ponieważ dostawca chmury jest odpowiedzialny za skalowanie aplikacji serverless i dostosowanie jej do dowolnie małego i dużego ruchu to może się zdarzyć, że po pewnym okresie bezczynności (na ogół kilkanaście minut) ponowne uruchomienie aplikacji będzie obarczone paroma karnymi sekundami.
Dostawca chmury obsługuje równocześnie setki tysięcy klientów. To są grube tysiące miliardów obsłużonych żądań dziennie. Jeśli akurat nikt nie korzysta z Twojego systemu, to dostawca optymalizuje swoje zasoby i usuwa z pamięci Twoją aplikacje. Karny zimny start związany jest z ponownym wgraniem kodu Twojego rozwiązania.
Podsumowanie
Jak widać serverless to nie tylko buzzword ale konkretna kategoria rozwiązań oferująca realne benefity. Jest to bardzo świeże podejście do tworzenia oprogramowania, które jeszcze boryka się z pewnymi problemami wieku młodzieńczego. Największym z nich wydaje się być brak wiedzy i podążający za nim brak zaufania ze strony inżynierów projektujących systemy.
Mimo tego, jak podają statystyki, 24% zupełnie nowych wdrożeń w chmurze to rozwiązania serverless. Serverless na naszych oczach staje się numerem jeden rozwiązań cloud native. (Źródło: Cloud Programming Simplified: A Berkeley View on Serverless Computing). Wynika to zapewne z krótszego czasu wdrożenia i znaczych oszczędności kosztowych w stosunku do równoważnych rozwiązań serwerowych.
Uważam, że zdecydowanie warto rozważyć serverless jako rozwiązanie dla Twojego przyszłego projektu w chmurze.
