AWS i IBM: una comparació de serveis IoT: 4 passos

2024 Autora: John Day | [email protected]. Última modificació: 2024-01-30 08:14

Avui comparem dues piles que permeten desenvolupar aplicacions IoT des del punt de vista de diferents ofertes de serveis.

Pas 1: Funcions com a servei

FaaS és una categoria de serveis al núvol que s’utilitzen per construir una arquitectura “sense servidor”. FaaS permet als clients desenvolupar, executar i gestionar funcionalitats d’aplicacions sense construir i mantenir la infraestructura.

Amazon ofereix AWS Lambda, IBM ofereix IBM Cloud Functions. Aquests serveis són bastant similars, però Lambda va ser el primer d’aquest tipus. Mitjançant FaaS podeu executar trossos de codi al núvol i tots els serveis admeten diferents llenguatges de programació.

Funcions del núvol d'IBM: JavaScript, Swift, Java, Go, Php, Python, Ruby,. NET (C # F # etc.), Qualsevol mitjançant Docker AWS Lambda: JavaScript, Java, C #, F #, Go, Python, Ruby, PowerShell, Any mitjançant API Runtime

IBM admet més idiomes i amb Docker és fàcil utilitzar scripts escrits en altres idiomes. Això es pot fer també amb Lambda, però no és immediat. Podeu llegir un exemple aquí:

Tots dos serveis tenen límits d’ús, els informem en una taula i en ressaltem els millors.

El preu es basa en GigaBytes per segon (RAM) i s’afegeix el nombre de sol·licituds per AWS Lambda. Cada servei té un pla gratuït i són gairebé equivalents. Com podeu veure, Lambda és una mica més barat per als GB / s, però té un cost relacionat amb les sol·licituds que Cloud Functions no té, de manera que el cost és gairebé el mateix en general. Per descomptat, si heu d’executar tasques que consumeixen memòria i utilitzen poques peticions, hauríeu d’utilitzar Lambda. Al nostre parer, l’avantatge principal d’IBM Cloud Function és que la seva pila és de codi obert. Està completament basat en Apache OpenWhisk i també es pot desplegar en una infraestructura privada.

Pas 2: aprenentatge automàtic

Un camp on les piles IBM i AWS ofereixen serveis similars és el de l’aprenentatge automàtic: Amazon amb el seu SageMaker i IBM amb Watson Machine Learning. Els dos serveis presenten molts aspectes molt similars: tots dos es presenten com a eines per ajudar els científics i desenvolupadors de dades a construir, formar i desplegar en entorns preparats per a la producció els seus models d’aprenentatge automàtic, però les filosofies que adopten les dues empreses varien força. Tots dos serveis us permeten triar entre diferents graus de control dels models que utilitzeu. A Watson ML, teniu alguns models integrats que ja estan entrenats per fer algunes tasques molt específiques: per exemple, si voleu reconèixer quins objectes hi ha presents en una imatge, només heu d’importar el model VisualRecognitionV3 i passar-hi la imatge que vull analitzar. També podeu crear un "model personalitzat", però a Watson ML això vol dir sobretot agafar un model ja construït i fer-hi la nostra formació, de manera que la personalització és bastant limitada. Tanmateix, és important notar que ni SageMaker ni Watson ML són les úniques maneres d’aprendre automàticament a les piles dels seus desenvolupadors, sinó que són només serveis que volen facilitar la vida dels desenvolupadors. La plataforma Watson ML també admet moltes de les biblioteques d’aprenentatge automàtic més populars, de manera que fins i tot podeu crear un model des de zero amb PyTorch, Tensorflow o biblioteques similars. O bé feu servir aquestes biblioteques directament o utilitzeu els models prefabricats, ja que no hi ha cap punt intermedi. A més, Watson ML no admet la biblioteca d’elecció d’Amazon, Apache MXNet, que en canvi té suport de primera classe a SageMaker.

L’enfocament d’Amazon SageMaker, fins i tot quan s’utilitzen opcions integrades, és una mica més baix: en lloc de fer-vos triar entre models prefabricats, us permet triar entre una gran quantitat d’algoritmes d’entrenament ja implementats, que podeu utilitzar a l’hora de construir el vostre model d’una manera més tradicional. Si no n’hi ha prou, també podeu utilitzar el vostre propi algorisme. Aquesta manera de fer coses requereix certament més coneixement sobre com es fa l’aprenentatge automàtic en comparació amb l’ús d’un model format a Watson ML.

