Kai serveriai tampa nematomi
Prisimenu, kaip prieš keletą metų kūrėme pirmąjį projektą su serverless architektūra. Komandoje kilo tikras chaosas – vieni entuziastingai šaukė, kad tai ateitis, kiti skeptiškai kratė galvas ir kalbėjo apie dar vieną technologijų madą. Dabar, po kelių metų praktinės patirties, galiu pasakyti, kad serverless tikrai nėra tik madinga frazė, bet fundamentalus pokytis, kaip kuriame ir valdome aplikacijas.
Serverless architektūra – tai būdas kurti ir paleisti aplikacijas negalvojant apie serverių valdymą. Skamba paradoksaliai, tiesa? Serveriai vis tiek egzistuoja, bet jūs jų nematote, nekonfigūruojate ir nesirūpinate jų priežiūra. Tai tarsi automobilio nuoma – jums reikia nuvažiuoti iš taško A į tašką B, bet jums nerūpi, kas keičia alyvą ar tikrina padangas.
Tradicinėje infrastruktūroje turite nuomotis ar pirkti serverius, įdiegti operacines sistemas, konfigūruoti tinklus, rūpintis saugumu, skaliavimu, atsarginėmis kopijomis. Su serverless visa tai tampa debesų tiekėjo problema. Jūs tiesiog įkeliate kodą ir jis veikia.
Kaip tai iš tikrųjų veikia praktikoje
Įsivaizduokite, kad kuriate internetinę parduotuvę. Tradiciniame scenarijuje turėtumėte serverį, kuris veikia 24/7, net jei jūsų svetainę lanko tik 100 žmonių per dieną ir dauguma jų – darbo valandomis. Jūs mokate už visą tą laiką, kai serveris tiesiog laukia užklausų.
Serverless veikia visiškai kitaip. Jūsų kodas suskaidomas į atskiras funkcijas – pavyzdžiui, viena funkcija tvarko vartotojo registraciją, kita – produktų paieškos logiką, trečia – mokėjimo apdorojimą. Kiekviena funkcija paleidžiama tik tada, kai jos reikia, ir veikia tik tiek laiko, kiek reikia užduočiai atlikti.
Štai konkretus pavyzdys: jūsų svetainėje vartotojas užsako produktą. Šis veiksmas aktyvuoja mokėjimo apdorojimo funkciją, kuri pabunda, atlieka savo darbą per 200 milisekundžių ir vėl „užmiega”. Jūs mokate tik už tas 200 milisekundžių. Jei kitą užsakymą gaunate po valandos, funkcija vėl pabunda, dirba ir vėl miega. Nėra jokių resursų švaistymo.
Kodėl visi šneka apie serverless dabar
Serverless populiarumas eksploziškai augo ne be priežasties. Pirma, tai ekonomika. Startuoliai ir mažos įmonės gali paleisti projektus su minimaliais pradiniais kaštais. Nereikia investuoti į infrastruktūrą, kuri galbūt net nebus pilnai panaudota. Mokate tik už tai, ką realiai naudojate.
Antra – greitis. Kūrėjai gali sutelkti dėmesį į verslo logiką, o ne į serverių konfigūravimą. Vienas mano pažįstamas startuolis paleido MVP (Minimum Viable Product) per dvi savaites naudodamas AWS Lambda ir API Gateway. Su tradicine infrastruktūra tai būtų užtrukę mėnesį ar ilgiau, nes reikėtų sukurti visą infrastruktūrą nuo nulio.
Trečia – automatinis skaliavimas. Jei jūsų aplikacija staiga tampa populiari (sakykime, patekote į Hacker News pirmą puslapį), serverless automatiškai prisitaiko prie apkrovos. Nereikia budėti naktimis ir rankiniu būdu pridėti serverių pajėgumų. Sistema pati sukuria tiek funkcijų instancų, kiek reikia užklausoms apdoroti.
Pagrindiniai serverless komponentai
Serverless ekosistema susideda iš kelių pagrindinių dalių. Pirmiausia – funkcijos kaip paslauga (FaaS – Functions as a Service). Tai AWS Lambda, Azure Functions, Google Cloud Functions. Čia gyvena jūsų verslo logika – maži, savarankiški kodo gabalai, kurie atlieka konkrečias užduotis.
Toliau – API valdymas. Jums reikia būdo, kaip išorinis pasaulis gali pasiekti jūsų funkcijas. Tam naudojami įrankiai kaip AWS API Gateway ar Azure API Management. Jie veikia kaip durininkai, kurie priima užklausas, patikrina autentifikaciją ir nukreipia jas į tinkamas funkcijas.
Duomenų bazės serverless pasaulyje taip pat evoliucionavo. DynamoDB, Aurora Serverless, Cosmos DB – šios duomenų bazės automatiškai skaliaviasi ir jūs mokate už naudojimą, o ne už rezervuotą pajėgumą. Nebereikia planuoti, kiek IOPS (Input/Output Operations Per Second) jums reikės – sistema pati prisitaiko.
Įvykių valdymas – dar viena svarbi dalis. Serverless aplikacijos dažnai veikia reaguodama į įvykius: naujas failas įkeltas į saugyklą, nauja žinutė atėjo į eilę, pasikeitė duomenys duomenų bazėje. Įrankiai kaip AWS EventBridge ar Azure Event Grid padeda orkestravoti šiuos įvykius.
Realūs panaudojimo atvejai
Vaizdų apdorojimas – klasikinis serverless pavyzdys. Vartotojas įkelia nuotrauką į jūsų aplikaciją. Tai aktyvuoja funkciją, kuri sukuria skirtingų dydžių miniatiūras, optimizuoja failą, galbūt atpažįsta veidus ar objektus. Visa tai vyksta automatiškai, be jūsų įsikišimo, ir jūs mokate tik už tą apdorojimo laiką.
API backend’ai – daugelis modernių aplikacijų naudoja serverless API. Mobili aplikacija siunčia užklausas, kurios aktyvuoja atitinkamas funkcijas. Tai puikiai veikia aplikacijoms su nepastovia apkrova. Pavyzdžiui, maisto pristatymo aplikacija gali turėti piką pietų metu, bet būti rami naktį.
Duomenų transformacija ir ETL (Extract, Transform, Load) procesai taip pat puikiai tinka serverless. Kas valandą reikia parsisiųsti duomenis iš išorinio API, juos apdoroti ir įrašyti į duomenų bazę? Sukuriate funkciją, nustatote laikmatį, ir viskas veikia automatiškai.
Chatbotai ir AI integracija – serverless puikiai dera su dirbtinio intelekto paslaugomis. Funkcija gauna vartotojo žinutę, siunčia ją į GPT API, gauna atsakymą ir grąžina vartotojui. Viskas vyksta per sekundes, o kaštai minimalūs, nes mokate tik už aktyvų naudojimą.
Kas ne taip idealu, kaip atrodo
Būkime sąžiningi – serverless nėra sidabrinė kulka. Yra realių iššūkių, apie kuriuos reikia žinoti prieš šokant į šią technologiją.
Šaltasis startas (cold start) – tai problema, kuri kankina daugelį kūrėjų. Kai funkcija ilgą laiką nebuvo naudojama, ji „užmiega”. Pirmoji užklausa turi ją „pažadinti”, o tai gali užtrukti nuo kelių šimtų milisekundžių iki kelių sekundžių. Vartotojui laukiančiam atsakymo tai gali būti jaučiama. Yra būdų tai spręsti – pavyzdžiui, „warming” strategijos, kai periodiškai siunčiate dirbtines užklausas, kad funkcija išliktų aktyvi, bet tai prideda papildomų kaštų ir sudėtingumo.
Debugging ir testavimas tampa sudėtingesni. Kai viskas vyksta lokalioje mašinoje, galite naudoti debugger’į, žingsnis po žingsnio sekti kodą. Su serverless tai sudėtingiau. Nors yra įrankių kaip AWS SAM ar Serverless Framework, kurie leidžia emuliuoti serverless aplinką lokaliai, tai niekada nėra 100% tas pats kaip produkcijoje.
Vendor lock-in – prisirišimas prie konkretaus tiekėjo. AWS Lambda funkcijos nėra tiesiogiai perkeliamos į Azure Functions. Nors kodas gali būti panašus, infrastruktūros konfigūracija, įvykių šaltiniai, integracija su kitomis paslaugomis – viskas skiriasi. Migruoti iš vieno debesų tiekėjo į kitą gali būti sudėtinga ir brangu.
Monitoringas ir observability reikalauja naujo požiūrio. Kai turite 50 skirtingų funkcijų, kurios bendrauja tarpusavyje, sekti užklausų kelią tampa iššūkiu. Reikia investuoti į tinkamus įrankius – AWS X-Ray, Datadog, New Relic ar panašius – kad suprastumėte, kas vyksta jūsų sistemoje.
Kaip pradėti be skausmo
Jei nusprendėte išbandyti serverless, nedarykite klasikinės klaidos – nebandykite iš karto perkelti visos savo infrastruktūros. Pradėkite mažai.
Pasirinkite vieną nedidelę funkcionalumo dalį – galbūt vaizdų apdorojimą, el. laiškų siuntimą ar paprastą API endpoint’ą. Sukurkite ją kaip serverless funkciją ir pamatysite, kaip tai veikia praktikoje. Išmoksite įrankius, suprasite apribojimus, pamatysite kaštus.
Infrastruktūra kaip kodas (Infrastructure as Code) yra būtina serverless pasaulyje. Naudokite Terraform, AWS CloudFormation ar Serverless Framework. Rankiniu būdu konfigūruoti funkcijas per web konsolę yra galima, bet greitai taps košmaru. Su IaC jūsų visa infrastruktūra aprašyta kode, versionuojama Git’e, ir galite ją atkurti bet kada.
Investuokite į automatizuotą testavimą nuo pat pradžių. Unit testai jūsų funkcijų logikai, integraciniai testai API endpoint’ams. Serverless aplikacijos dažnai susideda iš daugelio mažų dalių, ir be gerų testų greitai prarasite kontrolę.
Nustatykite biudžeto įspėjimus. Viena iš serverless grožybių – mokate už naudojimą. Bet tai taip pat reiškia, kad klaida kode (pavyzdžiui, begalinė ciklo funkcija) gali brangiai kainuoti. AWS, Azure ir Google Cloud leidžia nustatyti biudžeto limitus ir gauti įspėjimus, kai artėjate prie jų.
Serverless ekonomika ir optimizavimas
Kalbant apie pinigus, serverless kainodara gali būti ir palaiminimas, ir prakeikimas. Viskas priklauso nuo to, kaip jūsų aplikacija naudojama.
Jei turite aplikaciją su nepastovia apkrova – pavyzdžiui, B2B SaaS produktą, kuris naudojamas tik darbo valandomis – serverless gali sutaupyti daugybę pinigų. Tradicinis serveris veiktų 24/7, bet jūs mokėtumėte tik už ~40 valandų per savaitę, kai sistema tikrai naudojama.
Tačiau jei turite aukštą ir pastovią apkrovą, tradiciniai serveriai gali būti pigiau. Yra taškas, kai nuolatinis serverio mokestis tampa pigesnis už milijonus funkcijų iškvietimų. Dažnai šis taškas yra kažkur apie 70-80% serverio pajėgumų panaudojimą.
Optimizavimo patarimai: mažinkite funkcijų dydį. Kuo mažiau kodo, tuo greičiau funkcija startuoja ir tuo pigiau kainuoja. Jei naudojate Node.js, neįtraukite visos bibliotekos, jei jums reikia tik vienos funkcijos. Naudokite tree-shaking ir kitus optimizavimo būdus.
Atminties kiekis tiesiogiai veikia kainą ir našumą. Daugiau atminties = daugiau CPU galios = greičiau veikia = trumpesnis vykdymo laikas. Kartais verta mokėti už daugiau atminties, nes funkcija baigia darbą dvigubai greičiau ir bendri kaštai sumažėja.
Ateitis jau čia, bet ne visur vienodai
Serverless architektūra tikrai nėra tik trumpalaikė mada. Didžiosios technologijų kompanijos – Netflix, Coca-Cola, iRobot – naudoja serverless produkcijoje. Bet tai nereiškia, kad serverless tinka visiems ir visada.
Jei kuriate naują projektą su neaiškia apkrova, jei norite greitai paleisti MVP, jei jūsų komanda nedidelė ir nenorite leisti laiko infrastruktūros valdymui – serverless yra puikus pasirinkimas. Tai leidžia sutelkti dėmesį į tai, kas tikrai svarbu – kurti vertę vartotojams.
Tačiau jei turite legacy sistemą su stabiliai aukšta apkrova, jei jums reikia labai žemos latencijos (kelių milisekundžių), jei jūsų aplikacija reikalauja ilgai veikiančių procesų – tradicinė infrastruktūra vis dar gali būti geresnis pasirinkimas.
Svarbu suprasti, kad serverless nėra „viskas arba nieko” sprendimas. Daugelis įmonių naudoja hibridinį modelį – kritinės dalys veikia tradiciniuose serveriuose, o papildomos funkcijos, foniniai procesai, API endpoint’ai – serverless. Tai pragmatiškas požiūris, kuris leidžia pasinaudoti abiejų pasaulių privalumais.
Technologijos toliau evoliucionuoja. Šaltojo starto problemos mažėja, įrankiai tampa geresni, bendruomenė auga. Serverless konteineriai (AWS Fargate, Azure Container Instances) siūlo kompromisą tarp tradicinių konteinerių ir grynojo serverless. Edge computing ir serverless funkcijos, veikiančios arčiau vartotojų, mažina latenciją.
Galiausiai, serverless – tai ne tik technologija, bet ir mąstymo būdas. Tai skatina kurti mažesnes, labiau izoliuotas, lengviau testuojamas sistemas. Tai verčia galvoti apie kaštus ir efektyvumą. Ir tai leidžia mažesnėms komandoms pasiekti tai, kas anksčiau buvo įmanoma tik didelėms organizacijoms su dedikuotomis DevOps komandomis.
