• CloudPouch NEW!
  • Akademia
  • Blog
  • O stronie
  • Home

Co to jest serverless? Definicja i interpretacja


Czyli czym r├│┼╝ni si─Ö serverless od klasycznych rozwi─ůza┼ä?

Co to jest serverless? Definicja i interpretacja

Co to jest serverless?

Pomimo tego, i┼╝ z serverless jestem zwi─ůzany od 2016 roku to wbrew pozorom, jest to bardzo trudne pytanie. Aktualnie nie ma jednej definicji tego terminu. Ba! Nie ma nawet zgody co do przypisania serverless do jakiej┼Ť szerszej kategorii (przypomina si─Ö dziobak z biologii, kt├│ry zosta┼é w ko┼äcu ssakiem :-). Je┼Ťli chodzi o serverless to jedni twierdz─ů, ┼╝e to architektura, inni, ┼╝e technologia, podej┼Ťcie do wytwarzania oprogramowania, a nawet ÔÇ×spektrumÔÇŁ.

To wszystko i jeszcze wi─Öcej uj─ů┼é w swoim wyczerpuj─ůcym, ponad 10-cio stronicowym, artykule Jeremy Daly. Pomimo bycia niekwestionowanym autorytetem w temacie, nawet jemu nie uda┼éo si─Ö dok┼éadnie zdefiniowa─ç tego terminu. Wytrwa┼éym polecam lektur─Ö tutaj.

Brak jednoznacznej definicji nie s┼éu┼╝y nikomu, ale trzeba jako┼Ť ┼╝y─ç. Trudno jest o czym┼Ť m├│wi─ç, je┼Ťli si─Ö tego nie nazwie. Uwa┼╝am, ┼╝e nie ma sensu bi─ç piany i toczy─ç leksykalne potyczki. Aby zrozumie─ç idee serverless potrzebna nam wystarczaj─ůco dobra definicja. Zatem moim zdaniem:

Definicja serverless

Jest to architektura, a zarazem podej┼Ťcie do wytwarzania oprogramowania polegaj─ůce na ┼é─ůczeniu ze sob─ů r├│┼╝nych us┼éug (bloki budowlane) dost─Öpnych w chmurze publicznej w taki spos├│b, ┼╝e:

  • Nie musimy zarz─ůdza─ç infrastruktur─ů (pocz─ůwszy od topologii sieci, a┼╝ do serwera aplikacji w┼é─ůcznie),
  • Ko┼äcowe rozwi─ůzanie jest wysokoskalowalne,
  • Ko┼äcowe rozwi─ůzanie jest wysokodost─Öpne,
  • P┼éacimy tylko za realnie wykorzystane zasoby (us┼éugi), pomimo tego, i┼╝ s─ů one non-stop gotowe do u┼╝ycia przez nasze rozwi─ůzanie.

Jak rozumie─ç t─ů definicj─Ö?

Po pierwsze serverless to nie jest ┼╝adna specyficzna technologia. Amazon, Google, Microsoft i jeszcze wielu innych dostawc├│w maj─ů w┼éasne wachlarze us┼éug serverless w swojej ofercie. Ich us┼éugi to moim zdaniem bloki budowlane, z kt├│rych, mo┼╝na sk┼éada─ç w┼éasne rozwi─ůzania. W TOGAF (framework architektury korporacyjnej) blok budowlany reprezentuje nadaj─ůcy si─Ö do ponownego u┼╝ycia, komponent IT lub architektoniczny, kt├│ry mo┼╝e by─ç po┼é─ůczony z innym blokiem budowlanym w celu dostarczenia rozwi─ůzania. ┼ü─ůcz─ůc bloki budowlane (us┼éugi) ze sob─ů tworzymy architektur─Ö - dla mnie, serverless ma wszystkie niezb─Ödne znamiona, aby sklasyfikowa─ç go jako architektur─Ö. Natomiast, podej┼Ťcie do wytwarzania oprogramowania najlepiej oddaje ide─Ö, jak─ů reprezentuje ÔÇô do czego powr├│c─Ö p├│┼║niej.

