Nõuanded ja teabeallikad serverivabade rakenduste loomiseks

Kuigi serverita tehnoloogiad on viimastel aastatel kiiresti populaarsust kogunud, on nendega seotud endiselt palju müüte ja muresid. Muidugi räägitakse serverivabadest tehnoloogiatest, kui teemad nagu sõltuvus tarnijast, tööriistakast, kuluhaldus, külm käivitus, jälgimine ja arendusprotsessi elutsükkel. Selles artiklis käsitleme mõningaid selliseid teemasid ning jagame näpunäiteid ja linke kasulikele allikatele, mis aitavad algajatel luua võimsaid, paindlikke ja kulutõhusaid serverita rakendusi.

Müüdid serverita tehnoloogiate kohta

Paljud arvavad, et serveritus ja serveriväline andmetöötlus (Functions as a Service, FaaS) on peaaegu sama asi. Tundub, et erinevus ei ole liiga suur ja see tasub end ära. Kuigi AWS Lambda on olnud üks serverita tehnoloogiate tõusu 'tähtedest' ja üks populaarsemaid komponente serverita arhitektuuris, esindab see arhitektuur siiski midagi enamat kui FaaS.

Serverita tehnoloogiate põhimõte seisneb selles, et te ei pea muretsema infrastruktuuri haldamise ja skaleerimise pärast, maksate vaid selle eest, mida kasutate. Sellistele kriteeriumidele vastab palju teenuseid - AWS DynamoDB, S3, SNS või SQS, Graphcool, Auth0, Now, Netlify, Firebase ja paljud teised. Üldiselt tähendab serveritus kõikide pilvandmetöötluse võimaluste kasutamist ilma infrastruktuuri haldamise ja selle optimeerimise vajaduseta skaleerimise nimel. See tähendab ka, et infrastruktuuri tasemel turvalisus ei ole enam teie probleem, mis on tohutu eelis, arvestades turvastandardite järgimise raskusi ja keerukust. Lõpuks ei pea te ostma teile kasutamiseks pakutavat infrastruktuuri.

Serveritust võib pidada 'meeleoluks': teatud mõtteviisiks lahenduste kavandamisel. Vältige lähenemisviise, mis nõuavad infrastruktuuri hooldamist. Serverita lähenemisviisi puhul investeerime aega ülesannete lahendamisse, mis mõjutavad otseselt projekti ja toovad kasu meie kasutajatele: loome jätkusuutlikku äri loogikat, arendame kasutajaliidesi ja töötame välja kohandatavaid ning usaldusväärseid API-sid.

Näiteks, kui on võimalik vältida avatud tekstipõhise otsinguplatvormi haldamist ja hooldamist, siis just nii me tegutseme. Selline rakenduste kokkupanemise lähenemine võib oluliselt kiirendada toote turule toomist, kuna te ei pea enam muretsema keeruka infrastruktuuri haldamise pärast. Vabanege infrastruktuuri haldamise kohustustest ja kuludest ning keskenduge rakenduste ja teenuste loomisele, mis on teie klientide jaoks vajalikud. Patrick Debua nimetas sellist lähenemist 'servicefull', see termin on aktsepteeritud serverita kogukonnas. Funktsioone tuleks käsitleda kui siduvaid elemente teenuste, mis on disainitud kui juurutatavad moodulid (mitte kogu teegi või veebirakenduse juurutamine). See tagab hämmastava juurutamise ja muudatuste haldamise granulaarsuse. Kui te ei saa funktsioone selliselt juurutada, võib see viidata sellele, et funktsioonid teevad liiga palju ülesandeid ja need tuleks refaktoreerida.