A primera vista pot semblar que Watson ML és la forma “fàcil i ràpida”, sent Amazon SageMaker el més complex de configurar. Pot ser que això no sigui del tot cert des d'alguns punts de vista, ja que SageMaker està estructurat per fer que tot funcioni en un portàtil Jupyter, mentre que per a les mateixes funcions a Watson ML heu de configurar molts sub-serveis diferents de la interfície d'usuari web. El processament previ de les dades també té espais dedicats al servei IBM, mentre que SageMaker confia en que ho feu tot a partir del codi a la vostra llibreta. Això, a més del fet que els portàtils Jupyter no són exactament la millor opció des del punt de vista de l’enginyeria de programari, pot evitar que SageMaker s’escali molt bé a la producció. Tots dos serveis tenen mecanismes bastant bons i senzills per desplegar el vostre model i fer-ne API disponibles al món exterior.

En conclusió, Watson ML té un millor rendiment en grans projectes on els portàtils Jupyter comencen a mostrar els seus límits i on no necessiteu molta personalització del que fa el model en si. SageMaker és molt millor quan es necessita més flexibilitat a l’hora de definir els algoritmes, però a l’hora d’utilitzar-lo s’ha de tenir en compte el fet que s’ha de confiar en els portàtils Jupyter, que potser no s’escalen bé en la producció. Una solució podria ser desvincular la resta del codi del model tant com sigui possible, de manera que el codi dels portàtils reals no sigui massa gran i puguem organitzar millor el nostre programari en els altres mòduls que només fan servir l’API del nostre model..

Pas 3: transmissió de dades i anàlisi

Els serveis de transmissió de dades són crucials per tractar i analitzar en temps real grans fluxos de dades. Aquest flux pot ser des del núvol fins al dispositiu dels usuaris, com ara una transmissió de vídeo, o des dels usuaris fins al núvol, com ara telemetria IoT i lectures de sensors. Especialment en el segon cas, podríem tenir una situació en què fonts individuals pengen petites quantitats de dades, però quan considerem el rendiment global, provinent de tots els dispositius, consumeix una amplada de banda considerable, per la qual cosa té sentit utilitzar un servei especialitzat per gestionar aquest tipus de dades. fluxos de dades. Sense gestionar aquest flux continu directament, hauríem d’emmagatzemar la informació entrant en un emmagatzematge temporal i, en un segon temps, processar-la amb algun motor computacional. El problema d’aquest darrer enfocament és que hauríem de coordinar més serveis diferents per aconseguir el que ja fa un servei únic de flux de dades, augmentant la complexitat del manteniment i la configuració de l’aplicació. A més, la memòria intermèdia pot, en principi, fer que la nostra aplicació deixi de ser en temps real, ja que perquè un article es processi és necessari que es processin tots els altres elements anteriors, i afegir polítiques de precedència al tampó també, augmenten dràsticament la complexitat. En resum, els serveis de transmissió de dades ofereixen un tractament de flux de dades en temps real, amb una configuració senzilla, i poden proporcionar anàlisis de les dades entrants. Aquí comparem els dos serveis de transmissió principals de la pila IBM i AWS, és a dir, IBM Streams i AWS Kinesis.

Comencem per assenyalar que totes les funcions bàsiques que podem desitjar d’un servei de transmissió les ofereixen tant IBM com AWS. Aquestes funcions inclouen velocitat de processament pràcticament infinita, baixa latència i anàlisi de dades en temps real. Com que parlem de serveis professionals, tots dos ofereixen eines de producció per al desplegament i l'automatització.

Parlant d’anàlisi de dades, tots dos serveis l’ofereixen de manera opcional, cosa que us permet pagar només si ho necessiteu o no. En el cas de Kinesis, quan no necessiteu analítiques, sinó només un tractament de flux de dades, els preus es cobren per GB processats en lloc del temps de processament, com en el cas d’IBM. Els preus per GB solen ser menys costosos que els preus per temps, ja que només pagueu pel trànsit entrant. Durant la resta d’aquest post, considerarem tant IBM Streams com AWS Kinesis amb la funció d’anàlisi de dades activada.

Streams i Kinesis proporcionen integració amb diferents serveis per pre-processar i filtrar les dades entrants abans de passar-les a l’anàlisi de dades, respectivament amb Apache Edgent i AWS Lambda. Tot i que aquests serveis són radicalment diferents entre si, els parlarem només des del punt de vista dels dos serveis de transmissió. La diferència fonamental entre tots dos és que Apache Edgent s’executa al dispositiu, mentre que AWS Lambda s’executa al núvol. Això comporta molts avantatges i desavantatges: des del costat de Lambda tenim un servei flexible i fàcil d’utilitzar amb una integració perfecta amb Kinesis, però requereix que les dades ja es pengin al núvol, perdent així l’eficiència i pagant també a Kinesis. per les dades que finalment es descartaran. En canvi, des del costat d’Edgent, tenim la majoria dels càlculs realitzats a la vora de la xarxa (per tant als dispositius) abans de penjar dades inútils al núvol. El principal inconvenient és que Edgent és un marc ampli, que pot requerir temps per configurar-lo i que podria ser complex de mantenir. Una altra diferència que podria ser rellevant en l'elecció d'una plataforma és que Edgent és completament de codi obert, Lambda no. Això es pot veure tant com a professional, ja que tenir accés al codi que executareu vosaltres o el vostre client sempre és positiu, tant com a contrari, perquè pot haver-hi situacions en què necessiteu assistència urgent que no es pot proporcionar a tots els entorns de codi obert.

