AWS és IBM: IoT -szolgáltatások összehasonlítása: 4 lépés

2024 Szerző: John Day | [email protected]. Utoljára módosítva: 2024-01-30 09:41

Ma két köteget hasonlítunk össze, amelyek lehetővé teszik az IoT -alkalmazások fejlesztését a különböző szolgáltatási ajánlatok szempontjából.

1. lépés: Szolgáltatásként működik

A FaaS a felhőszolgáltatások kategóriája, amelyet „szerver nélküli” architektúra létrehozására használnak. A FaaS lehetővé teszi az ügyfelek számára az alkalmazásfunkciók fejlesztését, futtatását és kezelését az infrastruktúra kiépítése és karbantartása nélkül.

Az Amazon AWS Lambdát, az IBM pedig IBM felhőfunkciókat kínál. Ezek a szolgáltatások meglehetősen hasonlóak, azonban a Lambda volt az első ilyen jellegű. A FaaS használatával futtathat kódrészleteket a felhőben, és minden szolgáltatás támogatja a különböző programozási nyelveket.

IBM felhőfunkciók: JavaScript, Swift, Java, Go, Php, Python, Ruby,. NET (C# F# stb.), Bármi a Docker AWS Lambda segítségével: JavaScript, Java, C#, F#, Go, Python, Ruby, PowerShell, Bármi a Runtime API -n keresztül

Az IBM több nyelvet támogat, és a dokkolóval könnyen használható más nyelven írt szkriptek. Ezt meg lehet tenni a Lambdával is, de nem azonnal. Itt olvashat egy példát:

Mindkét szolgáltatásnak vannak használati korlátai, ezeket táblázatban jelentjük be, és kiemeljük a legjobbakat.

Az ár gigabájt másodpercenként (RAM) alapul, hozzáadva az AWS Lambda kérések számát. Minden szolgáltatás ingyenes tervvel rendelkezik, és szinte egyenértékű. Amint láthatja, a Lambda valamivel olcsóbb a GB/s -ért, de olyan költségekkel jár, amelyekkel a Cloud Functions nem rendelkezik, így a költségek általában közel azonosak. Természetesen, ha olyan feladatokat kell futtatnia, amelyek memóriát fogyasztanak és kevés kérést használnak, akkor használja a Lambda programot. Az IBM Cloud Function fő előnye véleményünk szerint az, hogy a verem nyílt forráskódú. Teljesen az Apache OpenWhisk -en alapul, és privát infrastruktúrán is telepíthető.

2. lépés: Gépi tanulás

Az IBM és az AWS verem hasonló szolgáltatásokat kínál a gépi tanulás területén: az Amazon a SageMakerrel és az IBM a Watson Machine Learninggel. A két szolgáltatás sok szempontból nagyon hasonló: mindketten eszközként mutatkoznak be, amelyek segítik az adattudósokat és a fejlesztőket gépi tanulási modelljeik felépítésében, képzésében, majd a termelésre kész környezetbe való telepítésében, de a két vállalat filozófiája meglehetősen eltérő. Mindkét szolgáltatás lehetővé teszi a választást a használt modellek különböző fokú vezérlése között. A Watson ML-ben van néhány beépített modellje, amelyek már nagyon speciális feladatok elvégzésére vannak kiképezve: például ha fel szeretné ismerni, hogy milyen objektumok vannak jelen a képen, akkor csak importálja a VisualRecognitionV3 modellt, és adja át neki a képet elemezni akarja. Készíthet „egyedi modellt” is, de a Watson ML -ben ez többnyire azt jelenti, hogy vesz egy már felépített modellt, és elvégzi rajta a képzést, így a testreszabás meglehetősen korlátozott. Fontos azonban észrevenni, hogy sem a SageMaker, sem a Watson ML nem az egyetlen módja a gépi tanulásnak a fejlesztők kötegében, csak szolgáltatások, amelyek megkönnyítik a fejlesztők életét. A Watson ML platform számos legnépszerűbb gépi tanulási könyvtárat is támogat, így akár a nulláról is létrehozhat egy modellt a PyTorch, Tensorflow vagy hasonló könyvtárakkal. Vagy közvetlenül használja ezeket a könyvtárakat, vagy használja az előre elkészített modelleket, nincs középút. A Watson ML nem támogatja az Amazon választott könyvtárát, az Apache MXNet -et, amely ehelyett első osztályú támogatást nyújt a SageMakerben.

Az Amazon SageMaker megközelítése, még akkor is, ha a beépített lehetőségeket használja, kissé alacsonyabb szintű: ahelyett, hogy az előre elkészített modellek közül választana, lehetővé teszi, hogy rengeteg, már megvalósított képzési algoritmus közül választhasson, amelyeket felhasználhat a modellt hagyományosabb módon. Ha ezek nem elegendőek, akkor saját algoritmusát is használhatja. Ez a módszer mindenképpen több tudást igényel a gépi tanulás módjáról, mint a Watson ML képzett modelljének használata.

Első pillantásra úgy tűnhet, hogy a Watson ML a „könnyű és gyors” módszer, az Amazon SageMaker a legösszetettebb beállítás. Ez bizonyos szempontból talán nem teljesen igaz, mivel a SageMaker úgy van felépítve, hogy mindent Jupyter Notebookon futtasson, míg a Watson ML azonos funkcióihoz sok különböző alszolgáltatást kell beállítania a webes felhasználói felületről. Az adatok előfeldolgozásának dedikált területei is vannak az IBM szolgáltatásban, míg a SageMaker arra támaszkodik, hogy mindezt a notebook kódjából teszi. Ez, valamint az a tény, hogy a Jupyter notebookok nem éppen a legjobb választás szoftverfejlesztési szempontból, megakadályozhatják, hogy a SageMaker nagyon jól méretezzen a gyártásban. Mindkét szolgáltatás nagyon jó és egyszerű mechanizmussal rendelkezik a modell telepítéséhez és az API -k elérhetővé tételéhez a külvilágban.

Összefoglalva, a Watson ML jobban teljesít hatalmas projektekben, ahol a Jupyter notebookok elkezdik megmutatni határaikat, és ahol nem kell sok testreszabás, amit maga a modell tesz. A SageMaker sokkal jobb, ha nagyobb rugalmasságra van szüksége az algoritmusok meghatározásakor, de használatakor figyelembe kell vennie azt a tényt, hogy a Jupyter Notebookokra kell támaszkodnia, amelyek esetleg nem megfelelőek a gyártásban. A megoldás az lehet, ha a kód többi részét a lehető legnagyobb mértékben leválasztjuk a modellről, hogy a tényleges notebookok kódja ne legyen túl nagy, és jobban megszervezhessük szoftverünket a többi modulban, amelyek csak a modellünk API -ját használják.

3. lépés: Adatfolyam és elemzés

Az adatfolyam -szolgáltatások kulcsfontosságúak a nagy adatáramok valós idejű kezelésében és elemzésében. Ez az áramlás történhet a felhőből a felhasználók eszközére, például a videó streamingjéhez, vagy a felhasználóktól a felhőbe, például az IoT telemetria és az érzékelő leolvasása. Különösen a második esetben előfordulhat, hogy egyes források kis mennyiségű adatot töltenek fel, de ha figyelembe vesszük az összes eszközről érkező teljes átviteli sebességet, akkor jelentős sávszélességet igényel, ezért célszerű egy ilyen szolgáltatások kezelésére szakosodott szolgáltatást igénybe venni. adatfolyamok. Anélkül, hogy ezt a folyamatos áramlást közvetlenül kezelnénk, a bejövő információkat ideiglenes tárolóba kell pufferelnünk, majd másodszor feldolgoznunk valamilyen számítási motorral. Ennek az utolsó megközelítésnek a problémája az, hogy több különböző szolgáltatást kell összehangolnunk ahhoz, hogy elérjük azt, amit egyetlen adatfolyam -szolgáltatás már önmagában tesz, növelve az alkalmazás karbantartásának és konfigurációjának összetettségét. Ezenkívül a pufferelés elvileg már nem valós idejűvé teszi az alkalmazásunkat, mivel egy elem feldolgozásához szükséges, hogy az összes többi elem is feldolgozásra kerüljön, és az elsőbbségi házirendek hozzáadása a pufferhez ismét, drasztikusan növeli a komplexitást. Összefoglalva, az adatfolyam -szolgáltatások valós időben, egyszerű konfigurálással kínálnak adatfolyam -kezelést, és elemzést biztosítanak a bejövő adatokról. Itt összehasonlítjuk az IBM és az AWS verem két fő streaming szolgáltatását, nevezetesen az IBM Streams és az AWS Kinesis szolgáltatásokat.

Kezdjük azzal, hogy megjegyezzük, hogy az összes alapvető funkciót, amelyet a streaming szolgáltatástól kérhetünk, mind az IBM, mind az AWS kínálja. Ezek közé tartozik a gyakorlatilag végtelen feldolgozási sebesség, az alacsony késleltetés és a valós idejű adatelemzés. Mivel professzionális szolgáltatásokról beszélünk, mindkettő gyártási szintű eszközöket kínál a telepítéshez és az automatizáláshoz.

Az adatelemzésről beszélve, mindkét szolgáltatás opcionálisan kínálja, így csak akkor kell fizetnie, ha szüksége van rá. A Kinesis esetében, amikor nem elemzésre van szüksége, hanem csak adatfolyam -kezelésre, az árakat feldolgozott GB -onként számítják fel a feldolgozási idő helyett, mint például az IBM esetében. A GB -onkénti ár általában olcsóbb lesz, mint az időbeli árazás, mivel csak a bejövő forgalomért fizet. A bejegyzés további részében figyelembe vesszük mind az IBM Streams, mind az AWS Kinesis engedélyezett adatelemzési funkcióját.

A Streams és a Kinesis integrálja a különböző szolgáltatásokat a bejövő adatok előfeldolgozására és szűrésére, mielőtt átadná azokat az adatelemzőknek, az Apache Edgent és az AWS Lambda segítségével. Bár ezek a szolgáltatások gyökeresen különböznek egymástól, ezeket csak a két streaming szolgáltatás szempontjából tárgyaljuk. Az alapvető különbség a kettő között az, hogy az Apache Edgent az eszközön, míg az AWS Lambda a felhőben hajt végre. Ennek számos előnye és hátránya van: Lambda oldalról rugalmas és könnyen használható szolgáltatásunk van, amely zökkenőmentesen integrálható a Kinesis-be, de megköveteli, hogy az adatokat már fel kell tölteni a felhőbe, így csökken a hatékonyság és fizet a Kinesis a később elvetendő adatokért. Ehelyett Edgent oldalról úgy látjuk, hogy a számítás nagy része a hálózat szélén (tehát az eszközökön) történik, mielőtt haszontalan adatokat töltene fel a felhőbe. A fő hátrány az, hogy az Edgent egy nagy keretrendszer, amelynek beállítása időbe telhet, és karbantartása összetett lehet. Egy másik különbség, amely releváns lehet a platformválasztásban, az, hogy az Edgent teljesen nyílt forráskódú, a Lambda nem. Ez mind profinak tekinthető, mivel az Ön vagy az ügyfél által végrehajtandó kódhoz való hozzáférés mindig pozitív dolog, mindkettő csalásként, mert előfordulhatnak olyan helyzetek, amikor sürgős támogatásra van szüksége, amelyet nem lehet megadni minden nyílt forráskódú környezetben.

További jellemzők, amelyeket megemlíthetünk, az a Kinesis által kiosztott erőforrások automatikus méretezhetősége. Valójában az általa kínált hardver számos, párhuzamosan futó, úgynevezett kinezisfeldolgozó egységből (KPU) áll össze, ahol egy KPU 1 vCore -t és 4 GB RAM -ot kínál. Számuk az alkalmazás igényeitől függ, és dinamikusan és automatikusan kerülnek kiosztásra (amit Ön fizet, az valóban a CPU idő szorzata a KPU -k számával), ne feledje, hogy Kinesis házirend szerint egy KPU -val többet kell fizetni, ha Java -t használ Alkalmazás. Az IBM Streams ehelyett nem nyújt ilyen rugalmasságot, és rögzített hardvert tartalmazó tárolót kínál, további részleteket az árképzésről beszélünk. Másrészt az IBM Streams nyitottabb, mint a Kinesis, mivel a WAN -hoz kapcsolódik a közösen használt protokollokon keresztül, mint például a HTTP, az MQTT és így tovább, míg a Kinesis zárva van az AWS ökoszisztéma előtt.

Végső összehasonlításként beszéljünk az árazásról, és hadd mondjam el, hogy az IBM nem működik nagyszerűen ezen a ponton. Három különböző kategóriába állítottunk be különböző megoldásokat (alapvető, csúcskategóriás, ultrakategóriás) mind az IBM, mind az AWS számára, és összehasonlítjuk áraikat. Az alapkonfigurációban van egy korábban említett AWS KPU, ugyanazzal a hardverrel rendelkező IBM megoldás ellen. A csúcskategóriában 8 KPU fut párhuzamosan a Kinesis számára, és 2 tároló mindig párhuzamosan az IBM számára, mindegyik 4 vCore-al és 12 GB RAM-mal. Az IBM mindig ultramodern kategóriában kínál egyetlen tárolót 16 vCore-al és 128 GB RAM-mal, míg az AWS-hez hasonló megoldást nem hagytunk ki, mivel ha néhány alkalmazás megköveteli ezt a nagy mennyiségű RAM-ot, akkor nem lehet futtatni különböző KPU-n. Az általunk közölt árak havi dollárban értendők, figyelembe véve a 24/7 használatot. Az alapkonfigurációhoz az IBM és az AWS esetében 164 dollár, illetve 490 dollár, a csúcsminőségű 1320 dollár és 3500 dollár esetében pedig az ultra-csúcsminőségű AWS nem tekinthető, és csak az IBM rendelkezik 6300 dollárral. Ezekből az eredményekből láthatjuk, hogy a Kinesis jobban működik a mindennapi felhasználók számára, akár vállalati szinten, miközben nincsenek lehetőségei az adatelemzés közvetlen kezelésére, amely hatalmas számítási teljesítményt igényel. A Kinesis jobb teljesítmény/dollár arányt nyújt, mint az IBM Streams, ehhez hozzájárul a kis erőforrásblokkok dinamikus elosztása is, ha szükséges, míg az IBM fix tárolót kínál. Ily módon, ha a munkaterhelését csúcsok jellemzik, az IBM kénytelen túlbecsülni az alkalmazás igényeit, és a legrosszabb esetben konfigurálni a megoldást. Az IBM óradíjat kínál a teljes hónap fizetése helyett, de nem automatizált, mint Kinesis.

4. lépés: IoT architektúra

Az aws iot eszközök konfigurálása meglehetősen egyszerű az ibm watson iot -hoz képest. Mivel az ibm watson iot -ban a hitelesítés eszközönként történik jogkivonattal, és miután megjelenítette a tokent, soha többé nem jelenik meg. Ha ismét az árazási részhez térünk, az ibm watson iot meglehetősen költséges az aws iot -hoz képest. Tehát az ibm watson iot díjak ára eszközönként, adattároláson, adatforgalomon alapul. De aws iot, egyszer kifizethetjük az összeget, és további eszközöket és adatokat adhatunk hozzá az eszközökről közzétett és az eszközökre szállított adatokhoz.

Kezdje az eszközével- legyen az érzékelő, átjáró vagy valami más-, és hagyja, hogy segítsünk a felhővel való kapcsolatteremtésben.

Az eszköz adatai mindig biztonságban vannak, amikor nyílt, könnyű MGTT üzenetküldő protokoll vagy HTTP használatával csatlakozik a felhőhöz. A protokollok és a csomópont-vörös segítségével csatlakoztathatjuk eszközünket az iot platformhoz, és hozzáférhetünk az élő és történelmi adatokhoz.

Használja a biztonságos API -kat, hogy összekapcsolja alkalmazásait az eszközeiről származó adatokkal.

Hozzon létre alkalmazásokat az adott felhőszolgáltatásunkon belül az adatok értelmezésére.