Mõned inimesed on segaduses tarnijast sõltuvuse pärast pilvandmetöötluse rakenduste arendamisel. Sama kehtib serverita tehnoloogiate kohta, ja see ei tundu olevat müüt. Meie kogemuse kohaselt on serverita rakenduste loomine AWS-is koos AWS Lambda võimekusega ühendada teisi AWS teenuseid - kõik see osalt loob serverita arhitektuuride voorused. See on hea näide sünergiast, kus tulemuse kogusumma on suurem kui lihtsalt komponentide summa. Kui üritate vältida sõltuvust tarnijast, võite silmitsi seista veelgi suuremate probleemidega. Mahutitega töötades on lihtsam hallata oma abstraktsioonitaset pilvandmeteenuste pakkujate vahel. Kuid serverita lahenduste puhul ei tasu pingutused end ära, eriti kui arvestada majanduslikku efektiivsust algusest peale. Uurige kindlasti, kuidas tarnijad teenuseid osutavad. mõned spetsialiseerunud teenused sõltuvad integratsioonipunktidest teiste tarnijatega ja võivad vaikimisi pakkuda plug-and-play stiilis ühendamise võimalust. Lambda kutsumise tagamine API värava lõpp-punktist on lihtsam kui mõne konteineri või EC2 instantsi kaudu päringu suunamine. Graphcool pakub lihtsat konfigureerimist koos Auth0-ga, mis on lihtsam kui kasutada kolmandate osapoolte autentimisvahendeid.

Õige teenusepakkuja valimine teie serverivaba rakenduse jaoks on arhitektuuri taseme otsus. Rakendust luues ei arvestata, et kunagi naased hallatavatele serveritele. Pilveteenuse pakkuja valimine ei erine konteinerite või andmebaaside kasutamise valimisest ega ka programmeerimiskeele valimisest.

Mõelge:

• Milliseid teenuseid vajate ja miks.
• Milliseid teenuseid pakuvad pilveteenuse pakkujad ja kuidas saate neid kombineerida valitud FaaS-lahendusega.
• Milliseid programmeerimiskeeli toetatakse (kas dünaamilise või staatilise tüübistamisega, kompileeritavad või tõlgitavad, millised on jõudluse piirangud, mis on külma käivituse puhul, milline on avatud lähtekoodiga ökosüsteem jne).
• Millised on teie turvanõuded (SLA, 2FA, OAuth, HTTPS, SSL jne).
• Kuidas hallata teie CI/CD ja tarkvaraarenduse tsükleid.
• Milliseid infrastruktuuri kui koodi lahendusi saate kasutada.

Kui laiendate olemasolevat rakendust ja lisate järk-järgult serverivabu funktsioone, võivad need piirata saadaolevaid võimalusi. Siiski pakuvad peaaegu kõik serverivabad tehnoloogiad mingeid API-sid (RESTi või sõnumijõu kaudu), mis võimaldavad laiendusi luua rakenduse tuumast sõltumatult ja kergesti integreerida. Otsige teenuseid, millel on selged API-d, hea dokumentatsioon ja tugev kogukond, ja te ei eksi. Integreerimise lihtsus võib olla sageli võtme mõõdik, ja see on tõenäoliselt üks peamisi põhjusi, miks AWS on alates 2015. aastast Lambda turule tulnud.

Kuna serverivabadus on kasulik

Serverivabasid tehnoloogiaid saab rakendada praktiliselt igas valdkonnas. Kuid nende eelised ei piirdu vaid rakendusaladega. Tänapäeval on pilvandmetöötluse sisenemiskünnis nii madal just serverivabade tehnoloogiate tõttu. Kui arendajatel on idee, kuid nad ei tea, kuidas pilveinfrastruktuuri hallata ja kulusid optimeerida, ei pea nad selleks inseneri otsima. Kui idufirma soovib luua platvormi, kuid kardab, et kulud võivad minna kontrolli alt välja, saavad nad hõlpsasti kasutada serverivabu lahendusi.

Kulude kokkuhoiu ja lihtsa skaleeritavuse tõttu on serverivabad lahendused võrdselt rakendatavad nii sise- kui ka välistesüsteemides, sealhulgas veebirakendustes, millel on miljoneid kasutajaid. Arved ei mõõdeta pigem eurodes, vaid sentides. Kõige lihtsama AWS EC2 (t1.micro) instantsi rentimise hind kuu jooksul on €15, isegi kui te seda ei kasuta (kes pole kunagi unustanud seda välja lülitada?!). Võrdluseks, et saavutada sellisel tasemel kulusid sama aja jooksul, peate käivitama Lambda suurusega 512 MB umbes 3 miljonit korda ühe sekundi jooksul. Ja kui te seda funktsiooni ei kasuta, siis te ei maksa midagi.

