AWS un IBM: IoT pakalpojumu salīdzinājums: 4 soļi

2024 Autors: John Day | [email protected]. Pēdējoreiz modificēts: 2024-01-30 10:56

Šodien mēs salīdzinām divas kaudzes, kas ļauj izstrādāt IoT lietojumprogrammas, ņemot vērā dažādus pakalpojumu piedāvājumus.

1. darbība: darbojas kā pakalpojums

FaaS ir mākoņpakalpojumu kategorija, ko izmanto, lai izveidotu arhitektūru bez serveriem. FaaS ļauj klientiem attīstīt, palaist un pārvaldīt lietojumprogrammu funkcijas, neveidojot un neuzturot infrastruktūru.

Amazon piedāvā AWS Lambda, IBM piedāvā IBM mākoņa funkcijas. Šie pakalpojumi ir diezgan līdzīgi, tomēr Lambda bija pirmais šāda veida pakalpojums. Izmantojot FaaS, jūs varat palaist koda gabalus mākonī, un katrs pakalpojums atbalsta dažādas programmēšanas valodas.

IBM mākoņa funkcijas: JavaScript, Swift, Java, Go, Php, Python, Ruby,. NET (C# F# utt.), Jebkurš, izmantojot Docker AWS Lambda: JavaScript, Java, C#, F#, Go, Python, Ruby, PowerShell, Jebkurš izmantojot Runtime API

IBM atbalsta vairāk valodu, un ar docker ir viegli izmantot skriptus, kas rakstīti citās valodās. To var izdarīt arī ar Lambda, bet tas nenotiek nekavējoties. Piemēru varat izlasīt šeit:

Abiem pakalpojumiem ir lietošanas ierobežojumi, mēs tos norādām tabulā un izceļam labāko.

Cena ir balstīta uz gigabaitiem sekundē (RAM), pievienojot AWS Lambda pieprasījumu skaitu. Katram pakalpojumam ir bezmaksas plāns, un tie ir gandrīz līdzvērtīgi. Kā redzat, Lambda ir nedaudz lētāka par GB/s, taču tai ir izmaksas, kas saistītas ar pieprasījumiem, ka Cloud Functions nav, tāpēc izmaksas kopumā ir gandrīz vienādas. Protams, ja jums ir jāizpilda uzdevumi, kas patērē atmiņu un izmanto maz pieprasījumu, izmantojiet Lambda. Mūsuprāt, galvenā IBM mākoņfunkcijas priekšrocība ir tā, ka tā kaudze ir atvērtā koda. Tas ir pilnībā balstīts uz Apache OpenWhisk, un to var izvietot arī privātā infrastruktūrā.

2. solis: mašīnmācīšanās

Lauks, kurā IBM un AWS kaudzes piedāvā līdzīgus pakalpojumus, ir mašīnmācīšanās: Amazon ar savu SageMaker un IBM ar Watson Machine Learning. Abi pakalpojumi daudzos aspektos ir ļoti līdzīgi: abi sevi parāda kā rīkus, kas palīdz datu zinātniekiem un izstrādātājiem izveidot, apmācīt un pēc tam izvietot ražošanai gatavā vidē savus mašīnmācīšanās modeļus, taču abu uzņēmumu pieņemtās filozofijas ir diezgan atšķirīgas. Abi pakalpojumi ļauj izvēlēties starp dažādiem izmantoto modeļu vadības līmeņiem. Programmā Watson ML jums ir daži iebūvēti modeļi, kas jau ir apmācīti dažu ļoti specifisku uzdevumu veikšanai: piemēram, ja vēlaties atpazīt, kādi objekti ir attēlā, jūs vienkārši importējat VisualRecognitionV3 modeli un nododat tam attēlu vēlas analizēt. Varat arī izveidot “pielāgotu modeli”, taču Watson ML tas galvenokārt nozīmē jau uzbūvēta modeļa ņemšanu un apmācību par to, tāpēc pielāgošana ir diezgan ierobežota. Tomēr ir svarīgi ņemt vērā, ka ne SageMaker, ne Watson ML nav vienīgie veidi, kā apgūt mašīnmācīšanos izstrādātāju krāvumos, tie ir tikai pakalpojumi, kuru mērķis ir atvieglot izstrādātāju dzīvi. Watson ML platforma atbalsta arī daudzas populārākās mašīnmācīšanās bibliotēkas, tāpēc jūs pat varat izveidot modeli no nulles, izmantojot PyTorch, Tensorflow vai līdzīgas bibliotēkas. Jūs vai nu izmantojat šīs bibliotēkas tieši, vai arī izmantojat iepriekš sagatavotus modeļus, nav vidusceļa. Arī Watson ML neatbalsta Amazon izvēles bibliotēku Apache MXNet, kurai tā vietā ir pirmās klases atbalsts SageMaker.

Amazon SageMaker pieeja, pat izmantojot iebūvētās opcijas, ir nedaudz zemāka: tā vietā, lai liktu jums izvēlēties no iepriekš sagatavotiem modeļiem, tā ļauj izvēlēties no daudziem jau ieviestajiem apmācības algoritmiem, kurus varat izmantot, veidojot savu modeli tradicionālā veidā. Ja ar tiem nepietiek, varat izmantot arī savu algoritmu. Šis veids, kā rīkoties, noteikti prasa vairāk zināšanu par mašīnmācīšanos, salīdzinot ar tikai apmācīta modeļa izmantošanu Watson ML.

No pirmā acu uzmetiena var šķist, ka Watson ML ir “vienkāršs un ātrs” veids, un Amazon SageMaker ir vissarežģītākais iestatīšanas veids. No dažiem viedokļiem tas var nebūt pilnīgi taisnība, jo SageMaker ir veidots tā, lai viss darbotos Jupyter piezīmjdatorā, savukārt, lai izmantotu tās pašas Watson ML funkcijas, no tīmekļa lietotāja interfeisa ir jāiestata daudzi dažādi apakšpakalpojumi. Datu priekšapstrādei ir arī īpašas vietas IBM pakalpojumā, savukārt SageMaker paļaujas uz to, ka jūs to visu darāt no piezīmjdatora koda. Tas, kā arī tas, ka Jupyter piezīmjdatori nav īsti labākā izvēle no programmatūras inženierijas viedokļa, var liegt SageMaker ļoti labi mērogot ražošanā. Abiem pakalpojumiem ir diezgan labi un vienkārši mehānismi, lai izvietotu jūsu modeli un padarītu tā API pieejamas ārpasaulē.

Visbeidzot, Watson ML darbojas labāk milzīgos projektos, kur Jupyter piezīmjdatori sāk parādīt savas robežas un kuros nav nepieciešams daudz pielāgot pašu modeli. SageMaker ir daudz labāks, ja jums ir nepieciešama lielāka elastība, definējot algoritmus, taču, to lietojot, jāņem vērā fakts, ka jums ir jāpaļaujas uz Jupyter piezīmjdatoriem, kuru ražošana var nebūt pietiekami liela. Risinājums varētu būt, cik vien iespējams, atdalīt pārējo kodu no modeļa, lai kods piezīmjdatoros nebūtu pārāk liels un mēs varētu labāk sakārtot savu programmatūru citos moduļos, kas vienkārši izmanto mūsu modeļa API.

3. darbība. Datu straumēšana un analīze

Datu straumēšanas pakalpojumiem ir izšķiroša nozīme, apstrādājot un analizējot reāllaikā lielas datu plūsmas. Šī plūsma var būt no mākoņa uz lietotāju ierīci, piemēram, video straumēšana, vai no lietotājiem uz mākoni, piemēram, IoT telemetrija un sensora rādījumi. Jo īpaši otrajā gadījumā mums varētu būt situācija, kad atsevišķi avoti augšupielādē nelielu datu apjomu, bet, ņemot vērā kopējo caurlaidspēju, kas nāk no visām ierīcēm, tā patērē ievērojamu joslas platumu, tāpēc ir lietderīgi izmantot pakalpojumu, kas specializēts šādu datu apstrādei datu plūsmas. Netiekot tieši galā ar šo nepārtraukto plūsmu, mums nāktos buferizēt ienākošo informāciju pagaidu krātuvē un otrreiz to apstrādāt ar kādu skaitļošanas dzinēju. Šīs pēdējās pieejas problēma ir tāda, ka mums būtu jāsaskaņo vairāk dažādu pakalpojumu, lai sasniegtu to, ko viens datu plūsmas pakalpojums jau dara viens pats, palielinot lietojumprogrammas apkopes un konfigurācijas sarežģītību. Turklāt buferizācija principā var padarīt mūsu lietojumprogrammu vairs reāllaikā, jo, lai vienums tiktu apstrādāts, ir nepieciešams, lai tiktu apstrādāti arī visi citi vienumi, kas pirms tā tiek apstrādāti, un, pievienojot buferim prioritātes politikas, krasi palielināt sarežģītību. Rezumējot, datu straumēšanas pakalpojumi piedāvā datu plūsmas apstrādi reālā laikā ar vienkāršu konfigurāciju un var nodrošināt ienākošo datu analīzi. Šeit mēs salīdzinām divus galvenos IBM un AWS steka straumēšanas pakalpojumus, proti, IBM Streams un AWS Kinesis.

Sākumā atzīmējam, ka visas pamata funkcijas, kuras mēs varētu vēlēties no straumēšanas pakalpojuma, piedāvā gan IBM, gan AWS. Šīs funkcijas ietver praktiski bezgalīgu apstrādes ātrumu, zemu latentumu un reāllaika datu analīzi. Tā kā mēs runājam par profesionāliem pakalpojumiem, tie abi piedāvā ražošanas kvalitātes rīkus izvietošanai un automatizācijai.

Runājot par datu analīzi, abi pakalpojumi piedāvā to pēc izvēles, liekot jums maksāt tikai neatkarīgi no tā, vai jums tas ir nepieciešams. Kinesis gadījumā, kad jums nav nepieciešama analīze, bet tikai datu plūsmas apstrāde, cenas tiek iekasētas par apstrādāto GB, nevis apstrādes laiku, piemēram, IBM gadījumā. Cena par GB parasti būs lētāka nekā cena par laiku, jo jūs maksājat tikai par ienākošo datplūsmu. Pārējā šī ziņojuma daļā mēs apsvērsim gan IBM Streams, gan AWS Kinesis ar iespējotu datu analīzes funkciju.

Streams un Kinesis nodrošina integrāciju ar dažādiem pakalpojumiem ienākošo datu pirmapstrādei un filtrēšanai pirms to nodošanas datu analītikai, attiecīgi ar Apache Edgent un AWS Lambda. Lai gan šie pakalpojumi ir radikāli atšķirīgi, mēs tos apspriedīsim tikai no abu straumēšanas pakalpojumu viedokļa. Būtiska atšķirība starp abiem ir tas, ka Apache Edgent izpilda ierīcē, bet AWS Lambda izpilda mākonī. Tam ir daudz plusi un mīnusi: no Lambda puses mums ir elastīgs un ērti lietojams pakalpojums ar nevainojamu integrāciju ar Kinesis, taču tas prasa, lai dati jau būtu augšupielādēti mākonī, tādējādi zaudējot efektivitāti un maksājot arī par Kinesis par datiem, kas galu galā tiks izmesti. Tā vietā no Edgent puses mums ir tā, ka lielākā daļa aprēķinu tiek veikta tīkla malā (tātad ierīcēs) pirms bezjēdzīgu datu augšupielādes mākonī. Galvenais trūkums ir tas, ka Edgent ir liels ietvars, kura uzstādīšana var prasīt laiku un kura uzturēšana var būt sarežģīta. Vēl viena atšķirība, kas varētu būt nozīmīga, izvēloties platformu, ir tā, ka Edgent ir pilnībā atvērts avots, bet Lambda nav. To var uzskatīt gan par profesionāli, jo piekļuve kodam, kuru jūs vai jūsu klients izpildīs, vienmēr ir pozitīva lieta, gan kā maldinājums, jo var būt situācijas, kad jums ir nepieciešams steidzams atbalsts, ko nevar nodrošināt visas atvērtā pirmkoda vides.

Citas iezīmes, kuras mēs varam pieminēt, ir Kinesis piešķirto resursu automātiska mērogojamība. Patiešām, tā piedāvāto aparatūru veido vairākas tā sauktās paralēli darbojošās Kinezes apstrādes vienības (KPU), kurās viens KPU piedāvā 1 vCore un 4 GB RAM. To skaits ir atkarīgs no lietojumprogrammas vajadzībām un tiek piešķirts dinamiski un automātiski (tas, ko jūs maksājat, patiešām ir CPU laiks, kas reizināts ar KPU skaitu), tikai atcerieties, ka saskaņā ar Kinesis politiku no jums tiek iekasēta maksa par vienu KPU vairāk, ja izmantojat Java pieteikumu. Tā vietā IBM Streams nenodrošina šāda veida elastību, piedāvājot jums konteineru ar fiksētu aparatūru, sīkāku informāciju, kad mēs runājam par cenām. No otras puses, IBM Streams ir atvērtāks nekā Kinesis, jo tas savienojas ar WAN, izmantojot bieži lietotus protokolus, piemēram, HTTP, MQTT un tā tālāk, savukārt Kinesis ir slēgts AWS ekosistēmai.

Galīgajā salīdzinājumā runāsim par cenām un ļaujiet man teikt, ka IBM šajā jautājumā nedarbojas lieliski. Mēs esam konfigurējuši dažādus risinājumus trim dažādām kategorijām (pamata, augstākās klases, īpaši augstas klases) gan IBM, gan AWS, un mēs salīdzināsim to cenu. Pamata konfigurācijā mums ir viens AWS KPU, kas minēts iepriekš, pret IBM risinājumu ar tādu pašu aparatūru. Augstākās klases ierīcēm mums ir 8 KPU, kas darbojas paralēli Kinesis, un 2 konteineri vienmēr paralēli IBM, katrs ar 4 vCores un 12 GB RAM. Vienmēr IBM īpaši augstākās klases piedāvājumā ir viens konteiners ar 16 vCores un 128 GB RAM, bet mēs izlaidām līdzvērtīgu risinājumu AWS, jo, ja kādai lietojumprogrammai ir vajadzīgs tik liels RAM apjoms, to nevarēs palaist ar dažādiem KPU. Cenas, par kurām ziņojam, ir izteiktas ASV dolāros mēnesī, ņemot vērā izmantošanu visu diennakti. Pamatkonfigurācijai mums ir IBM un AWS attiecīgi 164 USD un 490 USD, augstākās klases 1320 USD un 3500 USD, īpaši augstākās klases AWS netiek ņemta vērā, un ir tikai IBM ar 6300 USD. No šiem rezultātiem mēs redzam, ka Kinesis darbojas labāk ikdienas lietotājam līdz uzņēmuma līmenim, bet tam trūkst iespēju tieši apstrādāt datu analīzi, kas prasa milzīgu skaitļošanas jaudu. Kinesis nodrošina labāku veiktspējas/USD attiecību nekā IBM Streams, ko palīdz arī dinamiskā mazo resursu bloku piešķiršana tikai nepieciešamības gadījumā, savukārt IBM piedāvā fiksētu konteineru. Tādā veidā, ja jūsu darba slodzei ir raksturīga maksimuma palielināšanās, ar IBM jūs esat spiests pārvērtēt savas lietojumprogrammu vajadzības un konfigurēt risinājumu sliktākajā gadījumā. IBM piedāvā maksu par stundām, nevis visu mēnesi, bet tā nav automatizēta kā Kinesis.

4. solis: IoT arhitektūra

Aws iot ierīču konfigurācija ir diezgan vienkārša, salīdzinot ar ibm watson iot. Tā kā ibm watson iot autentifikācija tiek veikta katrai ierīcei ar marķieri, un, parādot marķieri, tā vairs netiks parādīta. Atkal pie cenu daļas ibm watson iot ir diezgan dārgi, salīdzinot ar aws iot. Tātad, cena ibm watson iot cenās ir atkarīga no ierīces, datu glabāšanas, datu trafika. Bet diemžēl mēs varam samaksāt summu vienu reizi, un mēs varam pievienot vairāk ierīču un datu, kas publicēti no ierīcēm un piegādāti ierīcēm.

Sāciet ar savu ierīci- neatkarīgi no tā, vai tas ir sensors, vārteja vai kas cits- un ļaujiet mums palīdzēt izveidot savienojumu ar mākoni.

Ierīces dati vienmēr ir droši, kad izveidojat savienojumu ar mākoni, izmantojot atvērtu, vieglu MGTT ziņojumapmaiņas protokolu vai HTTP. Izmantojot protokolus un mezglu sarkanu, mēs varam savienot savu ierīci ar iot platformu un piekļūt tiešajiem un vēsturiskajiem datiem.

Izmantojiet mūsu drošās API, lai savienotu savas lietotnes ar datiem no jūsu ierīcēm.

Izveidojiet lietojumprogrammas mūsu noteiktajā mākoņa pakalpojumā, lai interpretētu datus.