┼ü─ůczenie blok├│w budowlanych, us┼éug, czy komponent├│w (jak zwa┼é tak zwa┼é) nie jest niczym nowym w IT. Robimy to od dziesi─ůtek lat. Natomiast, po raz pierwszy mo┼╝emy si─Ö skupi─ç na mo┼╝liwo┼Ťciach oferowanych przez te komponenty bez zarz─ůdzania infrastruktur─ů, na kt├│rej s─ů realizowane.

Super szybki kurs na architekta chmury

Aby podkre┼Ťli─ç r├│┼╝nic─Ö pomi─Ödzy klasycznymi architekturami a serverless zrobi─Ö teraz super szybki kurs projektowania wysokodost─Öpnych i skalowalnych system├│w na chmurze AWS. Tego ucz─ů i wymagaj─ů na egzaminie na certyfikowanego architekta AWS. Dla jasno┼Ťci, przy rozwi─ůzaniach on-premises / fizycznych przemn├│┼╝ poziom komplikacji i obci─ů┼╝enia prac─ů przez 100 :-)

Aby nie zosta─ç pos─ůdzonym o manipulacj─Ö, pos┼éu┼╝─Ö si─Ö referencyjn─ů architektur─ů od AWS dla klasycznej, tr├│jwarstwowej aplikacji webowej be┼╝ ┼╝adnych dodatk├│w i udziwnie┼ä (cache, read-replica itp.). Jak popatrzysz na rysunek, to zobaczysz czemu zawdzi─Öcza sw─ů nazw─Ö: bazy danych, serwery aplikacji oraz serwery webowe s─ů rozmieszczone oddzielnie, tworz─ůc trzy warstwy.

Co to jest serverless? Definicja i interpretacja

Szybki kurs architektury na AWS - przyst─Öpujemy to projektowania

  1. Definiujemy wirtualn─ů sie─ç prywatn─ů VPC.
  2. Dzielimy nasz─ů sie─ç prywatn─ů na podsieci.
    a. Mamy 3 warstwy, wi─Öc b─Ödziemy potrzebowali 3 podsieci (subnet).
    b. Eee ┼║le! Aplikacja ma by─ç wysoko dost─Öpna, wiec musi dzia┼éa─ç w dw├│ch strefach dost─Öpno┼Ťci (Availability Zone - fizycznie osobne datacenter AWSa, minimum 3 na jeden region geograficzny)
    c. Czyli potrzebujemy 6 podsieci po 3 na ka┼╝d─ů stref─Ö dost─Öpno┼Ťci
    d. Eee ┼║le! A gdzie skalowalno┼Ť─ç? No tak, poniewa┼╝ b─Ödziemy mieli wi─Öcej ni┼╝ po jednym serwerze w danej warstwie, to jako┼Ť musimy dystrybuowa─ç ruch do wielu maszyn. Potrzebny nam Load Balancer, kt├│ry uwaga potrzebuje w┼éasnych podsieci.
    e. Dobra, czyli 4 podsieci razy 2 strefy dost─Öpno┼Ťci daje 8 podsieci w sumie.
    f. Super. Teraz adresacja podsieci, przecież każda posiec musi mieć swój przedział adresów IP, aby mogła funkcjonować.
    g. Teraz definiujemy wiele routing table dla tych podsieci, aby ruch sieciowy działał.
    h. Nie wchodz─ůc w szczeg├│┼éy, b─Ödziemy potrzebowali jeszcze NAT Gateway i Internet Gateway, aby serwery, kt├│re utworzymy, mia┼éy dost─Öp do sieci.
    i. Poprawiamy routing tables.
    j. Załóżmy, że topologia sieci jest już OK.
  3. Teraz zajmijmy si─Ö serwerami.
    a. Bazy danych ÔÇô korzystamy oczywi┼Ťcie z RDS, za┼é├│┼╝my, ┼╝e uruchomimy MySQL w modelu Master ÔÇô Slave, to znaczy, ┼╝e gdy Master padnie to AWS prze┼é─ůczy nas na Slave i w mniej ni┼╝ sekund─Ö nasza aplikacja b─Ödzie zn├│w dzia┼éa─ç. Super, co nie?
    b. Serwery aplikacji. Minimum dwa, po jednym na ka┼╝de Availability Zone we┼║my sobie Amazon Linuxa, zainstalujmy tam Jave, odpalmy nasz─ů aplikacj─Ö napisan─ů w Spring Boot. Lub cokolwiek innego co udost─Öpnia jakie┼Ť tam API dla ostatniej warstwy webowej.
    c. Serwery webowe, znow dwa, zn├│w linux, tutaj b─Ödziemy mieli jaki┼Ť serwer http. Nginx, tomcat. Co kto lubi? :-)
    d. Super. Koniec. UfffÔÇŽ
    e. Eee ┼║le. Mia┼éo by─ç skalowalne przecie┼╝. Trzeba serwery aplikacji i webowe wsadzi─ç w Auto Scalling GroupÔÇÖy ÔÇô dwie, po jednej na warstw─Ö.
    f. Skalowanie bazy pomijam!
    g. Wszystko?
    h. Gdzie tam, trzeba zadbać o bezpieczeństwo.. Tworzymy Secuirty Groups dla każdej warstwy osobno.
    i. Definiujemy role, dost─Öpy.
  4. I tak dalejÔÇŽ
  5. A potem jeszcze dalejÔÇŽ

