Näpunäited ja teabeallikad serverita rakenduste loomiseks

Kuigi serverita tehnoloogiad on viimastel aastatel kiiresti populaarsust kogunud, on nendega endiselt seotud palju väärarusaamu ja muresid. Tarnija sõltuvus, tööriistade komplekt, kulude juhtimine, külm käivitus, monitooring ja arenduse elutsükkel — need teemad on aktiivselt arutluse all serverita tehnoloogiate kontekstis. Selles artiklis käsitleme mõningaid mainitud teemasid ning jagame näpunäiteid ja viiteid kasulikele teabeallikatele, mis aitavad algajatel luua võimsaid, paindlikke ja kulutõhusaid serverita rakendusi.

Serverita tehnoloogiate väärarusaamad

Paljud arvavad, et serverituks tegemine ja serveriväline andmetöötlus (Functions as a Service, FaaS) on peaaegu üks ja sama. See tähendab, et erinevus pole kuigi suur ja uuenduse kasutuselevõtt on õigustatud. Kuigi AWS Lambda on olnud üks serverita tehnoloogiate tõusu "tähti" ja üks populaarsemaid komponente serverita arhitektuuris, representa see arhitektuur rohkem kui FaaS.

Serverita tehnoloogiate peamine põhimõte on see, et te ei pea muretsema infrastruktuuri haldamise ja skaleerimise pärast, maksate ainult selle eest, mida kasutate. Need kriteeriumid sobivad paljudele teenustele — AWS DynamoDB, S3, SNS või SQS, Graphcool, Auth0, Now, Netlify, Firebase ja paljud teised. Üldiselt tähendab serveritus, et saate kasutada kõiki pilvearvutuste võimalusi, ilma et peaksite haldama infrastruktuuri ja optimeerima seda skaleerimise nimel. Samuti tähendab see, et infrastruktuuri taseme turvalisus ei ole enam teie probleem, mis on suur eelis, arvestades turvastandardite järgimise keerukust ja raskust. Lõpuks ei pea te ostma teile kasutamiseks antud infrastruktuuri.

Serveritust saab pidada "meeleoluks": teatud mõtteviisiks lahenduste projekteerimisel. Vältige lähenemisi, mis nõuavad igasuguse infrastruktuuri hooldust. Serverita lähenemise korral kulutame aega probleemide lahendamisele, mis mõjutavad otse projekti ja toovad kasu meie kasutajatele: loome vastupidava äriloogika, arendame kasutajaliideseid ning loome paindlikke ja usaldusväärseid API-sid.

Näiteks, kui on võimalik vältida vaba tekstiotsingu platvormi haldamist ja hooldamist, siis me just nii teeme. Selline lähenemine rakenduste kogumisele võib toote turule toomise aega oluliselt kiirendada, kuna teil ei ole enam vaja mõelda keeruka infrastruktuuri haldamisele. Vabanege haldamise ja infrastruktuuri kulude kohustustest ning keskenduge rakenduste ja teenuste loomisele, mis on teie klientidele vajalikud. Patrick Debois nimetas sellist lähenemist ‘servicefull’, see termin on aktsepteeritud serverita kogukonnas. Funktsioone tuleks käsitleda kui seoselemente teenustele, mida esitatakse looditava moodulina (selle asemel, et rakendada kogu raamatukogu või veebirakendust). See tagab erakordse granulaarsuse rakenduse juurutamise ja muudatuste haldamisel. Kui te ei saa sel moel funktsioone juurutada, võib see viidata sellele, et funktsioonid täidavad liiga palju ülesandeid ja neid tuleks refaktoreerida.

