ProHoster > Blogs > Administrācija > Padomi un resursi bezserveru lietojumprogrammu izveidei

Padomi un resursi bezserveru lietojumprogrammu izveidei

Padomi un resursi bezserveru lietojumprogrammu izveidei
Lai gan bezserveru tehnoloÄ£ijas pēdējos gados ir strauji guvuÅ”as popularitāti, ar tām joprojām ir saistÄ«ti daudzi maldÄ«gi priekÅ”stati un bailes. AtkarÄ«ba no pārdevēja, rÄ«ki, izmaksu pārvaldÄ«ba, aukstā palaiÅ”ana, uzraudzÄ«ba un izstrādes dzÄ«ves cikls ir aktuālas tēmas, kad runa ir par tehnoloÄ£ijām bez serveriem. Å ajā rakstā mēs izpētÄ«sim dažas no minētajām tēmām, kā arÄ« dalÄ«simies ar padomiem un saitēm uz noderÄ«giem informācijas avotiem, lai palÄ«dzētu iesācējiem izveidot jaudÄ«gas, elastÄ«gas un rentablas lietojumprogrammas bez serveriem.

Nepareizi priekŔstati par tehnoloģijām bez serveriem

Daudzi cilvēki domā, ka apstrāde bez serveriem un bez serveriem (Darbojas kā pakalpojums, FaaS) ir gandrÄ«z viena un tā pati lieta. Tas nozÄ«mē, ka atŔķirÄ«ba nav pārāk liela un ir vērts ieviest jaunumu. Lai gan AWS Lambda bija viena no bezserveru ziedu laika zvaigznēm un viens no populārākajiem bezserveru arhitektÅ«ras elementiem, tomēr Ŕī arhitektÅ«ra ir daudz vairāk nekā FaaS.

Bezserveru tehnoloÄ£iju pamatprincips ir tāds, ka jums nav jāuztraucas par infrastruktÅ«ras pārvaldÄ«bu un mērogoÅ”anu, jÅ«s maksājat tikai par izmantoto. Daudzi pakalpojumi atbilst Å”iem kritērijiem ā€” AWS DynamoDB, S3, SNS vai SQS, Graphcool, Auth0, Now, Netlify, Firebase un daudzi citi. Kopumā bezservera nozÄ«mē visu mākoņdatoÅ”anas jaudu izmantoÅ”anu bez nepiecieÅ”amÄ«bas pārvaldÄ«t infrastruktÅ«ru un optimizēt to mērogoÅ”anas vajadzÄ«bām. Tas arÄ« nozÄ«mē, ka droŔība infrastruktÅ«ras lÄ«menÄ« vairs nav jÅ«su problēma, un tas ir milzÄ«gs ieguvums, ņemot vērā droŔības standartu izpildes grÅ«tÄ«bas un sarežģītÄ«bu. Visbeidzot, jums nav jāpērk jums nodroÅ”inātā infrastruktÅ«ra.

Bez servera var uzskatÄ«t "prāta stāvokli": noteiktu mentalitāti, izstrādājot risinājumus. Izvairieties no pieejām, kurām nepiecieÅ”ama jebkuras infrastruktÅ«ras uzturÄ“Å”ana. Izmantojot bezserveru pieeju, mēs pavadām laiku, risinot uzdevumus, kas tieÅ”i ietekmē projektu un sniedz ieguvumus mÅ«su lietotājiem: veidojam ilgtspējÄ«gu biznesa loÄ£iku, izstrādājam lietotāja saskarnes un izstrādājam adaptÄ«vas un uzticamas API.

Piemēram, ja ir iespējams izvairÄ«ties no brÄ«vā teksta meklÄ“Å”anas platformas pārvaldÄ«bas un uzturÄ“Å”anas, tad tā arÄ« darÄ«sim. Å Ä« pieeja lietojumprogrammu izveidei var ievērojami paātrināt laiku, kas nepiecieÅ”ams tirgÅ« nonākÅ”anai tirgÅ«, jo jums vairs nav jādomā par sarežģītas infrastruktÅ«ras pārvaldÄ«bu. AtbrÄ«vojieties no infrastruktÅ«ras pārvaldÄ«bas atbildÄ«bas un izmaksām un koncentrējieties uz klientiem nepiecieÅ”amo lietojumprogrammu un pakalpojumu izveidi. Patriks Debuā Å”o pieeju sauca 'apkalpojoÅ”s', termins ir pieņemts kopienā bez serveriem. Funkcijas jāuzskata par saiti uz pakalpojumiem kā izvietojamiem moduļiem (nevis izvietot visu bibliotēku vai tÄ«mekļa lietojumprogrammu). Tas nodroÅ”ina neticamu precizitāti lietojumprogrammas izvietoÅ”anas un izmaiņu pārvaldÄ«bai. Ja nevarat izvietot funkcijas Ŕādā veidā, tas var norādÄ«t, ka funkcijas veic pārāk daudz uzdevumu un ir jāpārveido.