Altres característiques que podem esmentar és l’escalabilitat automàtica de Kinesis dels recursos assignats. De fet, el maquinari que ofereix està compost per diverses unitats anomenades Kinesis Processing Units (KPU) que funcionen en paral·lel, on un KPU ofereix 1 vCore i 4 GB de RAM. El seu nombre depèn de les necessitats de l’aplicació i s’assigna de manera dinàmica i automàtica (el que pagueu és, de fet, el temps de la CPU multiplicat pel nombre de KPU), recordeu que és una política de Kinesis cobrar-vos una KPU més si utilitzeu un Java aplicació. IBM Streams, en canvi, no proporciona aquest tipus de flexibilitat, ja que us ofereix un contenidor amb maquinari fix, més detalls quan parlem de preus. D’altra banda, IBM Streams és més obert que Kinesis, ja que s’interface amb la WAN mitjançant protocols habituals, com HTTP, MQTT, etc., mentre que Kinesis està tancat a l’ecosistema AWS.

Com a comparació final, parlem de preus i deixeu-me dir que IBM no funciona molt bé en aquest punt. Hem configurat diferents solucions per a tres categories diferents (bàsica, gamma alta, gamma alta), tant per a IBM com per AWS, i compararem el seu preu. A la configuració bàsica tenim un AWS KPU, esmentat anteriorment, contra una solució IBM amb el mateix maquinari. Per a la gamma alta, tenim 8 KPU en execució paral·leles per a Kinesis i 2 contenidors sempre en paral·lel per a IBM, cadascun amb 4 vCores i 12 GB de RAM. Sempre IBM ofereix a la gamma ultra-alta un únic contenidor amb 16 vCores i 128 GB de RAM, mentre que hem omès una solució equivalent per AWS, ja que si alguna aplicació requereix aquesta gran quantitat de RAM, no seria possible executar-lo en diferents KPU.. Els preus que informem s’expressen en $ / mes tenint en compte un ús 24/7. Per a la configuració bàsica que tenim per a IBM i AWS respectivament 164 $ i 490 $, per a la gamma alta 1320 $ i 3500 $, per a la gamma AWS de gamma alta no es té en compte i només hi ha IBM amb 6300 $. A partir d'aquests resultats, podem veure que Kinesis funciona millor per a l'usuari quotidià fins a nivell empresarial, mentre que no té opcions per manejar directament l'analítica de dades que requereixen una gran quantitat de potència informàtica. Kinesis ofereix una millor relació rendiment / $ que els corrents d'IBM, ajudat també per l'assignació dinàmica de petits blocs de recursos només quan sigui necessari, mentre que IBM us ofereix un contenidor fix. D'aquesta manera, si la vostra càrrega de treball es caracteritza per pics, amb IBM us veieu obligat a sobreestimar les vostres necessitats d'aplicació i configurar una solució en el pitjor dels casos. IBM ofereix tarifes horàries en lloc de pagar tot el mes, però no està automatitzada com Kinesis.

Pas 4: Arquitectura IoT

La configuració per a dispositius per a aws iot és bastant senzilla en comparació amb ibm watson iot. Com que a ibm watson iot l’autenticació es fa per dispositiu amb token i un cop mostrat el testimoni mai més es tornarà a mostrar. Arribar a la part de preus de nou ibm watson iot és bastant costós en comparació amb aws iot. Per tant, el preu dels càrrecs ibot watson iot es basa en el dispositiu, l’emmagatzematge de dades i el trànsit de dades. Però a aws iot podem pagar l'import una vegada i podem afegir més dispositius i dades publicats des de dispositius i lliurats als dispositius.

Comenceu pel dispositiu (ja sigui un sensor, una passarel·la o alguna cosa més) i deixeu-nos ajudar-vos a connectar amb el núvol.

Les dades del dispositiu sempre són segures quan us connecteu al núvol mitjançant un protocol de missatgeria MGTT obert i lleuger o HTTP. Amb l'ajuda de protocols i vermell de node, podem connectar el nostre dispositiu amb plataforma iot i accedir a dades històriques i en directe.

Utilitzeu les nostres API segures per connectar les vostres aplicacions amb dades dels vostres dispositius.

Creeu aplicacions dins del nostre servei de núvol per interpretar les dades.