Dobra zaczynam siebie nienawidzić, że kazałem Ci to czytać :-P

A to tylko robota przy projektowaniu i tworzeniu infry. Tak, zgadzam si─Ö, ┼╝e t─Ö robot─Ö wykonuje si─Ö w praktyce raz pisz─ůc kod (Infrastructure as Code), ale wci─ů┼╝ trzeba przej┼Ť─ç przez te wszystkie etapy. Buduj─ůc ka┼╝dy nowy projekt od nowa. Potem trzeba jeszcze dogl─ůda─ç tych serwer├│w, monitorowa─ç, paczowa─ç (przyja┼║nie macham r─Ök─ů w kierunku Intela, dzi─Ökuj─ůc za dziury bezpiecze┼ästwa w ich procesorach) i tak dalejÔÇŽ

Jednym zdaniem: W ciul roboty.
Dobra wiadomo┼Ť─ç: W serverless w wi─Ökszo┼Ťci zosta┼éa ona przej─Öta przez dostawc─Ö chmury.

Specjalnie wymieni┼éem tak d┼éug─ů (ale niepe┼én─ů, bo ju┼╝ sam siebie zanudzi┼éem) list─Ö krok├│w, poniewa┼╝ zazwyczaj w artyku┼éach na temat serverless pada tego typu wypowied┼║:

ÔÇ×Brak administracji serwerami i konieczno┼Ťci projektowania infrastruktury sieciowej oznacza oszcz─Ödno┼Ť─ç czasu, zwi─Ökszenie bezpiecze┼ästwa i ograniczenie koszt├│w operacyjnych. ÔÇ×

To jest oczywi┼Ťcie PRAWDA! Jednak bardzo cz─Östo ludzie w IT nie maj─ů ┼Ťwiadomo┼Ťci, jak straszna jest alternatywa. Z mojego korpo-do┼Ťwiadczenia wynika, ┼╝e wi─Ökszo┼Ť─ç developer├│w nie potrafi uruchomi─ç produkcyjnie aplikacji, kt├│r─ů programuj─ů!

Wyobra┼║ sobie, ┼╝e Tw├│j mechanik samochodowy jest mega specem od silnik├│w i zawieszenia, ale nie potrafi prowadzi─ç samochodu. Dziwne, co nie? W IT nie!

W czasach przed DevOps to nie by┼éo problem, podzia┼é by┼é wr─Öcz wymuszany organizacyjnie (a czasem nawet prawnie). Ale teraz czasy si─Ö zmieni┼éy i od developer├│w oczekuje si─Ö wi─Ökszej ┼Ťwiadomo┼Ťci na temat utrzymania aplikacji, kt├│r─ů tworz─ů. W ko┼äcu DevOps to rozwi─ůzywanie problem├│w operacyjnych metodami programistycznymi. Nawet je┼Ťli w Twojej firmie nadal macie admin├│w, sieciowc├│w i innych spec├│w od utrzymania (ca┼ée to Ops) to wiedz, ┼╝e ta praca istnieje i kto┼Ť j─ů w klasycznych architekturach wykonuje (chc─ůc nie chc─ůc), nawet je┼Ťli przed Tob─ů, jako developerem, jest to ukryte.

Wr├│─çmy do definicji serverless. Ju┼╝ wiesz jak rozumie─ç brak zarz─ůdzania infrastruktur─ů. Przejd┼║my zatem dalej.