Dažus mulsina atkarÄ«ba no pārdevēja, izstrādājot mākoņa lietojumprogrammas. Tas pats attiecas uz tehnoloÄ£ijām bez serveriem, un diez vai tas ir nepareizs priekÅ”stats. MÅ«su pieredze liecina, ka bezserveru lietojumprogrammu izveide AWS, apvienojumā ar AWS Lambda spēju apvienot citus AWS pakalpojumus, ir daļa no bezserveru arhitektÅ«ras stiprajām pusēm. Å is ir labs sinerÄ£ijas piemērs, kad kombinācijas rezultāts ir vairāk nekā tikai terminu summa. Mēģinot izvairÄ«ties no atkarÄ«bas no pārdevēja, var rasties vēl vairāk problēmu. Strādājot ar konteineriem, ir vieglāk pārvaldÄ«t savu abstrakcijas slāni starp mākoņpakalpojumu sniedzējiem. Taču, ja runa ir par risinājumiem bez serveriem, pÅ«les neatmaksāsies, it Ä«paÅ”i, ja jau no paÅ”a sākuma tiek ņemta vērā izmaksu efektivitāte. Noteikti uzziniet, kā pārdevēji sniedz pakalpojumus. Daži specializētie pakalpojumi paļaujas uz integrācijas punktiem ar citiem piegādātājiem un var nodroÅ”ināt plug-and-play savienojumu. VienkārŔāk ir nodroÅ”ināt Lambda izsaukumu no vārtejas API galapunkta, nekā nosÅ«tÄ«t pieprasÄ«jumu starpniekserveri kādam konteineram vai EC2 instancei. Graphcool nodroÅ”ina vienkārÅ”u konfigurÄ“Å”anu ar Auth0, kas ir vienkārŔāk nekā treŔās puses autentifikācijas rÄ«ku izmantoÅ”ana.

Pareizā pārdevēja izvēle lietojumprogrammai bez servera ir arhitektonisks lēmums. Veidojot lietojumprogrammu, jÅ«s negaidāt, ka kādu dienu atgriezÄ«sities pie serveru pārvaldÄ«bas. Mākoņa pārdevēja izvēle neatŔķiras no konteineru vai datu bāzes vai pat programmÄ“Å”anas valodas izmantoÅ”anas.

Apsveriet:

  • Kādi pakalpojumi ir nepiecieÅ”ami un kāpēc.
  • Kādus pakalpojumus sniedz mākoņpakalpojumu sniedzēji un kā varat tos apvienot ar izvēlēto FaaS risinājumu.
  • Kādas programmÄ“Å”anas valodas tiek atbalstÄ«tas (ar dinamisku vai statisku rakstÄ«Å”anu, apkopotas vai interpretētas, kādi ir etaloni, kāda ir veiktspēja aukstā palaiÅ”anas režīmā, kāda ir atvērtā pirmkoda ekosistēma utt.).
  • Kādas ir jÅ«su droŔības prasÄ«bas (SLA, 2FA, OAuth, HTTPS, SSL utt.).
  • Kā pārvaldÄ«t CI/CD un programmatÅ«ras izstrādes ciklus.
  • Kādus infrastruktÅ«ras kā koda risinājumus varat izmantot.

