Kas tie serverless sprendimai ir kodėl apie juos visi kalba
Prisimenu, kai prieš kelerius metus pirmą kartą išgirdau terminą „serverless”. Mano pirmoji reakcija buvo – kaip tai be serverių? Kur tada veikia kodas, debesyje? Na, techniškai taip, bet ne visai taip, kaip įsivaizdavau. Serverless architektūra nereiškia, kad serverių nėra – jie egzistuoja, tik jūs jų nematote ir jais nerūpinatės. Tai tarsi nuomojatės butą su visomis komunalinėmis paslaugomis įskaičiuotomis į kainą – elektra, vanduo, šildymas veikia, bet jūs nežinote, kur stovi katilinė ir kaip visa tai organizuota.
Google Cloud Functions yra vienas iš populiariausių serverless sprendimų rinkoje, konkuruojantis su AWS Lambda ir Azure Functions. Esmė paprasta – rašote funkcijas, kurios paleidžiamos tik tada, kai jų reikia, ir mokate tik už faktinį naudojimą. Nereikia konfigūruoti serverių, rūpintis skalabilumu ar atnaujinimais. Skamba kaip svajonė, tiesa? Bet kaip visada, yra niuansų.
Kaip veikia Cloud Functions praktikoje
Įsivaizduokite, kad kuriate nuotraukų dalijimosi aplikaciją. Kai vartotojas įkelia nuotrauką, jums reikia sukurti kelių skirtingų dydžių miniatiūras, pridėti vandens ženklą ir galbūt paleisti kokį nors AI modelį, kuris atpažintų, kas nuotraukoje. Tradiciškai turėtumėte palaikyti serverį, kuris nuolat veiktų ir lauktų užklausų, net jei per dieną gaunate tik 10 nuotraukų.
Su Cloud Functions viskas kitaip. Parašote funkciją, kuri reaguoja į įvykį – šiuo atveju nuotraukos įkėlimą į Cloud Storage. Funkcija „pabunda” tik tada, kai atsiranda nauja nuotrauka, atlieka savo darbą ir vėl „užmiega”. Jei vienu metu įkeliama 100 nuotraukų, Google automatiškai sukuria 100 funkcijos instancijų, kad viską apdorotų lygiagrečiai.
Paleidžiant Cloud Functions, galite rinktis iš dviejų kartų – 1-os ir 2-os. Antroji karta (Gen 2) yra naujesnis variantas, pastatytas ant Cloud Run infrastruktūros, ir siūlo daugiau galimybių: ilgesnį vykdymo laiką (iki 60 minučių vietoj 9), daugiau atminties, geresnį tinklo valdymą. Jei tik pradedate naują projektą, rekomenduočiau naudoti būtent Gen 2 – tai ateities kryptis.
Kada Cloud Functions yra idealus pasirinkimas
Per savo karjerą mačiau projektų, kur serverless buvo puikus sprendimas, ir projektų, kur tai buvo tikra katastrofa. Pirmiausia apie tai, kada Cloud Functions tikrai praverčia.
Įvykiais grįsti procesai – tai klasikinis naudojimo atvejis. Failų apdorojimas, duomenų transformacijos, webhooks, automatiniai backup’ai. Pavyzdžiui, dirbau projekte, kur kas vakarą reikėjo sugeneruoti ataskaitas iš kelių duomenų šaltinių. Vietoj to, kad palaikytume serverį, kuris 23 valandas per parą nieko nedaro, sukūrėme Cloud Function su Cloud Scheduler triggeriu. Funkcija paleidžiama 6 valandą ryto, atlieka savo darbą per 5 minutes ir tiek. Mėnesio sąskaita? Centai.
API endpoint’ai su žemu ar nepastoviu srautu – jei kuriate aplikaciją, kuri dar neturi daug vartotojų, arba turite API, kuris naudojamas tik periodiškai, Cloud Functions leidžia išvengti fiksuotų serverio išlaidų. Tačiau čia svarbu suprasti „cold start” problemą, apie kurią kalbėsiu vėliau.
Mikroservisų architektūra – kai kiekvienas servisas atlieka vieną konkrečią užduotį. Vietoj monolitinės aplikacijos, turite dešimtis mažų funkcijų, kurios bendrauja tarpusavyje. Tai leidžia skirtingas komandas dirbti nepriklausomai ir diegti pakeitimus nesustabdant visos sistemos.
Kas gali sugadinti jūsų serverless patirtį
Dabar apie tai, ko dokumentacijoje nepabrėžiama. Cold start problema – tai realus skausmas. Kai funkcija kurį laiką nebuvo naudojama, Google „išjungia” jos instanciją. Kai ateina nauja užklausa, reikia laiko paleisti naują instanciją – kartais tai trunka kelis šimtus milisekundžių, kartais kelias sekundes. Jei kuriate real-time aplikaciją, kur kiekviena milisekundė svarbi, tai gali būti problema.
Yra būdų, kaip su tuo kovoti. Galite nustatyti minimalų instancijų skaičių (minimum instances), kad bent viena funkcijos instancija visada būtų „šilta”. Bet tada prarandate vieną iš pagrindinių serverless privalumų – mokėjimą tik už faktinį naudojimą. Tai kompromisas, kurį reikia apgalvoti.
Debugging ir testavimas – tai kita skausminga tema. Kai funkcija veikia jūsų kompiuteryje, bet nepavyksta produkcijoje, pradeda galvos skausmas. Google siūlo Functions Framework, kuris leidžia testuoti funkcijas lokaliai, bet tai ne visada idealiai atitinka produkcinę aplinką. Mano patarimas – investuokite laiko į gerą logging’ą nuo pat pradžių. Cloud Logging yra jūsų geriausias draugas.
Išlaidų spąstai, apie kuriuos niekas nekalba
Serverless yra pigus, kol nėra. Matėte tuos Reddit įrašus, kur žmonės gauna tūkstančių dolerių sąskaitas už AWS Lambda? Tas pats gali nutikti ir su Cloud Functions. Problema paprastai ne pačiose funkcijose, o duomenų perdavime ir išoriniuose servisų iškvietimuose.
Pavyzdžiui, jei jūsų funkcija kaskart jungiasi prie duomenų bazės, užklausa gali atrodyti greita ir pigi. Bet jei per dieną gaunate milijoną užklausų, staiga pastebite, kad duomenų bazės jungtys ir network egress mokesčiai sudaro didžiąją sąskaitos dalį. Sprendimas? Naudokite connection pooling, cache’inkite duomenis kur įmanoma, optimizuokite funkcijų dažnumą.
Praktiniai patarimai pradedantiesiems
Jei dar niekada nenaudojote Cloud Functions, štai keletas patarimų, kurie sutaupys jūsų laiko ir nervų.
Pradėkite nuo HTTP trigger’io – tai paprasčiausias būdas išbandyti platformą. Sukuriate funkciją, kuri reaguoja į HTTP užklausą, ir galite ją iškart testuoti naršyklėje. Vėliau galite pereiti prie sudėtingesnių trigger’ių – Pub/Sub, Cloud Storage, Firestore.
Naudokite environment variables – niekada nekodinkite API raktų ar slaptažodžių tiesiogiai į kodą. Cloud Functions leidžia nustatyti aplinkos kintamuosius deployment metu. Dar geriau – naudokite Secret Manager jautriems duomenims.
Štai paprastas Python funkcijos pavyzdys, kuris parodo pagrindinę struktūrą:
„`python
import functions_framework
import os
@functions_framework.http
def hello_world(request):
name = request.args.get(‘name’, ‘World’)
api_key = os.environ.get(‘API_KEY’)
# Jūsų logika čia
return f’Hello, {name}!’
„`
Stebėkite funkcijų vykdymo laiką – Cloud Functions turi timeout limitą. Gen 1 funkcijoms tai 9 minutės, Gen 2 – 60 minučių. Jei jūsų funkcija kartais viršija šį limitą, ji bus nutraukta be įspėjimo. Geriau suskaidyti ilgas operacijas į mažesnes dalis arba naudoti Cloud Run, jei reikia ilgesnio vykdymo laiko.
Integracijos su kitais Google Cloud servisais
Viena iš stipriausių Cloud Functions pusių – tai, kaip sklandžiai jie integruojasi su visa Google Cloud ekosistema. Tai ne tik patogu, bet ir atrakina galimybes, kurių neturėtumėte su standalone sprendimu.
Cloud Storage – klasikinis derinys. Funkcija automatiškai paleidžiama, kai failas įkeliamas, ištrinamas ar pakeičiamas. Nereikia jokių webhook’ų ar polling mechanizmų. Dirbau projekte, kur klientai įkeldavo CSV failus, ir funkcija automatiškai juos apdorodavo, validuodavo ir įkeldavo į BigQuery. Viskas veikė kaip laikrodis.
Pub/Sub – tai Google’o message queue sistema, ir ji puikiai dera su Cloud Functions. Galite kurti event-driven architektūras, kur viena funkcija publikuoja žinutę, o kita ją apdoroja. Tai leidžia decoupling – jei viena funkcija nepavyksta, kitos gali toliau veikti.
Firestore – jei naudojate Firestore kaip duomenų bazę, galite sukurti funkcijas, kurios reaguoja į dokumentų pakeitimus. Pavyzdžiui, kai vartotojas sukuria naują užsakymą, funkcija gali automatiškai išsiųsti patvirtinimo el. laišką ir atnaujinti inventory. Tai kaip database triggers, tik serverless būdu.
Saugumo aspektai, kuriuos reikia žinoti
Serverless nereiškia „security-less”. Iš tiesų, kadangi funkcijos dažnai turi prieigą prie jautrių duomenų ir kitų servisų, saugumas yra kritiškai svarbus.
Pirmiausia – IAM (Identity and Access Management). Kiekviena Cloud Function veikia su tam tikra service account, kuri turi konkrečias teises. Pagal nutylėjimą, funkcija gauna gana plačias teises, bet tai yra saugumo rizika. Mano rekomendacija – visada sukurkite dedicated service account kiekvienai funkcijai ar funkcijų grupei ir suteikite tik tas teises, kurių tikrai reikia. Tai vadinamas „least privilege” principas.
Antra – autentifikacija ir autorizacija. Jei jūsų funkcija turi HTTP trigger’į, pagal nutylėjimą ji yra vieša – bet kas, žinantis URL, gali ją iškviesti. Tai gali būti gerai testavimui, bet produkcijoje tikrai nenorite, kad kas nors galėtų paleisti jūsų funkcijas. Galite reikalauti autentifikacijos per IAM arba naudoti API Gateway su API key’ais.
Trečia – rate limiting. Net jei funkcija yra saugi, DDoS ataka gali sugeneruoti milžiniškas sąskaitas. Cloud Functions neturi built-in rate limiting, todėl reikia naudoti papildomus įrankius – Cloud Armor, API Gateway arba bent jau stebėti invocation metrics ir nustatyti alertus.
Ką daryti, kai jūsų projektas išauga iš serverless
Štai tiesa, kurios niekas nenori girdėti – ne visi projektai gali amžinai likti serverless. Kai jūsų aplikacija auga, kartais tradicinės architektūros tampa efektyvesnės ir pigesnės.
Jei pastebite, kad jūsų funkcijos veikia beveik nuolat, mokate už milijonus invocation’ų per mėnesį, ir cold start tampa realia problema – galbūt laikas pagalvoti apie migraciją į Cloud Run arba net GKE (Google Kubernetes Engine). Cloud Run yra tarsi tarpinis variantas – jūs vis dar negaunate serverių, bet turite daugiau kontrolės ir galite palaikyti long-running procesus.
Viename projekte pradėjome su Cloud Functions, bet po metų, kai srautas išaugo 10 kartų, migracija į Cloud Run sumažino mūsų sąskaitas 40%. Kodėl? Nes galėjome efektyviau naudoti resursus, palaikyti persistent connections į duomenų bazę ir išvengti cold start problemų.
Bet tai nereiškia, kad serverless yra blogas. Daugelis sėkmingų kompanijų naudoja hibridinę architektūrą – kritiniai, high-traffic endpoint’ai veikia ant Cloud Run ar GKE, o background jobs, webhooks ir periodic tasks lieka Cloud Functions. Tai geriausias iš abiejų pasaulių.
Kaip pradėti ir neklysti pirmais žingsniais
Jei perskaičius visa tai vis dar norite išbandyti Cloud Functions (ir turėtumėte!), štai praktinis planas, kaip pradėti be streso.
Pirma, sukurkite Google Cloud projektą ir įjunkite Cloud Functions API. Jums reikės billing account, bet Google duoda $300 free credits naujiems vartotojams, ko tikrai pakaks eksperimentams. Antra, įsidiekite Google Cloud SDK (gcloud) į savo kompiuterį – tai leis deploy’inti funkcijas iš komandinės eilutės.
Pradėkite nuo labai paprasto projekto. Mano rekomendacija – sukurkite funkciją, kuri priima webhook’ą ir išsaugo duomenis į Firestore arba siunčia notifikaciją per Slack. Tai pakankamai paprasta, kad suprastumėte pagrindus, bet pakankamai praktišką, kad matytumėte realią vertę.
Kai jau turite veikiančią funkciją, eksperimentuokite su skirtingais trigger’iais. Įkelkite failą į Cloud Storage ir sukurkite funkciją, kuri jį apdoroja. Nustatykite Cloud Scheduler job’ą, kuris paleidžia funkciją kas valandą. Sukurkite Pub/Sub topic’ą ir funkcijas, kurios komunikuoja per jį.
Svarbu – naudokite version control nuo pat pradžių. Laikykite funkcijų kodą Git repository ir naudokite CI/CD pipeline’us deployment’ui. Google Cloud Build puikiai integruojasi su Cloud Functions ir leidžia automatizuoti visą procesą. Tai gali atrodyti per daug pradžiai, bet patikėkite – kai turėsite 10+ funkcijų, būsite dėkingi sau už šį sprendimą.
Realybė po hype: kas lieka, kai dulkės nusėda
Serverless technologijos jau nebe naujiena – jos egzistuoja pakankamai ilgai, kad matytume, kas veikia, o kas ne. Cloud Functions nėra sidabrinis kulka, kuri išspręs visas jūsų problemas, bet tai tikrai galingas įrankis tinkamose situacijose.
Didžiausia pamoka, kurią išmokau – pradėkite mažai. Neperkelkite visos aplikacijos į serverless iš karto. Pradėkite nuo vieno komponento – galbūt background job’o ar webhook’o. Pamatysite, kaip tai veikia jūsų kontekste, suprasite cost model’į, išmoksite debugging’o ir deployment’o procesų. Tada galite plėsti toliau.
Cloud Functions tikrai turi savo vietą modernių aplikacijų architektūroje. Jie leidžia greitai kurti ir deploy’inti funkcionalumą, sumažina operational overhead’ą ir gali būti labai cost-effective. Bet jie taip pat turi apribojimų ir kompromisų, kuriuos reikia suprasti ir priimti.
Jei kuriate naują projektą ir nenorite rūpintis serveriais, jei turite event-driven workloads, jei jums svarbus greitas time-to-market – Cloud Functions yra puikus pasirinkimas. Tik nepamirškite stebėti metrikų, optimizuoti išlaidas ir būti pasiruošę adaptuoti architektūrą, kai projektas auga. Technologijos keičiasi, jūsų poreikiai keičiasi, ir gera architektūra yra ta, kuri gali evoliucionuoti kartu su jumis.
