Serverless nije o fizičkom odsustvu poslužitelja. To nije "ubica" kontejnera niti prolazni trend. To je novi pristup izgradnji sustava u oblaku. U današnjem članku osvrnut ćemo se na arhitekturu Serverless aplikacija, proučiti ulogu pružatelja Serverless usluga i open-source projekte. Na kraju ćemo razgovarati o pitanjima primjene Serverless.
Želim napisati poslužiteljsku stranu aplikacije (čak i internet trgovine). To može biti chat, usluga za objavu sadržaja ili ravnoteža opterećenja. U svakom slučaju, bit će mnogo glavobolja: morat ću pripremiti infrastrukturu, odrediti ovisnosti aplikacije i razmisliti o operativnom sustavu poslužitelja. Zatim ću morati ažurirati manje komponente koje ne utječu na rad ostatka monolita. I ne zaboravimo na skaliranje pod opterećenjem.
Što ako uzmemo efemerne kontejnere, u kojima su potrebne ovisnosti već unaprijed instalirane, a sami kontejneri su izolirani jedni od drugih i od OS-a poslužitelja? Monolit ćemo razbiti na mikroservise, od kojih svaki možemo ažurirati i skalirati neovisno od ostalih. Stavljajući kod u takav kontejner, moći ću ga pokrenuti na bilo kojoj infrastrukturi. Već je bolje.
A ako ne želim podešavati kontejnere? Ne želim razmišljati o skaliranju aplikacije. Ne želim plaćati za neaktivne pokrenute kontejnere, kada je opterećenje na servisu minimalno. Želim pisati kod. Fokusirati se na poslovnu logiku i izbacivati proizvode na tržište brzinom svjetlosti.
Takve misli dovele su me do besposlužiteljskog računalstva. Serverless u ovom slučaju znači ne fizičko odsustvo poslužitelja, već odsustvo glavobolje oko upravljanja infrastrukturom.
Ideja je u tome da se logika aplikacije razbija na neovisne funkcije. One imaju događajnu strukturu. Svaka funkcija izvršava jednu "mikrozadatak". Sve što se traži od developera je da učita funkcije u konzolu koju pruža oblačni pružatelj i poveže ih s izvorima događaja. Kod će se izvršavati na zahtjev u automatski pripremljenom kontejneru, a ja ću platiti samo za vrijeme izvršenja.
Pogledajmo kako će sada izgledati proces razvoja aplikacije.
S aspekta developera
Ranije smo počeli govoriti o aplikaciji za internetsku trgovinu. U tradicionalnom pristupu, glavna logika sustava obavlja se monolitnom aplikacijom. I poslužitelj s aplikacijom pokrenut je neprekidno, čak i kada nema opterećenja.
Da bismo prešli na serverless, razbijamo aplikaciju na mikrozadatke. Za svaki od njih pišemo svoju funkciju. Funkcije su neovisne jedna o drugoj i ne čuvaju informacije o stanju (stateless). Mogu čak biti napisane na različitim jezicima. Ako jedna od njih 'padne', cijela aplikacija se neće zaustaviti. Arhitektura aplikacije će izgledati ovako:
Podjela na funkcije u Serverlessu sliči radu s mikroservisima. Međutim, mikroservis može obavljati više 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 čitanje. U bezservernim izračunima to će biti dvije različite funkcije koje nisu povezane jedna s drugom. Razvijač štedi računalne resurse ako, na primjer, se statistika ažurira češće nego što se preuzima.
Serverless funkcije trebaju se izvoditi u kratkom vremenskom okviru (timeout) koji određuje pružatelj usluge. Na primjer, za AWS timeout iznosi 15 minuta. To znači da dugotrajne funkcije (long-lived) treba prilagoditi zahtjevima – ovim se Serverless razlikuje od drugih popularnih tehnologija danas (kontejnera i Platform as a Service).
Svakoj funkciji dodjeljujemo događaj. Događaj je okidač za akciju:
Događaj
Akcija koju funkcija izvodi
U skladištu je učitana slika proizvoda
Smanjiti sliku i učitati je u katalog
U bazi podataka je ažurirana adresa fizičke trgovine
Učitati novu lokaciju u karte
Korisnik plaća proizvod
Pokrenuti obradu plaćanja
Događaji mogu biti HTTP zahtjevi, streamovi podataka, redovi poruka i slično. Izvori događaja su promjena ili pojava podataka. Osim toga, funkcije se mogu pokretati prema tajmeru.
Arhitektura je razrađena i aplikacija je gotovo postala serverless. Dalje idemo prema pružatelju usluge.
S strane davatelja
Obično bezserverna računanja nude pružatelji cloud usluga. Ovisno o pružatelju, zovu ih različito: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Uslugu ćemo koristiti putem konzole ili osobnog računa pružatelja usluga. Kod funkcija može se učitati na jedan od sljedećih načina:
- napisati kod u ugrađenim uređivačima putem web konzole,
- uploadati arhivu s kodom,
- raditi s javnim ili privatnim git repozitorijima.
Ovdje također postavljamo događaje koji pozivaju funkciju. Skupovi događaja mogu se razlikovati kod različitih pružatelja.
Pružatelj je izgradio i automatizirao sustav Function as a Service (FaaS) na svojoj infrastrukturi:
- Kod funkcija dolazi u skladište na strani pružatelja.
- Kada se pojavi događaj, na poslužitelju se automatski pokreću kontejneri s pripremljenim okruženjem. Svakom primjerku funkcije dodjeljuje se vlastiti izolirani kontejner.
- Iz skladišta funkcija se šalje u kontejner, proračunava se i vraća rezultat.
- Broj paralelnih događaja raste — raste broj kontejnera. Sustav se automatski skalira. Ako korisnici ne pristupaju funkciji, ona će biti neaktivna.
- Pružatelj postavlja vrijeme mirovanja kontejnera — ako se u tom razdoblju funkcije ne pojave u kontejneru, on se uništava.
Tako dobivamo Serverless "iz kutije". Plaćat ćemo za uslugu prema modelu pay-as-you-go i samo za one funkcije koje se koriste, i samo za vrijeme kada su korištene.
Kako bi upoznali programere s uslugom, pružatelji nude do 12 mjeseci besplatnog testiranja, ali ograničavaju ukupno vrijeme proračuna, broj zahtjeva mjesečno, novčana sredstva ili potrošene resurse.
Glavna prednost rada s pružateljem je mogućnost da se ne brinete o infrastrukturi (poslužiteljima, virtualnim strojevima, kontejnerima). S svoje strane, pružatelj može implementirati FaaS kako na vlastitim razvojem, tako i uz pomoć open-source alata. O tome ćemo razgovarati dalje.
S aspekta open source
Posljednjih nekoliko godina zajednica open-source aktivno radi na alatima Serverless. Veliki igrači na tržištu također doprinose razvoju beservernih platformi:
- Google nudi programerima svoj open-source alat — . U njegovom razvoju sudjelovali su IBM, RedHat, Pivotal i SAP;
- IBM radili su na Serverless platformi , koja je kasnije postala projekt Apache Foundation;
- Microsoft djelomično su otvorili kod platforme .
Razvoj se odvija i u smjeru serverless okvira. i razvijaju se unutar unaprijed pripremljenih Kubernetes klastera, radi i s Kubernetes i s Docker Swarm. Okvir djeluje kao svojevrsni kontroler – na zahtjev priprema okruženje za izvršavanje unutar klastera, a zatim pokreće funkciju.
Okviri ostavljaju mogućnost za konfiguraciju alata prema vlastitim potrebama. Tako, u Kubelessu, developer može postaviti timeout izvršavanja funkcije (defaultna vrijednost – 180 sekundi). Fission, nastojeći riješiti problem hladnog pokretanja, nudi mogućnost održavanja dijela kontejnera uvijek pokrenutima (iako to nosi troškove vezane uz neiskorištene resurse). OpenFaaS nudi niz okidača koji odgovaraju svemu: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs i drugim.
Upute za početak rada mogu se pronaći u službenoj dokumentaciji okvira. Rad s njima zahtijeva malo više vještina nego rad s davateljem - to uključuje barem sposobnost pokretanja Kubernetes klastera putem CLI-a. Maksimum je uključiti u rad druge open-source alate (recimo, upravitelj redova Kafka).
Bez obzira na to kojim ćemo se načinom raditi s Serverless - putem davatelja ili uz pomoć open-source, dobit ćemo niz prednosti i nedostataka Serverless pristupa.
Što se tiče prednosti i nedostataka
Serverless razvija ideje kontejnerske infrastrukture i mikroslužbene arhitekture, pri čemu timovi mogu raditi u višejezičnom režimu, bez vezivanja na jednu platformu. Izgradnja sustava se pojednostavljuje, a ispravljanje grešaka postaje lakše. Mikroslužbena arhitektura omogućava dodavanje novog funkcionalnosti sustavu značajno brže nego u slučaju monolitne aplikacije.
Serverless dodatno skraćuje vrijeme razvoja, omogućavajući developeru da se isključivo fokusira na poslovnu logiku aplikacije i pisanje koda. Kao posljedica toga, vrijeme izlaska proizvoda na tržište se smanjuje.
Bonus je automatsko skaliranje pod opterećenjem, a plaćamo samo za korištene resurse i samo za vrijeme kada su korišteni.
Kao i svaka tehnologija, Serverless ima nedostatke.
Na primjer, jedan od nedostataka može biti vrijeme hladnog pokretanja (u prosjeku do 1 sekunde za jezike poput JavaScript, Python, Go, Java, Ruby).
S jedne strane, vrijeme hladnog pokretanja u praksi ovisi o mnogim varijablama: jeziku u kojem je napisana funkcija, broju biblioteka, obimu koda, komunikaciji s dodatnim resursima (kao što su baze podataka ili serveri za autentifikaciju). Budući da programer upravlja tim varijablama, može smanjiti vrijeme pokretanja. No, s druge strane, programer ne može upravljati vremenom pokretanja kontejnera ― tu sve ovisi o davatelju usluga.
Hladno pokretanje može postati toplo kada funkcija ponovno koristi prethodno pokrenuti kontejner koji je pokrenuo prethodni događaj. Takva situacija će nastati u tri slučaja:
- ako kupci često koriste uslugu i raste broj poziva funkciji;
- ako davatelj usluga, platforma ili okvir dopuštaju da dio kontejnera ostane stalno pokrenut;
- ako programer pokreće funkcije prema tajmeru (na primjer, svake 3 minute).
Za mnoge aplikacije hladno pokretanje nije problem. Treba uzeti u obzir vrstu i ciljeve usluge. Kašnjenje pokretanja od jedne sekunde nije uvijek kritično za poslovnu aplikaciju, ali može postati kritično za medicinske usluge. Vjerojatno, u tom slučaju serverless pristup već neće biti primjenjiv.
Sljedećim nedostatkom serverless-a smatra se kratak vijek trajanja funkcije (timeout unutar kojeg funkcija mora biti izvršena).
No, ako se planira raditi s dugotrajnim zadacima, može se koristiti hibridna arhitektura ― kombinirati serverless s drugom tehnologijom.
Nisu sve sustave moguće koristiti prema serverless shemi.
Neke aplikacije i dalje će čuvati podatke i stanje tijekom izvršavanja. Neke arhitekture ostat će monolitne, a neke funkcije će biti dugovječne. Međutim, kao što je bio slučaj s cloud tehnologijama, a zatim i kontejnerima, serverless je tehnologija s velikom budućnošću.
U tom kontekstu, želio bih glatko preći na pitanje primjene serverless pristupa.
S aspekta primjene
Tijekom 2018. godine, postotak korištenja serverless-a . Među tvrtkama koje su već implementirale tehnologiju u svoje usluge su takvi tržišni divovi kao što su Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Pri tome treba razumjeti da serverless nije panaceja, već alat za rješavanje određenog kruga zadataka:
- Smanjiti neiskorištenost resursa. Nema potrebe stalno održavati virtualni stroj za usluge koje imaju malo zahtjeva.
- Obraditi podatke "u hodu". Smanjiti slike, izrezati pozadinu, promijeniti kodiranje videa, raditi sa IoT senzorima, izvršiti matematičke operacije.
- "Povezati" druge usluge. Git repozitorij s internim programima, chatbot u Slacku s Jirai i kalendarom.
- Balansirati opterećenje. Ovdje ćemo se detaljnije zadržati.
Pretpostavimo da postoji usluga koju koristi 50 ljudi. Za nju je postavljen virtualni stroj s slabim hardverom. Povremeno opterećenje na uslugu znatno raste. Tada slab hardver ne može podnijeti teret.
Možemo uključiti u sustav balansirnik opterećenja koji će raspodijeliti opterećenje, recimo, na tri virtualna stroja. U ovom trenutku ne možemo točno predvidjeti opterećenje, stoga zadržavamo određeni broj resursa pokrenutih "za svaki slučaj". I pretplaćujemo se na prazne resurse.
U takvoj situaciji možemo optimizirati sustav putem hibridnog pristupa: iza balansirnika opterećenja ostavljamo jedan virtualni stroj i postavljamo vezu na Serverless Endpoint s funkcijama. Ako opterećenje premaši prag ― balansirnik pokreće instance funkcija koje preuzimaju dio obrade zahtjeva.
Na taj način, Serverless se može koristiti gdje je potrebno ne previše često, ali intenzivno obrađivati veliki broj zahtjeva. U tom slučaju, pokretanje nekoliko funkcija na 15 minuta isplativije je nego stalno održavati virtualni stroj ili server.
Unatoč svim prednostima bezposlužnih računalnih usluga, prije uvođenja najprije treba procijeniti logiku aplikacije i razumjeti koje zadatke Serverless može riješiti u konkretnoj situaciji.
Serverless i Selectel
U Selectelu smo već putem naše upravljačke ploče. Sada gradimo vlastitu FaaS platformu. Želimo da programeri mogu riješiti svoje zadatke putem Serverlessa kroz prikladno, fleksibilno sučelje.
Ako imate ideje o tome kako bi idealna FaaS platforma trebala izgledati i kako želite koristiti Serverless u svojim projektima, podijelite ih u komentarima. Uzet ćemo vaše želje u obzir prilikom razvoja platforme.
Materijali korišteni u članku:
Izvor: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Lithuanian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish