Dar prieš kokius dešimt metų, jei norėjai paleisti savo aplikaciją internete, teko galvoti apie serverius – ar pirkti fizinę mašiną, ar nuomotis VPS, ar bent jau konfigūruoti Nginx ir rūpintis, kad viskas neužstrigtų sekmadienio vakarą, kai eismas staiga išauga. Serverless architektūra šitą skausmą iš esmės pakeitė. Ne, serveriai niekur nedingo – jie tiesiog paslėpti nuo tavęs, ir tu galiausiai gali susikoncentruoti ties kodu, o ne infrastruktūra.
Šiame straipsnyje pažiūrėsim, kas ta serverless architektūra iš tikrųjų yra, kaip ji veikia po gaubtu, kokie yra realūs privalumai ir minusai, ir kada verta ją naudoti, o kada – ne.
Kas iš tikrųjų slypi po žodžiu „serverless“
Pavadinimas šiek tiek klaidina – serveriai, žinoma, egzistuoja, tik jais rūpinasi debesijos paslaugų teikėjas (AWS, Google Cloud, Azure ar kitas). Tavo užduotis – parašyti funkciją arba servisą, o platforma pati pasirūpina, kur ją paleisti, kiek resursų skirti, kaip ją mastelinti, kai srautas padidėja, ir kaip ją „užgesinti“, kai niekas jos nenaudoja.
Praktiškai tai dažniausiai reiškia darbą su FaaS (Function as a Service) modeliu – AWS Lambda, Google Cloud Functions, Azure Functions. Rašai atskirą funkciją, kuri reaguoja į įvykį: HTTP užklausą, failo įkėlimą į saugyklą, žinutę eilėje ar suplanuotą laiką. Ta funkcija pasileidžia, atlieka savo darbą ir išnyksta. Nemokant už tai, kad serveris tiesiog stovi ir laukia.
Be FaaS, į serverless kategoriją dažnai įtraukiamos ir kitos valdomos paslaugos – duomenų bazės be serverio valdymo (pvz., DynamoDB, Aurora Serverless), objektų saugyklos, autentifikacijos paslaugos. Idėja ta pati: tu naudoji funkcionalumą, o ne administruoji infrastruktūrą.
Kaip tai veikia praktiškai
Įsivaizduok paprastą pavyzdį – vartotojas įkelia nuotrauką į tavo aplikaciją. Tradiciniame modelyje turėtum turėti veikiantį serverį, kuris klausosi užklausų 24 valandas per parą, net jei per naktį niekas nieko neįkelia. Serverless atveju viskas kitaip: nuotraukos įkėlimas į S3 saugyklą (ar analogą) sugeneruoja įvykį, tas įvykis paleidžia Lambda funkciją, kuri, tarkim, sumažina nuotraukos dydį ir sugeneruoja miniatiūrą. Funkcija atlieka darbą per kelias sekundes ir užsidaro.
Svarbu suprasti „cold start“ sąvoką – kai funkcija nebuvo naudota kurį laiką, platformai reikia laiko ją inicijuoti iš naujo (paleisti konteinerį, užkrauti aplinką). Tai gali sukurti keliasdešimt milisekundžių, o kartais net kelių sekundžių delsą pirmajai užklausai. Jei tavo aplikacija reikalauja itin greito atsako kiekvienu momentu, tai reikia turėti omenyje ir galbūt naudoti „provisioned concurrency“ funkcijas, kurios palaiko dalį instancijų šiltas.
Kitas svarbus dalykas – statelessness. Kiekvienas funkcijos iškvietimas turi būti nepriklausomas nuo ankstesnio. Negali pasikliauti tuo, kad kintamasis atmintyje išliks tarp iškvietimų – kitą kartą funkcija gali pasileisti visai kitoje mašinoje. Bet kokia būsena turi būti saugoma išorėje – duomenų bazėje, cache sistemoje ar saugykloje.
Kur serverless tikrai veikia gerai
Yra situacijų, kur serverless architektūra tiesiog puikiai tinka. Pirma – nereguliarūs, „spike“ tipo krūviai. Jei tavo API kartais gauna 5 užklausas per minutę, o kartais staiga 5000 per sekundę (pvz., dėl rinkodaros kampanijos ar virusinio įrašo), serverless automatiškai prisitaiko be jokio papildomo konfigūravimo iš tavo pusės.
Antra – event-driven užduotys. Failo apdorojimas, duomenų transformacija, pranešimų siuntimas, webhook’ų apdorojimas – visa tai natūraliai tinka funkcijoms, kurios suveikia į konkretų įvykį ir baigia darbą.
Trečia – MVP ir prototipavimas. Kai kuri startuolis nori greitai patikrinti idėją, serverless leidžia paleisti backend’ą per kelias valandas, nesukant galvos apie serverių administravimą. Jei idėja nepasiteisina, tiesiog nustoji mokėti – jokių ilgalaikių įsipareigojimų dėl infrastruktūros.
Ketvirta – planinės užduotys (cron jobs). Duomenų bazės valymas, ataskaitų generavimas, sinchronizacija su išoriniais API kas valandą ar kas naktį – tobula serverless funkcijų taikymo sritis.
Kai serverless nebėra geriausias pasirinkimas
Nepaisant visų privalumų, serverless nėra universalus sprendimas visoms situacijoms. Jei tavo aplikacija veikia nuolat aukštu, pastoviu krūviu – pavyzdžiui, populiarus API, kuris visada gauna panašų srautą – tradicinis konteineris ar VM gali būti pigesnis. Serverless mokestis skaičiuojamas už kiekvieną iškvietimą ir vykdymo laiką, ir esant pastoviai apkrovai, tai gali kainuoti brangiau nei fiksuotas serveris.
Ilgai vykdomos užduotys – dar viena problema. Dauguma FaaS platformų riboja vieno vykdymo trukmę (pvz., AWS Lambda – iki 15 minučių). Jei turi ilgai trunkantį duomenų apdorojimą, video konvertavimą ar mašininio mokymosi treniravimą, teks arba skaidyti procesą į mažesnes dalis, arba rinktis kitą architektūrą.
Taip pat verta paminėti vendor lock-in problemą. Kiekviena platforma turi savo API, savo įrankius, savo tvarką. Persikelti iš AWS Lambda į Google Cloud Functions – tai ne tik kodo perrašymas, bet ir viso deployment proceso, monitoringo, saugumo konfigūracijų perkūrimas. Jei šis rizika tau svarbi, verta iš anksto galvoti apie abstrakcijos sluoksnius (pvz., Serverless Framework ar SAM), kurie palengvina perkėlimą.
Kaip suprojektuoti serverless sistemą teisingai
Vienas didžiausių klaidų, kurias daro pradedantys su serverless dirbti komandos – jie bando perkelti monolitinę architektūrą tiesiog į funkcijas, nepakeisdami mąstymo būdo. Tai neveikia gerai. Serverless reikalauja kitokio architektūrinio požiūrio.
Pirma taisyklė – kiekviena funkcija turėtų daryti vieną dalyką ir daryti jį gerai. Jei funkcija apima autentifikaciją, duomenų validaciją, verslo logiką ir dar duomenų bazės operacijas – ji tampa sunkiai testuojama ir sunkiai palaikoma. Geriau skaidyti į mažesnius, aiškiai apibrėžtus vienetus.
Antra – naudok asinchronines komunikacijos priemones tarp funkcijų, kur tik įmanoma. Vietoj to, kad viena funkcija tiesiogiai kviestų kitą ir laukti atsakymo, geriau naudoti pranešimų eiles (SQS, Pub/Sub) ar įvykių magistrales (EventBridge). Tai sumažina susietumą ir padidina sistemos atsparumą.
Trečia – nepamiršk apie monitoringą ir stebėjimą iš pat pradžių. Kadangi serverless sistemos yra paskirstytos ir dažnai susideda iš dešimčių ar šimtų atskirų funkcijų, klaidos gali būti sunkiai atsekamos be tinkamo distributed tracing. Įrankiai kaip AWS X-Ray, Datadog ar Sentry čia tampa būtinybe, o ne prabanga.
Ketvirta – galvok apie saugumą kiekvienai funkcijai atskirai. Kiekviena funkcija turėtų turėti minimalius reikalingus leidimus (principle of least privilege). Jei funkcija skirta tik nuotraukoms apdoroti, jai nereikia prieigos prie visos duomenų bazės – tik prie konkrečios lentelės ar saugyklos dalies.
Kaina – ne visada taip paprasta, kaip atrodo
Vienas iš pagrindinių serverless pardavimo argumentų – „mokėk tik už tai, ką naudoji“. Tai iš dalies tiesa, bet kaina gali greitai išaugti, jei nesi atidus. Pavyzdžiui, jei funkcija naudoja daug atminties arba vykdosi ilgai, kiekvienas iškvietimas kainuos daugiau. Jei turi milijonus iškvietimų per mėnesį, net ir mažos sumos susisumuoja į nemažą sąskaitą.
Praktinis patarimas – visada stebėk ne tik iškvietimų skaičių, bet ir vidutinę vykdymo trukmę bei atminties naudojimą. Kartais nedidelis kodo optimizavimas (pvz., dependency importavimo sumažinimas, connection pooling duomenų bazei) gali sumažinti sąskaitą kelis kartus. Taip pat verta nustatyti biudžeto perspėjimus (billing alerts), kad netikėtas srauto padidėjimas neišgąsdintų mėnesio pabaigoje.
Vietoj apibendrinimo: ką verta įsidėmėti prieš pradedant
Serverless architektūra nėra magija, kuri išsprendžia visas infrastruktūros problemas – tai tiesiog kitas įrankis įrankių dėžėje, ir kaip su bet kuriuo įrankiu, svarbu žinoti, kada jį naudoti. Jei kuriate API su nereguliariu srautu, event-driven sistemą ar norite greitai patikrinti idėją nesukant galvos apie DevOps, serverless suteiks realų pranašumą – greitesnį paleidimą, mažesnes pradines išlaidas ir automatinį mastelio keitimą.
Prieš šokant į serverless projektą, verta atsakyti sau į kelis klausimus. Ar mano darbo krūvis nereguliarus, ar pastovus? Ar galiu susitaikyti su cold start delsomis, ar man reikia garantuotai greito atsako kiekvieną kartą? Ar mano komanda jau turi patirties su paskirstytomis sistemomis, ar tai bus pirmasis toks projektas?
Praktiškai rekomenduočiau pradėti nuo mažo, izoliuoto komponento – pavyzdžiui, vieno webhook’o apdorojimo ar vieno fono darbo (background job), o ne bandyti iškart perkelti visą sistemą. Taip pamatysi realius kaštus, realų delsimo laiką ir realų monitoringo poreikį, prieš darant didesnius sprendimus.
Ir dar vienas dalykas, kurį verta prisiminti – serverless nereiškia „be architektūros“. Priešingai, gera serverless sistema reikalauja net didesnio dėmesio projektavimui, nes klaidos paskirstytoje sistemoje būna sunkiau pastebimos ir brangiau taisomos nei monolite. Investuok laiką į event schemas, klaidų apdorojimo strategijas ir testavimą – tai atsipirks jau po kelių mėnesių eksploatacijos.