Wysokoskalowalne i wysokodost─Öpne

Wysokoskalowalne i wysokodost─Öpne rozwi─ůzania otrzymujemy w serverless korzystaj─ůc z us┼éug (nasze bloki budowlane) w chmurze, kt├│re maj─ů te charakterystyki wbudowane.

Pos┼éu┼╝─Ö si─Ö przyk┼éadem, aby wyja┼Ťni─ç t─Ö kwesti─Ö.

  • Powy┼╝ej w architekturze tr├│jwarstwowej aplikacji webowej stworzyli┼Ťmy dwie instancje bazy danych MySQL: Master i Slave. Odczyt i zapis by┼é wykonywany na masterze, wszelkie zmiany (update, delete) s─ů synchronizowane synchronicznie do slave. W razie awarii mastera AWS automatycznie przekierowuje po┼é─ůczenia (przez zmian─Ö w DNS) na maszyn─Ö slave. Takie rozwi─ůzanie zapewnia tylko wysok─ů dost─Öpno┼Ť─ç aplikacji. W ┼╝aden spos├│b nie wspiera skalowalno┼Ťci.

  • W ┼Ťwiecie serverless wykorzystamy innego rodzaju baz─Ö danych o nazwie AWS DynamoDB. Charakteryzuje si─Ö ona:

    • Wbudowan─ů wysok─ů dost─Öpno┼Ťci─ů i trwa┼éo┼Ťci─ů danych ÔÇô s─ů one automatycznie replikowane do r├│┼╝nych Availability Zones w regionie. Nigdy nie s─ů przechowywane na pojedynczej maszynie!
    • Wbudowan─ů wysok─ů skalowalno┼Ťci─ů ÔÇô mo┼╝e obs┼éu┼╝y─ç chwilowe obci─ů┼╝enia (peak) rz─Ödu 20 milion├│w request├│w na sekund─Ö. Wyobra┼║ to sobie, ponad po┼éowa Polak├│w klika w tym samym momencie i generuje taki ruch :-) Ta baza jest niewiarygodnie skalowalna, ale te┼╝ bardzo droga, je┼Ťli zaprz─Ögniemy j─ů do super du┼╝ych obci─ů┼╝e┼ä lub b─Ödziemy w niej trzyma─ç du┼╝o danych.
    • Tym, ┼╝e jest w pe┼éni zarz─ůdzana przez AWS ÔÇô oznacza to, ┼╝e nie musimy uruchamia─ç ┼╝adnych serwer├│w, na kt├│rych jest ona instalowana. Przypominam, w RDS musimy uruchomi─ç wirtualne maszyny EC2, na kt├│rych AWS zainstaluje nam MySQL (upraszczam tutaj celowo). OS na takich maszynach trzeba aktualizowa─ç, paczowa─ç itd. Tutaj tego nie ma.

Na marginesie: DynamoDB jest r├│wnie┼╝ ┼Ťwietnym przyk┼éadem bloku budowlanego, kt├│ry ┼éatwo si─Ö integruje z innymi. Us┼éuga potrafi automatycznie generowa─ç zdarzenia (DynamoDB Streams API) i przesy┼éa─ç do innych powi─ůzanych us┼éug. Pozwala to w trywialny spos├│b projektowa─ç systemy zgodnie z Event Driven Architecture. Przyk┼éadowo, za ka┼╝dym razem, gdy kto┼Ť doda nowe zam├│wienie do bazy, ta informacja zostanie rozes┼éana do powi─ůzanych us┼éug. Automatycznie, bez budowania ┼╝adnych messagebusÔÇÖ├│w czy innych system├│w komunikacji. Jest to nowoczesne podej┼Ťcie, kt├│re staje si─Ö coraz bardziej popularne w ostatnich latach.

Koszty w serverless

Ostatni─ů cech─ů charakterystyczn─ů serverless, wed┼éug definicji, jest jej model kosztowy. Aby uzna─ç rozwi─ůzanie lub us┼éug─Ö za serverless, musi ona by─ç rozliczana w modelu pay-as-you-go. Czyli op┼éaty s─ů pobierane za realne u┼╝ycie, a nie czas trwania us┼éugi.

