AWS e IBM: una comparación de servicios de IoT: 4 pasos

2024 Autor: John Day | [email protected]. Última modificación: 2024-01-30 08:42

Hoy comparamos dos pilas que permiten desarrollar aplicaciones IoT bajo el punto de vista de diferentes ofertas de servicios.

Paso 1: funciona como servicio

FaaS es una categoría de servicios en la nube que se utiliza para construir una arquitectura "sin servidor". FaaS permite a los clientes desarrollar, ejecutar y administrar funcionalidades de aplicaciones sin construir y mantener la infraestructura.

Amazon ofrece AWS Lambda, IBM ofrece IBM Cloud Functions. Esos servicios son bastante similares, sin embargo Lambda fue el primero de este tipo. Con FaaS puede ejecutar fragmentos de código en la nube y cada servicio admite diferentes lenguajes de programación.

Funciones de IBM Cloud: JavaScript, Swift, Java, Go, Php, Python, Ruby,. NET (C # F #, etc.), Cualquiera a través de Docker AWS Lambda: JavaScript, Java, C #, F #, Go, Python, Ruby, PowerShell, Cualquiera a través de la API en tiempo de ejecución

IBM admite más idiomas y con la ventana acoplable es fácil de usar scripts escritos en otros idiomas. Esto también se puede hacer con Lambda pero no es inmediato. Puede leer un ejemplo aquí:

Ambos servicios tienen límites de uso, los reportamos en una tabla y resaltamos los mejores.

El precio se basa en GigaBytes por segundo (RAM) más el número de solicitudes de AWS Lambda, cada servicio tiene un plan gratuito y son casi equivalentes. Como puede ver, Lambda es un poco más barato para los GB / s, pero tiene un costo relacionado con las solicitudes que Cloud Functions no tiene, por lo que el costo es casi el mismo en general. Por supuesto, si necesita ejecutar tareas que consumen memoria y utiliza pocas solicitudes, debe usar Lambda. La principal ventaja de IBM Cloud Function, en nuestra opinión, es que su pila es de código abierto. Está completamente basado en Apache OpenWhisk y también se puede implementar en una infraestructura privada.

Paso 2: aprendizaje automático

Un campo en el que las pilas de IBM y AWS ofrecen servicios similares es el del aprendizaje automático: Amazon con su SageMaker e IBM con Watson Machine Learning. Los dos servicios son muy similares en muchos aspectos: ambos se presentan como herramientas para ayudar a los científicos y desarrolladores de datos a construir, entrenar y luego implementar en entornos listos para producción sus modelos de aprendizaje automático, pero las filosofías que adoptan las dos empresas varían bastante. Ambos servicios le permiten elegir entre diferentes grados de control sobre los modelos que utiliza. En Watson ML, tiene algunos modelos integrados que ya están entrenados para realizar algunas tareas muy específicas: por ejemplo, si desea reconocer qué objetos están presentes en una imagen, simplemente importe el modelo VisualRecognitionV3 y le pase la imagen que desee. quiero analizar. También puede crear un "modelo personalizado", pero en Watson ML esto significa principalmente tomar un modelo ya construido y hacer nuestro entrenamiento sobre él, por lo que la personalización es bastante limitada. Sin embargo, es importante tener en cuenta que ni SageMaker ni Watson ML son las únicas formas de hacer aprendizaje automático en las pilas de sus desarrolladores, son solo servicios que tienen como objetivo facilitar la vida de los desarrolladores. La plataforma Watson ML también es compatible con muchas de las bibliotecas de aprendizaje automático más populares, por lo que incluso puede crear un modelo desde cero con PyTorch, Tensorflow o bibliotecas similares. O usa esas bibliotecas directamente o usa los modelos prefabricados, no hay término medio. Además, Watson ML no es compatible con la biblioteca de opciones de Amazon, Apache MXNet, que en cambio tiene soporte de primera clase en SageMaker.

El enfoque de Amazon SageMaker, incluso cuando se utilizan opciones integradas, es de un nivel un poco más bajo: en lugar de hacer que elija entre modelos prefabricados, le permite elegir entre una gran cantidad de algoritmos de entrenamiento ya implementados, que puede usar al crear su modelo de una manera más tradicional. Si estos no son suficientes, también puede usar su propio algoritmo. Esta forma de hacer las cosas ciertamente requiere más conocimiento sobre cómo se realiza el aprendizaje automático en comparación con solo usar un modelo entrenado en Watson ML.

A primera vista, puede parecer que Watson ML es la forma "fácil y rápida", siendo Amazon SageMaker la más compleja de configurar. Esto puede no ser del todo cierto desde algunos puntos de vista, ya que SageMaker está estructurado para hacer que todo se ejecute en un Jupyter Notebook, mientras que para las mismas funciones en Watson ML debe configurar muchos subservicios diferentes desde la interfaz de usuario web. El preprocesamiento de los datos también tiene espacios dedicados en el servicio de IBM, mientras que SageMaker confía en que usted lo haga todo desde el código de su computadora portátil. Esto, sumado al hecho de que los portátiles Jupyter no son exactamente la mejor opción desde el punto de vista de la ingeniería de software, puede impedir que SageMaker escale muy bien en producción. Ambos servicios tienen mecanismos bastante buenos y simples para implementar su modelo y hacer que las API estén disponibles en el mundo exterior.

En conclusión, Watson ML funciona mejor en proyectos grandes en los que los cuadernos de Jupyter comienzan a mostrar sus límites y en los que no se necesita mucha personalización en lo que hace el modelo en sí. SageMaker es mucho mejor cuando necesita más flexibilidad para definir los algoritmos, pero al usarlo debe tener en cuenta el hecho de que debe confiar en Jupyter Notebooks, que pueden no escalar bien en producción. Una solución podría ser desacoplar el resto del código del modelo tanto como sea posible, para que el código en los cuadernos reales no sea demasiado grande y podamos organizar mejor nuestro software en los otros módulos que solo usan la API de nuestro modelo..

Paso 3: Streaming y análisis de datos

Los servicios de transmisión de datos son cruciales para el manejo y análisis en tiempo real de grandes flujos de datos. Este flujo puede ser de la nube al dispositivo de los usuarios, como una transmisión de video, o de los usuarios a la nube, como la telemetría de IoT y las lecturas de los sensores. Especialmente en el segundo caso, podríamos tener una situación en la que fuentes únicas cargan pequeñas cantidades de datos, pero cuando consideramos el rendimiento general, proveniente de todos los dispositivos, consume un ancho de banda considerable, por lo que tiene sentido utilizar un servicio especializado para manejar tales flujos de datos. Sin manejar este flujo continuo directamente, tendríamos que almacenar la información entrante en un almacenamiento temporal y, por segunda vez, procesarla con algún motor computacional. El problema de este último enfoque es que tendríamos que coordinar más servicios diferentes para lograr lo que ya hace un solo servicio de flujo de datos por sí solo, lo que aumenta la complejidad del mantenimiento y la configuración de la aplicación. Además, el almacenamiento en búfer puede, en principio, hacer que nuestra aplicación ya no esté en tiempo real, ya que para que un elemento sea procesado es necesario que todos los demás elementos anteriores a él también se procesen, y agregar políticas de precedencia al búfer puede, nuevamente, aumentar la complejidad drásticamente. En resumen, los servicios de transmisión de datos ofrecen manejo del flujo de datos en tiempo real, con una configuración sencilla, y pueden proporcionar análisis de los datos entrantes. Aquí comparamos los dos principales servicios de transmisión de la pila de IBM y AWS, a saber, IBM Streams y AWS Kinesis.

Comenzamos señalando que todas las características básicas que podemos desear de un servicio de transmisión son ofrecidas tanto por IBM como por AWS. Estas características incluyen una velocidad de procesamiento prácticamente infinita, baja latencia y análisis de datos en tiempo real. Dado que estamos hablando de servicios profesionales, ambos ofrecen herramientas de producción para implementación y automatización.

Hablando de analítica de datos, ambos servicios lo ofrecen como opcional, haciendo que pagues solo lo necesites o no. En el caso de Kinesis, cuando no necesita análisis sino solo manejo del flujo de datos, los precios se cobran por GB procesado en lugar del tiempo de procesamiento, como en el caso de IBM. El precio por GB será generalmente menos costoso que el precio por tiempo, ya que solo paga por el tráfico entrante. Para el resto de esta publicación, consideraremos IBM Streams y AWS Kinesis con la función de análisis de datos habilitada.

Streams y Kinesis brindan integración con diferentes servicios para preprocesar y filtrar los datos entrantes antes de pasarlos al análisis de datos, respectivamente con Apache Edgent y AWS Lambda. Si bien estos servicios son radicalmente diferentes entre sí, los discutiremos solo desde el punto de vista de los dos servicios de transmisión. La diferencia fundamental entre los dos es que Apache Edgent se ejecuta en el dispositivo, mientras que AWS Lambda se ejecuta en la nube. Esto trae muchos pros y contras: desde el lado de Lambda tenemos un servicio flexible y fácil de usar con una integración perfecta con Kinesis, pero requiere que los datos ya estén cargados en la nube, perdiendo así en eficiencia y pagando a Kinesis también. para los datos que eventualmente serán descartados. En cambio, desde el lado de Edgent, tenemos que la mayor parte del cálculo se realiza, bueno, en el borde de la red (por lo tanto, en los dispositivos) antes de cargar datos inútiles en la nube. El principal inconveniente es que Edgent es un marco grande, que puede requerir tiempo para configurar y podría ser complejo de mantener. Otra diferencia que podría ser relevante en la elección de una plataforma es que Edgent es completamente de código abierto, Lambda no lo es. Esto puede verse como un profesional, ya que tener acceso al código que usted o su cliente ejecutarán siempre es algo positivo, tanto como una estafa, porque puede haber situaciones en las que necesite soporte urgente que no se puede proporcionar en todos los entornos de código abierto.

Otras características que podemos mencionar es la escalabilidad automática de Kinesis de los recursos asignados. De hecho, el hardware que ofrece está compuesto por varias unidades de procesamiento Kinesis (KPU) que se ejecutan en paralelo, donde una KPU ofrece 1 núcleo virtual y 4 GB de RAM. Su número depende de las necesidades de la aplicación y se asignan de forma dinámica y automática (lo que paga es, de hecho, el tiempo de la CPU multiplicado por la cantidad de KPU), solo recuerde que es una política de Kinesis cobrarle una KPU más si usa Java solicitud. IBM Streams, en cambio, no proporciona este tipo de flexibilidad, ofreciéndole un contenedor con hardware fijo, más detalles cuando hablamos de precios. Por otro lado, IBM Streams es más abierto que Kinesis, ya que interactúa con la WAN a través de protocolos de uso común, como HTTP, MQTT, etc., mientras que Kinesis está cerrado al ecosistema AWS.

Como comparación final, hablemos de precios y déjeme decirle que IBM no funciona muy bien en este punto. Hemos configurado diferentes soluciones para tres categorías diferentes (básica, alta gama, ultra alta gama) tanto para IBM como para AWS, y vamos a comparar su precio. En la configuración básica tenemos una AWS KPU, mencionada anteriormente, contra una solución de IBM con el mismo hardware. Para la gama alta tenemos 8 KPUs ejecutándose en paralelo para Kinesis y 2 contenedores siempre en paralelo para IBM, cada uno con 4 vCores y 12GB de RAM. Siempre IBM ofrece en la ultra alta gama un solo contenedor con 16 vCores y 128GB de RAM, mientras que omitimos una solución equivalente para AWS, ya que si alguna aplicación requiere esta gran cantidad de RAM no podría ejecutarla en diferentes KPUs.. Los precios que informamos están expresados en $ / mes considerando un uso las 24 horas del día, los 7 días de la semana. Para la configuración básica tenemos para IBM y AWS respectivamente 164 $ y 490 $, para la gama alta 1320 $ y 3500 $, para la ultra alta gama no se considera AWS y solo hay IBM con 6300 $. A partir de estos resultados, podemos ver que Kinesis funciona mejor para el usuario diario hasta el nivel empresarial, mientras que carece de opciones para manejar directamente análisis de datos que requieren una enorme cantidad de potencia informática. Kinesis ofrece una mejor relación rendimiento / $ que IBM Streams, ayudado también por la asignación dinámica de pequeños bloques de recursos solo cuando es necesario, mientras que IBM le ofrece un contenedor fijo. De esta forma, si tu carga de trabajo se caracteriza por picos, con IBM te ves obligado a sobreestimar las necesidades de tu aplicación y configurando una solución en el peor de los casos. IBM ofrece tarifas por horas en lugar de pagar el mes completo, pero no está automatizado como Kinesis.

Paso 4: Arquitectura de IoT

La configuración de dispositivos para aws iot es bastante fácil en comparación con ibm watson iot. Porque en ibm watson iot la autenticación es por dispositivo con token y una vez que muestra el token, nunca se volverá a mostrar. Volver a fijar el precio de la pieza ibm watson iot es bastante costoso en comparación con aws iot. Por lo tanto, el precio en cargos de ibm watson iot se basa en por dispositivo, almacenamiento de datos y tráfico de datos. Pero en aws iot podemos pagar la cantidad una vez y podemos agregar más dispositivos y datos publicados desde dispositivos y entregados a dispositivos.

Comience con su dispositivo, ya sea un sensor, una puerta de enlace u otra cosa, y permítanos ayudarlo a conectarse con la nube.

Los datos de su dispositivo siempre están seguros cuando se conecta a la nube mediante el protocolo de mensajería MGTT abierto y ligero o HTTP. Con la ayuda de protocolos y node-red podemos conectar nuestro dispositivo con la plataforma iot y podemos acceder a datos históricos y en vivo.

Utilice nuestras API seguras para conectar sus aplicaciones con los datos de sus dispositivos.

Cree aplicaciones dentro de nuestro servicio en la nube para interpretar datos.