Bez poslužitelja ne radi se o fizičkoj odsutnosti poslužitelja. Ovo nije ubojica kontejnera ili prolazni trend. Ovo je novi pristup izgradnji sustava u oblaku. U današnjem ćemo se članku dotaknuti arhitekture aplikacija bez poslužitelja, da vidimo kakvu ulogu igraju pružatelji usluga bez poslužitelja i projekti otvorenog koda. Na kraju, razgovarajmo o problemima korištenja Serverless.
Želim napisati poslužiteljski dio aplikacije (ili čak online trgovine). To može biti chat, usluga objavljivanja sadržaja ili balanser opterećenja. U svakom slučaju, bit će puno glavobolja: morat ćete pripremiti infrastrukturu, odrediti ovisnosti aplikacija i razmisliti o operativnom sustavu hosta. Tada ćete morati ažurirati male komponente koje ne utječu na rad ostatka monolita. Pa, nemojmo zaboraviti na skaliranje pod opterećenjem.
Što ako uzmemo efemerne spremnike, u kojima su potrebne ovisnosti već unaprijed instalirane, a sami spremnici izolirani jedan od drugoga i od glavnog OS-a? Monolit ćemo podijeliti na mikroservise, od kojih se svaki može ažurirati i skalirati neovisno o drugima. Smještanjem koda u takav spremnik, mogu ga pokrenuti na bilo kojoj infrastrukturi. Već bolje.
Što ako ne želite konfigurirati spremnike? Ne želim razmišljati o skaliranju aplikacije. Ne želim plaćati kontejnere koji rade u praznom hodu kada je opterećenje usluge minimalno. Želim napisati kod. Usredotočite se na poslovnu logiku i iznesite proizvode na tržište brzinom svjetlosti.
Takve su me misli dovele do računalstva bez poslužitelja. Bez poslužitelja u ovom slučaju znači ne fizički nedostatak poslužitelja, već nedostatak upravljanja infrastrukturom glavobolje.
Ideja je da se logika aplikacije rastavlja na neovisne funkcije. Imaju strukturu događaja. Svaka funkcija obavlja jedan "mikrozadatak". Sve što se traži od programera je učitati funkcije u konzolu koju pruža pružatelj usluga oblaka i povezati ih s izvorima događaja. Kod će se izvršiti na zahtjev u automatski pripremljenom spremniku, a ja ću platiti samo vrijeme izvršenja.
Pogledajmo kako će sada izgledati proces razvoja aplikacije.
Sa strane programera
Ranije smo počeli razgovarati o aplikaciji za online trgovinu. U tradicionalnom pristupu, glavnu logiku sustava izvodi monolitna aplikacija. I poslužitelj s aplikacijom stalno radi, čak i ako nema opterećenja.
Za prelazak na serverless, aplikaciju dijelimo na mikrozadatke. Za svaku od njih pišemo vlastitu funkciju. Funkcije su neovisne jedna o drugoj i ne pohranjuju podatke o stanju (bez stanja). Mogu čak biti napisane na različitim jezicima. Ako jedan od njih “padne”, cijela aplikacija neće stati. Arhitektura aplikacije će izgledati ovako:
Podjela na funkcije u Serverless je slična radu s mikroservisima. Ali mikroservis može obavljati nekoliko zadataka, a funkcija bi idealno trebala obavljati jedan. Zamislimo da je zadatak prikupiti statistiku i prikazati je na zahtjev korisnika. U mikroservisnom pristupu zadatak obavlja jedna usluga s dvije ulazne točke: pisanje i čitanje. U računalstvu bez poslužitelja to će biti dvije različite funkcije koje nisu međusobno povezane. Programer štedi računalne resurse ako se, na primjer, statistika ažurira češće nego što se preuzima.
Funkcije bez poslužitelja moraju se izvršiti u kratkom vremenskom razdoblju (timeout), koje određuje davatelj usluge. Na primjer, za AWS vrijeme čekanja je 15 minuta. To znači da će dugotrajne funkcije morati biti promijenjene kako bi odgovarale zahtjevima - to je ono što razlikuje Serverless od ostalih popularnih tehnologija danas (kontejneri i platforma kao usluga).
Svakoj funkciji dodjeljujemo događaj. Događaj je okidač za radnju:
događaj
Radnja koju funkcija izvodi
Slika proizvoda je učitana u spremište.
Komprimirajte sliku i prenesite je u direktorij
Adresa fizičke trgovine ažurirana je u bazi podataka
Učitajte novu lokaciju u karte
Klijent plaća robu
Započnite obradu plaćanja
Događaji mogu biti HTTP zahtjevi, strujanje podataka, redovi poruka i tako dalje. Izvori događaja su promjene ili pojave podataka. Osim toga, funkcije se mogu pokrenuti pomoću timera.
Arhitektura je razrađena, a aplikacija je gotovo postala bez servera. Zatim idemo do pružatelja usluga.
Sa strane provajdera
Obično računalstvo bez poslužitelja nude pružatelji usluga u oblaku. Zovu se različito: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Uslugu ćemo koristiti putem konzole ili osobnog računa pružatelja usluga. Funkcijski kod se može preuzeti na jedan od sljedećih načina:
- pisanje koda u ugrađenim editorima putem web konzole,
- preuzmite arhivu s kodom,
- rad s javnim ili privatnim git spremištima.
Ovdje postavljamo događaje koji pozivaju funkciju. Skupovi događaja mogu se razlikovati za različite pružatelje usluga.
Davatelj je izgradio i automatizirao sustav funkcije kao usluge (FaaS) na svojoj infrastrukturi:
- Kôd funkcije završava u pohrani na strani pružatelja usluga.
- Kada se dogodi događaj, spremnici s pripremljenim okruženjem automatski se postavljaju na poslužitelj. Svaka instanca funkcije ima vlastiti izolirani spremnik.
- Iz pohrane se funkcija šalje u spremnik, izračunava i vraća rezultat.
- Raste broj paralelnih događaja – raste broj kontejnera. Sustav se automatski skalira. Ako korisnici ne pristupe funkciji, ona će biti neaktivna.
- Davatelj postavlja vrijeme mirovanja za spremnike - ako se tijekom tog vremena funkcije ne pojave u spremniku, on se uništava.
Na ovaj način dobivamo Serverless iz kutije. Uslugu ćemo plaćati po tekućem modelu i to samo za one funkcije koje se koriste i samo za vrijeme kada su se koristile.
Kako bi programere upoznali s uslugom, pružatelji usluga nude do 12 mjeseci besplatnog testiranja, ali ograničavaju ukupno vrijeme izračuna, broj zahtjeva mjesečno, sredstva ili potrošnju energije.
Glavna prednost rada s pružateljem je mogućnost da ne brinete o infrastrukturi (poslužiteljima, virtualnim strojevima, spremnicima). Sa svoje strane, pružatelj može implementirati FaaS koristeći vlastiti razvoj i koristeći alate otvorenog koda. Razgovarajmo o njima dalje.
Sa strane otvorenog koda
Zajednica otvorenog izvornog koda aktivno radi na alatima bez poslužitelja posljednjih nekoliko godina. Najveći tržišni igrači također doprinose razvoju platformi bez poslužitelja:
- Google nudi programerima svoj alat otvorenog koda - . U njegovom razvoju sudjelovali su IBM, RedHat, Pivotal i SAP;
- IBM radio na platformi bez poslužitelja , koji je potom postao projekt Zaklade Apache;
- microsoft djelomično otvorio kod platforme .
Razvoj je također u tijeku u smjeru okvira bez poslužitelja. и raspoređeni unutar unaprijed pripremljenih Kubernetes klastera, radi i s Kubernetesom i s Docker Swarmom. Framework djeluje kao neka vrsta kontrolera - na zahtjev priprema runtime okruženje unutar klastera, zatim tamo pokreće funkciju.
Okviri ostavljaju prostora za konfiguriranje alata prema vašim potrebama. Dakle, u Kubelessu programer može konfigurirati vremensko ograničenje izvršavanja funkcije (zadana vrijednost je 180 sekundi). Fission, u pokušaju da riješi problem hladnog pokretanja, predlaže da neki spremnici budu uključeni cijelo vrijeme (iako to uključuje troškove zastoja resursa). A OpenFaaS nudi skup okidača za svaki ukus i boju: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs i drugi.
Upute za početak rada nalaze se u službenoj dokumentaciji okvira. Rad s njima zahtijeva malo više vještina nego rad s pružateljem usluga - to je barem mogućnost pokretanja Kubernetes klastera putem CLI-ja. Najviše uključite druge alate otvorenog koda (na primjer, Kafka upravitelj čekanja).
Bez obzira na to kako radimo s Serverless - preko pružatelja ili korištenjem otvorenog koda, dobit ćemo niz prednosti i nedostataka Serverless pristupa.
Sa stajališta prednosti i nedostataka
Serverless razvija ideje kontejnerske infrastrukture i mikroservisnog pristupa, u kojem timovi mogu raditi u višejezičnom načinu rada bez vezivanja za jednu platformu. Izgradnja sustava je pojednostavljena i greške se lakše ispravljaju. Mikroservisna arhitektura omogućuje vam dodavanje nove funkcionalnosti sustavu mnogo brže nego u slučaju monolitne aplikacije.
Bez poslužitelja dodatno smanjuje vrijeme razvoja, omogućujući programeru da se usredotoči isključivo na poslovnu logiku i kodiranje aplikacije. Kao rezultat toga, vrijeme izlaska na tržište za razvoje je smanjeno.
Kao bonus, dobivamo automatsko skaliranje za opterećenje, a plaćamo samo za korištene resurse i samo u trenutku kada su korišteni.
Kao i svaka tehnologija, Serverless ima nedostatke.
Na primjer, takav nedostatak može biti vrijeme hladnog pokretanja (u prosjeku do 1 sekunde za jezike kao što su JavaScript, Python, Go, Java, Ruby).
S jedne strane, u stvarnosti vrijeme hladnog pokretanja ovisi o mnogim varijablama: jeziku na kojem je funkcija napisana, broju biblioteka, količini koda, komunikaciji s dodatnim resursima (iste baze podataka ili autentifikacijski poslužitelji). Budući da programer kontrolira ove varijable, on može smanjiti vrijeme pokretanja. Ali s druge strane, programer ne može kontrolirati vrijeme pokretanja spremnika - sve ovisi o davatelju.
Hladno pokretanje može se pretvoriti u toplo pokretanje kada funkcija ponovno koristi spremnik koji je pokrenuo prethodni događaj. Ova situacija će se pojaviti u tri slučaja:
- ako klijenti često koriste uslugu i povećava se broj poziva na funkciju;
- ako vam pružatelj, platforma ili okvir dopuštaju da neki spremnici rade cijelo vrijeme;
- ako programer pokreće funkcije na mjeraču vremena (recimo svake 3 minute).
Za mnoge primjene, hladni start ne predstavlja problem. Ovdje se trebate oslanjati na vrstu i zadatke službe. Odgoda početka od jedne sekunde nije uvijek kritična za poslovnu aplikaciju, ali može postati kritična za medicinske usluge. U ovom slučaju pristup bez poslužitelja vjerojatno više neće biti prikladan.
Sljedeći nedostatak Serverless je kratak životni vijek funkcije (timeout tijekom kojeg se funkcija mora izvršiti).
No, ako morate raditi s dugotrajnim zadacima, možete koristiti hibridnu arhitekturu - kombinirati Serverless s drugom tehnologijom.
Neće svi sustavi moći raditi pomoću sheme bez poslužitelja.
Neke će aplikacije i dalje pohranjivati podatke i stanje tijekom izvođenja. Neke će arhitekture ostati monolitne, a neke značajke dugovječne. Međutim (kao i tehnologije u oblaku, a potom i kontejneri), Serverless je tehnologija s velikom budućnošću.
U tom smislu, želio bih glatko prijeći na pitanje korištenja pristupa bez poslužitelja.
Sa strane primjene
Za 2018., postotak upotrebe bez poslužitelja . Među tvrtkama koje su već implementirale tehnologiju u svoje usluge su tržišni divovi kao što su Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. U isto vrijeme, morate shvatiti da Serverless nije lijek za sve, već alat za rješavanje određenog niza problema:
- Smanjite zastoj resursa. Nema potrebe stalno držati virtualni stroj za usluge koje imaju malo poziva.
- Obrada podataka u hodu. Komprimirajte slike, izrežite pozadine, promijenite video kodiranje, radite s IoT senzorima, izvodite matematičke operacije.
- “Lijepite” druge usluge zajedno. Git repozitorij s internim programima, chat bot u Slacku s Jirom i kalendarom.
- Uravnotežite opterećenje. Pogledajmo pobliže ovdje.
Recimo da postoji usluga koja privlači 50 ljudi. Ispod njega nalazi se virtualni stroj sa slabim hardverom. S vremena na vrijeme, opterećenje usluge značajno se povećava. Tada se slab hardver ne može nositi.
U sustav možete uključiti balanser koji će rasporediti opterećenje, recimo, na tri virtualna stroja. U ovoj fazi ne možemo točno predvidjeti opterećenje, tako da određenu količinu resursa držimo "u rezervi". I preplaćamo zastoj.
U takvoj situaciji možemo optimizirati sustav kroz hibridni pristup: ostavljamo jedno virtualno računalo iza balansera opterećenja i postavljamo vezu na Endpoint bez poslužitelja s funkcijama. Ako opterećenje premaši prag, balanser pokreće instance funkcija koje preuzimaju dio obrade zahtjeva.
Dakle, Serverless se može koristiti tamo gdje je potrebno obraditi veliki broj zahtjeva ne prečesto, ali intenzivno. U ovom slučaju, pokretanje nekoliko funkcija u trajanju od 15 minuta isplativije je od održavanja virtualnog stroja ili poslužitelja cijelo vrijeme.
Uz sve prednosti računalstva bez poslužitelja, prije implementacije prvo morate procijeniti logiku aplikacije i shvatiti koje probleme Serverless može riješiti u pojedinom slučaju.
Bez poslužitelja i Selectel
U Selectelu već jesmo putem naše upravljačke ploče. Sada gradimo vlastitu FaaS platformu. Želimo da programeri mogu riješiti svoje probleme koristeći Serverless putem praktičnog, fleksibilnog sučelja.
Ako imate ideje o tome kakva bi trebala biti idealna FaaS platforma i kako želite koristiti Serverless u svojim projektima, podijelite ih u komentarima. Vaše želje ćemo uzeti u obzir prilikom razvoja platforme.
Materijali korišteni u članku:
Izvor: www.habr.com