{"id":33935,"date":"2019-10-31T21:55:27","date_gmt":"2019-10-31T18:55:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/serverless-po-stoechkam\/"},"modified":"2019-10-31T21:55:27","modified_gmt":"2019-10-31T18:55:27","slug":"serverless-po-stoechkam","status":"publish","type":"post","link":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/serverless-po-stoechkam","title":{"rendered":"Serverless po koracima","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Serverless
\nServerless nije o fizi\u010dkom odsustvu poslu\u017eitelja. To nije \"ubica\" kontejnera niti prolazni trend. To je novi pristup izgradnji sustava u oblaku. U dana\u0161njem \u010dlanku osvrnut \u0107emo se na arhitekturu Serverless aplikacija, prou\u010diti ulogu pru\u017eatelja Serverless usluga i open-source projekte. Na kraju \u0107emo razgovarati o pitanjima primjene Serverless.
\n<\/a><\/noindex>
\n\u017delim napisati poslu\u017eiteljsku stranu aplikacije (\u010dak i internet trgovine). To mo\u017ee biti chat, usluga za objavu sadr\u017eaja ili ravnote\u017ea optere\u0107enja. U svakom slu\u010daju, bit \u0107e mnogo glavobolja: morat \u0107u pripremiti infrastrukturu, odrediti ovisnosti aplikacije i razmisliti o operativnom sustavu poslu\u017eitelja. Zatim \u0107u morati a\u017eurirati manje komponente koje ne utje\u010du na rad ostatka monolita. I ne zaboravimo na skaliranje pod optere\u0107enjem.<\/p>\n

\u0160to ako uzmemo efemerne kontejnere, u kojima su potrebne ovisnosti ve\u0107 unaprijed instalirane, a sami kontejneri su izolirani jedni od drugih i od OS-a poslu\u017eitelja? Monolit \u0107emo razbiti na mikroservise, od kojih svaki mo\u017eemo a\u017eurirati i skalirati neovisno od ostalih. Stavljaju\u0107i kod u takav kontejner, mo\u0107i \u0107u ga pokrenuti na bilo kojoj infrastrukturi. Ve\u0107 je bolje. <\/p>\n

A ako ne \u017eelim pode\u0161avati kontejnere? Ne \u017eelim razmi\u0161ljati o skaliranju aplikacije. Ne \u017eelim pla\u0107ati za neaktivne pokrenute kontejnere, kada je optere\u0107enje na servisu minimalno. \u017delim pisati kod. Fokusirati se na poslovnu logiku i izbacivati proizvode na tr\u017ei\u0161te brzinom svjetlosti. <\/p>\n

Takve misli dovele su me do besposlu\u017eiteljskog ra\u010dunalstva. Serverless u ovom slu\u010daju zna\u010di ne fizi\u010dko odsustvo poslu\u017eitelja, ve\u0107 odsustvo glavobolje oko upravljanja infrastrukturom.<\/em><\/p>\n

Ideja je u tome da se logika aplikacije razbija na neovisne funkcije. One imaju doga\u0111ajnu strukturu. Svaka funkcija izvr\u0161ava jednu \"mikrozadatak\". Sve \u0161to se tra\u017ei od developera je da u\u010dita funkcije u konzolu koju pru\u017ea obla\u010dni pru\u017eatelj i pove\u017ee ih s izvorima doga\u0111aja. Kod \u0107e se izvr\u0161avati na zahtjev u automatski pripremljenom kontejneru, a ja \u0107u platiti samo za vrijeme izvr\u0161enja. <\/p>\n

Pogledajmo kako \u0107e sada izgledati proces razvoja aplikacije.<\/p>\n

S aspekta developera<\/h2>\n

\nRanije smo po\u010deli govoriti o aplikaciji za internetsku trgovinu. U tradicionalnom pristupu, glavna logika sustava obavlja se monolitnom aplikacijom. I poslu\u017eitelj s aplikacijom pokrenut je neprekidno, \u010dak i kada nema optere\u0107enja.<\/p>\n

Da bismo pre\u0161li na serverless, razbijamo aplikaciju na mikrozadatke.<\/strong> Za svaki od njih pi\u0161emo svoju funkciju. Funkcije su neovisne jedna o drugoj i ne \u010duvaju informacije o stanju (stateless). Mogu \u010dak biti napisane na razli\u010ditim jezicima. Ako jedna od njih 'padne', cijela aplikacija se ne\u0107e zaustaviti. Arhitektura aplikacije \u0107e izgledati ovako:<\/p>\n

\"Serverless
\nPodjela na funkcije u Serverlessu sli\u010di radu s mikroservisima. Me\u0111utim, mikroservis mo\u017ee obavljati vi\u0161e zadataka, dok funkcija u idealu treba obavljati samo jedan. Pretpostavimo da je zadatak prikupiti statistiku i prikazati je na zahtjev korisnika. U mikroservisnom pristupu, zadatak obavlja jedan servis s dva ulaza: za upis i za \u010ditanje. U bezservernim izra\u010dunima to \u0107e biti dvije razli\u010dite funkcije koje nisu povezane jedna s drugom. Razvija\u010d \u0161tedi ra\u010dunalne resurse ako, na primjer, se statistika a\u017eurira \u010de\u0161\u0107e nego \u0161to se preuzima. <\/p>\n

Serverless funkcije trebaju se izvoditi u kratkom vremenskom okviru (timeout) koji odre\u0111uje pru\u017eatelj usluge. Na primjer, za AWS timeout iznosi 15 minuta. To zna\u010di da dugotrajne funkcije (long-lived) treba prilagoditi zahtjevima \u2013 ovim se Serverless razlikuje od drugih popularnih tehnologija danas (kontejnera i Platform as a Service).<\/p>\n

Svakoj funkciji dodjeljujemo doga\u0111aj.<\/strong> Doga\u0111aj je okida\u010d za akciju:<\/p>\n

Doga\u0111aj<\/strong>
\nAkcija koju funkcija izvodi<\/strong><\/p>\n

U skladi\u0161tu je u\u010ditana slika proizvoda
\nSmanjiti sliku i u\u010ditati je u katalog<\/p>\n

U bazi podataka je a\u017eurirana adresa fizi\u010dke trgovine
\nU\u010ditati novu lokaciju u karte<\/p>\n

Korisnik pla\u0107a proizvod
\nPokrenuti obradu pla\u0107anja<\/p>\n

Doga\u0111aji mogu biti HTTP zahtjevi, streamovi podataka, redovi poruka i sli\u010dno. Izvori doga\u0111aja su promjena ili pojava podataka. Osim toga, funkcije se mogu pokretati prema tajmeru.<\/p>\n

Arhitektura je razra\u0111ena i aplikacija je gotovo postala serverless. Dalje idemo prema pru\u017eatelju usluge.<\/p>\n

S strane davatelja<\/h2>\n

\nObi\u010dno bezserverna ra\u010dunanja nude pru\u017eatelji cloud usluga. Ovisno o pru\u017eatelju, zovu ih razli\u010dito: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions. <\/p>\n

Uslugu \u0107emo koristiti putem konzole ili osobnog ra\u010duna pru\u017eatelja usluga. Kod funkcija mo\u017ee se u\u010ditati na jedan od sljede\u0107ih na\u010dina:<\/p>\n