AWS in IBM: Primerjava storitev IoT: 4 koraki

2024 Avtor: John Day | [email protected]. Nazadnje spremenjeno: 2024-01-30 12:05

Danes primerjamo dva sklada, ki omogočata razvoj aplikacij IoT z vidika različnih ponudb storitev.

1. korak: deluje kot storitev

FaaS je kategorija storitev v oblaku, ki se uporabljajo za izgradnjo arhitekture brez strežnika. FaaS strankam omogoča razvoj, izvajanje in upravljanje funkcionalnosti aplikacij brez gradnje in vzdrževanja infrastrukture.

Amazon ponuja AWS Lambda, IBM ponuja funkcije IBM Cloud. Te storitve so si precej podobne, vendar je bila Lambda prva te vrste. S FaaS -om lahko zaženete kode v oblaku in vsaka storitev podpira različne programske jezike.

IBM -ove funkcije v oblaku: JavaScript, Swift, Java, Go, Php, Python, Ruby,. NET (C# F# itd.), Poljubno prek Docker AWS Lambda: JavaScript, Java, C#, F#, Go, Python, Ruby, PowerShell, poljubno prek API -ja za izvajanje

IBM podpira več jezikov, z dockerjem pa je enostavna uporaba skriptov, napisanih v drugih jezikih. To je mogoče storiti tudi z Lambdo, vendar ne takoj. Primer lahko preberete tukaj:

Obe storitvi imata omejitve uporabe, poročamo o njih v tabeli in izpostavljamo najboljše.

Cena temelji na gigabajtih na sekundo (RAM) z dodatkom števila zahtev za AWS Lambda. Vsaka storitev ima brezplačen načrt in so skoraj enakovredne. Kot lahko vidite, je Lambda za GB/s nekoliko cenejša, vendar ima stroške, povezane z zahtevami, ki jih funkcije v oblaku nimajo, zato so stroški na splošno skoraj enaki. Seveda, če morate izvajati opravila, ki porabijo pomnilnik in porabijo nekaj zahtev, uporabite Lambda. Glavna prednost IBM -ove funkcije v oblaku je po našem mnenju ta, da je njen sklad odprtokoden. V celoti temelji na Apache OpenWhisk in ga je mogoče uporabiti tudi v zasebni infrastrukturi.

2. korak: Strojno učenje

Področje, kjer kup IBM in AWS ponujata podobne storitve, je področje strojnega učenja: Amazon s svojim SageMakerjem in IBM z Watson Machine Learning. Obe storitvi sta si v mnogih pogledih zelo podobni: obe se predstavljata kot orodja, ki znanstvenikom in razvijalcem podatkov pomagata pri gradnji, usposabljanju in nato uvedbi svojih modelov strojnega učenja v pripravljena za proizvodnjo okolja, vendar se filozofije, ki jih sprejmeta obe podjetji, precej razlikujejo. Obe storitvi vam omogočata izbiro med različnimi stopnjami nadzora pri modelih, ki jih uporabljate. V Watson ML imate nekaj vgrajenih modelov, ki so že usposobljeni za opravljanje zelo posebnih nalog: na primer, če želite prepoznati, kateri predmeti so na sliki, preprosto uvozite model VisualRecognitionV3 in mu posredujete sliko, ki jo želite analizirati. Zgradite lahko tudi "model po meri", vendar v Watson ML to večinoma pomeni vzeti že zgrajen model in se na njem usposabljati, zato je prilagajanje precej omejeno. Pomembno pa je omeniti, da niti SageMaker niti Watson ML nista edina načina strojnega učenja na skladih svojih razvijalcev, ampak sta samo storitvi, ki olajšata življenje razvijalcem. Platforma Watson ML podpira tudi številne najbolj priljubljene knjižnice strojnega učenja, tako da lahko celo ustvarite model iz nič s knjižnicami PyTorch, Tensorflow ali podobnimi. Te knjižnice uporabljate neposredno ali pa uporabite že izdelane modele, ni vmesne poti. Tudi Watson ML ne podpira Amazonove izbrane knjižnice, Apache MXNet, ki ima namesto tega prvovrstno podporo v SageMakerju.

Pristop Amazon SageMaker je, tudi če uporabljate vgrajene možnosti, nekoliko nižji: namesto da bi izbirali med vnaprej izdelanimi modeli, vam omogoča, da izbirate med množico že implementiranih algoritmov za usposabljanje, ki jih lahko uporabite pri izdelavi svojega model na bolj tradicionalen način. Če ti niso dovolj, lahko uporabite tudi lasten algoritem. Ta način dela zagotovo zahteva več znanja o tem, kako poteka strojno učenje, v primerjavi s samo uporabo usposobljenega modela v Watson ML.

Na prvi pogled se lahko zdi, da je Watson ML "enostaven in hiter" način, pri čemer je Amazon SageMaker bolj zapleten za nastavitev. Z nekaterih vidikov to morda ne drži, saj je SageMaker strukturiran tako, da vse deluje na prenosnem računalniku Jupyter, medtem ko morate za iste funkcije v Watson ML nastaviti veliko različnih pod-storitev iz spletnega vmesnika. Predprocesiranje podatkov ima tudi namenske prostore v storitvi IBM, medtem ko se SageMaker zanaša na to, da vse to počnete iz kode v prenosnem računalniku. To in dejstvo, da prenosni računalniki Jupyter niso ravno najboljša izbira z vidika programskega inženiringa, lahko prepreči, da bi SageMaker zelo dobro razširil proizvodnjo. Obe storitvi imata precej dobre in preproste mehanizme za uvajanje vašega modela in omogočanje API -ja zanj na voljo v zunanjem svetu.

Skratka, Watson ML deluje bolje pri velikih projektih, kjer prenosniki Jupyter začnejo kazati svoje meje in kjer ne potrebujete veliko prilagajanja glede tega, kaj počne sam model. SageMaker je veliko boljši, ko potrebujete več prožnosti pri opredeljevanju algoritmov, vendar morate pri njegovi uporabi upoštevati dejstvo, da se morate zanašati na prenosnike Jupyter, ki se morda ne bodo dobro razširili v proizvodnji. Rešitev bi lahko bila, da preostanek kode čim bolj ločimo od modela, da koda v dejanskih zvezkih ne postane prevelika in da lahko svojo programsko opremo bolje organiziramo v druge module, ki uporabljajo samo API našega modela.

3. korak: Pretakanje podatkov in analitika

Storitve pretoka podatkov so ključnega pomena pri ravnanju in analizi velikega pretoka podatkov v realnem času. Ta tok je lahko iz oblaka v napravo uporabnika, na primer pretakanje videa, ali iz uporabnikov v oblak, na primer telemetrija IoT in odčitki senzorjev. Zlasti v drugem primeru bi lahko imeli situacijo, ko posamezni viri nalagajo majhne količine podatkov, vendar če upoštevamo celotno prepustnost, ki prihaja iz vseh naprav, porabi precejšnjo pasovno širino, zato je smiselno uporabiti storitev, specializirano za obravnavo takšnih podatkov. tokovi podatkov. Brez neposrednega ravnanja s tem neprekinjenim tokom bi morali vhodne informacije shraniti v začasno shranjevanje in jih nato drugič obdelati z nekim računalniškim mehanizmom. Težava tega zadnjega pristopa je v tem, da bi morali uskladiti več različnih storitev, da bi dosegli tisto, kar ena sama storitev podatkovnega toka že počne sama, kar bi povečalo zapletenost vzdrževanja in konfiguracije aplikacije. Poleg tega lahko medpomnjenje načeloma povzroči, da naša aplikacija ne bo več v realnem času, saj je za obdelavo elementa potrebno, da se obdelujejo tudi vsi drugi elementi, ki so pred njim, in dodajanje prednostnih pravil v medpomnilnik., dramatično povečati kompleksnost. Če povzamemo, storitve pretakanja podatkov ponujajo upravljanje podatkovnega toka v realnem času z enostavno konfiguracijo in lahko zagotovijo analizo vhodnih podatkov. Tukaj primerjamo dve glavni pretočni storitvi sklada IBM in AWS, in sicer IBM Streams in AWS Kinesis.

Najprej ugotavljamo, da IBM in AWS ponujata vse osnovne funkcije, ki jih morda želimo od storitve pretakanja. Te funkcije vključujejo skoraj neskončno hitrost obdelave, nizko zakasnitev in analitiko podatkov v realnem času. Ker govorimo o strokovnih storitvah, oba ponujata orodja za uvajanje in avtomatizacijo.

Ko govorimo o analitiki podatkov, jo obe storitvi ponujata kot neobvezno, zato plačate samo, če jo potrebujete ali ne. V primeru Kinesisa, ko ne potrebujete analitike, ampak samo obdelavo pretoka podatkov, se cene zaračunavajo na GB obdelane namesto časa obdelave, kot v primeru IBM. Cene na GB bodo na splošno cenejše od cen na čas, saj plačujete samo za dohodni promet. V preostalem delu te objave bomo obravnavali tako IBM Streams kot AWS Kinesis z omogočeno funkcijo analitike podatkov.

Streams in Kinesis zagotavljata integracijo z različnimi storitvami za predhodno obdelavo in filtriranje dohodnih podatkov, preden jih posredujejo v podatkovno analitiko, oziroma z Apache Edgent in AWS Lambda. Čeprav se te storitve med seboj radikalno razlikujejo, jih bomo obravnavali le z vidika obeh storitev pretakanja. Temeljna razlika med tema dvema je, da se Apache Edgent izvaja v napravi, medtem ko se AWS Lambda izvaja v oblaku. To prinaša veliko prednosti in slabosti: z lambda strani imamo prilagodljivo in enostavno uporabo storitev z nemoteno integracijo s Kinesisom, vendar zahteva, da so podatki že naloženi v oblak, s čimer se izgubi učinkovitost in plača tudi Kinesis za podatke, ki bodo sčasoma zavrženi. Namesto tega imamo Edgent stran večino izračunov na robu omrežja (torej na napravah), preden naložimo neuporabne podatke v oblak. Glavna pomanjkljivost je, da je Edgent velik okvir, ki lahko zahteva čas za nastavitev in je lahko zapleten za vzdrževanje. Druga razlika, ki bi lahko bila pomembna pri izbiri platforme, je ta, da je Edgent popolnoma odprtokoden, Lambda pa ne. To lahko razumemo kot profesionalca, saj je dostop do kode, ki jo boste izvedli vi ali vaša stranka, vedno pozitivna stvar, oboje kot prevara, ker lahko pride do situacij, ko potrebujete nujno podporo, ki je ni mogoče zagotoviti v vsa odprtokodna okolja.

Druge značilnosti, ki jih lahko omenimo, je samodejna prilagodljivost dodeljenih sredstev podjetja Kinesis. Dejansko strojno opremo, ki jo ponuja, sestavljajo številne tako imenovane vzporedno delujoče enote za obdelavo kinez (KPU), kjer en KPU ponuja 1 vCore in 4 GB RAM -a. Njihovo število je odvisno od potreb aplikacije in je dinamično in samodejno dodeljeno (kar plačate je čas cpu -krat število KPU -jev), ne pozabite, da je v skladu s politiko Kinesis zaračunavanje enega KPU -ja več, če uporabljate Java. aplikacijo. Namesto tega IBM Streams ne ponuja tovrstne prilagodljivosti in vam ponuja vsebnik s fiksno strojno opremo, več podrobnosti, ko govorimo o cenah. Po drugi strani je IBM Streams bolj odprt kot Kinesis, saj se povezuje z omrežjem WAN prek običajnih protokolov, kot so HTTP, MQTT in tako naprej, medtem ko je Kinesis zaprt za ekosistem AWS.

Kot zadnjo primerjavo se pogovorimo o cenah in naj povem, da IBM na tem področju ne deluje dobro. Za IBM in AWS smo konfigurirali različne rešitve za tri različne kategorije (osnovne, vrhunske, ultra visoke) in primerjali bomo njihovo ceno. V osnovni konfiguraciji imamo eno AWS KPU, omenjeno prej, proti rešitvi IBM z isto strojno opremo. Za vrhunske imamo 8 KPU-jev, ki delujejo vzporedno za Kinesis in 2 vsebnika, ki sta vedno vzporedna za IBM, vsak s 4 vCores in 12 GB RAM-a. IBM vedno v ultra visokem razredu ponuja en sam vsebnik s 16 vCores in 128 GB RAM-a, medtem ko smo izpustili enakovredno rešitev za AWS, saj če neka aplikacija zahteva tolikšno količino RAM-a, je ne bi bilo mogoče zagnati na različnih KPU-jih. Cene, o katerih poročamo, so izražene v USD/mesec glede na 24 -urno uporabo. Za osnovno konfiguracijo imamo za IBM oziroma AWS 164 $ oziroma 490 $, za vrhunske 1320 $ in 3500 $, za ultra-high-end AWS ne upoštevamo in obstaja le IBM s 6300 $. Iz teh rezultatov lahko vidimo, da Kinesis deluje bolje za vsakdanjega uporabnika do ravni podjetja, medtem ko nima možnosti za neposredno obravnavo podatkovne analitike, ki zahteva ogromno računalniške moči. Kinesis prinaša boljše razmerje med zmogljivostjo in $ kot IBM Streams, k čemur pripomore tudi dinamična dodelitev majhnih blokov virov le po potrebi, medtem ko vam IBM ponuja fiksni vsebnik. Na ta način, če je za vašo delovno obremenitev značilna največja obremenitev, ste pri IBM prisiljeni preceniti svoje potrebe po aplikacijah in konfigurirati rešitev v najslabšem primeru. IBM namesto plačila za cel mesec ponuja ure ur, vendar ni avtomatiziran kot Kinesis.

4. korak: Arhitektura IoT

Konfiguracija naprav za aws iot je precej enostavna v primerjavi z ibm watson iot. Ker je v ibm watson iot preverjanje pristnosti za vsako napravo z žetonom in ko žeton prikaže, se ne bo nikoli več prikazalo. Ponovno prihajamo na cenovni del ibm watson iot je precej drag v primerjavi z aws iot. Torej cena v ibm watson iot pristojbinah temelji na napravi, shranjevanju podatkov in podatkovnem prometu. Toda v aw iotu lahko enkrat plačamo znesek in lahko dodamo več naprav in podatkov, objavljenih iz naprav in dostavljenih v naprave.

Začnite s svojo napravo- naj bo to senzor, prehod ali kaj drugega- in dovolite nam, da vam pomagamo pri povezovanju z oblakom.

Ko se povežete z oblakom z odprtim, lahkim protokolom za sporočila MGTT ali HTTP, so podatki vaše naprave vedno varni. S pomočjo protokolov in node-red lahko svojo napravo povežemo z iot platformo in dostopamo do živih in zgodovinskih podatkov.

Uporabite naše varne API -je za povezovanje vaših aplikacij s podatki iz vaših naprav.

Ustvarite aplikacije v naši dani storitvi v oblaku za razlago podatkov.