Mõned inimesed tunnevad muret teenusepakkuja sõltuvuse üle pilve rakenduste arendamisel. Sama kehtib ka serverivaba tehnoloogia kohta ning see ei näi olema valearusaama tulemus. Meie kogemuse põhjal on AWS-is serverivabade rakenduste loomine koos AWS Lambda võimega siduda teisi AWS-teenuseid osaliselt need tõendid, mis toetavad serverivaba arhitektuuri eeliseid. See on hea näide sünergiast, kus tulemuse kogusumma ületab lihtsalt koostisosade summa. Püüdes vältida teenusepakkuja sõltuvust, võite kokku puutuda veelgi suuremate probleemidega. Konteinerite kasutamisel on kergem hallata oma abstraktsiooni taset erinevate pilveteenuse pakkujate vahel. Kuid kui jutt on serverivabadest lahendustest, siis ei tasu pingutused end ära, eriti kui arvestada algusest peale majanduslikku efektiivsust. Uurige kindlasti, kuidas teenusepakkujad teenuseid tarnivad. Mõned spetsialiseeritud teenused sõltuvad teiste teenusepakkujate integratsioonipunktidest ja võivad pakuda plug-and-play ühenduvust kohe välja pakkuda. Lambda kutsumise tagamine API gateway lõpupunktist on lihtsam kui päringu edastamine mõnes konteineris või EC2 instantsis. Graphcool pakub lihtsat seadistamist Auth0 kaudu, mis on lihtsam kui kolmandate osapoolte autentimisvahendite kasutamine.

Õige teenusepakkuja valimine teie serverivaba rakenduse jaoks on arhitektuuritase otsus. Rakendust luues ei looda te, et ühel päeval naasete serverite haldamise juurde. Pilveteenuse pakkuja valik ei erine konteinerite, andmebaaside või isegi programmeerimiskeele valikust.

Mõelge järgnevatele küsimustele:

• Milliseid teenuseid te vajate ja miks.
• Milliseid teenuseid pakuvad pilveteenuse pakkujad ja kuidas saate neid kombineerida valitud FaaS-lahendusega.
• Milliseid programmeerimiskeeli toetatakse (dünaamilise või staatilise tüübiga, kompileeritud või tõlgitud, millised on bench-markid, milline on jõudlus külma käivitamise korral, milline on avatud lähtekoodiga ökosüsteem jne).
• Millised on teie turvanõuded (SLA, 2FA, OAuth, HTTPS, SSL jne).
• Kuidas hallata CI/CD ja tarkvaraarenduse tsükleid.
• Milliseid infrastruktuuri kui koodi lahenduste eeliseid saate kasutada.

Kui laiendate olemasolevat rakendust ja lisate järk-järgult serverivabu funktsioone, võib see veidi piirata saadaval olevate võimaluste arvu. Siiski pakuvad peaaegu kõik serverivabad tehnoloogiad mingisuguseid API-sid (kas REST või sõnumijärjekordade kaudu), mis võimaldavad luua laiendusi sõltumatult rakenduse tuumast ja lihtsa integreerimisega. Otsige teenuseid, millel on selged API-d, hea dokumentatsioon ja tugev kogukond, ning te ei eksi. Integreerimise lihtsus võib sageli olla võtme mõõdik, ja see on tõenäoliselt üks peamisi põhjuseid, miks AWS on alates 2015. aastast Lambda turule tulnud.

Kuidas serverivabadus on kasulik

Serverivabu tehnoloogiaid saab rakendada praktiliselt igal pool. Siiski ei piirdu nende eelised vaid rakendamisviisidega. Täna on pilvcomputing’u sisenemiskünnis nii madal just tänu serverivabadele tehnoloogiatele. Kui arendajatel on idee, kuid nad ei tea, kuidas juhtida pilvinfra ja optimeerida kulusid, ei pea nad otsima inseneri. Kui idufirma soovib luua platvormi, kuid kardab, et kulud võivad uncontrolled‘iks minna, saavad nad hõlpsasti kasutada serverivabu lahendusi.

Kuna kulude kokkuhoid ja skaleeritavuse lihtsus, on serverivabad lahendused võrdselt rakendatavad nii sise- kui välissüsteemides, sealhulgas veebirakendustes, millel on miljoneid kasutajaid. Arved mõõdetakse pigem euros, mitte sendina. Lihtsaim AWS EC2 (t1.micro) hinna rent kuus on €15, isegi kui te ei tee sellega midagi (kes pole kunagi unustanud sellest välja lülitada?!). Võrdluseks, et sama kulu tasemele jõuda sama aja jooksul, peate kutsuma Lambda 512 MB ulatuses 1 sekundiks umbes 3 miljonit korda. Ja kui te ei kasuta seda funktsiooni, siis teile ei tule midagi maksma.