Kuna serverivabad tehnoloogiad sõltuvad peamiselt sündmustest, saab serverivaba infrastruktuuri suhteliselt hõlpsasti vanadesse süsteemidesse lisada. Näiteks saate AWS S3, Lambda ja Kinesis abil luua analüütikateenuse vanale jaemüügisüsteemile, mis suudab andmeid API kaudu hankida.

Enamik serverivabu platvorme toetab erinevaid programmeerimiskeeli. Kõige sagedamini on need Python, JavaScript, C#, Java ja Go. Üldiselt ei ole kõikide keelte puhul mingeid piiranguid teekide kasutamiseks, seega võite kasutada oma lemmikuid avatud lähtekoodiga teeke. Kuid on soovitatav mitte liialdada sõltuvustega, et teie funktsioonid töötaksid optimaalselt ja ei kaotaks teie serverivabade rakenduste hiiglasliku skaleeritavuse eeliseid. Mida rohkem pakette on vaja konteinerisse laadida, seda kauem kulub külma käivituse ajaks.

Külm käivitamine on siis, kui tuleb kõigepealt initsialiseerida konteiner, täitmisvahemik ja vigade töötleja enne nende kasutamist. Seetõttu võib funktsioonide töökatkestus kesta kuni 3 sekundit, mis pole parim variant kärsitutele kasutajatele. Külmad käivitamised toimuvad sageli esmakordsel taotlemisel pärast mõnda minutist pausifunktsiooni. Nii et paljud inimesed peavad seda tühiseks ebamugavuseks, mida saab vältida regulaarsete funktsioonide pinge kaudu, et hoida neid nagu mootori tühikäigul. Või ignoreerivad nad seda aspekti täiesti.

Kuigi AWS on välja andnud serverivaba SQL-andmebaasi Serverless Aurora, kuid SQL-andmebaasid ei sobi selliseks kasutamiseks hästi, kuna tehingute tegemine sõltub ühendustest, mis võivad suure liikluse korral AWS Lambdal kiiresti kitsaskohaks muutuda. Jah, arendajad parendavad pidevalt Serverless Aurora't, ja tasub seda proovida, kuid täna sobivad serverivabad süsteemid palju paremini NoSQL-lahendustele nagu DynamoDB. Siiski on selge, et see olukord muutub peagi.

Tööriistade osas on samuti mitmeid piiranguid, eriti kohaliku testimise vallas. Kuigi on olemas lahendusi nagu Docker-Lambda, DynamoDB Local ja LocalStack, nõuavad need siiski palju tööd ja märkimisväärset seadistamist. Kuid kõik need projektid arenevad aktiivselt, seega on lihtsalt ajaküsimus, millal tööriistade tase ulatub vajalikule tasemele.

Serverivabade tehnoloogiate mõju arendusprotsessile

Kuna teie infrastruktuur on lihtsalt konfiguratsioon, on võimalik koodi seadistada ja käitada skriptide, näiteks shell-skriptide abil. Või võite kasutada konfiguratsioonina koodi lahendusi nagu AWS CloudFormation. Kuigi see teenus ei paku konfiguratsiooni kõigis valdkondades, võimaldab see siiski määrata konkreetsed ressursid, mida kasutada Lambda-funktsioonidena. See tähendab, et seal, kus CloudFormation teid petab, saate kirjutada oma ressursi (Lambda-funktsiooni), mis katab selle puudujäägi. Seega saate teha peaaegu kõike, sealhulgas konfigureerida sõltuvusi väljaspool oma AWS-ümbrust.

