AWS i IBM: Usporedba IoT usluga: 4 koraka

2024 Autor: John Day | [email protected]. Zadnja promjena: 2024-01-30 09:35

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

Korak 1: Funkcionira kao usluga

FaaS je kategorija cloud usluga koje se koriste za izgradnju arhitekture "bez poslužitelja". FaaS omogućuje korisnicima razvoj, upravljanje i upravljanje aplikacijskim funkcionalnostima bez izgradnje i održavanja infrastrukture.

Amazon nudi AWS Lambda, IBM nudi IBM Cloud funkcije. Te su usluge prilično slične, no 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 s 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šćujemo 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 povezanu sa zahtjevima 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. Glavna prednost IBM Cloud funkcije, po našem mišljenju, je što je njezin stog otvorenog koda. Potpuno se temelji na Apache OpenWhisk -u, a može se postaviti i na privatnu infrastrukturu.

Korak 2: Strojno učenje

Područje u kojem hrpe IBM -a i AWS -a nude slične usluge je ono strojnog učenja: Amazon sa svojim SageMakerom i IBM s Watson strojnim učenjem. Dvije su usluge u mnogim aspektima vrlo slične: obje se predstavljaju kao alati za pomoć znanstvenicima i razvojnim programerima u izgradnji, osposobljavanju i primjeni modela za strojno učenje u proizvodno okruženje, ali filozofije koje dvije tvrtke 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ć su samo usluge čiji je cilj olakšati život programerima. Watson ML platforma također podržava mnoge od najpopularnijih knjižnica za strojno učenje, pa čak možete izraditi model od nule pomoću knjižnica PyTorch, Tensorflow ili sličnih. Ili koristite te knjižnice 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 prvorazrednu podršku u SageMakeru.

Pristup Amazon SageMakera, čak i kada se koriste ugrađenim opcijama, malo je niži: umjesto da odabirete već unaprijed izrađene modele, omogućuje vam odabir između mnoštva već implementiranih algoritama za obuku, koje možete koristiti pri izgradnji svog model na tradicionalniji način. Ako to nije dovoljno, možete upotrijebiti i vlastiti algoritam. Ovaj način rada zasigurno zahtijeva više znanja o načinu izvođenja strojnog učenja 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, a Amazon SageMaker je složeniji za postavljanje. S nekih gledišta to možda nije posve točno jer je SageMaker strukturiran tako da sve radi na Jupyter prijenosnom računalu, dok za iste značajke u Watson ML-u morate postaviti mnogo različitih pod-usluga s web sučelja. Predprocesiranje podataka također ima namjenske prostore na IBM -ovoj usluzi, dok se SageMaker oslanja na to da sve to radite iz koda u prijenosniku. To plus činjenica da Jupyter prijenosna računala nisu baš najbolji izbor sa stajališta softverskog inženjeringa može spriječiti SageMaker da se jako dobro poveća u proizvodnji. Obje usluge imaju prilično dobre i jednostavne mehanizme za implementaciju vašeg modela i stavljanje API -ja za njega dostupnim u vanjskom svijetu.

Zaključno, Watson ML bolje se snalazi u velikim projektima u kojima prijenosna računala Jupyter počinju pokazivati svoje granice i gdje vam ne treba mnogo prilagođavanja onoga što sam model radi. SageMaker je puno bolji kada vam je potrebna veća fleksibilnost u definiranju algoritama, ali pri korištenju 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 svoj softver u druge module koji samo koriste API našeg modela.

Korak 3: Prijenos podataka i analitika