Kuna serverivaba tehnoloogia sõltub peamiselt sündmustest, on vanadesse süsteemidesse serverivaba infrastruktuuri üsna lihtne lisada. Näiteks AWS S3, Lambda ja Kinesis abil saate luua analüüsiteenuse vanale jae süsteemile, mis suudab saada andmeid API kaudu.

Enamik serverivabu platvorme toetab erinevaid programmeerimiskeeli. Sageli on need Python, JavaScript, C#, Java ja Go. Üldiselt ei ole kõigis keeltes raamatukogude kasutamise osas mingeid piiranguid, seega võite kasutada oma lemmikuid avatud lähtekoodiga raamatukogusid. Siiski on soovitatav mitte kuritarvitada sõltuvusi, et teie funktsioonid töötaksid optimaalselt ja ei hävitaks teie serverivabade rakenduste suurt skaleeritavuse eelist. Mida rohkem pakette tuleb konteinerisse laadida, seda kauem kulub külma käivitamise teostamiseks.

Külm käivitamine tähendab, et konteiner, täitmisvõime ja veahaldur tuleb kõigepealt algatada, enne kui neid kasutama hakatakse. Selle tõttu võib funktsioonide teostamise viivitus ulatuda 3 sekundini, mis ei ole parim variant kannatamatutele kasutajatele. Kuid külmad käivitamised esinevad esmakordsel päringul pärast mõne minuti pikkust seisaku lõppu. Seetõttu peetakse seda paljude arvates tühiseks ebamugavuseks, mida saab vältida funktsiooni regulaarsel pingil hoidmisega, et seda tühikäigul hoida. Või jäetakse see aspekt sootuks tähelepanuta.

Kuigi AWS on välja andnud serverivaba SQL-andmebaasi Serverless Aurora, ei ole SQL-andmebaasid sellise kasutuse jaoks ideaalsed, kuna tehingute teostamisel sõltuvad nad ühendustest, mis võivad kiiresti saada kitsaskohaks suure liikluse korral AWS Lambdas. Jah, arendajad parendavad pidevalt Serverless Aurorat ja teil tasub sellega eksperimenteerida, kuid täna sobivad serverivabade süsteemide jaoks palju paremini NoSQL-lahendused nagu DynamoDB. Siiski on selge, et see olukord muutub peagi.

Tööriist komplekt kehtestab samuti palju piiranguid, eriti kohaliku testimise valdkonnas. Kuigi olemas on lahendused nagu Docker-Lambda, DynamoDB Local ja LocalStack, nõuavad need siiski põhjalikku tööd ja märkimisväärset konfigureerimist. Siiski arendavad kõik need projektid aktiivselt, seega on see vaid ajaküsimus, kuni tööriistade komplekt saavutab vajaliku taseme.

Serverivabade tehnoloogiate mõju arendusprotsessile

Kuna teie infrastruktuur on lihtsalt konfiguratsioon, saab koodi seadistada ja juurutada skriptide abil, näiteks shell-skriptide kaudu. Või saab kasutada konfiguratsiooni kui koodi lahendusi nagu AWS CloudFormation. Kuigi see teenus ei paku konfiguratsiooni kõigile valdkondadele, võimaldab see siiski määratleda spetsiifilised ressursid, mida kasutada Lambda-funktsioonidena. See tähendab, et seal, kus CloudFormation ei suuda, saate kirjutada oma ressursi (Lambda-funktsiooni), mis katab selle puudujäägi. Nii saate teha mida iganes, isegi konfigureerida sõltuvusi väljaspool teie AWS-ümbrust.

Kuna kõik need on lihtsalt konfiguratsioonid, saate parametriseerida oma juurutusskripte spetsiifiliste keskkondade, piirkondade ja kasutajate jaoks, eriti kui kasutate infrastruktuuri klastri lahendusi nagu CloudFormation. Näiteks võite juurutada iga haru jaoks oma infrastruktuuri koopia, et neid täielikult eraldatult arendamise käigus testida. See kiirendab radikaalselt tagasiside saamist arendajatel, kui nad soovivad mõista, kas nende kood töötab õigesti reaalajas keskkonnas. Juhtidel ei pea muretsema mitmete keskkondade juurutamise kulude üle, sest makstakse ainult tegeliku kasutamise eest.

