AWS dhe IBM: një Krahasim i Shërbimeve IoT: 4 Hapa

2024 Autor: John Day | [email protected]. E modifikuara e fundit: 2024-01-30 12:19

Sot ne po krahasojmë dy rafte që bëjnë të mundur zhvillimin e aplikacioneve IoT nën këndvështrimin e ofertave të ndryshme të shërbimit.

Hapi 1: Funksionet si shërbim

FaaS është një kategori e shërbimeve cloud të përdorura për të ndërtuar një arkitekturë "pa server". FaaS lejon klientët të zhvillojnë, drejtojnë dhe menaxhojnë funksionalitetet e aplikacionit pa ndërtuar dhe mirëmbajtur infrastrukturën.

Amazon ofron AWS Lambda, IBM ofron IBM Cloud Functions. Ato shërbime janë mjaft të ngjashme, megjithatë Lambda ishte e para e këtij lloji. Duke përdorur FaaS ju mund të ekzekutoni pjesë të kodit në cloud dhe çdo shërbim mbështet gjuhë të ndryshme programimi.

Funksionet IBM Cloud: JavaScript, Swift, Java, Go, Php, Python, Ruby,. NET (C# F# etj.), Çdo nëpërmjet Docker AWS Lambda: JavaScript, Java, C#, F#, Go, Python, Ruby, PowerShell, Any përmes API -së së ekzekutimit

IBM Mbështet më shumë gjuhë dhe me docker është e lehtë për t'u përdorur skriptet e shkruara në gjuhë të tjera. Kjo mund të bëhet edhe me Lambda por nuk është e menjëhershme. Ju mund të lexoni një shembull këtu:

Të dy shërbimet kanë kufij të përdorimit, ne i raportojmë ato në një tabelë dhe nxjerrim në pah më të mirat.

Çmimi bazohet në GigaBytes për sekonda (RAM) me shtimin e numrit të kërkesave për AWS Lambda. Çdo shërbim ka një plan falas dhe ato janë pothuajse ekuivalente. Siç mund ta shihni, Lambda është pak më e lirë për GB/s, por ka një kosto që lidhet me kërkesat që Funksionet Cloud nuk i kanë, kështu që kostoja është pothuajse e njëjtë në përgjithësi. Sigurisht, nëse keni nevojë të ekzekutoni detyra që hanë memorie dhe përdor pak kërkesa, duhet të përdorni Lambda. Përparësia kryesore e IBM Cloud Function, sipas mendimit tonë, është se pirgu i tij është me burim të hapur. Ai bazohet plotësisht në Apache OpenWhisk dhe mund të vendoset gjithashtu në një infrastrukturë private.

Hapi 2: Mësimi i Makinerisë

Një fushë ku grupet IBM dhe AWS ofrojnë shërbime të ngjashme është ajo e mësimit të makinerisë: Amazon me SageMaker -in e saj dhe IBM me Watson Machine Learning. Të dy shërbimet janë në shumë aspekte shumë të ngjashme: të dyja paraqiten si mjete për të ndihmuar shkencëtarët dhe zhvilluesit e të dhënave të ndërtojnë, trajnojnë dhe më pas të vendosin në mjedise të gatshme prodhimi modelet e tyre të mësimit të makinerisë, por filozofitë që miratojnë të dy kompanitë ndryshojnë shumë. Të dy shërbimet ju lejojnë të zgjidhni midis shkallëve të ndryshme të kontrollit mbi modelet që përdorni. Në Watson ML, ju keni disa modele të integruara që janë trajnuar tashmë për të bërë disa detyra shumë specifike: për shembull, nëse doni të njihni se cilat objekte janë të pranishme në një fotografi, ju thjesht importoni modelin VisualRecognitionV3 dhe i kaloni atij fotografinë që keni duan të analizojnë. Ju gjithashtu mund të ndërtoni një "model të personalizuar", por në Watson ML kjo kryesisht nënkupton marrjen e një modeli të ndërtuar tashmë dhe bërjen e trajnimit tonë mbi të, kështu që personalizimi është mjaft i kufizuar. It’sshtë e rëndësishme të theksohet edhe pse se as SageMaker as Watson ML nuk janë mënyrat e vetme për të mësuar makineri në pirgjet e zhvilluesve të tyre, ato janë vetëm shërbime që synojnë të bëjnë më të lehtë jetën e zhvilluesve. Platforma Watson ML gjithashtu mbështet shumë nga bibliotekat më të njohura të mësimit të makinerisë, kështu që madje mund të ndërtoni një model nga e para me PyTorch, Tensorflow ose biblioteka të ngjashme. Ju ose përdorni ato biblioteka drejtpërdrejt, ose përdorni modelet e paracaktuara, nuk ka rrugë të mesme. Gjithashtu Watson ML nuk mbështet bibliotekën e zgjedhur të Amazon, Apache MXNet, e cila në vend të kësaj ka mbështetje të klasit të parë në SageMaker.

Qasja e Amazon SageMaker, edhe kur përdorni opsionet e integruara, është pak më e ulët: në vend që t'ju bëjë të zgjidhni nga modelet e paracaktuara, ju lejon të zgjidhni nga një mori algoritmash trajnimi të zbatuar tashmë, të cilat mund t'i përdorni kur ndërtoni tuajin model në një mënyrë më tradicionale. Nëse këto nuk janë të mjaftueshme, mund të përdorni edhe algoritmin tuaj. Kjo mënyrë për të bërë gjëra sigurisht që kërkon më shumë njohuri se si bëhet mësimi i makinerisë në krahasim me përdorimin e një modeli të trajnuar në Watson ML.

Në shikim të parë mund të duket se Watson ML është mënyra "e lehtë dhe e shpejtë", me Amazon SageMaker që është më komplekse për tu vendosur. Kjo mund të mos jetë plotësisht e vërtetë nga disa këndvështrime, pasi SageMaker është i strukturuar që të bëjë gjithçka të funksionojë në një Jupyter Notebook, ndërsa për të njëjtat veçori në Watson ML ju duhet të krijoni shumë nën-shërbime të ndryshme nga UI në internet. Para -përpunimi i të dhënave gjithashtu ka hapësira të dedikuara në shërbimin IBM ndërsa SageMaker mbështetet tek ju që i bëni të gjitha nga kodi në fletoren tuaj. Ky plus fakti që fletoret Jupyter nuk janë zgjedhja më e mirë nga pikëpamja e inxhinierisë softuerike, mund të parandalojë që SageMaker të shkallëzohet shumë mirë në prodhim. Të dy shërbimet kanë mekanizma mjaft të mirë dhe të thjeshtë për të vendosur modelin tuaj dhe për të bërë API për të në dispozicion në botën e jashtme.

Si përfundim, Watson ML performon më mirë në projekte të mëdha ku fletoret Jupyter fillojnë të tregojnë kufijtë e tyre, dhe ku nuk keni nevojë për shumë personalizim në atë që bën vetë modeli. SageMaker është shumë më mirë kur keni nevojë për më shumë fleksibilitet në përcaktimin e algoritmeve, por kur e përdorni atë duhet të merrni parasysh faktin se duhet të mbështeteni në Fletoret Jupyter, të cilat mund të mos shkallëzohen mirë në prodhim. Një zgjidhje mund të jetë shkëputja e pjesës tjetër të kodit nga modeli sa më shumë që të jetë e mundur, në mënyrë që kodi në fletoret aktuale të mos bëhet shumë i madh dhe ne mund të organizojmë më mirë softuerin tonë në modulet e tjerë që përdorin API të modelit tonë Me

Hapi 3: Transmetimi i të dhënave dhe analitika

Shërbimet e transmetimit të të dhënave janë vendimtare në trajtimin dhe analizimin e rrjedhave të mëdha të të dhënave në kohë reale. Ky rrjedhë mund të jetë nga reja në pajisjen e përdoruesve, si një transmetim video, ose nga përdoruesit në re, si telemetria IoT dhe leximet e sensorëve. Sidomos në rastin e dytë, ne mund të kemi një situatë ku burimet e vetme ngarkojnë sasi të vogla të të dhënave, por kur marrim parasysh xhiros së përgjithshme, që vijnë nga të gjitha pajisjet, ajo konsumon një brez të konsiderueshëm brezi, kështu që ka kuptim të përdorim një shërbim të specializuar për të trajtuar të tilla rrjedhat e të dhënave. Pa e trajtuar drejtpërdrejt këtë rrjedhë të vazhdueshme, do të na duhej të ruanim informacionin e ardhur në një ruajtje të përkohshme dhe në një kohë të dytë ta përpunonim atë me ndonjë motor llogaritës. Problemi i kësaj qasjeje të fundit është se ne do të duhet të koordinojmë shërbime më të ndryshme për të arritur atë që një shërbim i vetëm i transmetimit të të dhënave tashmë e bën vetëm, duke rritur kompleksitetin e mirëmbajtjes dhe konfigurimit të aplikacionit. Përveç kësaj, ruajtja në parim mund ta bëjë aplikimin tonë jo më në kohë reale, pasi që një artikull të përpunohet është e nevojshme që të përpunohen gjithashtu të gjithë artikujt e tjerë para tij, dhe shtimi i politikave të përparësisë në tampon mund, përsëri, rrisin kompleksitetin në mënyrë drastike. Si përmbledhje, shërbimet e transmetimit të të dhënave ofrojnë trajtimin e rrjedhës së të dhënave në kohë reale, me një konfigurim të lehtë dhe mund të ofrojnë analitikë mbi të dhënat e ardhura. Këtu krahasojmë dy shërbimet kryesore të transmetimit të pirgut IBM dhe AWS, përkatësisht IBM Streams dhe AWS Kinesis.

Fillojmë duke vënë në dukje se të gjitha tiparet themelore që mund të duam nga një shërbim transmetimi ofrohen nga IBM dhe AWS. Këto karakteristika përfshijnë shkallë praktikisht të pafund të përpunimit, vonesë të ulët dhe analitikë të të dhënave në kohë reale. Meqenëse po flasim për shërbime profesionale, ata të dy ofrojnë mjete të klasës së prodhimit për vendosjen dhe automatizimin.

Duke folur për analizën e të dhënave, të dy shërbimet e ofrojnë atë si opsionale, duke ju bërë të paguani vetëm nëse keni nevojë për të apo jo. Në rastin e Kinesis, kur nuk keni nevojë për analitikë, por vetëm për trajtimin e rrjedhës së të dhënave, çmimet ngarkohen për GB të përpunuar në vend të kohës së përpunimit, si në rastin e IBM. Çmimi për GB do të jetë në përgjithësi më pak i shtrenjtë se çmimi në kohë, pasi po paguani vetëm për trafikun në hyrje. Për pjesën tjetër të këtij postimi ne do të marrim parasysh të dy IBM Streams dhe AWS Kinesis me veçorinë e analizës së të dhënave të aktivizuar.

Streams dhe Kinesis sigurojnë integrim me shërbime të ndryshme për para-përpunimin dhe filtrimin e të dhënave në hyrje para se t'i kalojnë ato në analitikë të të dhënave, përkatësisht me Apache Edgent dhe AWS Lambda. Ndërsa këto shërbime janë rrënjësisht të ndryshme njëri nga tjetri, ne do t'i diskutojmë ato vetëm nga pikëpamja e dy shërbimeve të transmetimit. Dallimi themelor midis të dyve është se Apache Edgent ekzekuton në pajisje, ndërsa AWS Lambda ekzekuton në cloud. Kjo sjell shumë të mirat dhe të këqijat: nga ana Lambda kemi një shërbim fleksibël dhe të lehtë për t’u përdorur me një integrim të përsosur me Kinesis, por kërkon që të dhënat të ngarkohen tashmë në cloud, duke humbur kështu në efikasitet dhe duke paguar Kinesis gjithashtu për të dhënat që përfundimisht do të hidhen poshtë. Nga ana Edgent, në vend të kësaj, ne kemi që shumica e llogaritjeve është bërë, mirë, në buzë të rrjetit (pra në pajisjet) para se të ngarkoni të dhëna të padobishme në cloud. Pengesa kryesore është se Edgent është një kornizë e madhe, e cila mund të kërkojë kohë për tu vendosur dhe mund të jetë komplekse për tu mirëmbajtur. Një tjetër ndryshim që mund të jetë i rëndësishëm në zgjedhjen e një platforme është se Edgent është plotësisht me burim të hapur, Lambda jo. Kjo mund të shihet si një profesionist, pasi të kesh qasje në kodin që ti ose klienti juaj do të ekzekutoni është gjithmonë një gjë pozitive, të dyja si një kundër, sepse mund të ketë situata kur keni nevojë për mbështetje urgjente që nuk mund të sigurohet në të gjitha mjediset me burim të hapur.

Karakteristika të tjera që mund të përmendim është shkallëzimi automatik i burimeve të alokuara nga Kinesis. Në të vërtetë, pajisja që ofron është e përbërë nga një numër i të ashtuquajturave Njësi të Përpunimit Kinesis (KPU) që funksionojnë paralelisht, ku një KPU ofron 1 vCore dhe 4 GB RAM. Numri i tyre varet nga nevojat e aplikacionit dhe ndahen në mënyrë dinamike dhe automatike (ajo që paguani është me të vërtetë koha e CPU -së sa numri i KPU -ve), vetëm mos harroni se është një politikë Kinesis që t'ju ngarkojë një KPU më shumë nëse përdorni Java aplikacion. Në vend të kësaj, IBM Streams nuk ofron këtë lloj fleksibiliteti, duke ju ofruar një enë me pajisje fikse, më shumë detaje kur flasim për çmimet. Nga ana tjetër, IBM Streams është më e hapur se Kinesis, pasi ndërlidhet me WAN përmes protokolleve të zakonshëm të përdorur, si HTTP, MQTT dhe kështu me radhë, ndërsa Kinesis është i mbyllur për ekosistemin AWS.

Si krahasim përfundimtar, le të flasim për çmimet, dhe më lejoni të them që IBM nuk punon mirë në këtë pikë. Ne kemi konfiguruar zgjidhje të ndryshme për tre kategori të ndryshme (bazë, të nivelit të lartë, ultra të lartë) për të dy IBM dhe AWS, dhe ne do të krahasojmë çmimin e tyre. Në konfigurimin bazë kemi një KPU AWS, të përmendur më herët, kundër një zgjidhjeje të IBM me të njëjtin harduer. Për pajisjet e nivelit të lartë kemi 8 KPU që funksionojnë paralelisht për Kinesis dhe 2 kontejnerë gjithmonë paralelisht për IBM, secila me 4 vCore dhe 12 GB RAM. Gjithmonë IBM ofron në kontejnerët ultra të lartë një enë të vetme me 16 vCore dhe 128 GB RAM, ndërsa ne kemi lënë një zgjidhje ekuivalente për AWS, pasi nëse ndonjë aplikacion kërkon këtë sasi të madhe RAM nuk do të ishte e mundur ta ekzekutoni atë në KPU të ndryshme Me Çmimet që ne raportojmë janë të shprehura në $/muaj duke marrë parasysh një përdorim 24/7. Për konfigurimin bazë që kemi për IBM dhe AWS respektivisht 164 $ dhe 490 $, për nivelet e larta 1320 $ dhe 3500 $, për AWS ultra të lartë nuk merren parasysh dhe ka vetëm IBM me 6300 $. Nga këto rezultate mund të shohim se Kinesis punon më mirë për përdoruesit e përditshëm deri në nivelin e ndërmarrjes, ndërsa i mungojnë opsionet për të trajtuar drejtpërdrejt analitikën e të dhënave të cilat kërkojnë sasi të madhe të fuqisë llogaritëse. Kinesis jep raport më të mirë të performancës/$ sesa IBM Streams, i ndihmuar gjithashtu nga alokimi dinamik i blloqeve të vogla të burimeve vetëm kur është e nevojshme, ndërsa IBM ju ofron një enë fikse. Në këtë mënyrë, nëse ngarkesa juaj e punës karakterizohet nga kulmet, me IBM jeni të detyruar të mbivlerësoni nevojat tuaja të aplikimit dhe të konfiguroni një zgjidhje në skenarin më të keq. IBM ofron tarifa për orë në vend që të paguajë muajin e plotë, por nuk është e automatizuar si Kinesis.

Hapi 4: Arkitektura IoT

Konfigurimi për pajisjet për aws iot është mjaft i lehtë kur krahasohet me ibm watson iot. Sepse në ibm watson iot vërtetimi bëhet për pajisje me shenjë dhe sapo të shfaqë shenjën nuk do të shfaqet më kurrë. Ardhja në pjesën e çmimeve përsëri ibm watson iot është mjaft e kushtueshme në krahasim me aws iot. Pra, çmimi në tarifat e ibm watson iot bazohet në pajisje, ruajtje të të dhënave, trafik të të dhënave. Por në aws iot ne mund të paguajmë shumën një herë dhe mund të shtojmë më shumë pajisje dhe të dhëna të publikuara nga pajisjet dhe të dorëzuara në pajisje.

Filloni me pajisjen tuaj- pavarësisht nëse është një sensor, portë hyrjeje ose diçka tjetër- dhe na lejoni t'ju ndihmojmë të lidheni me cloud.

Të dhënat e pajisjes tuaj janë gjithmonë të sigurta kur lidheni me cloud duke përdorur protokoll të hapur dhe të lehtë të mesazheve MGTT ose HTTP. Me ndihmën e protokolleve dhe nyjeve të kuqe ne mund ta lidhim pajisjen tonë me platformën iot dhe mund të kemi qasje në të dhënat e drejtpërdrejta dhe historike.

Përdorni API -të tona të sigurta për të lidhur aplikacionet tuaja me të dhëna nga pajisjet tuaja.

Krijoni aplikacione brenda shërbimit tonë të dhënë cloud për të interpretuar të dhënat.