Ključne točke
- Već nekoliko godina obećavaju nam da će serverless računanje otvoriti novu eru bez konkretnih operativnih sustava za izvršavanje aplikacija. Govorili su nam da će ta struktura riješiti mnoge probleme skalabilnosti. U stvarnosti je sve drugačije.
- Iako mnogi serverless tehnologiju smatraju novom idejom, njezini korijeni mogu se pratiti sve do 2006. godine, kada su se pojavili Zimki PaaS i Google App Engine - u oba slučaja korištena je serverless arhitektura.
- Postoje četiri razloga zašto je serverless revolucija zapela: od ograničene podrške jezika programiranja do problema s performansama.
- Serverless računanja nisu posve beskorisna. Nipošto ne. Međutim, ne bi ih trebalo smatrati izravnom zamjenom poslužitelja. Za neke aplikacije oni mogu biti zgodan alat.
Poslužitelj je mrtav, živio poslužitelj!
Tako zvuči bojali klic adpetata serverless revolucije. Dovoljno je površno pregledati industrijski tisak posljednjih nekoliko godina i lako se može doći do zaključka da je tradicionalni poslužiteljski model mrtav i da ćemo za nekoliko godina svi koristiti serverless arhitekture.
Kao što je poznato svima u industriji, a kako smo također naveli u našem članku o , to nije tako. Unatoč brojnim člancima o prednostima , ona se nikada nije ostvarila. U stvarnosti, , da je ova revolucija možda zaglavila.
Neka od obećanja za serverless modele su, nesumnjivo, realizirana, ali ne sve. Daleko od svega.
U ovom članku želim razmotriti razloge takvog stanja. Zašto nedostatak fleksibilnosti serverless modela još uvijek predstavlja prepreku za njihovo šire usvajanje, iako ostaju korisni u određenim, jasno definiranim okolnostima.
Što su obećavali adpeti serverless računalstva
Prije nego što pređemo na probleme serverless računalstva, hajde da vidimo što su trebali osigurati. bila su brojna i - ponekad - vrlo ambiciozna.
Za one koji nisu upoznati s terminom, evo kratke definicije. Bežerne računalne arhitekture definiraju strukturu u kojoj se aplikacije (ili dijelovi aplikacija) izvršavaju na zahtjev u okruženjima koja se obično udaljeno hostaju. Osim toga, bežerne sustave možete hostati i kod sebe. Tijekom nekoliko posljednjih godina, izgradnja otpornog bežernog sustava bila je glavna briga sistemskih administratora i SaaS kompanija, budući da (kako se navodi) ova arhitektura nudi nekoliko ključnih prednosti u odnosu na "tradicionalni" klijentsko-poslužiteljski model:
- Bežerni modeli ne zahtijevaju od korisnika da održavaju vlastite operacijske sustave ili čak razvijaju aplikacije kompatibilne s određenim OS-ovima. Umjesto toga, programeri kreiraju zajednički kod, učitavaju ga u bežernu platformu i prate njegovo izvršavanje.
- Resursi u bežernim okvirima obično se naplaćuju po minutama (ili čak sekundama). To znači da klijenti plaćaju samo za vrijeme kada kod zapravo radi. To je značajna razlika u odnosu na tradicionalne oblake VM, gdje stroj veći dio vremena mirova, ali za njega se mora plaćati.
- Problem skalabilnosti također je riješen. Resursi u bežernim okvirima dinamički se dodjeljuju, tako da sustav lako može podnijeti iznenadne poraste potražnje.
Ukratko, bežerni modeli pružaju fleksibilna, jeftina i skalabilna rješenja. Čudno je da nismo razmislili o ovoj ideji ranije.
Je li ovo zapravo nova ideja?
Zapravo, ideja nije nova. Koncept koji korisnicima omogućava da plaćaju samo za vrijeme kada se kod zapravo pokreće postoji otkako je uveden u okviru 2006. godine, a otprilike u to vrijeme Google App Engine ponudio je vrlo slično rješenje.
Uistinu, ono što sada nazivamo "bežernim" modelom starije je od mnogih tehnologija koje danas nazivamo "nativnim oblačnim", a koje nude gotovo isto. Kao što je već spomenuto, bežerni modeli su u suštini samo nastavak poslovnog modela SaaS koji postoji već nekoliko desetljeća.
Također je važno priznati da bezserverni model nije arhitektura FaaS, iako postoji veza između njih. FaaS je, u suštini, računalno orijentirani dio bezserverne arhitekture, ali ne obuhvaća cijeli sustav.
Pa koja je svrha cijele te buke? Pa, budući da se brzina prodiranja interneta u zemlje u razvoju nastavlja dramatično povećavati, potražnja za računalnim resursima također raste. Na primjer, u mnogim zemljama s brzo rastućim sektorima e-trgovine jednostavno ne postoji računalna infrastruktura za aplikacije na tim platformama. Tu dolaze do izražaja komercijalne bezserverne platforme.
Problemi bezservernih modela
Ovdje leži caka, bezserverni modeli imaju... probleme. Ne shvatite me krivo: ne kažem da su sami po sebi loši ili da ne donose značajnu vrijednost nekim tvrtkama u određenim okolnostima. No, glavno tvrđenje 'revolucije' – da će bezserverna arhitektura brzo zamijeniti tradicionalnu – nikada se neće ostvariti.
Evo zašto.
Ograničena podrška za programske jezike
Većina bezservernih platformi dopušta pokretanje samo onih aplikacija koje su napisane na određenim jezicima. To ozbiljno ograničava fleksibilnost i prilagodljivost tih sustava.
Pretpostavlja se da bezserverne platforme podržavaju većinu glavnih jezika. AWS Lambda i Azure Functions također pružaju omotač za pokretanje aplikacija i funkcija na nepodržanim jezicima, iako je to često povezano s troškovima na performansama. Dakle, za većinu organizacija obično to ograničenje nema veliku važnost. No, evo u čemu je stvar. Pretpostavlja se da je jedna od prednosti bezservernih modela u tome što se mali korišteni programi mogu koristiti jeftinije, budući da plaćate samo za vrijeme njihova izvođenja. A mali korišteni programi često su napisani na... malo poznatim, rijetko korištenim programskim jezicima.
To podriva jednu od ključnih prednosti bezservernog modela.
Odgovornost prema dobavljaču
Druga problema s bezservernim platformama, ili barem s načinom na koji se trenutno implementiraju, je da obično nisu slične jedna drugoj na operativnoj razini. Gotovo da nema standardizacije u području pisanja funkcija, implementacije i upravljanja. To znači da migracija funkcija s jedne platforme na drugu može trajati izuzetno dugo.
Najteži dio prelaska na bezserverni model nisu računske funkcije, koje su obično samo fragmenti koda, već način na koji su aplikacije povezane s povezanim sustavima poput objektnog spremišta, upravljanja identitetom i redovima. Funkcije se mogu premjestiti, ali ostatak aplikacije ne može. To je potpuna suprotnost obećanim jeftinim i fleksibilnim platformama.
Neki tvrde da su bezserverni modeli nedavno nastali i da nije bilo vremena za standardizaciju njihovog rada. No, oni nisu tako novi, kao što sam već napomenuo, a mnoge druge cloud tehnologije, poput kontejnera, već su postale mnogo korisnije zahvaljujući razvoju i širokoj primjeni dobrih standarda.
Performanse
Računsku učinkovitost bezservernih platformi teško je izmjeriti, dijelom zato što dobavljači nastoje zadržati informacije u tajnosti. Većina tvrdi da funkcije na udaljenim, bezservernim platformama rade jednako brzo kao na lokalnim serverima, osim nekoliko neizbježnih problema s latencijom.
Međutim, pojedinačni podaci ukazuju na suprotno. Funkcije koje ranije nisu pokretane na određenoj platformi ili nisu pokretane neko vrijeme zahtijevaju neko vrijeme za inicijalizaciju. Vjerojatno je to zbog toga što je njihov kod premješten na neki manje dostupni medij za pohranu, iako - kao i u slučaju s benchmarkovima - većina dobavljača neće vam reći o premještanju podataka.
Naravno, postoji nekoliko načina da se to zaobiđe. Jedan od njih uključuje optimizaciju funkcija za bilo koji cloud jezik na kojem radi vaša bezserverna platforma, ali to donekle potkopava tvrdnju da su te platforme "fleksibilne".
Drugi pristup je osigurati redovno izvođenje kritično važnih programa za performanse kako bi ostali "svježi". Ovaj drugi pristup, naravno, pomalo je u suprotnosti s tvrdnjom da su bezserverne platforme ekonomičnije, jer plaćate samo za vrijeme rada vaših programa. Oblak provajderi su uveli nove načine smanjenja hladnih pokretanja, ali mnogi od njih zahtijevaju "skaliranje na jedan" (scale to one), što potkopava prvotnu vrijednost FaaS-a.
Problem "hladnog pokretanja" može se djelomično riješiti pokretanjem bezservernih sustava vlastitim snagama, ali to dolazi s vlastitim troškovima i ostaje nišna opcija za timove dobro opskrbljene resursima.
Ne možete pokretati cijele aplikacije
Na kraju, možda najvažniji razlog zašto bezserverne arhitekture neće zamijeniti tradicionalne modele u bliskoj budućnosti: na njima (obično) nije moguće pokretati cijele aplikacije.
Točnije, to nije isplativo s obzirom na troškove. Vaš uspješni monolit vjerojatno ne vrijedi pretvarati u skup od četrdeset funkcija povezanih s osam prolaza, četrdeset redova i desetak instanci DB-a. Iz tog razloga, bezserverno je bolje za nove projekte. Gotovo nijednu postojeću aplikaciju (arhitekturu) nije moguće preseliti. Možete migrirati, ali morat ćete početi ispočetka.
To znači da se u pretežnom broju slučajeva bezserverne platforme koriste kao dodatak unutarnjim poslužiteljima za izvršavanje zadataka koji zahtijevaju velike proračune. To ih vrlo snažno razlikuje od dva druga oblika cloud tehnologije - kontejnera i virtualnih strojeva, koji nude cjelovit način za izvođenje udaljenih proračuna. To oslikava jednu od poteškoća prijelaza s mikroservisa na bezserverne sustave.
Naravno, to ne predstavlja uvijek problem. Mogućnost povremenog korištenja ogromnih računalnih resursa, bez kupnje vlastitog hardvera, može donijeti stvarne i dugoročne koristi za mnoge organizacije. No, ako su neka aplikacija na internim serverima, a druge na bezservernim cloud arhitekturama, upravljanje postaje na novoj razini složenosti.
Živjela revolucija?
Unatoč svim tim pritužbama, nemam ništa protiv bezservernih rješenja sama po sebi. Čista riječ. Samo što programeri moraju razumjeti - osobito ako prvi put istražuju bezserverne modele - da ova tehnologija nije izravna zamjena za servere. Umjesto toga, pogledajte naše savjete i resurse o i odlučite kako najbolje primijeniti ovaj model.
Izvor: habr.com