DevOps'il on vähem muresid, kuna nad peavad vaid kinnitama, et arendajatel on õige konfiguratsioon. Ei pea enam haldama instantside, koormuse tasakaalustajate või turvagruppide haldust. Seetõttu kasutatakse üha sagedamini terminit NoOps, kuigi on endiselt oluline osata infrastruktuuri konfigureerida, eriti IAM-konfiguratsiooni ja pilveressursside optimeerimise osas.

On väga võimsaid tööriistu jälgimiseks ja visuaalse esituse tegemiseks, nagu Epsagon, Thundra, Dashbird ja IOPipe. Need võimaldavad jälgida serverita rakenduste hetkeseisundit, pakkuda logisid ja jälgida, registreerida jõudluse mõõdikuid ja arhitektuuri kitsaskohti, teostada kulude analüüsi ja prognoosimist ning palju muud. Need mitte ainult ei anna DevOps-inseneridele, arendajatele ja arhitektidele põhjalikku ülevaadet rakenduste toimimisest, vaid võimaldavad ka juhtidel jälgida olukorda reaalajas, sekundi täpsusega kuludest ressursside ja prognoositud kuludega. Sellise korraldamine hallatava infrastruktuuri puhul on palju keerulisem.

Serverless rakenduste kujundamine on palju lihtsam, kuna te ei pea juurutama veebiservereid, haldama virtuaalmasinaid ega konteinerite, plaasima servereid, töötlussüsteeme, Interneti-lülsse jne. Kõigist neist kohustustest vabastamine võimaldab serverless arhitektuuril keskenduda peamisele — äriliste ja klientide vajaduste rahuldamisele.

Kuigi tööriistade arsenal võiks olla parem (see paraneb iga päev), saavad arendajad keskenduda ettevõtte loogika rakendamisele ja rakenduse keerukuse parimale jaotamisele erinevate teenuste vahel arhitektuuri piires. Serverless rakenduste haldamine toimub sündmuste põhjal ja on abstrakteeritud pilveteenuse pakkuja poolt (nt SQS, S3 sündmused või DynamoDB vood). Seetõttu piisab arendajatelt ainult äriloogika määramisest teatud sündmustele reageerimiseks, ilma et muretseks optimaalse andmebaasi ning sõnumijärjekordade rakendamise või andmete tõhususe kohta konkreetsetes riistvaralao ülesseadetes.

Koodi saab käitada ja siluda kohapeal, nagu iga arenduse puhul. Moodulite testimine jääb endiseks. Rakenduse kogu infrastruktuuri juurutamise võimalus konfigureeritava steki abil võimaldab arendajatel kiiresti olulisi tagasiside saada, muretsemata testimise kulude või kulukate hallatavate keskkondade mõju üle.

Serverless rakenduste koostamise tööriistad ja meetodid

Ei ole ühtegi kindlat viisi serverless rakenduste koostamiseks. Samuti ei ole kindlat teenuste komplekti selle ülesande täitmiseks. Täna on AWS juhtiv jõud võimsates serverless lahendustes, kuid tasub tähelepanu pöörata ka Google Cloud, Zeit ja Firebase. Kui kasutate AWS-i, siis rakenduste koostamise lähenemisviisina võib soovitada Serverless Application Model (SAM), eriti C# kasutamisel, kuna Visual Studio pakub suurepärast tööriistade komplekti. SAM CLI suudab teha kõike seda, mida ka Visual Studio, seega ei kaota te midagi, kui liigute teise IDE või tekstiredaktori juurde. Loomulikult töötab SAM ka teiste keeltega.

Kui kirjutate teistes keeltes, siis Serverless Framework on suurepärane avatud lähtekoodiga tööriist, mis võimaldab konfigureerida kõike väga võimsate YAML konfiguratsioonifailide abil. Serverless Framework toetab ka erinevaid pilveteenuseid, seetõttu soovitame seda neile, kes otsivad mitme pilve lahendust. Sellel on suur kogukond, mis on loonud hulga pluginaid igasuguste vajaduste jaoks.

