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 (, 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 , 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 izlaistsTomē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ā. 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 . 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ī , и . Ja izmantojat AWS, ieteicamā pieeja lietojumprogrammu apkopošanai ir (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