PaplaÅ”inot esoÅ”u lietojumprogrammu un pakāpeniski pievienojot bezservera funkcionalitāti, tas var nedaudz ierobežot pieejamās iespējas. Tomēr gandrÄ«z visas bezserveru tehnoloÄ£ijas nodroÅ”ina sava veida API (izmantojot REST vai ziņojumu rindas), kas ļauj izveidot paplaÅ”inājumus neatkarÄ«gi no lietojumprogrammas kodola un ar vienkārÅ”u integrāciju. Meklējiet pakalpojumus ar skaidrām API, labu dokumentāciju un spēcÄ«gu kopienu, un jÅ«s nevarat kļūdÄ«ties. Integrācijas vienkārŔība bieži var bÅ«t galvenais rādÄ«tājs, un tas, iespējams, ir viens no galvenajiem iemesliem, kāpēc AWS ir bijusi tik veiksmÄ«ga kopÅ” Lambda izlaiÅ”anas 2015. gadā.

Kad bez servera ir labi

TehnoloÄ£ijas bez serveriem var izmantot gandrÄ«z visur. Tomēr to priekÅ”rocÄ«bas neaprobežojas tikai ar vienu pielietoÅ”anas veidu. Pateicoties bezserveru tehnoloÄ£ijām, barjera ienākÅ”anai mākoņdatoÅ”anas jomā mÅ«sdienās ir tik zema. Ja izstrādātājiem ir ideja, bet viņi nezina, kā pārvaldÄ«t mākoņa infrastruktÅ«ru un optimizēt izmaksas, tad viņiem nav jāmeklē kāds inženieris, kas to izdarÄ«tu. Ja jaunizveidotais uzņēmums vēlas izveidot platformu, bet baidās, ka izmaksas var kļūt nekontrolējamas, viņi var viegli pievērsties risinājumiem bez serveriem.

Izmaksu ietaupÄ«jumu un mērogoÅ”anas vienkārŔības dēļ risinājumi bez serveriem ir vienlÄ«dz piemērojami gan iekŔējām, gan ārējām sistēmām, lÄ«dz pat tÄ«mekļa lietojumprogrammai ar vairāku miljonu auditoriju. Konti tiek mērÄ«ti nevis eiro, bet gan centos. VienkārŔākā AWS EC2 (t1.micro) eksemplāra noma uz mēnesi maksās 15 ā‚¬, pat ja ar to neko nedarÄ«sit (kurÅ” gan nekad neaizmirsa to izslēgt?!). SalÄ«dzinājumam, lai sasniegtu Å”o tēriņu lÄ«meni tajā paŔā laika periodā, jums 512 MB Lambda vajadzētu darbināt 1 sekundi aptuveni 3 miljonus reižu. Un, ja jÅ«s neizmantojat Å”o funkciju, tad jÅ«s neko nemaksājat.

Tā kā bezserveru funkcija galvenokārt ir balstīta uz notikumiem, vecākām sistēmām ir diezgan viegli pievienot infrastruktūru bez serveriem. Piemēram, izmantojot AWS S3, Lambda un Kinesis, varat izveidot analītikas pakalpojumu vecai mazumtirdzniecības sistēmai, kas var saņemt datus, izmantojot API.

Lielākā daļa bezserveru platformu atbalsta vairākas valodas. Visbiežāk tas ir Python, JavaScript, C#, Java un Go. Parasti nav ierobežojumu attiecÄ«bā uz bibliotēku izmantoÅ”anu visās valodās, tāpēc varat izmantot savas iecienÄ«tākās atvērtā pirmkoda bibliotēkas. Tomēr nav ieteicams ļaunprātÄ«gi izmantot atkarÄ«bas, lai jÅ«su funkcijas darbotos optimāli un netiktu noliegtas priekÅ”rocÄ«bas, ko sniedz bezserveru lietojumprogrammu milzÄ«gā mērogojamÄ«ba. Jo vairāk iepakojumu jāiekrauj konteinerā, jo ilgāks laiks bÅ«s aukstā iedarbināŔana.

Aukstā palaiÅ”ana ir tad, kad vispirms ir jāinicializē konteiners, izpildlaiks un kļūdu apstrādātājs pirms to izmantoÅ”anas. Å Ä« iemesla dēļ funkciju izpildes aizkave var bÅ«t lÄ«dz 3 sekundēm, un tas nav labākais risinājums nepacietÄ«giem lietotājiem. Tomēr aukstā iedarbināŔana notiek pirmajā zvanā pēc dažām dÄ«kstāves minÅ«tēm. Daudzi uzskata, ka tas ir neliels kairinājums, ko var novērst, regulāri pingot funkcijai, lai tā paliktu tukÅ”gaitā. Vai arÄ« viņi vispār ignorē Å”o aspektu.

