Bagama't mabilis na sumikat ang mga teknolohiyang walang server sa mga nakalipas na taon, marami pa ring maling akala at takot na nauugnay sa mga ito. Ang dependency ng vendor, tooling, pamamahala sa gastos, malamig na pagsisimula, pagsubaybay, at ang development lifecycle ay mainit na pinagtatalunan pagdating sa mga teknolohiyang walang server. Sa artikulong ito, tuklasin namin ang ilan sa mga paksang nabanggit, pati na rin ang pagbabahagi ng mga tip at link sa mga kapaki-pakinabang na mapagkukunan upang matulungan ang mga nagsisimula na bumuo ng makapangyarihan, nababaluktot, at cost-effective na mga serverless na application.
Mga Maling Paniniwala Tungkol sa Serverless Technologies
Iniisip ng maraming tao na walang server at walang server na pagpoproseso (, FaaS) ay halos pareho. Nangangahulugan ito na ang pagkakaiba ay hindi masyadong malaki at ito ay nagkakahalaga ng pagpapakilala ng isang bagong bagay. Bagama't ang AWS Lambda ay isa sa mga bituin ng walang server na kasagsagan at isa sa pinakasikat na elemento ng walang server na arkitektura, gayunpaman, ang arkitektura na ito ay higit pa sa FaaS.
Ang pangunahing prinsipyo sa likod ng mga teknolohiyang walang server ay hindi mo kailangang mag-alala tungkol sa pamamahala at pag-scale ng iyong imprastraktura, babayaran mo lang ang iyong ginagamit. Maraming serbisyo ang umaangkop sa mga pamantayang ito - AWS DynamoDB, S3, SNS o SQS, Graphcool, Auth0, Now, Netlify, Firebase at marami pang iba. Sa pangkalahatan, ang serverless ay nangangahulugan ng paggamit ng buong kapangyarihan ng cloud computing nang hindi nangangailangang pamahalaan ang imprastraktura at i-optimize ito para sa pag-scale. Nangangahulugan din ito na ang seguridad sa antas ng imprastraktura ay hindi na iyong alalahanin, na isang malaking benepisyo dahil sa kahirapan at pagiging kumplikado ng pagtupad sa mga pamantayan ng seguridad. Sa wakas, hindi mo na kailangang bilhin ang imprastraktura na ibinigay sa iyo.
Ang serverless ay maaaring ituring na isang "estado ng pag-iisip": isang tiyak na kaisipan kapag nagdidisenyo ng mga solusyon. Iwasan ang mga diskarte na nangangailangan ng pagpapanatili ng anumang imprastraktura. Sa walang server na diskarte, gumugugol kami ng oras sa paglutas ng mga gawain na direktang nakakaapekto sa proyekto at nagdudulot ng mga benepisyo sa aming mga user: lumikha kami ng napapanatiling lohika ng negosyo, bumuo ng mga user interface, at bumuo ng mga adaptive at maaasahang API.
Halimbawa, kung posible na maiwasan ang pamamahala at pagpapanatili ng isang libreng platform ng paghahanap ng teksto, iyon ang gagawin namin. Ang diskarte na ito sa pagbuo ng mga application ay maaaring lubos na mapabilis ang oras sa merkado, dahil hindi mo na kailangang mag-isip tungkol sa pamamahala ng kumplikadong imprastraktura. Tanggalin ang mga responsibilidad at gastos ng pamamahala sa imprastraktura at tumuon sa pagbuo ng mga aplikasyon at serbisyo na kailangan ng iyong mga customer. Tinawag ni Patrick Debois ang diskarteng ito , ang termino ay pinagtibay sa komunidad na walang server. Ang mga function ay dapat isipin bilang isang link sa mga serbisyo bilang mga deployable na module (sa halip na mag-deploy ng isang buong library o web application). Nagbibigay ito ng hindi kapani-paniwalang granularity para sa pamamahala ng deployment at mga pagbabago sa application. Kung hindi ka makapag-deploy ng mga function sa ganitong paraan, maaaring ipahiwatig nito na ang mga function ay gumaganap ng masyadong maraming mga gawain at kailangang refactored.
Ang ilan ay nalilito sa pag-asa sa vendor kapag bumubuo ng mga cloud application. Totoo rin ito sa mga teknolohiyang walang server, at hindi ito isang maling kuru-kuro. Sa aming karanasan, ang pagbuo ng mga serverless na application sa AWS, kasama ng kakayahan ng AWS Lambda na i-bundle ang iba pang mga serbisyo ng AWS nang magkasama, ay bahagi ng lakas ng mga serverless architecture. Ito ay isang magandang halimbawa ng synergy, kapag ang resulta ng kumbinasyon ay higit pa sa kabuuan ng mga termino. Ang pagsisikap na maiwasan ang dependency sa vendor ay maaaring magkaroon ng mas maraming problema. Kapag nagtatrabaho sa mga container, mas madaling pamahalaan ang iyong sariling abstraction layer sa pagitan ng mga cloud provider. Ngunit pagdating sa walang server na mga solusyon, ang pagsisikap ay hindi magbubunga, lalo na kung ang pagiging epektibo sa gastos ay isinasaalang-alang mula sa simula. Tiyaking alamin kung paano nagbibigay ng mga serbisyo ang mga vendor. Ang ilang mga espesyal na serbisyo ay umaasa sa mga punto ng pagsasama sa iba pang mga vendor at maaaring magbigay ng plug-and-play na koneksyon sa labas ng kahon. Mas madaling magbigay ng Lambda na tawag mula sa isang gateway API endpoint kaysa i-proxy ang kahilingan sa ilang container o EC2 instance. Nagbibigay ang Graphcool ng madaling pagsasaayos sa Auth0, na mas madali kaysa sa paggamit ng mga tool sa pagpapatunay ng third party.
Ang pagpili ng tamang vendor para sa iyong walang server na application ay isang desisyon sa arkitektura. Kapag lumikha ka ng isang application, hindi mo inaasahan na isang araw ay babalik sa pamamahala ng mga server. Ang pagpili ng cloud vendor ay walang pinagkaiba sa pagpili na gumamit ng mga container o isang database, o kahit isang programming language.
Isaalang-alang:
- Anong mga serbisyo ang kailangan mo at bakit.
- Anong mga serbisyo ang ibinibigay ng mga cloud provider at kung paano mo sila pagsasamahin sa iyong napiling solusyon sa FaaS.
- Anong mga programming language ang sinusuportahan (na may dynamic o static na pag-type, pinagsama-sama o binibigyang-kahulugan, ano ang mga benchmark, ano ang pagganap sa malamig na pagsisimula, ano ang open source ecosystem, atbp.).
- Ano ang iyong mga kinakailangan sa seguridad (SLA, 2FA, OAuth, HTTPS, SSL, atbp.).
- Paano pamahalaan ang iyong CI/CD at mga siklo ng pagbuo ng software.
- Aling mga solusyon sa imprastraktura-bilang-code ang maaari mong samantalahin.
Kung palawigin mo ang isang umiiral na application at unti-unting magdagdag ng walang server na paggana, maaaring medyo malimitahan nito ang mga magagamit na kakayahan. Gayunpaman, halos lahat ng mga teknolohiyang walang server ay nagbibigay ng ilang uri ng API (sa pamamagitan ng REST o mga pila ng mensahe) na nagbibigay-daan sa iyong lumikha ng mga extension na hiwalay sa core ng application at may madaling pagsasama. Maghanap ng mga serbisyong may malinaw na API, mahusay na dokumentasyon, at malakas na komunidad, at hindi ka maaaring magkamali. Ang kadalian ng pagsasama ay kadalasang maaaring maging pangunahing sukatan, at marahil ay isa sa mga pangunahing dahilan kung bakit naging matagumpay ang AWS mula nang ilabas ang Lambda noong 2015.
Kapag Maganda ang Serverless
Maaaring ilapat ang mga teknolohiyang walang server sa halos lahat ng dako. Gayunpaman, ang kanilang mga pakinabang ay hindi limitado sa isang paraan lamang ng aplikasyon. Napakababa ng hadlang sa pagpasok para sa cloud computing ngayon salamat sa mga teknolohiyang walang server. Kung may ideya ang mga developer, ngunit hindi nila alam kung paano pamahalaan ang imprastraktura ng ulap at i-optimize ang mga gastos, hindi na nila kailangang maghanap ng ilang uri ng inhinyero para gawin ito. Kung gusto ng isang startup na bumuo ng isang platform ngunit nangangamba na maaaring mawalan ng kontrol ang mga gastos, madali silang makakagamit sa mga solusyon na walang server.
Dahil sa pagtitipid sa gastos at kadalian ng pag-scale, ang mga walang server na solusyon ay pantay na naaangkop para sa parehong panloob at panlabas na mga system, hanggang sa isang web application na may multi-milyong audience. Ang mga account ay sinusukat sa halip na sa euro, ngunit sa sentimo. Ang pagrenta ng pinakasimpleng instance ng AWS EC2 (t1.micro) sa loob ng isang buwan ay nagkakahalaga ng β¬15, kahit na wala kang gagawin dito (sino ang hindi nakakalimutang i-off ito?!). Sa paghahambing, upang maabot ang antas na ito ng paggastos sa parehong yugto ng panahon, kakailanganin mong magpatakbo ng 512 MB Lambda sa loob ng 1 segundo nang humigit-kumulang 3 milyong beses. At kung hindi mo gagamitin ang feature na ito, wala kang babayaran.
Dahil ang serverless ay pangunahing batay sa kaganapan, medyo madaling magdagdag ng isang serverless na imprastraktura sa mga mas lumang system. Halimbawa, gamit ang AWS S3, Lambda, at Kinesis, maaari kang lumikha ng serbisyo ng analytics para sa isang lumang retail system na maaaring makatanggap ng data sa pamamagitan ng isang API.
Karamihan sa mga platform na walang server ay sumusuporta sa maraming wika. Kadalasan ito ay Python, JavaScript, C#, Java at Go. Karaniwang walang mga paghihigpit sa paggamit ng mga aklatan sa lahat ng mga wika, kaya maaari mong gamitin ang iyong mga paboritong open source na aklatan. Gayunpaman, ipinapayong huwag abusuhin ang mga dependency upang gumana nang mahusay ang iyong mga pag-andar at huwag balewalain ang mga benepisyo ng malaking scalability ng iyong mga serverless na application. Ang mas maraming mga pakete na kailangang i-load sa lalagyan, mas matagal ang malamig na pagsisimula.
Ang malamig na pagsisimula ay kapag kailangan mo munang simulan ang container, runtime, at error handler bago gamitin ang mga ito. Dahil dito, ang pagkaantala sa pagpapatupad ng mga pag-andar ay maaaring hanggang sa 3 segundo, at hindi ito ang pinakamahusay na pagpipilian para sa mga naiinip na gumagamit. Gayunpaman, nangyayari ang malamig na pagsisimula sa unang tawag pagkatapos ng ilang minuto ng idle function. Itinuturing ng marami na ito ay isang maliit na inis na maaaring ayusin sa pamamagitan ng regular na pag-ping sa function upang mapanatili itong idling. O binabalewala nila ang aspetong ito sa kabuuan.
Bagama't inilabas ang AWSGayunpaman, ang mga database ng SQL ay hindi perpekto para sa application na ito, dahil umaasa sila sa mga koneksyon upang magsagawa ng mga transaksyon, na maaaring mabilis na maging isang bottleneck na may matinding trapiko sa AWS Lambda. Oo, patuloy na pinapabuti ng mga developer ang Serverless Aurora, at dapat kang mag-eksperimento dito, ngunit ngayon ang mga solusyon sa NoSQL tulad ng. Gayunpaman, walang duda na ang sitwasyong ito ay magbabago sa lalong madaling panahon.
Ang toolkit ay nagpapataw din ng maraming mga paghihigpit, lalo na sa larangan ng lokal na pagsubok. Bagama't may mga solusyon tulad ng Docker-Lambda, DynamoDB Local at LocalStack, nangangailangan sila ng pagsusumikap at malaking halaga ng configuration. Gayunpaman, ang lahat ng mga proyektong ito ay aktibong binuo, kaya isang oras na lang bago maabot ng toolkit ang antas na kailangan namin.
Ang epekto ng mga teknolohiyang walang server sa ikot ng pag-unlad
Dahil ang iyong imprastraktura ay isang configuration lamang, maaari mong tukuyin at i-deploy ang code gamit ang mga script, gaya ng mga shell script. O maaari kang gumamit ng configuration-as-code na mga solusyon sa klase tulad ng . Bagama't hindi nagbibigay ang serbisyong ito ng configuration para sa lahat ng lugar, binibigyang-daan ka nitong tukuyin ang mga partikular na mapagkukunang gagamitin bilang mga function ng Lambda. Iyon ay, kung saan nabigo ang CloudFormation, maaari kang sumulat ng iyong sariling mapagkukunan (Lambda function) na magsasara ng puwang na ito. Sa ganitong paraan magagawa mo ang anumang bagay, kahit na i-configure ang mga dependency sa labas ng iyong AWS environment.
Dahil configuration lang ang lahat, maaari mong i-customize ang iyong mga script sa pag-deploy para sa mga partikular na kapaligiran, rehiyon, at user, lalo na kung gumagamit ka ng mga solusyon sa imprastraktura-bilang-code tulad ng CloudFormation. Halimbawa, maaari kang mag-deploy ng kopya ng imprastraktura para sa bawat sangay sa repository upang masubukan mo ang mga ito nang hiwalay sa panahon ng pag-unlad. Ito ay lubos na nagpapabilis ng feedback para sa mga developer kapag gusto nilang maunawaan kung gumagana nang maayos ang kanilang code sa isang live na kapaligiran. Ang mga tagapamahala ay hindi kailangang mag-alala tungkol sa gastos ng pag-deploy ng maraming kapaligiran, dahil nagbabayad lang sila para sa aktwal na paggamit.
Mas kaunting alalahanin ang DevOps dahil kailangan lang nilang tiyakin na tama ang configuration ng mga developer. Hindi mo na kailangan pang pamahalaan ang mga instance, balancer, o security group. Samakatuwid, ang terminong NoOps ay lalong ginagamit, bagama't mahalaga pa rin na ma-configure ang imprastraktura, lalo na pagdating sa configuration ng IAM at cloud resource optimization.
Mayroong napakalakas na mga tool sa pagsubaybay at visualization tulad ng Epsagon, Thundra, Dashbird at IOPipe. Nagbibigay-daan sa iyo ang mga ito na subaybayan ang kasalukuyang estado ng iyong mga application na walang server, magbigay ng pag-log at pagsubaybay, pagkuha ng mga sukatan ng pagganap at mga bottleneck ng arkitektura, magsagawa ng pagsusuri at pagtataya ng gastos, at higit pa. Hindi lamang binibigyan ng mga ito ang mga inhinyero, developer, at arkitekto ng DevOps ng komprehensibong pagtingin sa pagganap ng application, ngunit pinapayagan din ang mga tagapamahala na subaybayan ang sitwasyon sa real time, na may bawat segundong mga gastos sa mapagkukunan at pagtataya ng gastos. Mas mahirap ayusin ito gamit ang isang pinamamahalaang imprastraktura.
Ang pagdidisenyo ng mga serverless na application ay mas madali dahil hindi mo kailangang mag-deploy ng mga web server, pamahalaan ang mga virtual machine o container, patch server, operating system, internet gateway, atbp. Sa pamamagitan ng pag-abstract sa lahat ng mga responsibilidad na ito, ang isang serverless architecture ay maaaring tumuon sa core - ang solusyon.negosyo at pangangailangan ng customer.
Habang ang toolkit ay maaaring maging mas mahusay (ito ay nagiging mas mahusay araw-araw), ang mga developer ay maaaring tumuon sa pagpapatupad ng negosyo logic at pinakamahusay na pamamahagi ng pagiging kumplikado ng application sa iba't ibang mga serbisyo sa loob ng arkitektura. Ang pamamahala ng application na walang server ay batay sa kaganapan at na-abstract ng cloud provider (hal. SQS, mga kaganapan sa S3 o mga stream ng DynamoDB). Samakatuwid, kailangan lang ng mga developer na magsulat ng lohika ng negosyo upang tumugon sa ilang partikular na kaganapan, at hindi kailangang mag-alala tungkol sa kung paano pinakamahusay na ipatupad ang mga database at mga pila ng mensahe, o kung paano ayusin ang pinakamainam na trabaho gamit ang data sa mga partikular na imbakan ng hardware.
Maaaring patakbuhin at i-debug ang code nang lokal, tulad ng anumang proseso ng pag-unlad. Ang pagsubok sa yunit ay nananatiling pareho. Ang kakayahang mag-deploy ng isang buong imprastraktura ng application na may custom na pagsasaayos ng stack ay nagbibigay-daan sa mga developer na mabilis na makakuha ng mahalagang feedback nang hindi iniisip ang tungkol sa gastos ng pagsubok o ang epekto sa mga mamahaling pinamamahalaang kapaligiran.
Mga tool at diskarte para sa pagbuo ng mga serverless na application
Walang tiyak na paraan upang bumuo ng mga serverless na application. Pati na rin ang isang hanay ng mga serbisyo para sa gawaing ito. Ang AWS ang nangunguna sa mga mahuhusay na solusyon sa serverless ngayon, ngunit tingnan din , ΠΈ . Kung gumagamit ka ng AWS, ang inirerekomendang diskarte para sa pagkolekta ng mga application ay (SAM), lalo na kapag gumagamit ng C#, dahil ang Visual Studio ay may mahusay na tooling. Magagawa ng SAM CLI ang lahat ng magagawa ng Visual Studio, kaya walang mawawala sa iyo kung lilipat ka sa isa pang IDE o text editor. Siyempre, gumagana rin ang SAM sa iba pang mga wika.
Kung nagsusulat ka sa ibang mga wika, ang Serverless Framework ay isang mahusay na open source na tool na nagbibigay-daan sa iyong i-configure ang anumang bagay na may napakalakas na YAML configuration file. Sinusuportahan din ng Serverless Framework ang iba't ibang serbisyo sa cloud, kaya inirerekomenda namin ito sa mga naghahanap ng multi-cloud na solusyon. Mayroon itong malaking komunidad na lumikha ng isang bungkos ng mga plugin para sa anumang pangangailangan.
Para sa lokal na pagsubok, ang mga open source na tool na Docker-Lambda, Serverless Local, DynamoDB Local, at LocalStack ay angkop na angkop. Ang mga teknolohiyang walang server ay nasa kanilang mga unang yugto ng pag-unlad, gayundin ang mga tool para sa kanila, kaya kapag nagse-set up para sa mga kumplikadong sitwasyon ng pagsubok, kailangan mong magtrabaho nang husto. Gayunpaman, ang simpleng pag-deploy ng stack sa isang kapaligiran at pagsubok doon ay hindi kapani-paniwalang mura. At hindi mo kailangang gumawa ng eksaktong lokal na kopya ng mga cloud environment.
Gamitin ang AWS Lambda Layers para bawasan ang laki ng mga naka-deploy na package at pabilisin ang mga pag-download.
Gamitin ang tamang programming language para sa mga partikular na gawain. Ang iba't ibang mga wika ay may sariling mga pakinabang at disadvantages. Maraming mga benchmark, ngunit ang JavaScript, Python, at C# (.NET Core 2.1+) ang nangunguna sa pagganap ng AWS Lambda. Ipinakilala kamakailan ng AWS Lambda ang Runtime API, na nagbibigay-daan sa iyong tukuyin ang iyong gustong runtime na wika at kapaligiran, kaya mag-eksperimento.
Panatilihing maliit ang mga laki ng package para sa pag-deploy. Kung mas maliit ang mga ito, mas mabilis silang mag-load. Iwasang gumamit ng malalaking library, lalo na kung gumagamit ka ng ilang feature mula sa kanila. Kung nagprograma ka sa JavaScript, gumamit ng build tool tulad ng Webpack para i-optimize ang iyong build at isama lang ang talagang kailangan mo. Ang .NET Core 3.0 ay mayroong QuickJit at Tiered Compilation na nagpapaganda ng performance at nakakatulong ng malaki sa mga cold start.
Ang pagtitiwala sa mga function na walang server sa mga kaganapan ay maaaring magpahirap sa pag-coordinate ng lohika ng negosyo sa simula. Sa pagsasaalang-alang na ito, ang mga pila ng mensahe at mga makina ng estado ay maaaring maging lubhang kapaki-pakinabang. Ang mga function ng Lambda ay maaaring tumawag sa isa't isa, ngunit gawin lamang ito kung hindi ka umaasa ng tugon ("fire and forget") - hindi mo gustong masingil para sa paghihintay para sa isa pang function na makumpleto. Ang mga pila ng mensahe ay kapaki-pakinabang para sa paghihiwalay ng mga bahagi ng lohika ng negosyo, pamamahala ng mga bottleneck ng application, at pagproseso ng mga transaksyon (gamit ang mga pila ng FIFO). Maaaring italaga ang mga function ng AWS Lambda sa mga pila ng SQS bilang mga naka-stuck na queue ng mensahe na sumusubaybay sa mga nabigong mensahe para sa pagsusuri sa ibang pagkakataon. Ang AWS Step Functions (mga state machine) ay lubhang kapaki-pakinabang para sa pamamahala ng mga kumplikadong proseso na nangangailangan ng chaining ng mga function. Sa halip na isang Lambda na function ang tumawag sa isa pang function, ang mga step function ay maaaring mag-coordinate ng state transition, magpasa ng data sa pagitan ng mga function, at pamahalaan ang pandaigdigang estado ng mga function. Binibigyang-daan ka nitong tukuyin ang mga kundisyon na subukan muli, o kung ano ang gagawin kapag may nangyaring partikular na error - isang napakalakas na tool sa ilang partikular na kundisyon.
Konklusyon
Sa mga nagdaang taon, ang mga teknolohiyang walang server ay umuunlad sa hindi pa nagagawang bilis. Mayroong ilang mga maling kuru-kuro na nauugnay sa pagbabagong ito ng paradigm. Sa pamamagitan ng pag-abstract ng imprastraktura at pamamahala ng scaling, nag-aalok ang mga walang server na solusyon ng mga makabuluhang benepisyo, mula sa pinasimpleng pag-unlad at mga proseso ng DevOps hanggang sa napakalaking pagbawas sa mga gastos sa pagpapatakbo.
Bagama't ang diskarte na walang server ay walang mga disbentaha nito, may mga matatag na pattern ng disenyo na maaaring magamit upang bumuo ng matatag na mga application na walang server o isama ang mga elementong walang server sa mga umiiral nang arkitektura.
Pinagmulan: www.habr.com