AWS i IBM: Poređenje IoT usluga: 4 koraka

2024 Autor: John Day | [email protected]. Zadnja izmjena: 2024-01-30 08:07

Danas uspoređujemo dva gomila koja omogućuju razvoj IoT aplikacija s gledišta različitih ponuda usluga.

Korak 1: Funkcije kao usluga

FaaS je kategorija cloud usluga koje se koriste za izgradnju arhitekture bez servera. FaaS omogućava korisnicima da razvijaju, pokreću i upravljaju funkcionalnostima aplikacija bez izgradnje i održavanja infrastrukture.

Amazon nudi AWS Lambda, IBM nudi IBM Cloud funkcije. Te su usluge prilično slične, međutim Lambda je bila prva takve vrste. Pomoću FaaS -a možete pokrenuti komade koda u oblaku, a svaka usluga podržava različite programske jezike.

IBM Cloud funkcije: JavaScript, Swift, Java, Go, Php, Python, Ruby,. NET (C# F# itd.), Bilo koje putem Docker AWS Lambda: JavaScript, Java, C#, F#, Go, Python, Ruby, PowerShell, Bilo koje putem Runtime API -ja

IBM podržava više jezika, a sa dockerom je lako koristiti skripte napisane na drugim jezicima. To se može učiniti i s Lambdom, ali to nije odmah. Primjer možete pročitati ovdje:

Obje usluge imaju ograničenja korištenja, izvještavamo ih u tablici i ističemo najbolje.

Cijena se temelji na GigaBytes po sekundi (RAM) uz dodatak broja zahtjeva za AWS Lambda. Svaka usluga ima besplatan plan i oni su gotovo ekvivalentni. Kao što vidite, Lambda je malo jeftinija za GB/s, ali ima cijenu vezanu za zahtjeve koje Cloud Functions nemaju, pa je cijena općenito gotovo ista. Naravno, ako trebate pokrenuti zadatke koji troše memoriju i koriste nekoliko zahtjeva, trebali biste koristiti Lambdu. Po našem mišljenju, glavna prednost IBM Cloud funkcije je što je njen stek otvorenog koda. Potpuno je baziran na Apache OpenWhisk -u i može se postaviti i na privatnu infrastrukturu.

Korak 2: Mašinsko učenje

Područje u kojem hrpe IBM -a i AWS -a nude slične usluge je ono mašinskog učenja: Amazon sa svojim SageMakerom i IBM sa Watson mašinskim učenjem. Dvije su usluge u mnogim aspektima vrlo slične: obje se predstavljaju kao alati za pomoć naučnicima podataka i programerima u izgradnji, obuci i zatim implementaciji u okruženja spremna za proizvodnju svojih modela mašinskog učenja, ali filozofije koje dvije kompanije usvajaju prilično se razlikuju. Obje usluge omogućuju vam da odaberete između različitih stupnjeva kontrole na modelima koje koristite. U Watson ML-u imate neke ugrađene modele koji su već obučeni za obavljanje vrlo specifičnih zadataka: na primjer, ako želite prepoznati koji su objekti prisutni na slici, samo uvezite model VisualRecognitionV3 i proslijedite mu sliku koju želite analizirati. Također možete izgraditi “prilagođeni model”, ali u Watson ML -u to uglavnom znači uzimanje već izgrađenog modela i obučavanje o njemu, pa je prilagodba prilično ograničena. Važno je napomenuti da ni SageMaker ni Watson ML nisu jedini načini strojnog učenja na hrpi njihovih programera, već samo usluge čiji je cilj olakšati život programerima. Watson ML platforma također podržava mnoge od najpopularnijih biblioteka za strojno učenje, tako da čak možete izgraditi model od nule pomoću PyTorch, Tensorflow ili sličnih biblioteka. Ili koristite te biblioteke izravno, ili koristite već izrađene modele, nema sredine. Također Watson ML ne podržava Amazonovu biblioteku po izboru, Apache MXNet, koja umjesto toga ima prvoklasnu podršku u SageMakeru.

Pristup Amazon SageMakera, čak i kada se koriste ugrađenim opcijama, malo je niži nivo: umjesto da odabirete već unaprijed izrađene modele, on vam omogućuje da odaberete između mnoštva već implementiranih algoritama za obuku, koje možete koristiti pri izgradnji svog model na tradicionalniji način. Ako ovo nije dovoljno, možete koristiti i vlastiti algoritam. Ovakav način rada zasigurno zahtijeva više znanja o tome kako se izvodi mašinsko učenje u odnosu na samo korištenje obučenog modela u Watson ML -u.

Na prvi pogled može se činiti da je Watson ML "jednostavan i brz" način, s tim da je Amazon SageMaker složeniji za postavljanje. To s nekih gledišta možda nije sasvim točno jer je SageMaker strukturiran tako da sve radi na Jupyter prijenosnom računaru, dok za iste značajke u Watson ML-u morate postaviti mnogo različitih pod-usluga iz web sučelja. Predprocesiranje podataka također ima namjenske prostore na IBM servisu, dok se SageMaker oslanja na to da sve to radite iz koda u prijenosniku. Ovo plus činjenica da Jupyter prijenosni računari nisu baš najbolji izbor sa stanovišta softverskog inženjeringa može spriječiti SageMaker da se jako dobro proširi u proizvodnji. Obje usluge imaju prilično dobre i jednostavne mehanizme za implementaciju vašeg modela i omogućavanje API -ja za njega dostupnim u vanjskom svijetu.

Zaključno, Watson ML se bolje snalazi u velikim projektima u kojima Jupyter prijenosna računala počinju pokazivati svoje granice i gdje vam ne treba mnogo prilagođavanja onoga što sam model radi. SageMaker je mnogo bolji kada vam je potrebna veća fleksibilnost u definiranju algoritama, ali prilikom korištenja morate uzeti u obzir činjenicu da se morate osloniti na Jupyter prijenosna računala, koja se možda neće dobro skalirati u proizvodnji. Rješenje bi moglo biti odvajanje ostatka koda od modela što je više moguće, tako da kôd u stvarnim bilježnicama ne postane prevelik i da možemo bolje organizirati naš softver u druge module koji samo koriste API našeg modela.

Korak 3: Prijenos podataka i analitika

Usluge prijenosa podataka ključne su za rukovanje i analizu velikih protoka podataka u stvarnom vremenu. Taj tok može biti iz oblaka na korisnički uređaj, poput prijenosa videozapisa, ili od korisnika u oblak, poput IoT telemetrije i očitanja senzora. Pogotovo u drugom slučaju, mogli bismo imati situaciju da pojedinačni izvori učitavaju male količine podataka, ali kada uzmemo u obzir ukupnu propusnost koja dolazi sa svih uređaja, ona troši znatnu propusnost, pa ima smisla koristiti uslugu specijaliziranu za rukovanje takvim podacima tokovi podataka. Bez direktnog rukovanja ovim kontinuiranim tokom, morali bismo međuspremiti dolazne informacije u privremenu memoriju i po drugi put ih obraditi nekim računskim mehanizmom. Problem ovog posljednjeg pristupa je u tome što bismo morali koordinirati više različitih usluga kako bismo postigli ono što jedna usluga protoka podataka već sama radi, povećavajući složenost održavanja i konfiguracije aplikacije. Osim toga, međuspremljenje u načelu može učiniti da naša aplikacija više ne bude u stvarnom vremenu, budući da je za obradu stavke potrebno da se obrade i sve ostale stavke prije nje te dodavanje politika prioriteta u međuspremnik, drastično povećati složenost. Ukratko, usluge prijenosa podataka nude upravljanje protokom podataka u stvarnom vremenu, s jednostavnom konfiguracijom i mogu pružiti analitiku o ulaznim podacima. Ovdje uspoređujemo dvije glavne streaming usluge IBM i AWS stoga, naime IBM Streams i AWS Kinesis.

Počinjemo tako što primjećujemo da sve osnovne funkcije koje bismo možda htjeli od streaming usluge nude i IBM i AWS. Ove značajke uključuju gotovo beskonačnu brzinu obrade, nisko kašnjenje i analitiku podataka u stvarnom vremenu. Budući da govorimo o profesionalnim uslugama, obje nude alate za primjenu i automatizaciju.

Kada govorimo o analitici podataka, obje usluge nude je kao izbornu, zbog čega plaćate samo bez obzira na to trebate li ili ne. U slučaju Kinesis -a, kada vam ne trebaju analize, već samo rukovanje protokom podataka, cijene se naplaćuju po GB -u obrađenog umjesto vremena obrade, kao u slučaju IBM. Cijene po GB će općenito biti jeftinije od cijene po vremenu, budući da plaćate samo za dolazni promet. U ostatku ovog članka razmotrit ćemo i IBM Streams i AWS Kinesis s omogućenom funkcijom analize podataka.

Streams i Kinesis pružaju integraciju s različitim uslugama za prethodnu obradu i filtriranje dolaznih podataka prije nego što ih proslijede analitici podataka, odnosno s Apache Edgentom i AWS Lambdom. Iako se ove usluge međusobno radikalno razlikuju, razgovarat ćemo o njima samo sa stajališta dvaju streaming servisa. Osnovna razlika između ova dva je u tome što se Apache Edgent izvršava na uređaju, dok se AWS Lambda izvršava u oblaku. To donosi mnoge prednosti i nedostatke: s Lambda strane imamo fleksibilnu uslugu koja je jednostavna za korištenje s besprijekornom integracijom s Kinesisom, ali zahtijeva da se podaci već prenose u oblak, čime se gubi efikasnost i plaća Kinesis za podatke koji će na kraju biti odbačeni. Umjesto toga, sa Edgent strane imamo da se većina izračuna vrši, dobro, na rubu mreže (dakle na uređajima) prije postavljanja beskorisnih podataka u oblak. Glavni nedostatak je to što je Edgent veliki okvir koji može zahtijevati vrijeme za postavljanje i može biti složen za održavanje. Druga razlika koja bi mogla biti relevantna pri izboru platforme je ta što je Edgent potpuno otvorenog koda, a Lambda nije. Ovo se može posmatrati i kao profesionalac, jer je pristup kodu koji ćete izvršiti vi ili vaš klijent uvijek pozitivna stvar, oboje kao prevaru, jer se mogu pojaviti situacije u kojima vam je potrebna hitna podrška koja se ne može pružiti u sva okruženja otvorenog koda.

Druge značajke koje možemo spomenuti je Kinesisova automatska skalabilnost dodijeljenih resursa. Zaista, hardver koji nudi sastoji se od niza takozvanih Kinesis Processing Units (KPU) koji rade paralelno, gdje jedan KPU nudi 1 vCore i 4 GB RAM -a. Njihov broj ovisi o potrebama aplikacije i dinamički se i automatski dodjeljuju (ono što plaćate je doista vrijeme CPU -a puta broj KPU -ova), samo zapamtite da je politika Kinesisa da vam naplaćuje jedan KPU više ako koristite Java aplikacija. IBM Streams, umjesto toga, ne pruža ovu vrstu fleksibilnosti, nudeći vam spremnik s fiksnim hardverom, više detalja kada govorimo o cijenama. S druge strane, IBM Streams je otvoreniji od Kinesisa jer se povezuje s WAN -om putem uobičajenih protokola, poput HTTP -a, MQTT -a i tako dalje, dok je Kinesis zatvoren za AWS ekosistem.

Za krajnju usporedbu, razgovarajmo o cijenama i dopustite mi da kažem da IBM ne radi dobro po ovom pitanju. Konfigurirali smo različita rješenja za tri različite kategorije (osnovne, vrhunske, ultra-visoke klase) i za IBM i za AWS, a mi ćemo uporediti njihovu cijenu. U osnovnoj konfiguraciji imamo jedan AWS KPU, spomenut ranije, protiv IBM rješenja s istim hardverom. Za high-end imamo 8 KPU-ova koji rade paralelno za Kinesis i 2 spremnika uvijek paralelno za IBM, svaki sa 4 vCores i 12GB RAM-a. Uvijek IBM nudi u ultra-high-end-u jedan kontejner sa 16 vCores i 128 GB RAM-a, dok smo izostavili ekvivalentno rješenje za AWS, jer ako neka aplikacija zahtijeva ovu veliku količinu RAM-a, ne bi se moglo pokrenuti na različitim KPU-ovima. Cijene koje prijavljujemo izražene su u USD/mjesečno s obzirom na korištenje 24 sata dnevno. Za osnovnu konfiguraciju imamo za IBM odnosno AWS 164 $ i 490 $, za high-end 1320 $ i 3500 $, za ultra-high-end AWS se ne razmatra i postoji samo IBM sa 6300 $. Iz ovih rezultata možemo vidjeti da Kinesis radi bolje za svakodnevne korisnike do nivoa preduzeća, dok mu nedostaju mogućnosti za direktno rukovanje analitikom podataka za koju je potrebna ogromna računarska snaga. Kinesis pruža bolji omjer performansi/$ od IBM Streamsa, čemu pomaže i dinamička alokacija malih blokova resursa samo po potrebi, dok vam IBM nudi fiksni spremnik. Na ovaj način, ako vaše radno opterećenje karakteriziraju vrhovi, s IBM -om ste prisiljeni precijeniti svoje potrebe aplikacija i konfigurirati rješenje u najgorem slučaju. IBM nudi naknade za sate umjesto da plaća cijeli mjesec, ali nije automatiziran kao Kinesis.

Korak 4: IoT arhitektura

Konfiguracija uređaja za aws iot prilično je jednostavna u usporedbi s ibm watson iot. Budući da se u ibm watson iot autentikacija vrši po uređaju s tokenom i jednom kada prikaže token više se neće prikazati. Ponovo dolazimo do cijene ibm watson iot je prilično skup u odnosu na aws iot. Dakle, cijene u ibm watson iot naknadama temelje se na uređaju, pohrani podataka i prometu podataka. No, u najboljem slučaju, iznos možemo platiti jednom i možemo dodati više uređaja i podataka objavljenih s uređaja i isporučenih na uređaje.

Počnite sa svojim uređajem- bilo da je to senzor, pristupnik ili nešto drugo- i dopustite nam da vam pomognemo pri povezivanju s oblakom.

Podaci vašeg uređaja uvijek su sigurni kada se povežete na oblak pomoću otvorenog, laganog MGTT protokola za razmjenu poruka ili HTTP -a. Uz pomoć protokola i node-red možemo povezati naš uređaj s iot platformom i pristupiti podacima uživo i povijesti.

Koristite naše sigurne API -je za povezivanje vaših aplikacija s podacima s vaših uređaja.

Kreirajte aplikacije u okviru naše usluge u oblaku za tumačenje podataka.