Usluge strujanja podataka ključne su za rukovanje i analizu velikih protoka podataka u stvarnom vremenu. Taj tok može biti iz oblaka na korisnikov uređaj, poput streaminga videozapisa, ili iz korisnika u oblak, poput IoT telemetrije i očitanja senzora. Pogotovo u drugom slučaju, mogli bismo imati situaciju da pojedinačni izvori prenose 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 izravnog rukovanja ovim kontinuiranim tokom, morali bismo spremati dolazne informacije u privremenu pohranu, a zatim ih drugi put obraditi nekim računalnim strojem. 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, spremanje u međuspremnik 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 pravila prioriteta u međuspremnik, drastično povećati složenost. Ukratko, usluge strujanja podataka nude upravljanje protokom podataka u stvarnom vremenu, s jednostavnom konfiguracijom i mogu pružiti analizu dolaznih podataka. Ovdje uspoređujemo dvije glavne streaming usluge IBM i AWS stoga, naime IBM Streams i AWS Kinesis.

Počinjemo napominjući da sve osnovne značajke koje bismo možda htjeli od streaming usluge nude i IBM i AWS. Ove značajke uključuju gotovo beskonačnu brzinu obrade, nisku latenciju i analitiku podataka u stvarnom vremenu. Budući da govorimo o profesionalnim uslugama, oboje nude alate proizvodnog razreda za implementaciju i automatizaciju.

Govoreći o analizi podataka, obje usluge nude je kao izbornu, pa ćete platiti samo bez obzira na to trebate li ili ne. U slučaju Kinesisa, kada vam ne trebaju analize, već samo rukovanje protokom podataka, cijene se naplaćuju po obrađenom GB umjesto po vremenu obrade, kao u slučaju IBM -a. 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 značajkom 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, o njima ćemo raspravljati samo sa stajališta dviju usluga streaminga. Temeljna 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 učinkovitost i plaća Kinesis za podatke koji će na kraju biti odbačeni. S Edgentove strane, umjesto toga, imamo da se većina izračuna vrši, dobro, na rubu mreže (dakle na uređajima) prije prijenosa 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. To se može promatrati i kao profesionalac, budući da je pristup kodu koji ćete izvršiti vi ili vaš klijent uvijek pozitivna stvar, i kao prevara, jer mogu postojati situacije u kojima vam je potrebna hitna podrška koja se ne može pružiti u svih okruženja otvorenog koda.

Druge značajke koje možemo spomenuti je Kinesisova automatska skalabilnost dodijeljenih resursa. Doista, hardver koji nudi sastoji se od niza takozvanih Kinesis Processing Units (KPU -ova) 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 doista je vrijeme CPU -a puta broj KPU -ova), samo zapamtite da je politika Kinesisa naplatiti vam jedan KPU više ako koristite Java primjena. 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 otvoreniji je 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 ekosustav.

Kao konačnu usporedbu, razgovarajmo o cijenama i dopustite mi da kažem da IBM u ovom trenutku ne radi dobro. 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 usporediti 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 s 4 vCores i 12 GB RAM-a. Uvijek IBM u ultra-high-end-u nudi jedan spremnik 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 razine poduzeća, a nedostaju mu mogućnosti za izravno rukovanje analitikom podataka koja zahtijeva ogromnu računalnu snagu. Kinesis pruža bolji omjer performansi/$ od IBM Streamsa, čemu pomaže i dinamička dodjela malih blokova resursa samo po potrebi, dok vam IBM nudi fiksni spremnik. Na taj 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 plaćanja 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 iotu autentikacija vrši po uređaju s tokenom, a kad jednom prikaže token, više se neće prikazati. Ponovno dolazak na dio cijene ibm watson iot je prilično skup u usporedbi s aws iot. Dakle, cijene u ibm watson iot naknadama temelje se na uređaju, pohrani podataka i podatkovnom prometu. Ali u aw iot iznosu možemo platiti jednom i možemo dodati još uređaja i podataka objavljenih s uređaja i isporučenih na uređaje.

Počnite sa svojim uređajem- bilo da se radi o senzoru, pristupniku ili nečem drugom- i dopustite nam da vam pomognemo pri povezivanju s oblakom.

Podaci vašeg uređaja uvijek su sigurni kada se povežete s oblakom 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 aktivnim i povijesnim podacima.

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

Izradite aplikacije unutar naše usluge u oblaku za tumačenje podataka.