Kohalikuks testimiseks sobivad hästi avatud lähtekoodiga tööriistad nagu Docker-Lambda, Serverless Local, DynamoDB Local ja LocalStack. Serverless tehnoloogiad on endiselt arengu algusjärgus, nagu ka nende tööriistakomplekt, nii et keeruliste testimisstsenaariumide seadistamine võib olla väljakutsuv. Siiski on steigi käivitamine ja seal testimine uskumatult odav. Ja teil ei ole vaja teha täpset kohaliku versiooni koopia pilvesüsteemidest.

Pakettide suuruse vähendamiseks ja laadimise kiirusestamiseks kasutage AWS Lambda kihte.

Kasutage konkreetsete ülesannete jaoks õigeid programmeerimiskeeli. Erinevatel keeltele on omad eelised ja puudused. Palju on benchmarke, kuid JavaScript, Python ja C# (.NET Core 2.1+) on AWS Lambda jõudluse osas liidrid. Hiljuti lisandus AWS Lambda-sse Runtime API, mis võimaldab määrata soovitud keele ja täitmisplatvormi, nii et katsetage.

Hoidke pakettide suurus võimalikult väike. Mida väiksemad nad on, seda kiiremini nad laaditakse. Vältige suurte raamatukogude kasutamist, eriti kui kasutasite neist vaid paari funktsiooni. Kui programmeerite JavaScriptis, siis kasutage selliseid kogumise tööriistu nagu Webpack, et optimeerida kogumist ja lisada ainult seda, mis teil tõeliselt vajalik on. .NET Core 3.0-s on QuickJit ja Tiered Compilation, mis parandavad jõudlust ja aitavad oluliselt külmade käivituste korral.

Serverless funktsioonide sõltuvus sündmustest võib alguses keeruliseks muuta äriloogika koordineerimise. Seetõttu võivad sõnumijärjekorrad ja lõpmõisted olla äärmiselt kasulikud. Lambda-funktsioonid saavad üksteist kutsuda, kuid tehke seda vaid siis, kui te ei oota vastust („tulistasin ja unustasin”) — te ei taha ju saada arvet ootamise eest, kuni teine funktsioon lõpule jõuab. Sõnumijärjekorrad on kasulikud äriloogika osade eraldamiseks, rakenduste kitsaskohtade juhtimiseks ja tehingute töötlemiseks (kasutades FIFO järjekordi). AWS Lambda funktsioone saab siduda SQS järjekordadega kui „kinni jäänud” sõnumite järjekordadeks, mis jälgivad ebaõnnestunud sõnumeid edasiseks analüüsiks. AWS Step Functionsi funktsioonid (lõpmõisted) on väga kasulikud keerukate protsesside juhtimisel, mis vajavad funktsioonide kettide loomist. Selle asemel, et Lambda funktsioon kutsuks ülesse teise funktsiooni, saavad Step-funktsioonid koordineerida olekute üleminekuid, edastada andmeid funktsioonide vahel ja hallata funktsioonide globaalset olekut. See võimaldab määrata tingimused korduste jaoks või mida teha konkreetse vea ilmnemisel — teatud tingimustes äärmiselt võimas tööriist.

Kokkuvõte

Viimastel aastatel on serverless tehnoloogiad arenenud erakordse kiirusel. Selle paradigma muutusega on seotud teatud väärarusaamad. Tänu infrastruktuuri ja skaleerimise haldamise abstraktimisele pakuvad serverless lahendused märkimisväärseid eeliseid: alates arendamise ja DevOps-protsesside lihtsustamisest kuni operaatorite kulude märgise vähenemiseni.
Ja kuigi serverless lähenemisel ei ole puudusi, on olemas usaldusväärsed tehnikad ja disainimustrid, mis võimaldavad luua stabiilseid serverless rakendusi või integreerida serverless koostisosad olemasolevatesse arhitektuuridesse.

Allikas: habr.com