AWS at IBM: isang Paghahambing sa Mga Serbisyo ng IoT: 4 na Hakbang

2024 May -akda: John Day | [email protected]. Huling binago: 2024-01-30 13:13

Ngayon ay pinaghahambing namin ang dalawang mga stack na ginagawang posible upang paunlarin ang mga aplikasyon ng IoT sa ilalim ng pananaw ng iba't ibang mga alok ng serbisyo.

Hakbang 1: Mga Pag-andar Bilang Isang Serbisyo

Ang FaaS ay isang kategorya ng mga serbisyong cloud na ginamit upang bumuo ng isang "serverless" na arkitektura. Pinapayagan ng FaaS ang mga customer na bumuo, magpatakbo, at pamahalaan ang mga pagpapaandar ng aplikasyon nang hindi itinatayo at pinapanatili ang imprastraktura.

Nag-aalok ang Amazon ng AWS Lambda, nag-aalok ang IBM ng IBM Cloud Function. Ang mga serbisyong iyon ay halos magkatulad, subalit ang Lambda ang nauna sa ganitong uri. Gamit ang FaaS maaari kang magpatakbo ng mga piraso ng code sa cloud at sinusuportahan ng bawat serbisyo ang iba't ibang mga wika ng programa.

Mga Function ng IBM Cloud: JavaScript, Swift, Java, Go, Php, Python, Ruby,. NET (C # F # atbp.), Anumang sa pamamagitan ng Docker AWS Lambda: JavaScript, Java, C #, F #, Go, Python, Ruby, PowerShell, Anumang sa pamamagitan ng Runtime API

Sinusuportahan ng IBM ang higit pang mga wika at sa docker ay madaling gamitin ang mga script na nakasulat sa ibang mga wika. Maaari rin itong gawin sa Lambda ngunit hindi ito agaran. Maaari mong basahin ang isang halimbawa dito:

Ang parehong mga serbisyo ay may mga limitasyon sa paggamit, iniuulat namin ang mga ito sa isang talahanayan at i-highlight ang pinakamahusay.

Ang presyo ay batay sa GigaBytes bawat segundo (RAM) na may pagdaragdag ng bilang ng mga kahilingan para sa AWS Lambda. Ang bawat serbisyo ay may isang libreng plano at halos katumbas ang mga ito. Tulad ng nakikita mo na ang Lambda ay medyo mas mura para sa GB / s ngunit mayroon itong gastos na nauugnay sa mga kahilingan na wala ang Cloud Function kaya't halos pareho ang gastos sa pangkalahatan. Siyempre, kung kailangan mong magpatakbo ng mga gawain na kumakain ng memorya at gumagamit ng kaunting mga kahilingan dapat mong gamitin ang Lambda. Ang pangunahing bentahe ng IBM Cloud Function, sa aming palagay, ay ang stack nito ay bukas na mapagkukunan. Ito ay ganap na batay sa Apache OpenWhisk at maaari ding i-deploy sa isang pribadong imprastraktura.

Hakbang 2: Pag-aaral ng Makina

Ang isang patlang kung saan ang IBM at AWS stack ay nag-aalok ng mga katulad na serbisyo ay ang pag-aaral ng machine: Amazon kasama ang SageMaker at IBM na may Watson Machine Learning. Ang dalawang serbisyo ay sa maraming mga aspeto na magkatulad: kapwa ipinakita ang kanilang mga sarili bilang mga tool upang matulungan ang mga siyentipiko ng data at mga developer na bumuo, sanayin at pagkatapos ay i-deploy sa mga handa na produksyon ang kanilang mga modelo sa pag-aaral ng makina, ngunit ang mga pilosopiya na pinagtibay ng dalawang kumpanya ay medyo nag-iiba. Pinapayagan ka ng parehong mga serbisyo na pumili sa pagitan ng iba't ibang antas ng kontrol sa mga modelo na iyong ginagamit. Sa Watson ML, mayroon kang ilang mga built-in na modelo na sinanay na upang gawin ang ilang mga tiyak na gawain: halimbawa, kung nais mong makilala kung anong mga bagay ang naroroon sa isang larawan na-import mo lamang ang modelo ng VisualRecognitionV3 at ipasa rito ang larawan na iyong nais na pag-aralan. Maaari ka ring bumuo ng isang "pasadyang modelo", ngunit sa Watson ML ito ay nangangahulugang pagkuha ng isang naka-built na modelo at gawin ang aming pagsasanay dito, kaya't ang pagpapasadya ay medyo limitado. Mahalagang pansinin na kahit na ang SageMaker o Watson ML ay hindi lamang ang mga paraan ng paggawa ng pag-aaral ng makina sa mga stack ng kanilang mga developer, ang mga ito ay mga serbisyo lamang na naglalayong gawing mas madali ang buhay ng mga developer. Sinusuportahan din ng platform ng Watson ML ang marami sa mga pinakatanyag na aklatan ng machine machine, kaya maaari ka ring bumuo ng isang modelo mula sa simula sa PyTorch, Tensorflow o mga katulad na aklatan. Maaaring direkta mong gamitin ang mga silid-aklatan na iyon, o gamitin ang paunang ginawa na mga modelo, walang gitnang batayan. Gayundin ang Watson ML ay hindi sumusuporta sa pagpipilian ng library ng Amazon, Apache MXNet, na sa halip ay may suporta sa unang klase sa SageMaker.

Ang diskarte ng Amazon SageMaker, kahit na gumagamit ng mga built-in na pagpipilian, ay medyo mas mababang antas: sa halip na piliin ka mula sa mga paunang ginawa na mga modelo, pinapayagan kang pumili mula sa isang napakaraming naipatupad na mga algorithm sa pagsasanay, na maaari mong gamitin kapag itinatayo ang iyong modelo sa isang mas tradisyunal na paraan. Kung hindi sapat ang mga ito, maaari mo ring gamitin ang iyong sariling algorithm. Ang ganitong paraan ng paggawa ng mga bagay-bagay ay tiyak na nangangailangan ng higit na kaalaman sa kung paano ginagawa ang pag-aaral ng makina kumpara sa paggamit lamang ng isang may kasanayang modelo sa Watson ML.

Sa isang unang tingin ay maaaring mukhang ang Watson ML ay ang "madali at mabilis" na paraan, kasama ang Amazon SageMaker na mas kumplikadong i-set up. Maaaring hindi ito ganap na totoo mula sa ilang mga punto ng view, tulad ng SageMaker ay nakabalangkas upang mapatakbo ang lahat sa isang Jupyter Notebook, habang para sa parehong mga tampok sa Watson ML kailangan mong mag-set up ng maraming iba't ibang mga sub-serbisyo mula sa web UI. Ang preprocessing ng data ay mayroon ding nakatuon na mga puwang sa serbisyong IBM habang ang SageMaker ay umaasa sa iyong ginagawa ang lahat mula sa code sa iyong kuwaderno. Dagdag nito ang katotohanang ang mga notebook ng Jupyter ay hindi eksakto ang pinakamahusay na pagpipilian mula sa isang pananaw ng software engineering, maaaring hadlangan ang SageMaker mula sa pag-scale nang mahusay sa paggawa. Ang parehong mga serbisyo ay may magandang at simpleng mga mekanismo upang mai-deploy ang iyong modelo at gawing magagamit ang mga API para dito sa labas ng mundo.

Bilang konklusyon, ang Watson ML ay gumaganap nang mas mahusay sa mga malalaking proyekto kung saan nagsisimulang ipakita ang mga notebook ng Jupyter ang kanilang mga limitasyon, at kung saan hindi mo kailangan ng labis na pagpapasadya sa kung ano mismo ang ginagawa ng modelo. Ang SageMaker ay mas mahusay kung kailangan mo ng higit na kakayahang umangkop sa pagtukoy ng mga algorithm, ngunit kapag ginagamit ito kailangan mong isaalang-alang ang katotohanang kailangan mong umasa sa Jupyter Notebooks, na maaaring hindi masukat nang mahusay sa produksyon. Ang isang solusyon ay maaaring upang mai-decouple ang natitirang code mula sa modelo hangga't maaari, upang ang code sa aktwal na mga notebook ay hindi masyadong malaki at mas mahusay naming ayusin ang aming software sa iba pang mga module na ginagamit lamang ang API ng aming modelo..

Hakbang 3: Pag-stream ng Data at Analytics

Ang mga serbisyo ng streaming ng data ay mahalaga sa paghawak at pag-aaral sa real time na malalaking daloy ng data. Ang daloy na ito ay maaaring mula sa cloud patungo sa aparato ng mga gumagamit, tulad ng isang streaming ng video, o mula sa mga gumagamit patungo sa cloud, tulad ng IoT telemetry at pagbabasa ng sensor. Lalo na sa pangalawang kaso, maaari kaming magkaroon ng isang sitwasyon kung saan ang mga solong mapagkukunan ay nag-a-upload ng maliit na halaga ng data ngunit kapag isinasaalang-alang namin ang pangkalahatang throughput, na nagmumula sa lahat ng mga aparato, kumokonsumo ito ng malaking bandwidth, kaya makatuwiran na gumamit ng isang dalubhasang serbisyo upang hawakan ang ganoong daloy ng data. Nang walang paghawak ng tuluy-tuloy na daloy na ito nang direkta, kakailanganin naming i-buffer ang papasok na impormasyon sa isang pansamantalang imbakan at sa isang pangalawang pagkakataon iproseso ito ng ilang computational engine. Ang problema ng huling diskarte na ito ay kakailanganin naming mag-coordinate ng higit pang magkakaibang mga serbisyo upang makamit kung ano ang nag-iisa na ang serbisyo ng stream ng data, na nagdaragdag ng pagiging kumplikado ng pagpapanatili at pagsasaayos ng application. Bilang karagdagan, ang buffering ay maaaring sa prinsipyo gawin ang aming aplikasyon hindi na sa real time, dahil para sa isang item na maiproseso kinakailangan na ang lahat ng iba pang mga item bago ito maproseso din, at ang pagdaragdag ng mga patakaran sa precedence sa buffer maaari, muli, dagdagan ang pagiging kumplikado nang husto. Sa kabuuan, nag-aalok ang mga serbisyo ng streaming ng data ng paghawak ng daloy ng data sa real time, na may isang madaling pagsasaayos, at maaaring magbigay ng analytics sa papasok na data. Inihambing namin ang dalawang pangunahing serbisyo sa streaming ng IBM at AWS stack, lalo na ang IBM Streams at AWS Kinesis.

Nagsisimula kami sa pamamagitan ng pagpuna na ang lahat ng mga pangunahing tampok na maaaring gusto namin mula sa isang streaming na serbisyo ay inaalok ng parehong IBM at AWS. Ang mga tampok na ito ay nagsasama ng halos walang katapusang rate ng pagproseso, mababang latency at real time data analytics. Dahil pinag-uusapan natin ang tungkol sa mga propesyonal na serbisyo, pareho silang nag-aalok ng mga tool sa antas ng produksyon para sa pag-deploy at automation.

Pinag-uusapan tungkol sa data analytics, inaalok ito ng parehong mga serbisyo bilang isang opsyonal, na magbabayad ka lamang kung kailangan mo ito o hindi. Sa kaso ng Kinesis, kapag hindi mo kailangan ng analytics ngunit paghawak lamang sa daloy ng data, sisingilin ang mga presyo bawat GB na naproseso sa halip na oras ng pagproseso, tulad ng sa kaso ng IBM. Ang pagpepresyo bawat GB sa pangkalahatan ay magiging mas mura kaysa sa pagpepresyo bawat oras, dahil nagbabayad ka lamang para sa papasok na trapiko. Para sa natitirang post na ito isasaalang-alang namin ang parehong IBM Streams at AWS Kinesis na pinagana ang tampok na analytics ng data.

Nagbibigay ang mga Stream at Kinesis ng pagsasama sa iba't ibang mga serbisyo para sa paunang pagproseso at pag-filter ng papasok na data bago ipasa ang mga ito sa data analytics, ayon sa Apache Edgent at AWS Lambda. Habang ang mga serbisyong ito ay radikal na magkakaiba sa isa't isa, tatalakayin lamang namin ang mga ito mula sa pananaw ng dalawang serbisyo sa streaming. Ang pangunahing pagkakaiba sa pagitan ng dalawa ay ang Apache Edgent na nagpapatupad sa aparato, habang ang AWS Lambda ay nagpapatupad sa cloud. Nagdudulot ito ng maraming kalamangan at kahinaan: mula sa panig ng Lambda mayroon kaming isang nababaluktot at madaling gamiting serbisyo na may isang seamless na pagsasama sa Kinesis, ngunit kinakailangan nito ang data na ma-upload sa cloud, kaya't nawawala sa kahusayan at nagbabayad din ng Kinesis para sa data na kalaunan ay itatapon. Mula sa panig ng Edgent, mayroon kaming na ang karamihan sa pagkalkula ay tapos na, mabuti, sa gilid ng network (kaya sa mga aparato) bago mag-upload ng walang kwentang data sa cloud. Ang pangunahing sagabal ay ang Edgent ay isang malaking balangkas, na maaaring mangailangan ng oras upang mai-set up at maaaring maging kumplikado upang mapanatili. Ang isa pang pagkakaiba na maaaring nauugnay sa pagpili ng isang platform ay ang Edgent ay buong bukas na mapagkukunan, ang Lambda ay hindi. Maaari itong makita kapwa bilang isang pro, dahil ang pagkakaroon ng pag-access sa code na isasagawa mo o ng iyong customer ay palaging isang positibong bagay, kapwa bilang isang con, dahil maaaring may mga sitwasyon kung saan kailangan mo ng agarang suporta na hindi maibigay sa lahat ng mga kapaligiran sa open source.

Ang iba pang mga tampok na maaari nating banggitin ay ang auto-scalability ng Kinesis ng inilaan na mga mapagkukunan. Sa katunayan, ang hardware na inaalok nito ay binubuo ng isang bilang ng tinatawag na Kinesis Processing Units (KPUs) na tumatakbo nang kahanay, kung saan ang isang KPU ay nag-aalok ng 1 vCore at 4GB ng RAM. Ang kanilang numero ay nakasalalay sa mga pangangailangan ng aplikasyon at dinamiko at awtomatikong inilalaan (kung ano ang iyong babayaran ay ang oras ng CPU oras na bilang ng mga KPU), tandaan lamang na isang patakaran ng Kinesis na singilin ka ng higit sa isang KPU kung gumamit ka ng isang Java aplikasyon. Ang IBM Streams, sa halip, ay hindi nagbibigay ng ganitong uri ng kakayahang umangkop, na nag-aalok sa iyo ng isang lalagyan na may nakapirming hardware, higit pang mga detalye kapag pinag-uusapan namin ang tungkol sa pagpepresyo. Sa kabilang banda, ang IBM Streams ay mas bukas kaysa sa Kinesis, dahil nakikipag-interface ito sa WAN sa pamamagitan ng mga karaniwang ginamit na mga protokol, tulad ng HTTP, MQTT at iba pa, habang ang Kinesis ay sarado sa AWS ecosystem.

Bilang pangwakas na paghahambing pag-usapan natin ang tungkol sa pagpepresyo, at hayaan mong sabihin ko na hindi gagana ang IBM sa puntong ito. Na-configure namin ang iba't ibang mga solusyon para sa tatlong magkakaibang kategorya (pangunahing, high-end, ultra-high-end) para sa parehong IBM at AWS, at ihahambing namin ang kanilang presyo. Sa pangunahing pagsasaayos mayroon kaming isang AWS KPU, na nabanggit nang mas maaga, laban sa isang solusyon sa IBM na may parehong hardware. Para sa high-end mayroon kaming 8 KPUs na tumatakbo ay parallel para sa Kinesis at 2 lalagyan na laging kahanay para sa IBM, bawat isa ay may 4 vCores at 12GB ng RAM. Palaging nag-aalok ang IBM sa ultra-high-end ng isang solong lalagyan na may 16 vCores at 128GB ng RAM, habang tinanggal namin ang isang katumbas na solusyon para sa AWS, dahil kung ang ilang aplikasyon ay nangangailangan ng malaking dami ng RAM na ito ay hindi posible na patakbuhin ito sa iba't ibang mga KPU. Ang mga presyo na naiulat namin ay ipinahayag sa $ / buwan isinasaalang-alang ang isang 24/7 na paggamit. Para sa pangunahing pagsasaayos na mayroon kami para sa IBM at AWS ayon sa pagkakabanggit 164 $ at 490 $, para sa high-end 1320 $ at 3500 $, para sa ultra-high-end na AWS ay hindi isinasaalang-alang at mayroon lamang IBM na may 6300 $. Mula sa mga resulta ay makikita natin na ang Kinesis ay mas mahusay na gumagana para sa pang-araw-araw na gumagamit hanggang sa antas ng enterprise, habang wala itong mga pagpipilian upang direktang hawakan ang data analytics na nangangailangan ng napakalaking halaga ng kapangyarihan sa computing. Naghahatid ang Kinesis ng mas mahusay na ratio ng pagganap / $ kaysa sa Mga Stream ng IBM, na tinulungan din ng dinamikong paglalaan ng maliit na mga bloke ng mapagkukunan lamang kung kinakailangan, habang inaalok ka ng IBM ng isang nakapirming lalagyan. Sa ganitong paraan, kung ang iyong karga sa trabaho ay nailalarawan ng mga taluktok, sa IBM napipilitan kang sobra-sobra ang iyong mga pangangailangan sa aplikasyon at pag-configure ng isang solusyon sa pinakapangit na sitwasyon. Nag-aalok ang IBM ng mga bayarin sa oras sa halip na bayaran ang buong buwan, ngunit hindi ito awtomatiko bilang Kinesis.

Hakbang 4: IoT Architecture

Ang pagsasaayos para sa mga aparato para sa aws iot ay medyo madali kung ihinahambing sa ibm watson iot. Sapagkat sa ibm watson iot ang pagpapatotoo ay bawat aparato na may token at sa sandaling maipakita ang token hindi na ito muling ipakita. Ang pagpunta sa bahagi ng pagpepresyo muli ibm watson iot ay medyo magastos kung ihahambing sa aws iot. Kaya, ang presyo sa mga singil sa ibm watson iot ay batay sa bawat aparato, imbakan ng data, trapiko ng data. Ngunit sa mga kamangha-manghang maaari naming bayaran ang halaga nang isang beses at maaari kaming magdagdag ng higit pang mga aparato at data na nai-publish mula sa mga aparato at naihatid sa mga aparato.

Magsimula sa iyong aparato- kung ito ay isang sensor, gateway, o iba pa- at hayaan kang tulungan kang makakonekta sa cloud.

Palaging ligtas ang data ng iyong aparato kapag kumonekta ka sa cloud gamit ang bukas, magaan na MGTT messaging protocol o HTTP. Sa tulong ng mga protocol at node-red maaari naming maiugnay ang aming aparato sa iot platform at ma-access ang live at makasaysayang data.

Gamitin ang aming mga secure na API upang ikonekta ang iyong mga app sa data mula sa iyong mga aparato.

Lumikha ng mga application sa loob ng aming ibinigay na cloud service upang bigyang kahulugan ang data.