Serverless ni o fizični odsotnosti strežnikov. Ni »ubijalec« kontejnerjev in ni trenutni trend. To je nov pristop k gradnji sistemov v oblaku. V današnjem članku se bomo dotaknili arhitekture Serverless aplikacij, pogledali, kakšno vlogo igra ponudnik Serverless storitve in odprtokodni projekti. Na koncu se bomo pogovorili o vprašanju uporabe Serverless.
Želim napisati serverski deo aplikacije (čak i internet prodavnicu). To može biti i chat, i servis za objavljivanje sadržaja, i balansiranje opterećenja. U svakom slučaju, izazova neće nedostajati: potrebno je pripremiti infrastrukturu, odrediti zavisnosti aplikacije, razmisliti o operativnom sistemu servera. Zatim će biti potrebno ažurirati male komponente koje ne utiču na rad ostatka monolita. I ne zaboravimo na skaliranje pod opterećenjem.
A šta ako uzmemo efemerne kontejnere, u kojima su potrebne zavisnosti već unapred instalirane, a sami kontejneri su izolovani jedni od drugih i od operativnog sistema domaćina? Monolit ćemo podeliti na mikrosервise, svaki od kojih može biti nezavisno ažuriran i skaliran. Stavljajući kod u takav kontejner, moći ću ga pokretati na bilo kojoj infrastrukturi. Već je bolje.
A ako ne želim da podešavam kontejnere? Ne želim da razmišljam o skaliranju aplikacije. Ne želim da plaćam za vreme kada su kontejneri pokrenuti, kada je opterećenje na servisu minimalno. Želim da pišem kod. Fokusirati se na poslovnu logiku i lansirati proizvode na tržište brzinom svetlosti.
Ove misli su me dovele do serverless računarstva. Serverless u ovom slučaju znači ne fizičko odsustvo servera, već odsustvo glavobolje oko upravljanja infrastrukturom.
Ideja je da se logika aplikacije razbije na nezavisne funkcije. One imaju događajnu strukturu. Svaka od funkcija izvršava jednu „mikrozadatak“. Sve što se od programera zahteva je da učita funkcije u konzolu koju pruža cloud provajder i poveže ih sa izvorima događaja. Kod će se izvršavati na zahtev u automatski pripremljenom kontejneru, a ja ću platiti samo za vreme izvršavanja.
Hajde da vidimo kako će sada izgledati proces razvoja aplikacije.
Sa strane programera
Pre smo počeli da govorimo o aplikaciji za internet prodavnicu. U tradicionalnom pristupu, glavnu logiku sistema obavlja monolitna aplikacija. I server sa aplikacijom je neprekidno pokrenut, č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 nezavisne jedna od druge i ne čuvaju informacije o stanju (stateless). Mogu čak biti napisane na različitim jezicima. Ako jedna od njih padne, cela aplikacija se neće zaustaviti. Arhitektura aplikacije će izgledati ovako:
Podela na funkcije u Serverless sistemu nalikuje radu s mikroservisima. Međutim, mikroservis može izvršavati više zadataka, dok bi funkcija idealno trebala da izvršava samo jedan. Zamislimo da je zadatak prikupljanje statistike i prikazivanje po korisničkom zahtevu. U mikroservisnom pristupu, zadatak izvršava jedna usluga sa dva ulaza: za pisanje i za čitanje. U serverless računarstvu, to će biti dve različite funkcije, koje nisu povezane. Razvijač štedi računske resurse ako se, na primer, statistika ažurira češće nego što se preuzima.
Serverless funkcije trebaju se izvršavati u kratkom vremenskom intervalu (timeout) koji određuje provajder usluge. Na primer, za AWS, timeout iznosi 15 minuta. To znači da dugotrajne funkcije (long-lived) treba prilagoditi zahtevima - ovo je ono što serverless razlikuje od drugih popularnih tehnologija danas (kontejnera i Platform as a Service).
Svakoj funkciji dodeljujemo događaj. Događaj je okidač za radnju:
Događaj
Radnja koju izvršava funkcija
U skladištu je otpremljena slika proizvoda
Smanjiti sliku i otpremiti je u katalog
U bazi podataka se ažurirala adresa fizičke prodavnice
Učitati novu lokaciju na mape
Klijent plaća proizvod
Pokrenuti obradu uplate
Događaji mogu biti HTTP zahtevi, strimovane podatke, poruke u redovima i slično. Izvori događaja su promene ili pojava podataka. Pored toga, funkcije se mogu pokretati po tajmeru.
Arhitektura je razrađena i aplikacija je gotovo serverless. Idemo sada ka provajderu usluge.
Sa strane provajdera
Obično serverless računarske usluge nude provajderi cloud usluga. Zovu ih različito: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Uslugu ćemo koristiti putem konzole ili korisničkog računa provajdera. Kod funkcija se može učitati na jedan od sledećih načina:
- napišite kod u ugrađenim uređivačima putem veb konzole,
- učitajte arhivu sa kodom,
- radite sa javnim ili privatnim git repozitorijumima.
Tukaj nastavljamo dogodke, ki sprožijo funkcijo. Pri različnih ponudnikih se lahko nabori dogodkov razlikujejo.
Ponudnik je na svoji infrastrukturi zgradil in avtomatiziral sistem Function as a Service (FaaS):
- Koda funkcij se shranjuje na strani ponudnika.
- Ko se pojavi dogodek, se na strežniku samodejno zaženejo kontejnerji s pripravljenim okoljem. Vsaka instanca funkcije ima svoj izoliran kontejner.
- Iz shrambe funkcija pride v kontejner, se izračuna in vrne rezultat.
- Število sočasnih dogodkov narašča — narašča tudi število kontejnerjev. Sistem se samodejno prilagaja. Če uporabniki ne dostopajo do funkcije, bo ta neaktivna.
- Ponudnik nastavi čas neaktivnosti kontejnerjev — če v tem času funkcij ni v kontejnerju, se ta uniči.
Tako dobimo Serverless 'iz škatlice'. Plačali bomo za storitev po modelu pay-as-you-go in le za tiste funkcije, ki se uporabljajo, in le za čas, ko so bile uporabljene.
Da bi razvijalcem predstavili storitev, ponudniki ponujajo do 12 mesecev brezplačnega preizkušanja, vendar omejijo skupni čas izračunov, število zahtevkov na mesec, sredstva ali porabljene moči.
Glavna prednost dela s ponudnikom je možnost, da se ne skrbimo za infrastrukturo (strežnike, virtualne računalnike, kontejnerje). S svoje strani lahko ponudnik izvede FaaS tako na lastnih rešitvah kot tudi z uporabo orodij odprte kode. O tem se bomo pogovarjali naprej.
S strani odprte kode
V zadnjih dveh letih je skupnost odprte kode aktivno delala na orodjih Serverless. Med drugim prispevajo k razvoju brezstrežnih platform največji igralci na trgu:
- Google ponuja razvijalcem svoje orodje odprte kode — . V njegovi razvijanju so sodelovali IBM, RedHat, Pivotal in SAP;
- IBM so delali na platformi Serverless , ki je kasneje postala projekt Apache Foundation;
- Microsoft so deloma odprli kodo platforme .
Razvoj poteka tudi v smeri brezstrežnih okvirjev. in se izvajajo znotraj vnaprej pripravljenih Kubernetes grozdov, deluje tako s Kubernetesom kot s Docker Swarm. Orodje deluje kot svojevrsten kontroler – na zahtevo pripravi okolje za izvajanje znotraj klasterja in nato tam zažene funkcijo.
Okviri omogočajo prilagoditev orodja svojim potrebam. Tako lahko v Kubeless razvijalec nastavi timeout za izvajanje funkcije (privzeta vrednost je 180 sekund). Fission v poskusu reševanja težave s hladnim zagonom ponuja, da del vsakega kontejnerja deluje ves čas (čeprav to prinaša stroške neizkoriščenih virov). OpenFaaS ponuja niz sprožilcev po okusu in barvi: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs in druge.
Navodila za začetek dela lahko najdete v uradni dokumentaciji okvirov. Delo z njimi zahteva nekoliko več znanja kot pri delu s ponudnikom – to je vsaj sposobnost zaženeti Kubernetes klaster skozi CLI. Največ, vključiti v delo druge open-source naprave (recimo, upravljalnik vrstic Kafka).
Ne glede na to, kako bomo delali s Serverless – preko ponudnika ali s pomočjo open-source, bomo pridobili vrsto prednosti in slabosti pristopa Serverless.
Z radarskega vidika prednosti in slabosti
Serverless razvija ideje kontejnerske infrastrukture in mikroservisnega pristopa, pri katerem lahko ekipe delajo v večjezičnem načinu, ne da bi se vezale na eno platformo. Gradnja sistema se poenostavi, prav tako je lažje odpravljati napake. Mikroservisna arhitektura omogoča dodajanje nove funkcionalnosti v sistem znatno hitreje kot v primeru monolitne aplikacije.
Serverless še bolj skrajša čas razvoja, kar omogoča razvijalcu, da se osredotoči izključno na poslovno logiko aplikacije in pisanje kode. Posledično se čas dostopa razvojev na trg skrajša.
Kot dodatek dobimo avtomatsko skaliranje pod obremenitvijo, plačamo pa le za uporabljene vire in le takrat, ko se uporabljajo.
Kot vsaka tehnologija, ima tudi Serverless slabosti.
Na primer, ena od slabosti je čas hladnega zagona (v povprečju do 1 sekunde za jezike, kot so JavaScript, Python, Go, Java, Ruby).
Z jedne strane, čas hladného štartu závisí od mnohých premenných: jazyk, v ktorom je napísaná funkcia, počet knižníc, objem kódu, interakcia s ďalšími zdrojmi (tými istými databázami alebo autentifikačnými servermi). Keďže vývojár má kontrolu nad týmito premennými, môže skrátiť čas štartu. Na druhej strane však vývojár nemôže ovplyvniť čas spustenia kontajnera – to závisí len od poskytovateľa.
Hladný štart sa môže premeniť na teplý, keď funkcia znovu využíva kontajner spustený predchádzajúcou udalosťou. Taká situácia nastane v troch prípadoch:
- ak zákazníci často používajú službu a rastie počet volaní na funkciu;
- ak poskytovateľ, platforma alebo rámec umožňujú mať niektoré kontajnery počas celého času spustené;
- ak vývojár spúšťa funkcie podľa časového plánu (povedzme každé 3 minúty).
Pre mnohé aplikácie nie je hladný štart problém. Tu je potrebné zohľadniť typ a úlohy služby. Zdržanie štartu o sekundu nie je vždy kritické pre podnikové aplikácie, ale môže sa stať kritickým pre zdravotné služby. Pravdepodobne v takomto prípade bezserverový prístup nebude vhodný.
Ďalším nedostatkom Serverless sa nazýva krátky čas životnosti funkcie (timeout, do ktorého musí funkcia byť vykonaná).
Avšak, ak sa chystáte pracovať s dlhodobými úlohami, môžete použiť hybridnú architektúru – skombinovať Serverless s inou technológiou.
Nie všetky systémy budú schopné fungovať podľa schémy Serverless.
Niektoré aplikácie stále uchovávajú dáta a stav počas behu. Niektoré architektúry zostanú monolitné, a niektoré funkcie budú dlhodobé. Avšak (ako kedysi cloudové technológie a neskôr kontajnery), Serverless je technológia s veľkou budúcnosťou.
V tomto zmysle by som rád plynule prešiel k otázke aplikácie prístupu Serverless.
Z pohľadu aplikácie
V roku 2018 sa percento využívania Serverless . Medzi spoločnosťami, ktoré už implementovali technológiu do svojich služieb, sú giganty trhu ako Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Pri tom je potrebné chápať, že Serverless nie je panacea, ale nástroj na riešenie určitých okruhov úloh:
- Skraťte prestoje zdrojov. Ni vam ni treba ves čas imeti virtualnega stroja za storitve, do katerih je malo povpraševanja.
- Obdelava podatkov "v teku". Stiskanje slik, odstranjevanje ozadja, spreminjanje kodiranja videa, delo s senzorji IoT, izvajanje matematičnih operacij.
- "Povezovanje" drugih storitev med seboj. Git repozitorij z notranjimi programi, klepetalni robot v Slacku povezani z Jiro in koledarjem.
- Uravnotežiti obremenitev. Tukaj se bomo podrobneje ustavili.
Recimo, da obstaja storitev, ki jo obišče 50 oseb. Za to je dodeljen virtualni stroj z šibko strojno opremo. Občasno se obremenitev storitve močno poveča. Takrat šibka oprema ne zmore.
Lahko vključimo uravnoteževalnik obremenitve, ki bo obremenitev razdelil na, recimo, tri virtualne stroje. V tem trenutku ne moremo natančno napovedati obremenitve, zato določeno število virov držimo aktivnih "za rezervo". In preplačujemo za mirujoče stanje.
V takšni situaciji lahko optimiziramo sistem s hibridnim pristopom: za uravnoteževalnikom obremenitve pustimo en virtualni stroj in postavimo povezavo na Serverless Endpoint s funkcijami. Če obremenitev preseže prag, uravnoteževalnik zažene primere funkcij, ki prevzamejo del obdelave zahtevkov.
Tako je Serverless mogoče uporabiti tam, kjer se neobičajno pogosto, vendar intenzivno obdela velika količina zahtevkov. V tem primeru je zažetak več funkcij za 15 minut cenejši kot ves čas imeti vklopljen virtualni stroj ali strežnik.
Kljub vsem prednostim brezstrežnega računalništva je pred uvedbo najprej treba oceniti logiko aplikacije in razumeti, katere naloge lahko Serverless reši v konkretnem primeru.
Serverless in Selectel
V Selectelu smo že prek naše nadzorne plošče. Zdaj gradimo svojo lastno FaaS platformo. Želimo, da lahko razvijalci rešejo svoje naloge s pomočjo Serverless prek priročnega in fleksibilnega vmesnika.
Če imate ideje, kakšna naj bi bila idealna FaaS platforma in kako bi želeli uporabljati Serverless v svojih projektih, jih delite v komentarjih. Upoštevali bomo vaše želje pri razvoju platforme.
Viri uporabljeni v članku:
Izvor: habr.com