Pos┼éu┼╝my si─Ö przyk┼éadem. Za┼é├│┼╝my, ┼╝e mamy w┼éasn─ů aplikacj─Ö typu SaaS, kt├│r─ů sprzedajemy innym biznesom w modelu subskrypcji. Dajmy na to, ┼╝e to aplikacja kadrowa, pozwala pracownikom naszych klient├│w sk┼éada─ç wnioski urlopowe przez Internet.

  • W klasycznej architekturze webowej aplikacji tr├│jwarstwowej (om├│wionej powy┼╝ej) mieli┼Ťmy uruchomione w us┼éudze RDS dwa serwery EC2, na kt├│rych dzia┼éa┼éy dwie instancje bazy MySQL: master i slave. Bez r├│┼╝nicy czy kto┼Ť czyta┼é, zapisywa┼é czy kompletnie nic nie robi┼é z tymi bazami, to musimy za nie p┼éaci─ç. Podw├│jnie bo s─ů dwie. Model op┼éaty us┼éugi EC2 zale┼╝y od czasu. Bez r├│┼╝nicy czy wykorzystujemy ten zas├│b w jednym czy w stu procentach. P┼éacimy tyle samo. Owszem, EC2 jest rozliczany, co do sekundy, ale poniewa┼╝ bazy danych zazwyczaj s─ů w┼é─ůczone non stop to wiele nam to nie pomaga. W perspektywie naszej aplikacji SaaS mo┼╝emy za┼éo┼╝y─ç, ┼╝e prawie nikt nie b─Ödzie z niej korzysta┼é od godziny 18:00 do 7:00 rano nast─Öpnego dnia. My, jako biznes, p┼éacimy za niewykorzystane zasoby, kt├│re generuj─ů nam 13 godzin dziennie starty!
    To daje nam 13/24 = 54% niepotrzebnych koszt├│w!

  • W ┼Ťwiecie serverless wykorzystaliby┼Ťmy DynamoDB. Tutaj p┼éacimy za ilo┼Ť─ç danych przechowywany oraz ilo┼Ť─ç i wielko┼Ť─ç odczyt├│w i zapis├│w do bazy, ale nie za czas ┼╝ycia bazy. Od 18-stej do 7-mej rano, je┼Ťli nikt nie korzysta┼é z naszej aplikacji nie ponosimy koszt├│w odczytu/zapisu tylko ewentualnie koszt przechowywania danych. Warto tu jednak zaznaczy─ç, ┼╝e powsta┼éo kilka wzorc├│w projektowych, kt├│re pozwalaj─ů na wykorzystanie mocy bazy przy zniwelowaniu koszt├│w przechowywania w niej danych.
    Poniewa┼╝ nie by┼éo zapis├│w, nie by┼éo te┼╝ koszt├│w. Nasza strata wynosi okr─ůg┼ée 0%.

Podsumowuj─ůc,model kosztowy serverless przypomina model op┼éat za telefon kom├│rkowy bez abonamentu, w kt├│rym p┼éacimy tylko za wykonane rozmowy. Pomimo tego, ┼╝e telefon jest ci─ůgle pod┼é─ůczony do sieci operatora i gotowy do u┼╝ycia (mo┼╝e odebra─ç nadchodz─ůce po┼é─ůczenie lub wykona─ç wychodz─ůce) my za to nie p┼éacimy, ten koszt operacyjny bierze na siebie operator.

W skr├│cie op┼éata za serverless przypomina rachunek za telefon, a op┼éata za klasyczne rozwi─ůzania przypomina bardziej rachunek za gaz, w kt├│rym mamy:
ÔÇó op┼éat─Ö taryfow─ů
ÔÇó abonament
ÔÇó op┼éat─Ö sieciow─ů sta┼é─ů
ÔÇó op┼éat─Ö sieciow─ů zmienn─ů
ÔÇó zu┼╝ycie
WTF?! Ja nie rozumiem tych rachunk├│w za gazÔÇŽ

Mam nadziej─Ö, ┼╝e teraz r├│┼╝nice w modelach kosztowych s─ů dla Ciebie jasne. Zapewne teraz ju┼╝ rozumiesz, dlaczego serverless jest tak popularny w┼Ťr├│d startup├│w, kt├│re maj─ů ograniczone fundusze, a czasem ich brak (wiem to z w┼éasnego do┼Ťwiadczenia) i nie chc─ů ich trwoni─ç na niepotrzebnie dzia┼éaj─ůce serwery.

