Þrátt fyrir að netþjónalaus tækni hafi náð miklum vinsældum á undanförnum árum, þá eru enn margar ranghugmyndir og áhyggjur tengdar þeim. Háð söluaðila, verkfæri, kostnaðarstjórnun, kaldræsing, eftirlit og þróunarlífsferill eru öll harðneskjuleg umræðuefni þegar kemur að netþjónalausri tækni. Í þessari grein munum við kanna sum efnin sem nefnd eru, auk þess að deila ábendingum og tenglum á gagnleg úrræði til að hjálpa byrjendum að byggja upp öflug, sveigjanleg og hagkvæm netþjónalaus forrit.
Ranghugmyndir um netþjónalausa tækni
Margir telja að netþjónalaus og netþjónalaus gagnavinnsla (, FaaS) eru nánast það sama. Þetta þýðir að munurinn er ekki of mikill og þess virði að kynna nýja vöru. Þrátt fyrir að AWS Lambda hafi verið ein af stjörnunum í uppgangi netþjónalausrar tækni og einn vinsælasti þátturinn í netþjónalausum arkitektúr, þá er meira til í þessum arkitektúr en FaaS.
Kjarnareglan um netþjónalaust er að þú þarft ekki að hafa áhyggjur af því að stjórna eða stækka innviði þína; þú borgar aðeins fyrir það sem þú notar. Margar þjónustur passa við þessi skilyrði - AWS DynamoDB, S3, SNS eða SQS, Graphcool, Auth0, Now, Netlify, Firebase og margir aðrir. Almennt séð þýðir netþjónalaust að nota alla getu tölvuskýja án þess að þurfa að stjórna og fínstilla innviðina í þágu skala. Það þýðir líka að öryggi á innviðastigi er ekki lengur vandamál þitt, sem er gríðarlegur ávinningur í ljósi þess hve erfitt og flókið það er að uppfylla öryggisstaðla. Að lokum þarftu ekki að kaupa innviðina sem þér er veittur.
Miðlaralaust getur talist „hugsunarástand“: ákveðið hugarfar við hönnun lausna. Forðastu aðferðir sem krefjast viðhalds hvers kyns innviða. Með netþjónalausri nálgun eyðum við tíma í að leysa vandamál sem hafa bein áhrif á verkefnið og færa notendum okkar gildi: búa til öfluga viðskiptarökfræði, þróa notendaviðmót og þróa móttækileg og áreiðanleg API.
Til dæmis, ef það er hægt að forðast að stjórna og viðhalda frjálsum textaleitarvettvangi, þá er það það sem við munum gera. Þessi nálgun við að byggja upp forrit getur hraðað verulega tíma til markaðssetningar vegna þess að þú þarft ekki lengur að hugsa um að stjórna flóknum innviðum. Losaðu þig undan ábyrgð og kostnaði við innviðastjórnun og einbeittu þér að því að byggja upp þau forrit og þjónustu sem viðskiptavinir þínir þurfa. Patrick Debois kallaði þessa nálgun , þetta hugtak er samþykkt í netþjónalausu samfélaginu. Líta ætti á aðgerðir sem límið sem bindur þjónustu saman sem dreifanlegar einingar (frekar en að setja upp heilt bókasafn eða vefforrit). Þetta veitir ótrúlega nákvæmni til að stjórna uppsetningu og breytingum á forritinu. Ef þú getur ekki dreift aðgerðum á þennan hátt gæti það bent til þess að aðgerðirnar séu að gera of marga hluti og þurfi að endurskoða þær.
Sumir eru ruglaðir vegna háð söluaðila þegar þeir þróa skýjaforrit. Það sama á við um netþjónalausa tækni og ólíklegt er að þetta sé afleiðing misskilnings. Reynsla okkar er að smíða netþjónalaus forrit á AWS, ásamt getu AWS Lambda til að safna saman öðrum AWS þjónustu, er hluti af því sem gerir netþjónalausan arkitektúr svo frábæran. Þetta er gott dæmi um samvirkni þegar árangur samsetningar er meiri en bara summan af hlutum hennar. Að reyna að forðast lokun söluaðila getur leitt til enn meiri vandamála. Þegar unnið er með gáma er auðveldara að stjórna þínu eigin abstraktlagi á milli skýjaveitenda. En þegar kemur að netþjónalausum lausnum mun fyrirhöfnin ekki borga sig, sérstaklega ef þú íhugar hagkvæmni frá upphafi. Vertu viss um að komast að því hvernig söluaðilar veita þjónustu. Sum sérhæfð þjónusta treystir á samþættingarpunkta við aðra söluaðila og gæti veitt „plug-and-play“ tengingu beint úr kassanum. Það er auðveldara að veita Lambda-símtal frá API-endapunkti gáttar heldur en að senda beiðnina umboð til einhvers gáms eða EC2-tilviks. Graphcool gerir kleift að stilla auðveldlega með Auth0, sem er auðveldara en að nota þriðja aðila auðkenningarverkfæri.
Að velja réttan söluaðila fyrir netþjónalausa forritið þitt er ákvörðun á byggingarstigi. Þegar þú býrð til forrit, býst þú ekki við að fara aftur að stjórna netþjónum einn daginn. Að velja skýjasöluaðila er ekkert öðruvísi en að velja að nota gáma eða gagnagrunn, eða jafnvel forritunarmál.
Hugleiddu:
- Hvaða þjónustu þarftu og hvers vegna.
- Hvaða þjónustu veita skýjaveitur og hvernig þú getur sameinað hana með því að nota FaaS lausnina sem þú valdir.
- Hvaða forritunarmál eru studd (virkt eða kyrrstætt slegið, sett saman eða túlkað, hver eru viðmiðin, hver er frammistaða kaldræsingar, hvað er vistkerfi opinn uppspretta osfrv.).
- Hverjar eru öryggiskröfur þínar (SLA, 2FA, OAuth, HTTPS, SSL osfrv.).
- Hvernig á að stjórna CI/CD og hugbúnaðarþróunarferlum.
- Hvaða innviði-sem-kóða lausnir geturðu nýtt þér?
Ef þú ert að stækka núverandi forrit og bæta við netþjónslausum aðgerðum smám saman, gæti það takmarkað tiltæka möguleika að einhverju leyti. Hins vegar veitir næstum öll netþjónalaus tækni einhvers konar API (með REST eða skilaboða biðröð) sem gerir þér kleift að búa til viðbætur óháð forritskjarna og með auðveldri samþættingu. Leitaðu að þjónustu með skýrum API, góðum skjölum og sterku samfélagi og þú getur ekki farið úrskeiðis. Auðveld samþætting getur oft verið lykilmælikvarði og er líklega ein helsta ástæða þess að AWS hefur gengið vel síðan Lambda kom út árið 2015.
Hvenær er netþjónalaust gagnlegt?
Hægt er að nota netþjónalausa tækni nánast hvar sem er. Hins vegar eru kostir þeirra ekki takmarkaðir við aðeins notkunaraðferðirnar. Aðgangshindrun fyrir tölvuský er svo lítil í dag einmitt vegna netþjónalausrar tækni. Ef verktaki hefur hugmynd, en þeir vita ekki hvernig á að stjórna skýjainnviðum og hagræða kostnaði, þá þurfa þeir ekki að leita að einhverjum verkfræðingi til að gera það. Ef sprotafyrirtæki vill byggja upp vettvang en hefur áhyggjur af því að kostnaður gæti farið úr böndunum, geta þeir auðveldlega snúið sér að netþjónalausum lausnum.
Þökk sé kostnaðarsparnaði og auðveldri stærðarstærð eiga netþjónalausar lausnir jafnt við bæði innri og ytri kerfi, allt upp í vefforrit með margra milljóna dollara áhorfendur. Reikningar eru mældir í sentum frekar en evrum. Að leigja einfaldasta AWS EC2 dæmið (t1.micro) í mánuð mun kosta 15 evrur, jafnvel þótt þú gerir ekkert með það (hver hefur einhvern tíma gleymt að slökkva á því?!). Til samanburðar, til að ná þessu eyðslustigi á sama tíma, þyrftir þú að keyra 512 MB Lambda í 1 sekúndu um það bil 3 milljón sinnum. Og ef þú notar ekki þennan eiginleika borgarðu ekki neitt.
Þar sem netþjónalaust er fyrst og fremst atburðadrifið er frekar auðvelt að bæta netþjónslausum innviðum við eldri kerfi. Til dæmis, með því að nota AWS S3, Lambda og Kinesis, geturðu búið til greiningarþjónustu fyrir eldra smásölukerfi sem getur tekið á móti gögnum í gegnum API.
Flestir netþjónalausir pallar styðja mörg tungumál. Oftast eru þetta Python, JavaScript, C#, Java og Go. Venjulega hafa öll tungumál engar takmarkanir á notkun bókasöfnum, svo þú getur notað uppáhalds opinn uppspretta bókasöfnin þín. Hins vegar er ráðlegt að ofnota ekki ósjálfstæði svo að aðgerðir þínar virki sem best og ógildi ekki ávinninginn af gífurlegum sveigjanleika netþjónalausu forritanna þinna. Því fleiri pakkningar sem þarf að hlaða í gáminn, því lengri tíma tekur kaldræsingin.
Köld byrjun er þegar þú þarft fyrst að frumstilla ílátið, keyrslutímann og villustjórnun áður en þú notar þá. Vegna þessa getur seinkunin á framkvæmd aðgerða verið allt að 3 sekúndur og þetta er ekki besti kosturinn fyrir óþolinmóða notendur. Hins vegar koma kaldræsingar í fyrsta símtalinu eftir nokkrar mínútur af aðgerðalausu. Svo margir telja þetta minniháttar óþægindi sem hægt er að vinna úr með því að smella reglulega á aðgerðina til að halda henni í aðgerðalausri stöðu. Eða þeir hunsa þennan þátt með öllu.
Þó að AWS hafi gefið útHins vegar eru SQL gagnagrunnar ekki tilvalin fyrir þessa tegund notkunar vegna þess að þeir treysta á tengingar til að framkvæma viðskipti, sem geta fljótt orðið flöskuháls þegar mikil umferð er á AWS Lambda. Já, forritarar eru stöðugt að bæta Serverless Aurora, og þú ættir að gera tilraunir með það, en í dag NoSQL lausnir eins og. Hins vegar er enginn vafi á því að þetta ástand mun breytast mjög fljótlega.
Verkfærakistan setur einnig margar takmarkanir, sérstaklega á sviði staðbundinna prófana. Þó að það séu til lausnir eins og Docker-Lambda, DynamoDB Local og LocalStack, krefjast þær vandaðrar vinnu og umtalsverðrar stillingar. Hins vegar eru öll þessi verkefni í virkri þróun og því er aðeins tímaspursmál hvenær tækin ná því marki sem við þurfum.
Áhrif netþjónalausrar tækni á þróunarferilinn
Þar sem innviðir þínir eru einfaldlega stillingar geturðu skilgreint og dreift kóða með því að nota forskriftir, eins og skeljaforskriftir. Eða þú getur gripið til stillingar-sem-kóða flokkslausna eins og . Þrátt fyrir að þessi þjónusta veiti ekki uppsetningu fyrir öll svæði gerir hún þér kleift að skilgreina tiltekin úrræði til notkunar sem Lambda-aðgerðir. Það er að segja, þar sem CloudFormation bregst þér geturðu skrifað þína eigin auðlind (Lambda aðgerð) sem mun loka þessu bili. Þannig geturðu gert hvað sem er, jafnvel stillt ósjálfstæði utan AWS umhverfisins þíns.
Vegna þess að þetta er allt bara uppsetning geturðu stillt uppsetningarforskriftirnar þínar fyrir tiltekið umhverfi, svæði og notendur, sérstaklega ef þú ert að nota innviða-sem-kóða lausnir eins og CloudFormation. Til dæmis geturðu sett afrit af innviðum fyrir hverja útibú í geymslunni svo þú getir prófað þá alveg í einangrun meðan á þróun stendur. Þetta flýtir verulega fyrir þeim tíma sem þróunaraðilar fá endurgjöf þegar þeir vilja skilja hvort kóðinn þeirra virki nægilega vel í lifandi umhverfi. Stjórnendur þurfa ekki að hafa áhyggjur af kostnaði við að dreifa mörgum umhverfi vegna þess að þeir greiða aðeins fyrir raunverulega notkun.
DevOps hafa minna að hafa áhyggjur af þar sem þeir þurfa aðeins að ganga úr skugga um að forritarar hafi réttar stillingar. Ekki lengur að stjórna tilvikum, jafnvægismönnum eða öryggishópum. Þess vegna er hugtakið NoOps notað í auknum mæli þó enn sé mikilvægt að geta stillt innviðina, sérstaklega þegar kemur að IAM stillingum og hagræðingu á skýjaauðlindum.
Það eru mjög öflug vöktunar- og sýnileikaverkfæri eins og Epsagon, Thundra, Dashbird og IOPipe. Þeir gera þér kleift að fylgjast með núverandi ástandi netþjónalausra forrita, útvega annála og rekja, fanga árangursmælingar og byggingarflöskuhálsa, framkvæma kostnaðargreiningu og spá og margt fleira. Þeir gefa DevOps verkfræðingum, þróunaraðilum og arkitektum ekki aðeins yfirgripsmikla sýn á frammistöðu forrita, heldur gera þeir stjórnendum einnig kleift að öðlast sýnileika í rauntíma auðlindaeyðslu og kostnaðarspá sekúndu fyrir sekúndu. Það er miklu erfiðara að skipuleggja þetta með stýrðum innviðum.
Það er miklu auðveldara að hanna netþjónalaus forrit vegna þess að þú þarft ekki að dreifa vefþjónum, stjórna sýndarvélum eða gámum, plástraþjónum, stýrikerfum, internetgáttum o.s.frv. Að draga úr öllum þessum skyldum gerir netþjónalausum arkitektúr kleift að einbeita sér að því sem skiptir mestu máli: lausnina þarfir fyrirtækja og viðskiptavina.
Þó að verkfærin gætu verið betri (það batnar með hverjum deginum), geta forritarar einbeitt sér að því að innleiða viðskiptarökfræði og hvernig best sé að dreifa flóknu forritinu yfir mismunandi þjónustu innan arkitektúrsins. Netþjónalaus forritastjórnun er viðburðabundin og tekin af skýjaveitunni (til dæmis SQS, S3 viðburðir eða DynamoDB straumar). Þess vegna þurfa forritarar aðeins að skrifa viðskiptarökfræði til að bregðast við ákveðnum atburðum og þurfa ekki að hafa áhyggjur af því hvernig best sé að útfæra gagnagrunna og skilaboðabiðraðir eða hvernig best sé að vinna með gögn í tilteknum vélbúnaðargeymslum.
Hægt er að keyra kóða og villuleita á staðnum, eins og með hvaða þróunarferli sem er. Einingaprófun er óbreytt. Hæfni til að dreifa heilu forritainnviði með því að nota sérsniðna staflastillingu gerir forriturum kleift að fá fljótt mikilvæg endurgjöf án þess að hafa áhyggjur af kostnaði við prófun eða áhrifum á dýrt stýrt umhverfi.
Verkfæri og tækni til að byggja upp netþjónalaus forrit
Það er engin sérstök leið til að smíða netþjónalaus forrit. Sem og safn af þjónustu fyrir þetta verkefni. Leiðtogi öflugra netþjónalausra lausna í dag er AWS, en gaum að , и . Ef þú ert að nota AWS, þá getum við mælt með því sem aðferð til að safna forritum (SAM), sérstaklega þegar þú notar C#, vegna þess að Visual Studio hefur frábær verkfæri. SAM CLI getur gert allt sem Visual Studio getur gert, þannig að þú tapar engu ef þú skiptir yfir í annan IDE eða textaritil. Auðvitað virkar SAM með öðrum tungumálum líka.
Ef þú skrifar á öðrum tungumálum er Serverless Framework frábært opinn uppspretta tól sem gerir þér kleift að stilla hvað sem er með mjög öflugum YAML stillingarskrám. Serverless Framework styður einnig ýmsa skýjaþjónustu og því mælum við með henni fyrir þá sem eru að leita að multi-ský lausn. Það hefur risastórt samfélag sem hefur búið til fullt af viðbótum fyrir allar þarfir.
Fyrir staðbundnar prófanir henta opinn hugbúnaður Docker-Lambda, Serverless Local, DynamoDB Local og LocalStack vel. Serverlaus tækni er enn á frumstigi þróunar, eins og verkfærin fyrir hana, svo þú verður að vinna hörðum höndum þegar þú setur upp flóknar prófunaraðstæður. Hins vegar reynist það ótrúlega ódýrt að dreifa staflanum einfaldlega í umhverfinu og prófa hann þar. Og þú þarft ekki að búa til nákvæma staðbundna afrit af skýjaumhverfinu þínu.
Notaðu AWS Lambda Layers til að draga úr dreifðum pakkastærðum og flýta fyrir hleðslutíma.
Notaðu rétt forritunarmál fyrir ákveðin verkefni. Mismunandi tungumál hafa sína kosti og galla. Það eru mörg viðmið, en JavaScript, Python og C# (.NET Core 2.1+) eru leiðandi hvað varðar AWS Lambda árangur. AWS Lambda kynnti nýlega Runtime API sem gerir þér kleift að tilgreina viðkomandi tungumál og keyrsluumhverfi, svo gerðu tilraunir.
Haltu dreifingarpakkastærðum litlum. Því minni sem þær eru, því hraðar hlaðast þær. Forðastu að nota stór bókasöfn, sérstaklega ef þú notar nokkra eiginleika úr þeim. Ef þú ert að forrita í JavaScript, notaðu byggingartól eins og Webpack til að fínstilla bygginguna þína og innihalda aðeins það sem þú raunverulega þarft. .NET Core 3.0 inniheldur QuickJit og Tiered Compilation, sem bæta afköst og hjálpa mjög við kaldræsingu.
Háð netþjónalausra aðgerða af atburðum getur gert það erfitt að samræma viðskiptarökfræði í fyrstu. Skilaboðaraðir og ríkisvélar geta verið ótrúlega gagnlegar í þessu sambandi. Lambda aðgerðir geta hringt hver í aðra, en gerðu þetta aðeins ef þú býst ekki við svari ("eld og gleymir") - þú vilt ekki fá reikning fyrir að bíða eftir að annarri aðgerð ljúki. Skilaboðsraðir eru gagnlegar til að einangra hluta af viðskiptarökfræði, stjórna flöskuhálsum forrita og vinna úr færslum (með því að nota FIFO biðraðir). Hægt er að úthluta AWS Lambda aðgerðum á SQS biðraðir sem fastar skilaboðaraðir sem rekja misheppnaðar skilaboð til síðari greiningar. AWS Step Functions (ríkisvélar) eru mjög gagnlegar til að stjórna flóknum ferlum sem krefjast keðjuaðgerða. Í stað þess að Lambda aðgerð kallar á aðra aðgerð geta Step aðgerðir samræmt ástandsbreytingar, sent gögn á milli aðgerða og stjórnað hnattrænu ástandi aðgerða. Þetta gerir þér kleift að skilgreina skilyrði fyrir endurreynslu, eða hvað á að gera þegar ákveðin villa kemur upp - mjög öflugt tæki við ákveðnar aðstæður.
Ályktun
Undanfarin ár hefur netþjónalaus tækni verið að þróast á áður óþekktum hraða. Það eru ákveðnar ranghugmyndir tengdar þessari hugmyndabreytingu. Með því að draga saman innviði og stjórna sveigjanleika, bjóða netþjónalausar lausnir verulegan ávinning, allt frá einföldri þróun og DevOps ferlum til mikillar lækkunar á rekstrarkostnaði.
Þrátt fyrir að netþjónalausa nálgunin sé ekki án galla, þá eru til áreiðanleg hönnunarmynstur sem hægt er að nota til að búa til öflug netþjónalaus forrit eða samþætta netþjónalausa þætti í núverandi arkitektúr.
Heimild: www.habr.com