Kuna see on kõik lihtsalt konfiguratsioon, saate parametriseerida oma juurutusskriptid konkreetsete keskkondade, piirkondade ja kasutajate järgi, eriti kui kasutate infrastruktuuridena koodi lahendusi nagu CloudFormation. Näiteks saate juurutada iga haru jaoks, et täielikult isoleeritud need arenduse käigus testida. See kiirendab radikaalselt tagasiside saamist arendajatelt, kui nad soovivad mõista, kas nende kood töötab elukeskkonnas adekvaatselt. Juhtidel ei pea olema muret selle üle, kui palju erinevate keskkondade juurutamine maksab, kuna tasustatakse ainult tegelikku kasutamist.

DevOps-il on vähem muresid, kuna nad peavad vaid veenduma, et arendajatel on õige konfiguratsioon. Enam ei pea haldama instantsse, tasakaalustajaid või turbegruppe. Seetõttu kasutatakse üha sagedamini mõistet NoOps, kuigi on endiselt oluline osata konfigureerida infrastruktuuri, eriti kui on juttu IAM-konfiguratsioonist ja pilveteenuste optimeerimisest.

On väga võimsaid tööriistu jälgimiseks ja visualiseerimiseks, nagu Epsagon, Thundra, Dashbird ja IOPipe. Need võimaldavad jälgida serverivabade rakenduste hetkeseisu, pakuvad logisid ja jälgimist, registreerivad jõudlusnäitajaid ja arhitektuuri kitsaskohti, teevad kulude analüüsi ja prognoositavust ning palju muud. Need mitte ainult ei anna DevOps-inseneridele, arendajatele ja arhitektidele põhjalikku ülevaadet rakenduste tööst, vaid võimaldavad ka juhtidel jälgida olukorda reaalajas, sekundisi kulude ressursside ja kulude prognoosimisega. Sellise süsteemi haldamine on hallatavast infrastruktuurist oluliselt keerulisem.

Serverivabade rakenduste projekteerimine on oluliselt lihtsam, kuna teil ei ole vaja juurutada veebiservereid, hallata virtuaalmasinaid või konteinerite, patcheerida servereid, operatsioonisüsteeme, interneti väravaid jne. Kõigist neist kohustustest abstraheerimine võimaldab serverivabal arhitektuuril keskenduda peamisele — ettevõtte ja klientide vajaduste rahuldamisele.

Kuigi tööriistad võivad olla paremad (need paranevad iga päev), saavad arendajad keskenduda äri loogika rakendamisele ja rakenduse keerukuse optimaalsetele jaotustele erinevate teenuste vahel kogu arhitektuuri ulatuses. Serverivabade rakenduste haldamine põhineb sündmustel ja on pilveteenuse pakkuja poolt abstraktne (nt SQS, S3 sündmused või DynamoDB vood). Seega peavad arendajad lihtsalt kirjutama äri loogika kindlatele sündmustele reageerimiseks ja nad ei pea muretsema selle üle, kuidas parimal viisil andmebaase ja sõnumijärjekordi teostada, ega selle üle, kuidas korraldada optimaalset andmetöötlust konkreetsetes riistvarahoidlates.

Koodi saab kohapeal käivitada ja siluda, nagu iga arendusprotsessi puhul. Moodulitestimine jääb samaks. Rakenduse infrastruktuuri täieliku juurutamise võimalus konfigureeritava tehnoloogia abil võimaldab arendajatel kiiresti olulist tagasisidet saada, mõtlemata testimise kuludele või kallite haldusalade mõjule.

Bessarveliste rakenduste koostamise tööriistad ja meetodid

Bessarveliste rakenduste koostamiseks ei ole kindlat meetodit. Nagu ka teenuste kogumit selle ülesande jaoks. Täna on AWS juhtiv jõud tugevate bessarveliste lahenduste seas, kuid tasub tähele panna ka Google Cloud, Zeit ja Firebase. Kui kasutate AWS-i, siis võib rakenduste koostamiseks soovitada Serverless Application Model (SAM), eriti C#-iga, kuna Visual Studio pakub suurepäraseid tööriistu. SAM CLI suudab teha kõike seda, mida ka Visual Studio, seega ei kaota te midagi, kui lähete teise IDE või tekstiredaktori juurde. Loomulikult töötab SAM ka teiste keeltest.

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-failide abil. Samuti toetab Serverless Framework erinevaid pilveteenuseid, seega soovitame seda neile, kes otsivad mitme pilve lahendust. Sellel on suur kogukond, kes on loonud palju pluginaid igasuguste vajaduste jaoks.