Total Cost of Ownership i Activity Based Costing

Nie by┼é bym sob─ů gdybym nie wspomnia┼é w kontek┼Ťcie koszt├│w o jeszcze jednej rzeczy. Serverless jest r├│wnie┼╝ bardzo ch─Ötnie wykorzystywany przez wielkie korporacje (np. Coca-Cola), kt├│re nie musz─ů, a jednak licz─ů dok┼éadnie koszty. Zagadnienie liczenia koszt├│w w IT jest bardzo trudne. Kto si─Ö kiedy┼Ť interesowa┼é Total Cost of Ownership lub Activity Based Costing ten wie, ┼╝e niesamowicie trudno jest dok┼éadnie powiedzie─ç: Ten system kosztuje nas 38 674 z┼éote miesi─Öcznie.

W ca┼ékowity koszt utrzymania wchodzi mn├│stwo element├│w, takich jak kadry, sprz─Öt, internet, obs┼éuga, itp. a┼╝ do rachunku za pr─ůd i budynek serwerowni. Jak to wszystko adekwatnie podzieli─ç pomi─Ödzy N system├│w IT, kt├│re masz u siebie w firmie? To jest aspekt ksi─Ögowy, natomiast aspekt biznesowy jest taki, ┼╝e mega trudno jest odpowiedzie─ç na pytanie: Ile kosztuje nas jedna ÔÇ×transakcjaÔÇŁ klienta (np. z┼éo┼╝enie wniosku o urlop)? To jest 8 groszy, czy mo┼╝e z┼éoty dwadzie┼Ťcia? Tego typu wiedza pozwala skorelowa─ç koszty z cen─ů us┼éugi dla klienta i realnie okre┼Ťli─ç nasz─ů mar┼╝─Ö na tej konkretnej us┼éudze. Wiem, ┼╝e to zagadnienia biznesowe, kt├│re nie interesuj─ů przeci─Ötnego developera, ale przecie┼╝ Ty nie jeste┼Ť przeci─Ötny! :-D

Tak na marginesie, uwa┼╝am, ┼╝e model pay-as-you-go b─Ödzie si─Ö robi┼é coraz bardziej popularny. Wynika to z ewolucji technologi. Jest to bardzo fascynuj─ůca wycieczka po historii IT, kt├│r─ů mo┼╝e kiedy┼Ť Wam opowiem :-)

Podsumowanie

Dzi─Ökuj─Ö za przeczytanie tak d┼éugiego tekstu. W nagrod─Ö za wytrwa┼éo┼Ť─ç zdj─Öcie dziobaka dla Ciebie!

Dziobak

Mam nadziej─Ö, ┼╝e po tym artykule masz ju┼╝ ca┼ékiem dobre poj─Öcie o tym, czym jest serverless. Wiesz, czym si─Ö r├│┼╝ni od klasycznych system├│w i jaki jest jego model kosztowy s┼éu┼╝─ůcy do rozlicze┼ä.

Jedyne, czego nie wyt┼éumaczy┼éem, to dlaczego uwa┼╝am serverless za podej┼Ťcie do wytwarzania oprogramowania. ÔÇ×Podej┼ŤcieÔÇŁ w rozumieniu takim, jak rozumiemy Agile czy DevOps, ale o tym napisz─Ö w kolejnym artykule.

Udanej reszty dnia!




Cze┼Ť─ç

Nazywam si─Ö Pawe┼é Zubkiewicz i ciesz─Ö si─Ö, ┼╝e tu jeste┼Ť!
Od ponad 18 lat profesjonalnie tworz─Ö oprogramowanie, a od 2016 roku pasjonuje si─Ö Serverless.
T─ů stron─Ö stworzy┼éem z my┼Ťl─ů o Tobie i o nas wszystkich, kt├│rzy uwa┼╝aj─ů, ┼╝e trend serverless trwale zmieni spos├│b tworzenia oprogramowania.
Wi─Öcej o tej stronie...

Kategorie

Pobierz bezpłatny PDF

Poradnik 12 Rzeczy o Serverless

Wybrane artykuły