Lai gan AWS izlaists bez servera SQL datu bāze Bez servera AuroraTomēr SQL datu bāzes nav ideāli piemērotas Å”ai lietojumprogrammai, jo tās ir atkarÄ«gas no savienojumiem, lai veiktu transakcijas, kas var ātri kļūt par sastrēgumu ar lielu trafiku AWS Lambda. Jā, izstrādātāji nepārtraukti uzlabo bez serveru Aurora, un jums vajadzētu ar to eksperimentēt, taču Å”odien tādi NoSQL risinājumi kā DynamoDB. Tomēr nav Å”aubu, ka Ŕī situācija ļoti drÄ«z mainÄ«sies.

RÄ«ku komplekts uzliek arÄ« daudz ierobežojumu, jo Ä«paÅ”i vietējās testÄ“Å”anas jomā. Lai gan ir tādi risinājumi kā Docker-Lambda, DynamoDB Local un LocalStack, tie prasa smagu darbu un ievērojamu konfigurācijas apjomu. Taču visi Å”ie projekti tiek aktÄ«vi attÄ«stÄ«ti, tāpēc ir tikai laika jautājums, kad instrumentu kopums sasniegs mums vajadzÄ«go lÄ«meni.

Bezserveru tehnoloģiju ietekme uz attīstības ciklu

Tā kā jÅ«su infrastruktÅ«ra ir tikai konfigurācija, varat definēt un izvietot kodu, izmantojot skriptus, piemēram, čaulas skriptus. Vai arÄ« varat izmantot konfigurācijas kā koda klases risinājumus, piemēram AWS mākoņu veidoÅ”anās. Lai gan Å”is pakalpojums nenodroÅ”ina konfigurāciju visām jomām, tas ļauj definēt konkrētus resursus, ko izmantot kā Lambda funkcijas. Tas ir, ja CloudFormation jums neizdodas, varat uzrakstÄ«t savu resursu (Lambda funkcija), kas novērsÄ«s Å”o plaisu. Tādā veidā jÅ«s varat darÄ«t jebko, pat konfigurēt atkarÄ«bas ārpus AWS vides.

Tā kā tas viss ir tikai konfigurācija, varat pielāgot savus izvietoÅ”anas skriptus noteiktām vidēm, reÄ£ioniem un lietotājiem, Ä«paÅ”i, ja izmantojat infrastruktÅ«ras kā koda risinājumus, piemēram, CloudFormation. Piemēram, katrai repozitorijas filiālei varat izvietot infrastruktÅ«ras kopiju, lai izstrādes laikā varētu tās pilnÄ«bā pārbaudÄ«t atseviŔķi. Tas ievērojami paātrina atgriezenisko saiti izstrādātājiem, kad viņi vēlas saprast, vai viņu kods darbojas atbilstoÅ”i dzÄ«vajā vidē. Pārvaldniekiem nav jāuztraucas par vairāku vidi izvietoÅ”anas izmaksām, jo ā€‹ā€‹viņi maksā tikai par faktisko izmantoÅ”anu.

DevOps ir mazāk raižu, jo viņiem tikai jāpārliecinās, vai izstrādātājiem ir pareiza konfigurācija. Jums vairs nav jāpārvalda gadÄ«jumi, balansētāji vai droŔības grupas. Tāpēc arvien biežāk tiek lietots termins NoOps, lai gan joprojām ir svarÄ«gi spēt konfigurēt infrastruktÅ«ru, it Ä«paÅ”i, ja runa ir par IAM konfigurāciju un mākoņa resursu optimizāciju.

Ir ļoti jaudÄ«gi uzraudzÄ«bas un vizualizācijas rÄ«ki, piemēram, Epsagon, Thundra, Dashbird un IOPipe. Tie ļauj pārraudzÄ«t bezserveru lietojumprogrammu paÅ”reizējo stāvokli, nodroÅ”ināt reÄ£istrÄ“Å”anu un izsekoÅ”anu, veiktspējas metriku un arhitektÅ«ras vājās vietas, veikt izmaksu analÄ«zi un prognozÄ“Å”anu un daudz ko citu. Tie ne tikai sniedz DevOps inženieriem, izstrādātājiem un arhitektiem visaptveroÅ”u priekÅ”statu par lietojumprogrammu veiktspēju, bet arÄ« ļauj vadÄ«tājiem uzraudzÄ«t situāciju reāllaikā, izmantojot resursu izmaksas sekundē un izmaksu prognozÄ“Å”anu. Ar pārvaldÄ«tu infrastruktÅ«ru to organizēt ir daudz grÅ«tāk.

