Kuigi serverita tehnoloogiad on viimastel aastatel kiiresti populaarsust kogunud, on nendega seotud endiselt palju väärarusaamu ja muresid. Tarnijasõltuvus, tööriistad, kulude haldamine, külmkäivitus, jälgimine ja arendustöö elutsükkel on kõik kuumad teemad, mis puudutavad serverita tehnoloogiaid. Selles artiklis käsitleme mõnda mainitud teemat ning jagame näpunäiteid ja linke kasulike ressursside juurde, mis aitavad algajatel luua võimsaid, paindlikke ja kuluefektiivseid serverita rakendusi.
Valed arusaamad serverita tehnoloogiate kohta
Paljud inimesed usuvad, et serverita ja serverita andmetöötlus (, FaaS) on peaaegu sama asi. See tähendab, et vahe pole liiga suur ja tasub võtta kasutusele uus toode. Kuigi AWS Lambda oli üks serverita tehnoloogia tõusu tähte ja üks populaarsemaid serverita arhitektuuri elemente, on selles arhitektuuris rohkem kui FaaS.
Serverita põhiprintsiip on see, et te ei pea muretsema oma infrastruktuuri haldamise või skaleerimise pärast, maksate ainult selle eest, mida kasutate. Paljud teenused vastavad nendele kriteeriumidele – AWS DynamoDB, S3, SNS või SQS, Graphcool, Auth0, Now, Netlify, Firebase ja paljud teised. Üldiselt tähendab serverita pilvandmetöötluse kõigi võimaluste kasutamist, ilma et oleks vaja skaleerimise huvides infrastruktuuri hallata ja optimeerida. See tähendab ka seda, et turvalisus infrastruktuuri tasemel ei ole enam teie probleem, mis on tohutu kasu, arvestades turvastandardite täitmise raskust ja keerukust. Lõpuks ei pea te teile pakutavat infrastruktuuri ostma.
Serverita võib pidada „meeleseisundiks“: teatud mentaliteet lahenduste kavandamisel. Vältige lähenemisviise, mis nõuavad mis tahes infrastruktuuri hooldamist. Serverita lähenemisega kulutame aega probleemide lahendamisele, mis projekti otseselt mõjutavad ja meie kasutajatele väärtust toovad: loome tugeva äriloogika, arendame kasutajaliideseid ning arendame reageerivaid ja usaldusväärseid API-sid.
Näiteks kui on võimalik vältida vaba tekstiotsingu platvormi haldamist ja hooldamist, siis seda me ka teeme. Selline lähenemine rakenduste loomisele võib märkimisväärselt kiirendada turule jõudmise aega, sest te ei pea enam mõtlema keeruka infrastruktuuri haldamisele. Vabastage end infrastruktuuri haldamise kohustustest ja kuludest ning keskenduge oma klientidele vajalike rakenduste ja teenuste loomisele. Patrick Debois nimetas seda lähenemist , on see termin serverita kogukonnas aktsepteeritud. Funktsioone tuleks käsitleda kui liimi, mis seob teenuseid juurutatavate moodulitena (mitte juurutada terve teeki või veebirakendust). See annab rakenduse juurutamise ja muudatuste haldamiseks uskumatu detailsuse. Kui te ei saa funktsioone sel viisil juurutada, võib see viidata sellele, et funktsioonid teevad liiga palju asju ja vajavad ümberkujundamist.
Mõned inimesed on pilverakenduste arendamisel segaduses tarnijasõltuvusest. Sama kehtib ka serveriteta tehnoloogiate kohta ja tõenäoliselt pole see eksiarvamuse tagajärg. Meie kogemuse kohaselt on serverita rakenduste loomine AWS-is koos AWS Lambda võimega koondada muid AWS-i teenuseid osa sellest, mis teeb serverita arhitektuurid nii suurepäraseks. See on hea näide sünergiast, kui kombinatsiooni tulemus on suurem kui lihtsalt selle osade summa. Püüdes vältida müüja lukustumist, võib tekkida veelgi rohkem probleeme. Konteineritega töötades on lihtsam hallata oma pilvepakkujate vahelist abstraktsioonikihti. Kuid mis puutub serverita lahendustesse, siis vaev ei tasu end ära, eriti kui arvestada kuluefektiivsust algusest peale. Uurige kindlasti, kuidas müüjad teenuseid pakuvad. Mõned spetsialiseeritud teenused tuginevad integratsioonipunktidele teiste tarnijatega ja võivad pakkuda pistik-ja-mängi-ühenduvust. Lihtsam on pakkuda Lambda kõnet lüüsi API lõpp-punktist kui päringu puhverserveriga mõnele konteinerile või EC2 eksemplarile. Graphcool võimaldab hõlpsat konfigureerimist Auth0 abil, mis on lihtsam kui kolmanda osapoole autentimistööriistade kasutamine.
Serverita rakenduse jaoks õige tarnija valimine on arhitektuuritasandi otsus. Rakendust luues ei oota te ühel päeval serverite haldamise juurde tagasi pöördumist. Pilveteenuse pakkuja valimine ei erine konteinerite või andmebaasi või isegi programmeerimiskeele valimisest.
Kaaluge:
- Milliseid teenuseid vajate ja miks.
- Milliseid teenuseid pilveteenuse pakkujad pakuvad ja kuidas saate neid valitud FaaS-lahendust kasutades kombineerida.
- Milliseid programmeerimiskeeli toetatakse (dünaamiliselt või staatiliselt trükitud, koostatud või tõlgendatud, millised on etalonid, milline on külmkäivituse jõudlus, milline on avatud lähtekoodiga ökosüsteem jne).
- Millised on teie turvanõuded (SLA, 2FA, OAuth, HTTPS, SSL jne).
- Kuidas hallata oma CI/CD ja tarkvara arendustsükleid.
- Milliseid infrastruktuuri kui koodi lahendusi saate kasutada?
Kui laiendate olemasolevat rakendust ja lisate järk-järgult serverita funktsioone, võib see saadaolevaid võimalusi mõnevõrra piirata. Peaaegu kõik serverita tehnoloogiad pakuvad aga mingit API-d (REST või sõnumijärjekorra kaudu), mis võimaldab luua rakenduse tuumast sõltumatuid ja hõlpsasti integreeritavaid laiendusi. Otsige selgete API-de, hea dokumentatsiooni ja tugeva kogukonnaga teenuseid ning te ei saa valesti minna. Integreerimise lihtsus võib sageli olla võtmenäitaja ja tõenäoliselt üks peamisi põhjusi, miks AWS on olnud edukas pärast Lambda väljatulekut 2015. aastal.
Millal on serverita kasulik?
Serverita tehnoloogiaid saab kasutada peaaegu kõikjal. Kuid nende eelised ei piirdu ainult rakendusmeetoditega. Pilvandmetöötlusele sisenemise barjäär on täna nii madal just tänu serverita tehnoloogiatele. Kui arendajatel on idee, kuid nad ei tea, kuidas pilveinfrastruktuuri hallata ja kulusid optimeerida, ei pea nad selle tegemiseks mõnda inseneri otsima. Kui idufirma soovib luua platvormi, kuid tunneb muret, et kulud võivad kontrolli alt väljuda, võib ta kergesti pöörduda serverita lahenduste poole.
Tänu kulude kokkuhoiule ja skaleerimise lihtsusele on serverita lahendused võrdselt rakendatavad nii sise- kui ka välissüsteemides, kuni mitme miljoni dollari suuruse vaatajaskonnaga veebirakenduseni. Kontod mõõdetakse pigem sentides kui eurodes. Lihtsaima AWS EC2 eksemplari (t1.micro) kuuks rentimine maksab 15 €, isegi kui te sellega midagi ei tee (kes on selle kunagi unustanud välja lülitada?!). Võrdluseks, selle kulutaseme saavutamiseks sama aja jooksul peaksite 512 MB Lambdat 1 sekundi jooksul käivitama umbes 3 miljonit korda. Ja kui te seda funktsiooni ei kasuta, ei maksa te midagi.
Kuna serverita on peamiselt sündmustepõhine, on serverivaba infrastruktuuri lisamine pärandsüsteemidele üsna lihtne. Näiteks saate AWS S3, Lambda ja Kinesise abil luua analüütikateenuse pärandjaemüügisüsteemi jaoks, mis saab API kaudu andmeid vastu võtta.
Enamik serverita platvorme toetab mitut keelt. Enamasti on need Python, JavaScript, C#, Java ja Go. Tavaliselt ei ole kõikidel keeltel teekide kasutamisel mingeid piiranguid, nii et saate kasutada oma lemmik avatud lähtekoodiga teeke. Siiski ei ole soovitatav sõltuvusi mitte üle kasutada, et teie funktsioonid toimiksid optimaalselt ega kaotaks ära serverita rakenduste tohutu mastaapsuse eeliseid. Mida rohkem pakendeid tuleb konteinerisse laadida, seda kauem võtab külmkäivitus aega.
Külmkäivitus on siis, kui peate esmalt lähtestama konteineri, käitusaja ja veakäsitleja enne nende kasutamist. Seetõttu võib funktsioonide täitmise viivitus olla kuni 3 sekundit ja see pole kannatamatute kasutajate jaoks parim valik. Külmkäivitus toimub aga esimesel kõnel pärast mõneminutilist jõudeolekut. Paljud arvavad, et see on väike ebamugavus, mida saab vältida, kui funktsiooni regulaarselt pingida, et see tühikäigul püsiks. Või ignoreerivad nad seda aspekti üldse.
Kuigi AWS vabastatiSQL-andmebaasid ei ole aga seda tüüpi kasutuseks ideaalsed, kuna need tuginevad tehingute sooritamiseks ühendustele, mis võib kiiresti muutuda kitsaskohaks, kui AWS Lambdas on palju liiklust. Jah, arendajad täiustavad pidevalt Serverless Aurorat ja sellega tuleks katsetada, kuid tänapäeval on NoSQL-i lahendused nagu. Siiski pole kahtlust, et see olukord väga peagi muutub.
Tööriistakomplekt seab ka palju piiranguid, eriti kohaliku testimise valdkonnas. Kuigi on selliseid lahendusi nagu Docker-Lambda, DynamoDB Local ja LocalStack, nõuavad need hoolikat tööd ja märkimisväärset konfiguratsiooni. Kõik need projektid arenevad aga aktiivselt, seega on vaid aja küsimus, millal tööriistad meile vajalikule tasemele jõuavad.
Serverita tehnoloogiate mõju arendustsüklile
Kuna teie infrastruktuur on lihtsalt konfiguratsioon, saate koodi määratleda ja juurutada skriptide (nt shelliskriptide) abil. Või võite kasutada konfiguratsiooni-koodina klassi lahendusi, näiteks . Kuigi see teenus ei paku konfiguratsiooni kõigi piirkondade jaoks, võimaldab see määratleda konkreetsed ressursid kasutamiseks lambda funktsioonidena. See tähendab, et kui CloudFormation ebaõnnestub, saate kirjutada oma ressursi (Lambda funktsioon), mis selle lünga täidab. Nii saate teha kõike, isegi konfigureerida sõltuvusi väljaspool oma AWS-i keskkonda.
Kuna see kõik on vaid konfiguratsioon, saate oma juurutusskripte parameetrites määrata konkreetsete keskkondade, piirkondade ja kasutajate jaoks, eriti kui kasutate infrastruktuuri-koodina lahendusi, nagu CloudFormation. Näiteks saate iga hoidla haru jaoks juurutada infrastruktuuri koopia, et saaksite neid arenduse ajal täielikult isoleeritult testida. See kiirendab radikaalselt aega, mille jooksul arendajad saavad tagasisidet, kui nad tahavad mõista, kas nende kood toimib reaalajas keskkonnas piisavalt. Haldurid ei pea muretsema mitme keskkonna juurutamise kulude pärast, sest nad maksavad ainult tegeliku kasutamise eest.
DevOpsil on vähem muret, kuna nad peavad ainult veenduma, et arendajatel on õige konfiguratsioon. Enam ei halda eksemplare, tasakaalustajaid ega turberühmi. Seetõttu kasutatakse üha enam terminit NoOps, kuigi endiselt on oluline osata infrastruktuuri konfigureerida, eriti mis puudutab IAM-i seadistamist ja pilveressursside optimeerimist.
Seal on väga võimsad jälgimis- ja nähtavustööriistad nagu Epsagon, Thundra, Dashbird ja IOPipe. Need võimaldavad teil jälgida serverita rakenduste hetkeseisu, pakkuda logisid ja jälgi, jäädvustada jõudlusmõõdikuid ja arhitektuurilisi kitsaskohti, teostada kulude analüüsi ja prognoosimist ning palju muud. Need mitte ainult ei anna DevOpsi inseneridele, arendajatele ja arhitektidele igakülgset ülevaadet rakenduste toimivusest, vaid võimaldavad ka juhtidel saada reaalajas, sekund-sekundilise ressursikulu ja kulude prognoosimise nähtavust. Hallatud infrastruktuuriga on seda palju keerulisem korraldada.
Serverita rakenduste kujundamine on palju lihtsam, kuna te ei pea juurutama veebiservereid, haldama virtuaalmasinaid või konteinereid, paigaservereid, operatsioonisüsteeme, Interneti-lüüsi jne. Kõigi nende kohustuste koondamine võimaldab serverita arhitektuuril keskenduda kõige olulisemale: lahendusele. äri- ja klientide vajadustele.
Kuigi tööriistad võiksid olla paremad (täiustub iga päevaga), saavad arendajad keskenduda äriloogika rakendamisele ja sellele, kuidas rakenduse keerukust kõige paremini arhitektuuri eri teenuste vahel jaotada. Serverivaba rakenduste haldamine on sündmustepõhine ja pilveteenuse pakkuja poolt võetud (näiteks SQS, S3 sündmused või DynamoDB vood). Seetõttu peavad arendajad teatud sündmustele reageerimiseks kirjutama ainult äriloogika ega pea muretsema selle pärast, kuidas andmebaase ja sõnumijärjekordi kõige paremini rakendada või kuidas konkreetsetes riistvaramäludes olevate andmetega optimaalselt töötada.
Koodi saab käivitada ja siluda kohapeal, nagu iga arendusprotsessi puhul. Ühiku testimine jääb samaks. Võimalus juurutada kogu rakenduse infrastruktuuri kohandatud virna konfiguratsiooni abil võimaldab arendajatel saada kiiresti olulist tagasisidet, muretsemata testimiskulude või mõju pärast kulukatele hallatavatele keskkondadele.
Tööriistad ja tehnikad serverita rakenduste loomiseks
Serverita rakenduste loomiseks pole konkreetset viisi. Nagu ka selle ülesande jaoks teenuste komplekt. Tänapäeval on võimsate serverita lahenduste liider AWS, kuid pöörake sellele tähelepanu , и . Kui kasutate AWS-i, saame rakenduste kogumiseks soovitada (SAM), eriti C# kasutamisel, sest Visual Studiol on suurepärased tööriistad. SAM CLI saab teha kõike, mida Visual Studio suudab, nii et te ei kaota midagi, kui lülitute mõnele muule IDE-le või tekstiredaktorile. Muidugi töötab SAM ka teiste keeltega.
Kui kirjutate teistes keeltes, on Serverless Framework suurepärane avatud lähtekoodiga tööriist, mis võimaldab teil väga võimsate YAML-i konfiguratsioonifailide abil kõike konfigureerida. Serverless Framework toetab ka erinevaid pilveteenuseid, seega soovitame seda neile, kes otsivad mitme pilve lahendust. Sellel on tohutu kogukond, mis on loonud hunniku pistikprogramme mis tahes vajaduse jaoks.
Kohalikuks testimiseks sobivad hästi avatud lähtekoodiga tööriistad Docker-Lambda, Serverless Local, DynamoDB Local ja LocalStack. Serverivabad tehnoloogiad, nagu ka nende jaoks mõeldud tööriistad, on alles arendamise varajases staadiumis, seega peate keerukate testimisstsenaariumide seadistamisel kõvasti tööd tegema. Kuid lihtsalt pinu keskkonnas juurutamine ja seal testimine osutub uskumatult odavaks. Ja te ei pea oma pilvekeskkondadest täpset kohalikku koopiat tegema.
Kasutage AWS-i lambdakihte, et vähendada juurutatud pakettide suurust ja kiirendada laadimisaegu.
Kasutage konkreetsete ülesannete jaoks õigeid programmeerimiskeeli. Erinevatel keeltel on oma eelised ja puudused. Võrdlusaluseid on palju, kuid JavaScript, Python ja C# (.NET Core 2.1+) on AWS Lambda jõudluse osas liidrid. AWS Lambda tutvustas hiljuti Runtime API-t, mis võimaldab teil määrata soovitud keele ja käituskeskkonna, seega katsetage.
Hoidke juurutuspaketi suurused väikesed. Mida väiksemad need on, seda kiiremini laaditakse. Vältige suurte teekide kasutamist, eriti kui kasutate neist paari funktsiooni. Kui programmeerite JavaScriptis, kasutage ehitustööriistu, nagu Webpack, et optimeerida oma ehitust ja kaasata ainult seda, mida tegelikult vajate. .NET Core 3.0 sisaldab QuickJiti ja Tiered Compilationi, mis parandavad jõudlust ja aitavad oluliselt külmkäivituse korral.
Serverita funktsioonide sõltuvus sündmustest võib alguses raskendada äriloogika koordineerimist. Sõnumijärjekorrad ja olekumasinad võivad selles osas olla väga kasulikud. Lambda funktsioonid võivad üksteisele helistada, kuid tehke seda ainult siis, kui te ei oota vastust ("tulista ja unusta") – te ei soovi saada arvet teise funktsiooni täitmise ootamise eest. Sõnumijärjekorrad on kasulikud äriloogika osade eraldamiseks, rakenduste kitsaskohtade haldamiseks ja tehingute töötlemiseks (FIFO järjekordade abil). AWS Lambda funktsioone saab määrata SQS-i järjekordadele kinnijäänud sõnumijärjekordadena, mis jälgivad ebaõnnestunud sõnumeid hilisemaks analüüsiks. AWS-i sammufunktsioonid (olekumasinad) on väga kasulikud keerukate protsesside haldamiseks, mis nõuavad funktsioonide aheldamist. Selle asemel, et Lambda funktsioon kutsuks mõnda teist funktsiooni, saavad sammufunktsioonid koordineerida olekute üleminekuid, edastada andmeid funktsioonide vahel ja hallata funktsioonide globaalset olekut. See võimaldab määratleda uuesti proovimise tingimusi või seda, mida teha konkreetse vea ilmnemisel – see on teatud tingimustel väga võimas tööriist.
Järeldus
Viimastel aastatel on serverita tehnoloogiad arenenud enneolematu kiirusega. Selle paradigma muutusega on seotud teatud väärarusaamad. Taristu abstraheerimise ja skaleeritavuse haldamise kaudu pakuvad serverita lahendused märkimisväärset kasu alates lihtsustatud arendusest ja DevOpsi protsessidest kuni tegevuskulude suure vähenemiseni.
Kuigi serverita lähenemisel pole ka puudusi, on olemas usaldusväärsed disainimustrid, mida saab kasutada tugevate serverita rakenduste loomiseks või serverita elementide integreerimiseks olemasolevatesse arhitektuuridesse.
Allikas: www.habr.com