Kohapealseks testimiseks sobivad suurepäraselt avatud lähtekoodiga tööriistad nagu Docker-Lambda, Serverless Local, DynamoDB Local ja LocalStack. Bessarvelised tehnoloogiad on endiselt arengu algstaadiumis, nagu ka nendele mõeldud tööriistade komplekt, seega võib keeruliste testimistsenaariumide seadistamine olla väljakutse. Kuid steki juurutamine keskkonnas ja seal testimine osutub uskumatult odavaks. Ja te ei vaja täpset kohapealset koopiat pilvesüsteemidest.

Juhtige arendatud pakettide suurust ja kiirendage laadimist, kasutades AWS Lambda Layers.

Kasutage konkreetsete ülesannete jaoks õigeid programmeerimiskeeli. Erinevatel keeladel on omad eelised ja puudused. Palju on benchamrke, kuid JavaScript, Python ja C# (.NET Core 2.1+) on AWS Lambda jõudluse osas liidrid. Hiljuti ilmus AWS Lambda-s Runtime API, mis võimaldab määrata soovitud keele ja keskkonna, seega katsetage.

Hoia juurutamiseks paketid väiksed. Mida väiksemad nad on, seda kiiremini laaditakse. Vältige suurte teekide kasutamist, eriti kui kasutate neist ainult mõnda funktsiooni. Kui programmeerite JavaScriptis, siis kasutage koostamisvahendeid nagu Webpack, et optimeerida koostamist ja lisada ainult seda, mis tõeliselt vajalik on. .NET Core 3.0-l on QuickJit ja Tiered Compilation, mis parendavad jõudlust ja aitavad väga hästi külmade käivituste korral.

Bessarveliste funktsioonide sõltuvus sündmustest võib alguses keerukaks muuta äriloogika koordineerimist. Seetõttu võivad sõnumijärjekorrad ja lõppautomaatide süsteemid olla äärmiselt kasulikud. Lambda funktsioonid saavad üksteist kutsuda, kuid tehke seda ainult juhul, kui te ei oota vastust ("laskisid ja unustasid") — ei tasu maksta selle eest, et oodata teise funktsiooni lõppu. Sõnumijärjekorrad on kasulikud äriloogika osade isoleerimiseks, rakenduse kitsaste kohtade haldamiseks ja tehingute töötlemiseks (FIFO järjekordade kaudu). AWS Lambda funktsioonid võivad olla seotud SQS järjekordadega kui "seiskunud" sõnumite järjekordadega, mis jälgivad ebaõnnestunud sõnumeid edasise analüüsi jaoks. AWS Step Functions (lõppautomaatide süsteemid) on väga kasulikud keeruliste protsesside haldamiseks, mis vajavad funktsioonide ketide loomist. Selle asemel, et Lambda funktsioon kutsuks teise funktsiooni, saavad Step-funktsioonid koordineerida olekute üleminekuid, edastada andmeid funktsioonide vahel ja juhtida funktsioonide globaalset olekut. See võimaldab määrata ümberkatsete tingimusi või mida teha, kui esineb konkreetne viga — teatud tingimustes on see väga võimas tööriist.

Kokkuvõte

Viimastel aastatel on bessarvelised tehnoloogiad arenenud enneolematult kiiresti. Sellise paradigmapöördega on seotud teatud väärarusaamad. Tänu infrastruktuuri ja skaleerimise haldamise abstraktsioonile pakuvad bessarvelised lahendused märkimisväärseid eeliseid: alates arendamise ja DevOpsi protsesside lihtsustamisest kuni suuremate opereerimiskulude vähendamiseni.
Kuigi serveriteta lähenemisel on puudusi, on olemas usaldusväärsed disainimustrid, millega saab luua vastupidavaid serveriteta rakendusi või integreerida serveriteta komponente olemasolevatesse arhitektuuridesse.

Allikas: habr.com