Bezserveru lietojumprogrammu izstrāde ir daudz vienkārŔāka, jo jums nav jāizvieto tÄ«mekļa serveri, jāpārvalda virtuālās maŔīnas vai konteineri, ielāpu serveri, operētājsistēmas, interneta vārtejas utt. Abstrahējot visus Å”os pienākumus, arhitektÅ«ra bez serveriem var koncentrēties uz galveno - risinājums, biznesa un klientu vajadzÄ«bas.

Lai gan rÄ«kkopa varētu bÅ«t labāka (tas kļūst labāks ar katru dienu), izstrādātāji var koncentrēties uz biznesa loÄ£ikas ievieÅ”anu un vislabāko lietojumprogrammas sarežģītÄ«bas sadali dažādos arhitektÅ«ras pakalpojumos. Lietojumprogrammu pārvaldÄ«ba bez serveriem ir balstÄ«ta uz notikumiem, un mākoņpakalpojumu sniedzējs to abstrahē (piemēram, SQS, S3 notikumi vai DynamoDB straumes). Tāpēc izstrādātājiem ir tikai jāraksta biznesa loÄ£ika, lai reaģētu uz noteiktiem notikumiem, un nav jāuztraucas par to, kā vislabāk ieviest datu bāzes un ziņojumu rindas vai organizēt optimālu darbu ar datiem konkrētās aparatÅ«ras krātuvēs.

Kodu var palaist un atkļūdot lokāli, tāpat kā jebkurā izstrādes procesā. VienÄ«bas pārbaude paliek nemainÄ«ga. Iespēja izvietot visu lietojumprogrammu infrastruktÅ«ru ar pielāgotu steka konfigurāciju ļauj izstrādātājiem ātri iegÅ«t svarÄ«gas atsauksmes, nedomājot par testÄ“Å”anas izmaksām vai ietekmi uz dārgām pārvaldÄ«tām vidēm.

Rīki un metodes bezserveru lietojumprogrammu veidoŔanai

Nav Ä«paÅ”a veida, kā izveidot lietojumprogrammas bez serveriem. Kā arÄ« pakalpojumu komplekts Å”im uzdevumam. MÅ«sdienās AWS ir lÄ«deris starp jaudÄ«giem bezserveru risinājumiem, taču apskatiet arÄ« Google mākonis, laiks Šø Firebase. Ja izmantojat AWS, ieteicamā pieeja lietojumprogrammu apkopoÅ”anai ir Lietojumprogrammu modelis bez servera (SAM), it Ä«paÅ”i, ja izmantojat C#, jo Visual Studio ir lieliski rÄ«ki. SAM CLI var darÄ«t visu, ko spēj Visual Studio, tāpēc jÅ«s neko nezaudēsit, pārslēdzoties uz citu IDE vai teksta redaktoru. Protams, SAM darbojas arÄ« ar citām valodām.

Ja rakstāt citās valodās, Serverless Framework ir lielisks atvērtā pirmkoda rÄ«ks, kas ļauj konfigurēt jebko ar ļoti jaudÄ«giem YAML konfigurācijas failiem. Serverless Framework atbalsta arÄ« dažādus mākoņpakalpojumus, tāpēc iesakām tiem, kas meklē vairāku mākoņu risinājumu. Tam ir milzÄ«ga kopiena, kas ir izveidojusi virkni spraudņu jebkurai nepiecieÅ”amÄ«bai.

Vietējai testÄ“Å”anai ir labi piemēroti atvērtā pirmkoda rÄ«ki Docker-Lambda, Serverless Local, DynamoDB Local un LocalStack. TehnoloÄ£ijas bez serveriem joprojām ir agrÄ«nā izstrādes stadijā, tāpat kā tām paredzētie rÄ«ki, tāpēc, iestatot sarežģītus testa scenārijus, jums bÅ«s smagi jāstrādā. Tomēr vienkārÅ”a steka izvietoÅ”ana vidē un testÄ“Å”ana tur ir neticami lēta. Un jums nav jāizveido precÄ«za mākoņa vides lokāla kopija.

