AWS și IBM: o comparație a serviciilor IoT: 4 pași

2024 Autor: John Day | [email protected]. Modificat ultima dată: 2024-01-30 11:44

Astăzi comparăm două stive care fac posibilă dezvoltarea de aplicații IoT din punctul de vedere al diferitelor oferte de servicii.

Pasul 1: Funcții ca serviciu

FaaS este o categorie de servicii cloud utilizate pentru a construi o arhitectură „fără server”. FaaS permite clienților să dezvolte, să ruleze și să gestioneze funcționalitățile aplicației fără a construi și a menține infrastructura.

Amazon oferă AWS Lambda, IBM oferă IBM Cloud Functions. Aceste servicii sunt destul de similare, cu toate acestea Lambda a fost primul de acest gen. Folosind FaaS puteți rula bucăți de cod în cloud și fiecare serviciu acceptă diferite limbaje de programare.

Funcții IBM Cloud: JavaScript, Swift, Java, Go, Php, Python, Ruby,. NET (C # F # etc.), Orice prin Docker AWS Lambda: JavaScript, Java, C #, F #, Go, Python, Ruby, PowerShell, Any prin API Runtime

IBM acceptă mai multe limbi și cu docker este ușor de utilizat scripturile scrise în alte limbi. Acest lucru se poate face și cu Lambda, dar nu este imediat. Puteți citi un exemplu aici:

Ambele servicii au limite de utilizare, le raportăm într-un tabel și le evidențiem pe cele mai bune.

Prețul se bazează pe GigaBytes pe secunde (RAM), adăugând numărul de solicitări pentru AWS Lambda. Fiecare serviciu are un plan gratuit și sunt aproape echivalente. După cum puteți vedea, Lambda este puțin mai ieftin pentru GB / s, dar are un cost legat de cererile pe care Cloud Functions nu le are, deci costul este aproape același în general. Desigur, dacă trebuie să executați sarcini care consumă memorie și utilizează puține cereri, ar trebui să utilizați Lambda. Principalul avantaj al IBM Cloud Function, în opinia noastră, este că stiva sa este open source. Este complet bazat pe Apache OpenWhisk și poate fi implementat și pe o infrastructură privată.

Pasul 2: Învățarea automată

Un domeniu în care pachetele IBM și AWS oferă servicii similare este cel al învățării automate: Amazon cu SageMaker și IBM cu Watson Machine Learning. Cele două servicii prezintă multe aspecte foarte asemănătoare: ambele se prezintă ca instrumente pentru a ajuta oamenii de știință și dezvoltatorii de date să construiască, să se instruiască și apoi să implementeze în mediile pregătite pentru producție modelele lor de învățare automată, dar filozofiile adoptate de cele două companii variază destul de mult. Ambele servicii vă permit să alegeți între diferite grade de control pe modelele pe care le utilizați. În Watson ML, aveți câteva modele încorporate, care sunt deja instruiți pentru a realiza unele sarcini foarte specifice: de exemplu, dacă doriți să recunoașteți ce obiecte sunt prezente într-o imagine, trebuie doar să importați modelul VisualRecognitionV3 și să îi transmiteți imaginea pe care o aveți vreau să analizăm. De asemenea, puteți construi un „model personalizat”, dar în Watson ML acest lucru înseamnă mai ales să luați un model deja construit și să vă instruiți pe acesta, astfel încât personalizarea este destul de limitată. Este important de observat însă că nici SageMaker și nici Watson ML nu sunt singurele modalități de a face învățare automată pe stivele dezvoltatorilor lor, ci sunt doar servicii care urmăresc să le faciliteze viața dezvoltatorilor. Platforma Watson ML acceptă, de asemenea, multe dintre cele mai populare biblioteci de învățare automată, astfel încât puteți chiar să construiți un model de la zero cu PyTorch, Tensorflow sau biblioteci similare. Fie folosiți acele biblioteci direct, fie folosiți modelele prefabricate, nu există un punct de mijloc. De asemenea, Watson ML nu acceptă biblioteca de alegeri Amazon, Apache MXNet, care are în schimb suport de primă clasă în SageMaker.

Abordarea Amazon SageMaker, chiar și atunci când se utilizează opțiuni încorporate, este ceva mai scăzută: mai degrabă decât să te facă să alegi dintre modele prefabricate, îți permite să alegi dintr-o mulțime de algoritmi de instruire deja implementați, pe care îi poți folosi atunci când îți construiești model într-un mod mai tradițional. Dacă acestea nu sunt suficiente, puteți utiliza și propriul algoritm. Acest mod de a face lucruri necesită cu siguranță mai multe cunoștințe despre modul în care se face învățarea automată în comparație cu utilizarea unui model instruit în Watson ML.

La prima vedere, poate părea că Watson ML este calea „ușoară și rapidă”, Amazon SageMaker fiind cel mai complex de configurat. Acest lucru s-ar putea să nu fie în întregime adevărat din anumite puncte de vedere, deoarece SageMaker este structurat pentru a face totul să ruleze pe un notebook Jupyter, în timp ce pentru aceleași caracteristici din Watson ML trebuie să configurați multe sub-servicii diferite din interfața de utilizare web. Preprocesarea datelor are, de asemenea, spații dedicate pentru serviciul IBM, în timp ce SageMaker se bazează pe faptul că faceți totul din cod în notebook-ul dvs. Acest lucru plus faptul că notebook-urile Jupyter nu sunt tocmai cea mai bună alegere din punct de vedere al ingineriei software, pot împiedica SageMaker să se adapteze foarte bine în producție. Ambele servicii au mecanisme destul de bune și simple pentru a vă implementa modelul și pentru a face API-urile disponibile pentru acesta în lumea exterioară.

În concluzie, Watson ML funcționează mai bine în proiecte uriașe în care notebook-urile Jupyter încep să își arate limitele și în care nu aveți nevoie de multă personalizare în ceea ce face modelul în sine. SageMaker este mult mai bun atunci când aveți nevoie de mai multă flexibilitate în definirea algoritmilor, dar atunci când îl utilizați trebuie să țineți cont de faptul că trebuie să vă bazați pe notebook-urile Jupyter, care s-ar putea să nu scară bine în producție. O soluție ar putea fi decuplarea cât mai mult a restului de cod de model, astfel încât codul din notebook-urile reale să nu devină prea mare și să putem organiza mai bine software-ul nostru în celelalte module care folosesc doar API-ul modelului nostru.

Pasul 3: flux de date și analize

Serviciile de transmitere a datelor sunt cruciale în tratarea și analiza în timp real a fluxurilor mari de date. Acest flux poate fi de la cloud la dispozitivul utilizatorilor, cum ar fi un flux video, sau de la utilizatori la cloud, cum ar fi telemetria IoT și citirile senzorilor. Mai ales în cel de-al doilea caz, am putea avea o situație în care sursele individuale încarcă cantități mici de date, dar când luăm în considerare debitul global, care provine de pe toate dispozitivele, consumă o lățime de bandă considerabilă, astfel are sens să folosim un serviciu specializat pentru a gestiona astfel de fluxuri de date. Fără a gestiona direct acest flux continuu, ar trebui să tamponăm informațiile primite într-un stocare temporară și, în al doilea rând, să le procesăm cu un motor de calcul. Problema acestei ultime abordări este că ar trebui să coordonăm mai multe servicii diferite pentru a realiza ceea ce un singur serviciu de flux de date face deja singur, sporind complexitatea întreținerii și configurației aplicației. În plus, tamponarea poate, în principiu, face ca aplicația noastră să nu mai fie în timp real, deoarece pentru ca un articol să fie procesat este necesar ca toate celelalte articole dinaintea acestuia să fie procesate și adăugarea unor politici de prioritate la buffer să poată, din nou, crește complexitatea drastic. Rezumând, serviciile de streaming de date oferă gestionarea fluxului de date în timp real, cu o configurație ușoară și pot oferi analize privind datele primite. Aici comparăm cele două servicii principale de streaming ale stivei IBM și AWS, și anume IBM Streams și AWS Kinesis.

Începem prin a observa că toate caracteristicile de bază pe care le-am putea dori de la un serviciu de streaming sunt oferite atât de IBM, cât și de AWS. Aceste caracteristici includ o rată de procesare practic infinită, o latență scăzută și analize de date în timp real. Deoarece vorbim despre servicii profesionale, ambele oferă instrumente de producție pentru implementare și automatizare.

Vorbind despre analiza datelor, ambele servicii o oferă ca opțional, ceea ce vă face să plătiți doar dacă aveți nevoie sau nu de ea. În cazul Kinesis, atunci când nu aveți nevoie de analize, ci doar de gestionarea fluxului de date, prețurile sunt taxate pe GB procesat în loc de timp de procesare, ca în cazul IBM. Prețul pe GB va fi, în general, mai puțin costisitor decât prețul pe timp, deoarece plătiți doar pentru traficul primit. Pentru restul acestei postări vom lua în considerare atât IBM Streams, cât și AWS Kinesis, cu funcția de analiză a datelor activată.

Fluxurile și Kinesis oferă integrare cu diferite servicii pentru pre-procesare și filtrare a datelor primite înainte de a le transmite analizei datelor, respectiv cu Apache Edgent și AWS Lambda. În timp ce aceste servicii sunt radical diferite unul de altul, le vom discuta doar din punctul de vedere al celor două servicii de streaming. Diferența fundamentală dintre cele două este că Apache Edgent execută pe dispozitiv, în timp ce AWS Lambda execută pe cloud. Acest lucru aduce multe avantaje și dezavantaje: din partea Lambda avem un serviciu flexibil și ușor de utilizat, cu o integrare perfectă cu Kinesis, dar necesită ca datele să fie deja încărcate în cloud, pierzând astfel din eficiență și plătind și Kinesis pentru datele care vor fi în cele din urmă aruncate. În schimb, din partea Edgent, avem cea mai mare parte a calculului realizat, bine, la marginea rețelei (deci pe dispozitive) înainte de a încărca date inutile pe cloud. Principalul dezavantaj este că Edgent este un cadru larg, care poate necesita timp pentru a fi instalat și ar putea fi complex de întreținut. O altă diferență care ar putea fi relevantă în alegerea unei platforme este că Edgent este complet open source, Lambda nu. Acest lucru poate fi văzut atât ca un profesionist, deoarece accesul la codul pe care dvs. sau clientul dvs. îl veți executa este întotdeauna un lucru pozitiv, atât ca un con, deoarece pot exista situații în care aveți nevoie de asistență urgentă care nu poate fi oferită în toate mediile open source.

Alte caracteristici pe care le putem menționa este scalabilitatea automată a resurselor alocate de către Kinesis. Într-adevăr, hardware-ul pe care îl oferă este compus dintr-un număr de așa-numitele unități de procesare Kinesis (KPU) care rulează în paralel, unde un KPU oferă 1 vCore și 4 GB de RAM. Numărul lor depinde de nevoile aplicației și sunt alocate dinamic și automat (ceea ce plătiți este într-adevăr timpul de procesare de câte ori este numărul de KPU-uri), amintiți-vă că este o politică Kinesis să vă taxați încă un KPU dacă utilizați un Java cerere. IBM Streams, în schimb, nu oferă acest tip de flexibilitate, oferindu-vă un container cu hardware fix, mai multe detalii atunci când vorbim despre prețuri. Pe de altă parte, IBM Streams este mai deschis decât Kinesis, deoarece se interfață la WAN prin protocoale comune utilizate, cum ar fi HTTP, MQTT și așa mai departe, în timp ce Kinesis este închis ecosistemului AWS.

Ca o comparație finală, să vorbim despre prețuri și permiteți-mi să spun că IBM nu funcționează excelent în acest punct. Am configurat soluții diferite pentru trei categorii diferite (de bază, high-end, ultra-high-end) atât pentru IBM, cât și pentru AWS și vom compara prețul acestora. În configurația de bază avem un AWS KPU, menționat anterior, împotriva unei soluții IBM cu același hardware. Pentru high-end avem 8 KPU-uri care rulează este paralel pentru Kinesis și 2 containere întotdeauna în paralel pentru IBM, fiecare cu 4 vCores și 12 GB RAM. Întotdeauna IBM oferă în ultra-high-end un singur container cu 16 vCores și 128GB RAM, în timp ce am omis o soluție echivalentă pentru AWS, deoarece dacă o aplicație necesită această cantitate mare de RAM, nu ar putea fi posibil să-l rulăm pe diferite KPU-uri.. Prețurile pe care le raportăm sunt exprimate în USD / lună, având în vedere utilizarea 24/7. Pentru configurația de bază pe care o avem pentru IBM și respectiv 164 $ și AWS 490 $, pentru modelele high-end 1320 $ și 3500 $, pentru AWS ultra-high-end nu este luată în considerare și există doar IBM cu 6300 $. Din aceste rezultate putem vedea că Kinesis funcționează mai bine pentru utilizatorul de zi cu zi până la nivelul întreprinderii, în timp ce nu are opțiuni pentru a gestiona direct analiza datelor care necesită o cantitate enormă de putere de calcul. Kinesis oferă un raport performanță / $ mai bun decât IBM Streams, ajutat și de alocarea dinamică a blocurilor mici de resurse numai atunci când este necesar, în timp ce IBM vă oferă un container fix. În acest fel, dacă volumul de muncă este caracterizat de vârfuri, cu IBM sunteți forțați să supraestimați nevoile aplicației dvs. și să configurați o soluție în cel mai rău caz. IBM oferă taxe de ore în loc să plătească luna întreagă, dar nu este automatizat ca Kinesis.

Pasul 4: Arhitectura IoT

Configurarea pentru dispozitive pentru aws iot este destul de ușoară în comparație cu ibm watson iot. Deoarece în ibm watson iot autentificarea este pe dispozitiv cu token și odată ce afișează token-ul nu se va mai afișa niciodată. Venirea din nou la prețul piesei ibm watson iot este destul de costisitoare în comparație cu aws iot. Deci, prețul în taxele ibm watson iot se bazează pe dispozitiv, stocare de date, trafic de date. Dar în aws iot putem plăti suma o dată și putem adăuga mai multe dispozitive și date publicate de pe dispozitive și livrate pe dispozitive.

Începeți cu dispozitivul dvs. - indiferent dacă este un senzor, un gateway sau altceva - și permiteți-ne să vă ajutăm să vă conectați cu cloud.

Datele dispozitivului dvs. sunt întotdeauna sigure când vă conectați la cloud utilizând protocolul de mesagerie MGTT deschis sau ușor sau HTTP. Cu ajutorul protocoalelor și roșu-nod, ne putem conecta dispozitivul cu platforma iot și putem accesa date live și istorice.

Utilizați API-urile noastre sigure pentru a vă conecta aplicațiile cu datele de pe dispozitivele dvs.

Creați aplicații în cadrul serviciului nostru dat de cloud pentru interpretarea datelor.