Pangunahing puntos
- Sa loob ng ilang taon na ngayon, ipinangako sa amin na ang serverless computing ay magdadala sa isang bagong panahon na walang partikular na OS na magpapatakbo ng mga application. Sinabi sa amin na malulutas ng istrukturang ito ang maraming problema sa scalability. Sa katunayan, ang lahat ay iba.
- Habang tinitingnan ng marami ang walang server bilang isang bagong ideya, ang mga pinagmulan nito ay maaaring masubaybayan noong 2006 sa pagdating ng Zimki PaaS at Google App Engine, na parehong gumagamit ng walang server na arkitektura.
- Mayroong apat na dahilan kung bakit tumigil ang serverless revolution, mula sa limitadong suporta sa programming language hanggang sa mga isyu sa performance.
- Ang serverless computing ay hindi lahat na walang silbi. Hindi talaga. Gayunpaman, hindi sila dapat ituring na isang direktang kapalit para sa mga server. Para sa ilang mga application maaari silang maging isang madaling gamiting tool.
Patay na ang server, mabuhay ang server!
Ito ang sigaw ng labanan ng walang server na rebolusyon. Isang mabilis na sulyap sa industriya press sa nakalipas na ilang taon at madaling isiping patay na ang tradisyonal na modelo ng server at sa loob ng ilang taon ay gagamit na tayong lahat ng mga serverless architecture.
Tulad ng alam ng sinuman sa industriya, at tulad ng itinuro din namin sa aming artikulo sa , mali ito. Sa kabila ng maraming mga artikulo tungkol sa mga merito , hindi ito naganap. Sa katunayan, na ang rebolusyong ito ay maaaring umabot sa isang patay na dulo.
Ang ilan sa mga pangako ng mga modelong walang server ay tiyak na natupad, ngunit hindi lahat. Hindi lahat.
Sa artikulong ito gusto kong tingnan ang mga dahilan para sa kondisyong ito. Kung bakit ang kakulangan ng flexibility ng mga serverless na modelo ay hadlang pa rin sa kanilang mas malawak na pag-aampon, kahit na nananatiling kapaki-pakinabang ang mga ito sa mga partikular at mahusay na tinukoy na mga pangyayari.
Ano ang ipinangako ng mga dalubhasa sa serverless computing
Bago tayo pumasok sa mga hamon ng serverless computing, tingnan natin kung ano ang dapat na ibigay nito. ay marami at - kung minsan - napaka ambisyoso.
Para sa mga hindi pamilyar sa termino, narito ang isang mabilis na kahulugan. Ang serverless computing ay tumutukoy sa isang arkitektura kung saan ang mga application (o mga bahagi ng mga application) ay tumatakbo nang on demand sa mga runtime na kapaligiran na karaniwang naka-host nang malayuan. Bilang karagdagan, ang mga serverless system ay maaaring i-host sa bahay. Ang pagbuo ng nababanat na mga sistemang walang server ay isang pangunahing alalahanin para sa mga tagapangasiwa ng system at mga kumpanya ng SaaS sa nakalipas na ilang taon, dahil (ito ay inaangkin) ang arkitektura na ito ay nag-aalok ng ilang pangunahing bentahe sa "tradisyonal" na modelo ng client-server:
- Ang mga modelong walang server ay hindi nangangailangan ng mga user na panatilihin ang kanilang sariling mga operating system o kahit na lumikha ng mga application na tugma sa mga partikular na OS. Sa halip, gumagawa ang mga developer ng nakabahaging code, ina-upload ito sa isang walang server na platform, at panoorin itong tumatakbo.
- Ang mga mapagkukunan sa mga walang server na framework ay karaniwang sinisingil ng minuto (o kahit na ang segundo). Nangangahulugan ito na ang mga kliyente ay nagbabayad lamang para sa oras na aktwal nilang patakbuhin ang code. Ito ay maihahambing sa isang tradisyunal na cloud VM, kung saan ang makina ay idle halos lahat ng oras, ngunit kailangan mong magbayad para dito.
- Nalutas din ang problema sa scalability. Ang mga mapagkukunan sa mga framework na walang server ay dynamic na itinalaga upang ang system ay madaling makayanan ang mga biglaang pag-akyat sa demand.
Sa madaling salita, ang mga modelong walang server ay nagbibigay ng nababaluktot, mura, at nasusukat na mga solusyon. Nakakagulat na hindi namin naisip ang ideyang ito nang mas maaga.
Ito ba ay talagang isang bagong ideya?
Sa katunayan, ang ideya ay hindi bago. Ang konsepto ng pagpayag sa mga user na magbayad lamang para sa oras na aktwal na tumatakbo ang code ay umiikot mula noong ipinakilala ito ni noong 2006, at sa parehong oras ay nag-alok ang Google App Engine ng halos katulad na solusyon.
Sa katunayan, ang tinatawag natin ngayon na "walang server" na modelo ay mas luma kaysa sa maraming teknolohiyang tinatawag na ngayong "cloud native" na nagbibigay ng halos parehong bagay. Tulad ng nabanggit, ang mga modelong walang server ay mahalagang extension lamang ng modelo ng negosyo ng SaaS na nasa loob ng mga dekada.
Ito rin ay nagkakahalaga ng pagkilala na ang serverless ay hindi isang arkitektura ng FaaS, bagama't may koneksyon sa pagitan ng dalawa. Ang FaaS ay mahalagang bahagi ng compute-centric ng isang walang server na arkitektura, ngunit hindi ito kumakatawan sa buong system.
Kaya ano ang lahat ng kaguluhan tungkol sa? Buweno, habang ang mga rate ng pagtagos ng internet ay patuloy na tumataas sa mga umuunlad na bansa, ang pangangailangan para sa mga mapagkukunan ng computing ay tumataas din sa parehong oras. Halimbawa, maraming mga bansa na may mabilis na lumalagong mga sektor ng e-commerce ay walang sapat na imprastraktura sa pag-compute para sa mga aplikasyon sa mga platform na ito. Dito pumapasok ang mga bayad na serverless platform.
Mga problema sa Mga Modelong Walang Server
Ang catch ay ang mga serverless na modelo ay may... mga problema. Huwag kang magkamali: Hindi ko sinasabing masama sila o hindi nagbibigay ng makabuluhang halaga sa ilang kumpanya sa ilang pagkakataon. Ngunit ang pangunahing pag-aangkin ng "rebolusyon" -na ang walang server na arkitektura ay mabilis na papalitan ang tradisyonal na arkitektura - ay hindi kailanman matutupad.
kaya lang.
Limitadong suporta para sa mga programming language
Karamihan sa mga platform na walang server ay nagpapahintulot lamang sa iyo na magpatakbo ng mga application na nakasulat sa ilang mga wika. Seryosong nililimitahan nito ang flexibility at adaptability ng mga system na ito.
Ang mga platform na walang server ay itinuturing na sumusuporta sa karamihan ng mga pangunahing wika. Nagbibigay din ang AWS Lambda at Azure Functions ng wrapper para sa pagpapatakbo ng mga application at function sa mga hindi sinusuportahang wika, bagama't madalas itong may kasamang gastos sa pagganap. Kaya para sa karamihan ng mga organisasyon ang limitasyong ito ay karaniwang hindi isang malaking bagay. Ngunit narito ang bagay. Ang isa sa mga benepisyo ng mga modelong walang server ay dapat na ang mga hindi kilalang, bihirang ginagamit na mga programa ay maaaring magamit nang mas mura dahil magbabayad ka lamang para sa oras na tumatakbo ang mga ito. At ang mga hindi kilalang, bihirang ginagamit na mga programa ay kadalasang nakasulat sa... hindi gaanong kilala, bihirang ginagamit na mga programming language.
Pinapahina nito ang isa sa mga pangunahing benepisyo ng modelong walang server.
Nagbubuklod ng vendor
Ang pangalawang problema sa mga walang server na platform, o hindi bababa sa paraan ng kanilang kasalukuyang ipinapatupad, ay ang mga ito ay karaniwang hindi katulad sa isa't isa sa antas ng pagpapatakbo. Halos walang standardisasyon sa mga tuntunin ng pag-andar ng pagsulat, pag-deploy at pamamahala. Nangangahulugan ito na ang paglilipat ng mga feature mula sa isang platform patungo sa isa pa ay lubhang nakakaubos ng oras.
Ang pinakamahirap na bahagi ng paglipat sa isang serverless na modelo ay hindi ang mga compute function, na kadalasan ay mga snippet lang ng code, ngunit kung paano nakikipag-ugnayan ang mga application sa mga konektadong system gaya ng object storage, identity management, at queue. Maaaring ilipat ang mga function, ngunit hindi maaaring ilipat ang natitirang bahagi ng application. Ito ang eksaktong kabaligtaran ng mura at nababaluktot na mga platform na ipinangako.
Ang ilan ay nangangatwiran na ang mga modelong walang server ay bago at wala pang oras upang i-standardize kung paano gumagana ang mga ito. Ngunit ang mga ito ay hindi na bago, tulad ng nabanggit ko sa itaas, at maraming iba pang mga teknolohiya ng ulap, tulad ng mga lalagyan, ay naging mas kapaki-pakinabang salamat sa pag-unlad at malawakang pag-aampon ng magagandang pamantayan.
Pagiging Produktibo
Ang pagganap ng pag-compute ng mga serverless platform ay mahirap sukatin, sa isang bahagi dahil ang mga vendor ay may posibilidad na panatilihing pribado ang impormasyon. Karamihan ay nangangatuwiran na ang mga pag-andar sa malayuan, walang server na mga platform ay tumatakbo nang kasing bilis ng mga nasa panloob na server, maliban sa ilang hindi maiiwasang isyu sa latency.
Gayunpaman, ang mga indibidwal na katotohanan ay nagpapahiwatig ng kabaligtaran. Ang mga feature na hindi pa tumatakbo dati sa isang partikular na platform o matagal nang hindi tumatakbo ay magtatagal bago masimulan. Ito ay malamang dahil sa katotohanan na ang kanilang code ay nai-port sa ilang hindi gaanong naa-access na storage medium, bagaman - tulad ng sa mga benchmark - karamihan sa mga vendor ay hindi sasabihin sa iyo ang tungkol sa paglipat ng data.
Siyempre, may ilang mga paraan sa paligid nito. Ang isa ay ang pag-optimize ng mga feature para sa anumang cloud language na pinapatakbo ng iyong walang server na platform, ngunit medyo pinapahina nito ang pag-aangkin na ang mga platform na ito ay "maliksi."
Ang isa pang diskarte ay upang matiyak na ang mga programang kritikal sa produktibidad ay regular na pinapatakbo upang panatilihing sariwa ang mga ito. Ang pangalawang diskarte na ito, siyempre, ay medyo kontradiksyon sa pag-aangkin na ang mga platform na walang server ay mas cost-effective dahil magbabayad ka lang sa oras na tumatakbo ang iyong mga programa. Ang mga cloud provider ay nagpakilala ng mga bagong paraan upang bawasan ang malamig na pagsisimula, ngunit marami sa kanila ay nangangailangan ng "scale to one," na nagpapahina sa orihinal na halaga ng FaaS.
Ang problema sa malamig na pagsisimula ay maaaring bahagyang malutas sa pamamagitan ng pagpapatakbo ng mga serverless system sa loob ng bahay, ngunit ito ay kasama ng sarili nitong mga gastos at nananatiling isang angkop na opsyon para sa mahusay na mapagkukunan na mga koponan.
Hindi mo maaaring patakbuhin ang buong application
Sa wakas, marahil ang pinakamahalagang dahilan kung bakit hindi mapapalitan ng mga walang server na arkitektura ang mga tradisyonal na modelo anumang oras sa lalong madaling panahon: hindi sila (karaniwan) ay maaaring magpatakbo ng mga buong application.
Mas tiyak, ito ay hindi praktikal mula sa isang punto ng gastos. Ang iyong matagumpay na monolith ay malamang na hindi dapat gawing set ng apat na dosenang function na konektado ng walong gateway, apatnapung pila at isang dosenang database instances. Para sa kadahilanang ito, ang serverless ay mas angkop para sa mga bagong development. Halos walang umiiral na application (arkitektura) ang maaaring ilipat. Maaari kang mag-migrate, ngunit kailangan mong magsimula sa simula.
Nangangahulugan ito na sa karamihan ng mga kaso, ginagamit ang mga walang server na platform bilang pandagdag sa mga back-end na server upang magsagawa ng mga compute-intensive na gawain. Ito ay ginagawang ibang-iba sa mga ito mula sa iba pang dalawang anyo ng mga teknolohiya ng ulapβmga lalagyan at virtual machineβna nag-aalok ng isang holistic na paraan upang maisagawa ang malayuang pag-compute. Inilalarawan nito ang isa sa mga hamon ng paglipat mula sa mga microservice patungo sa walang server.
Siyempre, hindi ito palaging isang problema. Ang kakayahang pana-panahong gumamit ng napakalaking mapagkukunan ng computing nang hindi kinakailangang bumili ng sarili mong hardware ay maaaring magdala ng tunay, pangmatagalang benepisyo sa maraming organisasyon. Ngunit kapag ang ilang mga application ay naninirahan sa mga panloob na server at ang iba sa mga serverless cloud architecture, ang pamamahala ay tumatagal sa isang bagong antas ng pagiging kumplikado.
Mabuhay ang rebolusyon?
Sa kabila ng lahat ng mga reklamong ito, hindi ako laban sa mga walang server na solusyon sa bawat isa. Sa totoo lang. Kailangan lang maunawaan ng mga developerβlalo na kung nag-e-explore sila nang walang server sa unang pagkakataonβna ang teknolohiya ay hindi direktang kapalit para sa mga server. Sa halip, tingnan ang aming mga tip at mapagkukunan para sa at magpasya kung paano pinakamahusay na ilapat ang modelo.
Pinagmulan: www.habr.com