Izmantojiet AWS Lambda slāņus, lai samazinātu izvietoto pakotņu lielumu un paātrinātu lejupielādi.

Konkrētu uzdevumu veikÅ”anai izmantojiet pareizās programmÄ“Å”anas valodas. Dažādām valodām ir savas priekÅ”rocÄ«bas un trÅ«kumi. Ir daudz etalonu, taču JavaScript, Python un C# (.NET Core 2.1+) ir lÄ«deri AWS Lambda veiktspējas ziņā. AWS Lambda nesen ieviesa Runtime API, kas ļauj norādÄ«t vēlamo izpildlaika valodu un vidi, tāpēc eksperimentējiet.

Saglabājiet mazu iepakojuma izmēru izvietoÅ”anai. Jo mazāki tie ir, jo ātrāk tie tiek ielādēti. Izvairieties no lielu bibliotēku izmantoÅ”anas, Ä«paÅ”i, ja no tām izmantojat dažas funkcijas. Ja programmējat JavaScript, izmantojiet veidoÅ”anas rÄ«ku, piemēram, Webpack, lai optimizētu bÅ«vējumu un iekļautu tikai to, kas jums patieŔām nepiecieÅ”ams. .NET Core 3.0 ir QuickJit un daudzpakāpju kompilācija, kas uzlabo veiktspēju un ļoti palÄ«dz aukstās palaiÅ”anas gadÄ«jumā.

Bezserveru funkciju paļauÅ”anās uz notikumiem sākotnēji var apgrÅ«tināt biznesa loÄ£ikas koordinÄ“Å”anu. Å ajā sakarā ziņojumu rindas un stāvokļa maŔīnas var bÅ«t neticami noderÄ«gas. Lambda funkcijas var piezvanÄ«t viena otrai, taču dariet to tikai tad, ja negaidāt atbildi ("aizdedzināt un aizmirst") ā€” jÅ«s nevēlaties saņemt rēķinu par citas funkcijas pabeigÅ”anas gaidÄ«Å”anu. Ziņojumu rindas ir noderÄ«gas, lai izolētu biznesa loÄ£ikas daļas, pārvaldÄ«tu lietojumprogrammu vājās vietas un apstrādātu darÄ«jumus (izmantojot FIFO rindas). AWS Lambda funkcijas var pieŔķirt SQS rindām kā iestrēguÅ”u ziņojumu rindas, kas seko neveiksmÄ«giem ziņojumiem vēlākai analÄ«zei. AWS Step Functions (stāvokļa maŔīnas) ir ļoti noderÄ«gas, lai pārvaldÄ«tu sarežģītus procesus, kuriem nepiecieÅ”ama funkciju ķēde. Tā vietā, lai Lambda funkcija izsauktu citu funkciju, Step funkcijas var koordinēt stāvokļa pārejas, nodot datus starp funkcijām un pārvaldÄ«t funkciju globālo stāvokli. Tas ļauj definēt atkārtota mēģinājuma nosacÄ«jumus vai to, ko darÄ«t, ja rodas konkrēta kļūda ā€“ tas ir ļoti spēcÄ«gs rÄ«ks noteiktos apstākļos.

Secinājums

Pēdējos gados bezserveru tehnoloÄ£ijas attÄ«stās nepieredzētā tempā. Ar Å”o paradigmas maiņu ir saistÄ«ti daži nepareizi priekÅ”stati. Abstrahējot infrastruktÅ«ru un mērogoÅ”anas pārvaldÄ«bu, risinājumi bez serveriem piedāvā ievērojamas priekÅ”rocÄ«bas, sākot no vienkārÅ”otas izstrādes un DevOps procesiem lÄ«dz ievērojamiem darbÄ«bas izmaksu samazinājumiem.
Lai gan bezserveru pieejai ir trÅ«kumi, ir stabili dizaina modeļi, ko var izmantot, lai izveidotu stabilas bezserveru lietojumprogrammas vai integrētu bezserveru elementus esoÅ”ajās arhitektÅ«rās.

Avots: www.habr.com

Pievieno komentāru