Nors pastaraisiais metais technologijos be serverių sparčiai populiarėjo, su jomis vis dar kyla daug klaidingų nuomonių ir baimių. Priklausomybė nuo pardavėjo, įrankiai, išlaidų valdymas, šaltasis paleidimas, stebėjimas ir kūrimo gyvavimo ciklas yra karštos temos, kai kalbama apie technologijas be serverių. Šiame straipsnyje išnagrinėsime kai kurias minėtas temas, taip pat pasidalinsime patarimais ir nuorodomis į naudingus informacijos šaltinius, kurie padės pradedantiesiems kurti galingas, lanksčias ir ekonomiškas programas be serverio.
Klaidingos nuomonės apie technologijas be serverių
Daugelis žmonių mano, kad duomenų apdorojimas be serverio ir be serverio (, FaaS) yra beveik tas pats dalykas. Tai reiškia, kad skirtumas nėra per didelis ir verta pristatyti naujovę. Nors AWS Lambda buvo viena iš klestėjimo be serverių žvaigždžių ir vienas populiariausių be serverių architektūros elementų, tačiau ši architektūra yra daug daugiau nei FaaS.
Pagrindinis be serverio principas yra tai, kad jums nereikia jaudintis dėl infrastruktūros valdymo ar mastelio; mokate tik už tai, ką naudojate. Daugelis paslaugų atitinka šiuos kriterijus – AWS DynamoDB, S3, SNS arba SQS, Graphcool, Auth0, Now, Netlify, Firebase ir daugelis kitų. Apskritai be serverio reiškia naudoti visas debesų kompiuterijos galimybes, nereikia valdyti ir optimizuoti infrastruktūros mastelio keitimo sumetimais. Tai taip pat reiškia, kad saugumas infrastruktūros lygmeniu nebėra jūsų problema, o tai yra didžiulė nauda, atsižvelgiant į saugumo standartų laikymosi sunkumus ir sudėtingumą. Galiausiai, jums nereikia pirkti jums suteiktos infrastruktūros.
Be serverio galima laikyti „dvasios būseną“: tam tikrą mentalitetą kuriant sprendimus. Venkite požiūrių, kuriems reikia bet kokios infrastruktūros priežiūros. Taikydami be serverio metodą, leidžiame laiką spręsdami užduotis, kurios tiesiogiai veikia projektą ir atneša naudos mūsų vartotojams: kuriame tvarią verslo logiką, kuriame vartotojo sąsajas, kuriame prisitaikančias ir patikimas API.
Pavyzdžiui, jei įmanoma išvengti laisvo teksto paieškos platformos valdymo ir priežiūros, tai mes taip ir padarysime. Šis požiūris į programų kūrimą gali žymiai pagreitinti pateikimo į rinką laiką, nes jums nebereikia galvoti apie sudėtingos infrastruktūros valdymą. Pašalinkite infrastruktūros valdymo atsakomybę ir išlaidas ir sutelkite dėmesį į jūsų klientams reikalingų programų ir paslaugų kūrimą. Patrickas Deboisas pavadino šį požiūrį , šis terminas priimtas bendruomenėje be serverio. Funkcijos turėtų būti laikomos klijais, sujungiančiais paslaugas kaip įdiegtus modulius (o ne diegti visą biblioteką ar žiniatinklio programą). Tai suteikia neįtikėtiną detalumą valdant diegimus ir programos pakeitimus. Jei negalite įdiegti funkcijų tokiu būdu, tai gali reikšti, kad funkcijos atlieka per daug dalykų ir turi būti pertvarkytos.
Kai kuriuos glumina priklausomybė nuo pardavėjo kuriant debesų programas. Tas pats pasakytina ir apie technologijas be serverių, ir tai vargu ar klaidinga nuomonė. Mūsų patirtis rodo, kad programų be serverių kūrimas naudojant AWS, kartu su AWS Lambda galimybe sujungti kitas AWS paslaugas, yra be serverių architektūros stiprybės dalis. Tai geras sinergijos pavyzdys, kai derinio rezultatas yra daugiau nei tik terminų suma. Bandant išvengti priklausomybės nuo pardavėjo gali kilti dar daugiau problemų. Kai dirbate su konteineriais, lengviau valdyti savo abstrakcijos sluoksnį tarp debesies paslaugų teikėjų. Tačiau kalbant apie sprendimus be serverių, pastangos neatsipirks, ypač jei nuo pat pradžių bus atsižvelgta į ekonomiškumą. Būtinai pasidomėkite, kaip pardavėjai teikia paslaugas. Kai kurios specializuotos paslaugos remiasi integravimo taškais su kitais tiekėjais ir gali suteikti „plug-and-play“ ryšį. Lengviau pateikti Lambda skambutį iš šliuzo API galinio taško, nei perduoti užklausą tarpiniam serveriui į kokį nors konteinerį arba EC2 egzempliorių. „Graphcool“ suteikia lengvą konfigūraciją naudojant „Auth0“, o tai lengviau nei naudoti trečiųjų šalių autentifikavimo įrankius.
Tinkamo tiekėjo pasirinkimas programai be serverio yra architektūrinis sprendimas. Kai kuriate programą, nesitikite, kad vieną dieną grįšite prie serverių valdymo. Debesų tiekėjo pasirinkimas nesiskiria nuo konteinerių ar duomenų bazės ar net programavimo kalbos pasirinkimo.
Apsvarstykite:
- Kokių paslaugų jums reikia ir kodėl.
- Kokias paslaugas teikia debesijos paslaugų teikėjai ir kaip galite jas derinti su pasirinktu FaaS sprendimu.
- Kokios programavimo kalbos yra palaikomos (su dinaminiu ar statiniu spausdinimu, kompiliuojamos ar interpretuojamos, kokie yra etalonai, koks yra šaltojo paleidimo našumas, kokia yra atvirojo kodo ekosistema ir kt.).
- Kokie yra jūsų saugumo reikalavimai (SLA, 2FA, OAuth, HTTPS, SSL ir kt.).
- Kaip valdyti CI/CD ir programinės įrangos kūrimo ciklus.
- Kokiais infrastruktūros kaip kodo sprendimais galite pasinaudoti.
Jei pratęsite esamą programą ir laipsniškai pridėsite be serverio funkcijų, tai gali šiek tiek apriboti turimas galimybes. Tačiau beveik visos be serverio technologijos suteikia tam tikrą API (per REST arba pranešimų eiles), kuri leidžia kurti plėtinius nepriklausomai nuo programos branduolio ir lengvai integruojamus. Ieškokite paslaugų su aiškiomis API, gera dokumentacija ir stipria bendruomene, ir jūs negalite suklysti. Integravimo paprastumas dažnai gali būti pagrindinis rodiklis ir tikriausiai yra viena iš pagrindinių priežasčių, kodėl AWS buvo tokia sėkminga nuo tada, kai „Lambda“ buvo išleista 2015 m.
Kai be serverių yra gerai
Technologijos be serverių gali būti taikomos beveik visur. Tačiau jų pranašumai neapsiriboja tik vienu taikymo būdu. Kliūtys patekti į debesų kompiuteriją šiandien yra labai mažos dėl technologijų be serverių. Jei kūrėjai turi idėją, bet nemoka valdyti debesų infrastruktūros ir optimizuoti sąnaudų, tai jiems nereikia ieškoti kažkokio inžinieriaus, kuris tai padarytų. Jei startuolis nori sukurti platformą, bet bijo, kad išlaidos gali tapti nekontroliuojamos, jis gali lengvai kreiptis į sprendimus be serverių.
Dėl sutaupytų sąnaudų ir lengvo mastelio keitimo be serverių sprendimai vienodai taikomi tiek vidinėms, tiek išorinėms sistemoms, iki žiniatinklio programos, turinčios kelių milijonų auditoriją. Sąskaitos matuojamos ne eurais, o centais. Paprasčiausio AWS EC2 egzemplioriaus (t1.micro) nuoma mėnesiui kainuos 15 €, net jei su juo nieko nedarysite (kas niekada nepamiršo jo išjungti?!). Palyginimui, norint pasiekti tokį išlaidų lygį per tą patį laikotarpį, jums reikės 512 MB Lambda paleisti 1 sekundę maždaug 3 milijonus kartų. O jei šia funkcija nesinaudosite, tai nieko ir nemokėsite.
Kadangi be serverių sistema pirmiausia yra pagrįsta įvykiais, gana lengva pridėti be serverio infrastruktūrą prie senų sistemų. Pavyzdžiui, naudodami AWS S3, Lambda ir Kinesis, galite sukurti analitikos paslaugą senai mažmeninei sistemai, kuri gali gauti duomenis per API.
Dauguma be serverių platformų palaiko kelias kalbas. Dažniausiai tai yra Python, JavaScript, C#, Java ir Go. Paprastai bibliotekų naudojimui visomis kalbomis nėra jokių apribojimų, todėl galite naudoti mėgstamas atvirojo kodo bibliotekas. Tačiau patartina nepiktnaudžiauti priklausomybėmis, kad jūsų funkcijos veiktų optimaliai ir nepaneigia didžiulio be serverio taikomų programų mastelio privalumų. Kuo daugiau pakuočių reikės sukrauti į konteinerį, tuo ilgiau užtruks šaltas užvedimas.
Šaltasis paleidimas yra tada, kai prieš naudojant pirmiausia reikia inicijuoti konteinerį, vykdymo laiką ir klaidų tvarkyklę. Dėl šios priežasties funkcijų vykdymo vėlavimas gali siekti iki 3 sekundžių, ir tai nėra geriausias pasirinkimas nekantriems vartotojams. Tačiau šaltas paleidimas įvyksta per pirmąjį skambutį po kelių minučių tuščiosios eigos funkcijos. Daugelis mano, kad tai yra nedidelis susierzinimas, kurį galima išvengti reguliariai tikrinant funkciją, kad ji veiktų tuščiąja eiga. Arba jie visiškai nepaiso šio aspekto.
Nors AWS išleistasTačiau SQL duomenų bazės nėra idealios tokio tipo naudojimui, nes jos remiasi ryšiais, kad atliktų operacijas, o tai gali greitai tapti kliūtimi, kai AWS Lambda srautas yra didelis. Taip, kūrėjai nuolat tobulina Serverless Aurora, ir jūs turėtumėte su ja eksperimentuoti, tačiau šiandien tokie NoSQL sprendimai kaip. Tačiau neabejotina, kad ši situacija labai greitai pasikeis.
Priemonių rinkinys taip pat nustato daug apribojimų, ypač vietinio testavimo srityje. Nors yra tokių sprendimų kaip „Docker-Lambda“, „DynamoDB Local“ ir „LocalStack“, jiems reikia sunkaus darbo ir daug konfigūracijos. Tačiau visi šie projektai yra aktyviai vystomi, todėl tik laiko klausimas, kada priemonių rinkinys pasieks mums reikalingą lygį.
Technologijų be serverių įtaka kūrimo ciklui
Kadangi jūsų infrastruktūra yra tik konfigūracija, kodą galite apibrėžti ir įdiegti naudodami scenarijus, pvz., apvalkalo scenarijus. Arba galite pasinaudoti konfigūracijos kaip kodo klasės sprendimais, pvz . Nors ši paslauga nepateikia visų sričių konfigūracijos, ji leidžia apibrėžti konkrečius išteklius, kuriuos naudosite kaip Lambda funkcijas. Tai reiškia, kad ten, kur „CloudFormation“ jums nepavyks, galite parašyti savo šaltinį (Lambda funkciją), kuris pašalins šią spragą. Tokiu būdu galite daryti bet ką, net konfigūruoti priklausomybes už AWS aplinkos ribų.
Kadangi visa tai tik konfigūracija, galite parametruoti savo diegimo scenarijus konkrečioms aplinkoms, regionams ir vartotojams, ypač jei naudojate infrastruktūros kaip kodo sprendimus, pvz., „CloudFormation“. Pavyzdžiui, galite įdiegti infrastruktūros kopiją kiekvienai saugyklos šakai, kad galėtumėte visiškai jas išbandyti atskirai kūrimo metu. Tai radikaliai pagreitina laiką, per kurį kūrėjai gauna grįžtamąjį ryšį, kai nori suprasti, ar jų kodas tinkamai veikia gyvoje aplinkoje. Vadovams nereikia jaudintis dėl kelių aplinkų diegimo išlaidų, nes jie moka tik už faktinį naudojimą.
„DevOps“ turi mažiau rūpesčių, nes jiems tereikia įsitikinti, kad kūrėjai turi tinkamą konfigūraciją. Jums nebereikia tvarkyti egzempliorių, balansavimo priemonių ar saugos grupių. Todėl terminas NoOps vis dažniau vartojamas, nors vis dar svarbu mokėti konfigūruoti infrastruktūrą, ypač kai kalbama apie IAM konfigūraciją ir debesų išteklių optimizavimą.
Yra labai galingų stebėjimo ir vizualizavimo įrankių, tokių kaip Epsagon, Thundra, Dashbird ir IOPipe. Jie leidžia stebėti esamą jūsų programų be serverio būseną, teikti registravimą ir sekimą, užfiksuoti našumo metriką ir architektūros kliūtis, atlikti sąnaudų analizę ir prognozes ir dar daugiau. Jie ne tik suteikia DevOps inžinieriams, kūrėjams ir architektams visapusišką programos našumo vaizdą, bet ir leidžia vadovams stebėti situaciją realiu laiku, naudojant sekundės išteklių sąnaudas ir išlaidų prognozes. Su tvarkoma infrastruktūra tai organizuoti daug sunkiau.
Kurti programas be serverių yra daug lengviau, nes jums nereikia diegti žiniatinklio serverių, tvarkyti virtualių mašinų ar konteinerių, pataisų serverių, operacinių sistemų, interneto šliuzų ir t. t. Atsisakius visų šių įsipareigojimų, architektūra be serverio gali sutelkti dėmesį į pagrindinį sprendimas.verslo ir klientų poreikiai.
Nors įrankių rinkinys galėtų būti geresnis (jis gerėja kiekvieną dieną), kūrėjai gali sutelkti dėmesį į verslo logikos įgyvendinimą ir geriausio programos sudėtingumo paskirstymą įvairiose architektūros paslaugose. Programų valdymas be serverio yra pagrįstas įvykiais ir debesies paslaugų teikėjo abstrahuojamas (pvz., SQS, S3 įvykiai arba DynamoDB srautai). Todėl kūrėjams tereikia parašyti verslo logiką, kad reaguotų į tam tikrus įvykius, ir nereikia sukti galvos, kaip geriausiai įdiegti duomenų bazes ir pranešimų eiles, ar kaip organizuoti optimalų darbą su duomenimis konkrečiose aparatinės įrangos saugyklose.
Kodą galima paleisti ir derinti vietoje, kaip ir bet kuriame kūrimo procese. Vieneto testavimas išlieka toks pat. Galimybė įdiegti visą taikomųjų programų infrastruktūrą su tinkinta dėklo konfigūracija leidžia kūrėjams greitai gauti svarbių atsiliepimų, negalvojant apie testavimo išlaidas ar poveikį brangiai valdomai aplinkai.
Įrankiai ir metodai, skirti kurti programas be serverių
Nėra konkretaus būdo kurti programas be serverių. Taip pat paslaugų rinkinį šiai užduočiai atlikti. AWS šiandien yra lyderis tarp galingų sprendimų be serverių, bet taip pat pažiūrėkite , и . Jei naudojate AWS, galime rekomenduoti kaip būdą rinkti programas (SAM), ypač naudojant C#, nes „Visual Studio“ turi puikių įrankių. SAM CLI gali padaryti viską, ką gali „Visual Studio“, todėl nieko neprarasite, jei persijungsite į kitą IDE ar teksto rengyklę. Žinoma, SAM veikia ir su kitomis kalbomis.
Jei rašote kitomis kalbomis, „Serverless Framework“ yra puikus atvirojo kodo įrankis, leidžiantis sukonfigūruoti bet ką naudojant labai galingus YAML konfigūracijos failus. „Serverless Framework“ taip pat palaiko įvairias debesų paslaugas, todėl rekomenduojame jį ieškantiems kelių debesų sprendimo. Ji turi didžiulę bendruomenę, kuri sukūrė daugybę papildinių bet kokiam poreikiui.
Vietiniam testavimui puikiai tinka atvirojo kodo įrankiai Docker-Lambda, Serverless Local, DynamoDB Local ir LocalStack. Technologijos be serverių vis dar yra ankstyvoje kūrimo stadijoje, kaip ir joms skirti įrankiai, todėl nustatydami sudėtingus testavimo scenarijus turėsite sunkiai dirbti. Tačiau paprasčiausiai įdiegti steką aplinkoje ir išbandyti ją ten pasirodo neįtikėtinai pigu. Ir jums nereikia kurti tikslios vietinės debesies aplinkos kopijos.
Naudokite AWS Lambda sluoksnius, kad sumažintumėte įdiegtų paketų dydį ir paspartintumėte atsisiuntimą.
Tam tikroms užduotims naudokite tinkamas programavimo kalbas. Skirtingos kalbos turi savų privalumų ir trūkumų. Yra daug etalonų, tačiau „JavaScript“, „Python“ ir C# (.NET Core 2.1+) yra lyderiai pagal AWS Lambda našumą. AWS Lambda neseniai pristatė Runtime API, kuri leidžia nurodyti norimą kalbą ir vykdymo aplinką, todėl eksperimentuokite.
Norėdami naudoti, naudokite mažus paketų dydžius. Kuo jie mažesni, tuo greičiau įkeliami. Nenaudokite didelių bibliotekų, ypač jei naudojate kelias jų funkcijas. Jei programuojate naudodami „JavaScript“, naudokite kūrimo įrankį, pvz., „Webpack“, kad optimizuotumėte kūrimą ir įtrauktumėte tik tai, ko jums tikrai reikia. .NET Core 3.0 turi „QuickJit“ ir pakopinį kompiliavimą, kuris pagerina našumą ir labai padeda šaltuoju paleidimu.
Dėl funkcijų be serverio priklausomybės nuo įvykių iš pradžių gali būti sunku suderinti verslo logiką. Šiuo atžvilgiu pranešimų eilės ir būsenos mašinos gali būti neįtikėtinai naudingos. Lambda funkcijos gali skambinti viena kitai, tačiau darykite tai tik tuo atveju, jei nesitikite atsakymo ("uždekite ir pamirškite") – nenorite gauti sąskaitos už tai, kad laukėte, kol baigsis kita funkcija. Pranešimų eilės yra naudingos norint atskirti verslo logikos dalis, valdyti programų kliūtis ir apdoroti operacijas (naudojant FIFO eiles). AWS Lambda funkcijas galima priskirti SQS eilėms kaip užstrigusioms pranešimų eilėms, kurios seka nesėkmingus pranešimus, kad būtų galima vėliau analizuoti. AWS Step Functions (būsenos mašinos) yra labai naudingos valdant sudėtingus procesus, kuriems reikia funkcijų grandinės. Vietoj Lambda funkcijos, kuri iškviečia kitą funkciją, žingsninės funkcijos gali koordinuoti būsenų perėjimus, perduoti duomenis tarp funkcijų ir valdyti visuotinę funkcijų būseną. Tai leidžia apibrėžti pakartotinio bandymo sąlygas arba ką daryti, kai įvyksta tam tikra klaida – labai galingas įrankis tam tikromis sąlygomis.
išvada
Pastaraisiais metais be serverių technologijos vystėsi neregėtu tempu. Yra tam tikrų klaidingų nuomonių, susijusių su šiuo paradigmos pasikeitimu. Atitraukiant infrastruktūrą ir mastelio valdymą, sprendimai be serverių suteikia didelę naudą – nuo supaprastinto kūrimo ir „DevOps“ procesų iki didžiulio veiklos sąnaudų sumažinimo.
Nors metodas be serverio neturi savo trūkumų, yra patikimų projektavimo modelių, kuriuos galima naudoti kuriant patikimas programas be serverių arba integruoti be serverio elementus į esamas architektūras.
Šaltinis: www.habr.com