Enfoques de arquitectura para IoT en una solución multiinquilino

Existe una gran variedad de soluciones de IoT multiinquilino. Es posible que tenga muchos requisitos y restricciones, que van desde la propiedad de la infraestructura, el aislamiento de los datos del cliente y hasta el cumplimiento. Puede ser complicado definir un patrón que cumpla todas estas restricciones de diseño y, a menudo, es necesario tener en cuenta varias dimensiones. En este artículo se describen varios enfoques que se usan habitualmente para resolver consideraciones multiinquilino para soluciones basadas en IoT. En este documento se incluyen arquitecturas multiinquilino de ejemplo que aprovechan los componentes comunes, según la arquitectura de referencia de IoT.

Consideraciones clave y requisitos

Estas consideraciones y requisitos se presentan en el orden en que normalmente se les da prioridad para el diseño de una solución.

Gobernanza y cumplimiento

Las consideraciones de gobernanza y cumplimiento pueden requerir que use un patrón o conjunto de recursos de IoT determinados. No todos los servicios de IoT tienen las mismas certificaciones o funcionalidades. Si necesita cumplir estándares de cumplimiento específicos, es posible que tenga que seleccionar servicios específicos. La información sobre gobernanza y cumplimiento se trata en un artículo dedicado sobre ese tema.

La gobernanza en IoT también puede tomar formas adicionales, como la propiedad y la administración de dispositivos. ¿Es el cliente el propietario del dispositivo o lo es el proveedor de soluciones? ¿Quién posee la administración de esos dispositivos? Estas observaciones e implicaciones son únicas para cada proveedor de soluciones y pueden dar lugar a distintas opciones en la tecnología, el patrón de implementación y el patrón multiinquilino que use.

Escala

Es importante planear la escala de la solución. A menudo, la escala se tiene en cuenta en estas tres dimensiones:

• Cantidad de dispositivos: todos los servicios de administración de dispositivos de Azure (Azure IoT Central, Azure IoT Hub Device Provisioning Service (DPS) y Azure IoT Hub) tienen limitaciones en el número de dispositivos admitidos en una sola instancia.

  Sugerencia

  Consulte la documentación a gran escala si planea implementar un gran número de dispositivos.

• Rendimiento del dispositivo: los distintos dispositivos, incluso en la misma solución, pueden tener requisitos de rendimiento diferentes. "Rendimiento" en este contexto hace referencia tanto al número de mensajes durante un período de tiempo como al tamaño de los mensajes. Por ejemplo, en una solución de creación inteligente, es probable que los termostatos proporcionen datos con una frecuencia menor que los ascensores, mientras que en una solución de vehículo conectado, la cámara del vehículo que registra los mensajes de datos probablemente será mayor que los mensajes de telemetría de navegación. Si los mensajes se limitan según la frecuencia, es posible que tenga que escalar horizontalmente a más instancias de un servicio determinado, pero si se limitan según el tamaño, es posible que tenga que escalar verticalmente a instancias más grandes de un servicio determinado.

• Inquilinos: la escala de un solo inquilino puede ser pequeña, pero cuando se multiplica por el número de inquilinos, puede crecer rápidamente.

Rendimiento y confiabilidad

Aislamiento de inquilinos

Las soluciones totalmente compartidas pueden tener vecinos ruidosos. En los casos de IoT Hub e IoT Central, esto puede dar lugar a códigos de respuesta HTTP 429 ("Demasiadas solicitudes"), que son errores graves que pueden provocar un efecto en cascada. Para obtener más información, consulte Cuotas y límites.

En soluciones que son totalmente multiinquilino, estos efectos pueden darse en cascada. Cuando los clientes comparten aplicaciones de IoT Hub o IoT Central, todos los clientes de la infraestructura compartida comenzarán a recibir errores. Dado que IoT Hub e IoT Central normalmente son los puntos de entrada de los datos a la nube, es probable que también se puedan producir errores en otros sistemas de bajada que dependen de estos datos. A menudo, esto sucede cuando se ha superado un límite de cuota de mensajes. En esta situación, la solución más rápida y sencilla para las soluciones de IoT Hub es actualizar la SKU de IoT Hub, aumentar el número de unidades de IoT Hub o realizar ambas opciones. En el caso de las soluciones de IoT Central, la solución se escala automáticamente según sea necesario, hasta el número documentado de mensajes admitidos.

Puede aislar y distribuir inquilinos en los planos de comunicaciones, administración y control de IoT mediante las directivas de asignación personalizadas de DPS. Además, cuando sigue las instrucciones de las soluciones de IoT de gran escala, puede administrar la distribución de asignación adicional en el nivel de equilibrador de carga de DPS.

Almacenamiento, consulta, uso y retención de datos

Las soluciones de IoT tienden a hacer un uso intensivo de los datos, ya sea durante la transmisión como en reposo. Para obtener más información sobre la administración de datos en soluciones multiinquilino, consulte Enfoques de arquitectura para el almacenamiento y los datos en soluciones multiinquilino.

Seguridad

Las soluciones de IoT suelen tener consideraciones de seguridad en varias capas, especialmente en las soluciones que se implementan en una arquitectura de referencia empresarial de Purdue modificada en la nube o soluciones de la Industria 4.0. El enfoque de diseño seleccionado de entre los que se indican a continuación influirá en las capas y límites de red existentes; una vez seleccionado el diseño físico, se puede seleccionar la implementación de la seguridad. Entre las herramientas que se pueden usar en cualquier enfoque se incluyen:

• Microsoft Defender para IoT, una solución completa de supervisión de IoT que debe tener en cuenta que ofrece una licencia de EIoT por dispositivo y licencias de sitio de OT para cada dispositivo de cliente o sitio. Según el enfoque seleccionado más adelante en este artículo, es posible que el escenario de licencias de usuario con nombre de Microsoft 365 no sea posible. En ese caso, las opciones de licencia por dispositivo y sitio están disponibles, que son opciones de licencia independientes de las licencias de inquilino de Microsoft 365.

• Azure Firewall o un dispositivo de firewall de terceros, que debe considerar para aislar las capas de red, así como para supervisar el tráfico de red. La elección exacta del enfoque influirá en que las cargas de trabajo tengan aislamiento de red frente a una red compartida, como se explica a continuación.

• Azure IoT Edge u Operaciones de IoT de Azure, que debe considerar como parte de la conectividad de dispositivos a los servicios hospedados en Azure sin exponer directamente los dispositivos al acceso directo a Internet. Como Operaciones de IoT de Azure está en versión preliminar en este momento, en este documento no se describe el uso de esta oferta en general. En una futura revisión de este documento se abordará esta cuestión.

La mayoría de estos temas de seguridad se aplican en una solución multiinquilino de forma similar a como lo harían en una solución de inquilino único, con las variaciones ligadas al enfoque seleccionado. Un componente que probablemente sea sustancialmente diferente en una solución de IoT general es la identidad de usuario y aplicación. Los enfoques arquitectónicos para la identidad en soluciones multiinquilino describen este aspecto de una solución multiinquilino general.

Enfoques a tener en cuenta

Todas las cuestiones que normalmente tendría en cuenta en una arquitectura de IoT, en todos los componentes principales (como la administración, la ingesta, el procesamiento, el almacenamiento, la seguridad, etc.), son todas elecciones que aún debe hacer al buscar una solución multiinquilino. La principal diferencia es cómo organizar y usar los componentes para admitir el multiinquilino. Por ejemplo, los puntos de decisión comunes para el almacenamiento podrían decidir si usar SQL Server o Azure Data Explorer; asimismo, en el nivel de ingesta y administración, puede elegir entre IoT Hub e IoT Central.

La mayoría de las soluciones de IoT se ajustan a un patrón de arquitectura raíz, que es una combinación del destino de implementación, el modelo de inquilino y el patrón de implementación. Estos factores están determinados por los requisitos y consideraciones clave descritos anteriormente.

Uno de los puntos más importantes a tener en cuenta al tomar una decisión en el espacio de IoT, es seleccionar entre una Aplicación de plataforma como servicio (aPaaS) y Plataforma como servicio (PaaS). Para obtener más información, consulte Comparación de enfoques de soluciones de Internet de las cosas (IoT); PaaS frente a aPaaS.

Este es el dilema común de "compilación frente a compra" al que se enfrentan muchas organizaciones en muchos proyectos. Es importante evaluar las ventajas y desventajas de ambas opciones.

Conceptos y consideraciones para soluciones de aPaaS

Una solución aPaaS típica que usa Azure IoT Central como núcleo de la solución, podría usar los siguientes servicios PaaS y aPaaS de Azure:

• Azure Event Hubs como un motor de flujo de datos y mensajería multiplataforma de nivel empresarial.
• Azure Logic Apps como una oferta de plataforma como servicio de integración o iPaaS.
• Azure Data Explorer como una plataforma de análisis de datos.
• Power BI como plataforma de visualización e informes.

En el diagrama anterior, los inquilinos comparten un entorno de IoT Central, Azure Data Explorer, Power BI y Azure Logic Apps.

Este enfoque suele ser la manera más rápida de obtener una solución para el mercado. Se trata de un servicio a gran escala que admite multiinquilinos mediante organizaciones.

Es importante comprender que, dado que IoT Central es una oferta de aPaaS, hay ciertas decisiones que están fuera del control de un implementador. Estas decisiones incluyen:

• IoT Central usa Microsoft Entra ID como proveedor de identidades.
• Las implementaciones de IoT Central se logran mediante operaciones de plano de datos y de control, que combinan documentos declarativos con código imperativo.
• En un patrón multiinquilino, tanto el límite máximo de nodos de IoT Central (que se aplica tanto a los elementos principales como secundarios) y la profundidad máxima del árbol, pueden obligar a un proveedor de servicios a tener varias instancias de IoT Central. En ese caso, debe considerar la posibilidad de seguir el patrón de implementación de Stamp.
• IoT Central impone límites de llamadas API, lo que podría afectar a implementaciones de gran tamaño.

Conceptos y consideraciones para soluciones de aPaaS

Un enfoque basado en PaaS podría usar los siguientes servicios de Azure:

• Azure IoT Hub como plataforma principal de comunicaciones y configuración de dispositivos.
• Azure IoT Device Provisioning Service como la plataforma de implementación y configuración inicial del dispositivo.
• Azure Data Explorer para almacenar y analizar datos de series temporales de ruta de acceso activa e inactiva desde dispositivos IoT.
• Azure Stream Analytics para analizar los datos de ruta de acceso frecuente de los dispositivos IoT.
• Azure IoT Edge para ejecutar inteligencia artificial (IA), servicios de terceros o su propia lógica de negocios en dispositivos IoT Edge.

En el diagrama anterior, cada inquilino se conecta a una aplicación web compartida, que recibe datos de instancias de IoT Hub y de una aplicación de funciones. Los dispositivos se conectan al servicio de aprovisionamiento de dispositivos y a IoT Hub.

Este enfoque requiere que el desarrollador dedique un esfuerzo extra para crear, implementar y mantener la solución (frente a un enfoque de aPaaS). Hay menos funcionalidades creadas previamente para mayor comodidad del implementador. Esto significa que este enfoque también ofrece más control, ya que se insertan menos suposiciones en la plataforma subyacente.

Patrones de arquitectura raíz

En la tabla siguiente se enumeran los patrones comunes para las soluciones de IoT multiinquilino. Cada patrón incluye la siguiente información:

• Nombre del patrón, que se basa en la combinación del destino, el modelo y el tipo de implementación.
• El destino de implementación, que representa la suscripción de Azure en la que se implementarán los recursos.
• El modelo de inquilino al que hace referencia el patrón, como se describe en Modelos multiinquilino.
• El patrón de implementación, que hace referencia a una implementación simple con consideraciones de implementación mínimas, un patrón de nodo geográfico o un patrón de marca de implementación.

Patrón	Destino de implementación	Modelo de inquilino	Patrón de implementación
SaaS simple	Suscripción del proveedor de servicios	Completamente de tipo multiinquilino	Simple
SaaS horizontal	Suscripción del proveedor de servicios	Particionado horizontalmente	Sello de implementación
Un solo inquilino automatizado	Suscripción del proveedor de servicios o del cliente	Un solo inquilino por cliente	Simple

SaaS simple

Destino de la implementación	Modelo de inquilino	Modelo de implementación
Suscripción del proveedor de servicios	Completamente de tipo multiinquilino	Simple

El enfoque de SaaS simple es la implementación más sencilla para una solución de IoT de SaaS. Tal como se muestra en el diagrama anterior, se comparte toda la infraestructura y no se aplica ninguna marca geográfica o de escala. A menudo, la infraestructura reside en una sola suscripción de Azure.

Azure IoT Central admite el concepto de organizaciones. Las organizaciones permiten a un proveedor de soluciones separar fácilmente los inquilinos de una manera segura y jerárquica, al tiempo que comparten el diseño básico de la aplicación entre todos los inquilinos.

Las comunicaciones a sistemas fuera de IoT Central, por ejemplo, para realizar el análisis de datos a largo plazo, a lo largo de una ruta de acceso esporádico o de conectividad con operaciones empresariales, se realizan a través de otras ofertas de PaaS y aPaaS de Microsoft. Estas ofertas adicionales pueden incluir los siguientes servicios:

• Azure Event Hubs como un motor de flujo de datos y mensajería multiplataforma de nivel empresarial.
• Azure Logic Apps como una oferta de plataforma como servicio de integración o iPaaS.
• Azure Data Explorer como una plataforma de análisis de datos.
• Power BI como plataforma de visualización e informes.

Si compara el enfoque de SaaS simple con el modelo aPaaS automatizado de inquilino único, muchas características son similares. La diferencia principal entre los dos modelos es que, en el modelo automatizado de un solo inquilino, se implementa una instancia de IoT Central distinta para cada inquilino, mientras que en el modelo SaaS simple con un modelo de aPaaS, en su lugar se implementa una instancia compartida para varios clientes y se crea una organización de IoT Central para cada inquilino.

A medida que comparte una capa de datos de varios inquilinos en este modelo, deberá implementar la seguridad del nivel de fila, tal y como se describe en Enfoques de arquitectura para el almacenamiento y los datos en soluciones multiinquilino, con el fin de aislar los datos de los clientes.

Ventajas

• Es más fácil de administrar y operar con respecto a los otros enfoques presentados aquí.

Riesgos:

• Es posible que este enfoque no se escale fácilmente a un número muy elevado de dispositivos, mensajes o inquilinos.

• Dado que todos los servicios y componentes se comparten, un error en cualquier componente podría afectar a todos los inquilinos. Esto es un riesgo para la confiabilidad y la alta disponibilidad de la solución.

• Es importante tener en cuenta cómo administrar el cumplimiento, las operaciones, el ciclo de vida de los inquilinos y la seguridad de las flotas de dispositivos. Estas consideraciones son importantes debido a la naturaleza compartida de este tipo de solución en los planos de control, administración y comunicaciones.

SaaS horizontal

Destino de implementación	Modelo de inquilino	Patrón de implementación
Suscripción del proveedor de servicios	Particionado horizontalmente	Sello de implementación

Un enfoque de escalabilidad común es particionar horizontalmente la solución. Esto significa que tiene algunos componentes compartidos y algunos componentes por cliente.

En una solución de IoT, hay muchos componentes que se pueden particionar horizontalmente. Los subsistemas con particiones horizontales se organizan normalmente mediante un patrón de marca de implementación que se integra con la solución mayor.

SaaS horizontal de ejemplo

En el ejemplo de arquitectura siguiente se particiona IoT Central por cliente final, que actúa como portal de administración, comunicaciones y administración de dispositivos. Esto se hace a menudo de manera que el cliente final que consume la solución tiene control total sobre la adición, eliminación y actualización de dispositivos, sin la intervención del proveedor del software. El resto de la solución sigue un patrón de infraestructura compartida estándar, que resuelve las necesidades de análisis de rutas de acceso activas, de integraciones empresariales, de administración de SaaS y de análisis de dispositivos.

Cada inquilino tiene su propia organización IoT Central, que envía telemetría a una aplicación de función compartida y la pone a disposición de los usuarios empresariales de los inquilinos a través de una aplicación web.

Ventajas

• Por lo general, es fácil de administrar y operar, aunque puede ser necesaria una administración adicional para los componentes de un solo inquilino.
• Opciones de escalado flexibles, ya que las capas se escalan según sea necesario.
• Se reduce el impacto de los errores de los componentes. Aunque un error de un componente compartido afecta a todos los clientes, los componentes escalados horizontalmente solo afectan a los clientes asociados a instancias de escalado específicas.
• Se ha mejorado la información de consumo por inquilino para componentes con particiones.
• Los componentes con particiones proporcionan personalizaciones por inquilino más sencillas.

Riesgos:

• Tenga en cuenta la escala de la solución, especialmente para los componentes compartidos.
• La confiabilidad y la alta disponibilidad se pueden ver afectadas. Un único error en los componentes compartidos podría afectar a todos los inquilinos a la vez.
• La personalización de componentes con particiones por inquilino requiere consideraciones de administración y DevOps a largo plazo.

A continuación se muestran los componentes más comunes que suelen ser adecuados para la creación de particiones horizontales.

Bases de datos

Puede optar por crear particiones de las bases de datos. A menudo son los almacenes de datos de telemetría y de dispositivo los que tienen particiones. Con frecuencia, se usan varios almacenes de datos para distintos propósitos específicos, como el almacenamiento flexible frente al almacenamiento de archivado, o para la información de estado de la suscripción de inquilino.

Separe las bases de datos de cada inquilino para obtener las siguientes ventajas:

• Compatibilidad con estándares de cumplimiento. Los datos de cada inquilino están aislados en las instancias del almacén de datos.
• Evitar los problemas de tipo "vecino ruidoso".

Administración, comunicaciones y gestión de dispositivos

Las aplicaciones de Azure IoT Hub Device Provisioning Service, IoT Hub e IoT Central se pueden implementar a menudo como componentes con particiones horizontales. Si sigue este enfoque, debe tener un servicio adicional para redirigir los dispositivos al servicio de aprovisionamiento de dispositivos adecuado para la administración, el control y el plano de telemetría de ese inquilino concreto. Para obtener más información, consulte las notas del producto sobre el Escalado horizontal de una solución de Azure IoT para que admita millones de dispositivos.

Esto suele hacerse para permitir que los clientes finales administren y controlen sus propias flotas de dispositivos, ya que son más directas y están completamente aisladas.

Si el plano de comunicaciones del dispositivo tiene particiones horizontales, los datos de telemetría deben enriquecerse con datos para el inquilino de origen, de modo que el procesador de flujos sepa qué reglas de inquilino se aplicarán al flujo de datos. Por ejemplo, si un mensaje de telemetría genera una notificación en el procesador de flujos, este deberá determinar la ruta de acceso de notificaciones adecuada para el inquilino asociado.

Procesamiento de flujos

Al crear particiones del procesamiento de secuencias, se habilitan personalizaciones por inquilino del análisis en los procesadores de secuencias.

Un solo inquilino automatizado

Un enfoque automatizado de un solo inquilino se basa en un proceso de decisión y diseño similares a una solución empresarial.

Cada inquilino tiene su propio entorno aislado idéntico, con una organización de IoT Central y otros componentes dedicados a ellos.

Destino de la implementación	Modelo de inquilino	Modelo de implementación
Suscripción del proveedor de servicios o del cliente	Un solo inquilino por cliente	Simple

Un punto de decisión fundamental en este enfoque es elegir en qué suscripción de Azure se deben implementar los componentes. Si los componentes se implementan en su suscripción, tendrá más control y mejor visibilidad sobre el costo de la solución, pero es necesario que tenga en cuenta los problemas de seguridad y gobernanza de la solución. Por el contrario, si la solución se implementa en la suscripción del cliente, este es responsable en última instancia de la seguridad y la gobernanza de la implementación.

Este patrón admite un alto grado de escalabilidad. Esto se debe a que los requisitos de inquilino y suscripción suelen ser factores de limitación en la mayoría de las soluciones. Por lo tanto, aísle cada inquilino para poder proporcionar un gran ámbito y así escalar la carga de trabajo de cada inquilino, sin tener que realizar un esfuerzo sustancial como desarrollador de la solución.

En comparación con otros patrones, este patrón también suele tener una latencia baja, ya que puede implementar los componentes de la solución en función de la ubicación geográfica de los clientes. La afinidad geográfica permite crear rutas de acceso de red más cortas entre un dispositivo IoT y la implementación de Azure.

Si es necesario, puede ampliar la implementación automatizada para que admita una latencia o escala mejoradas; gracias a esto, puede realizar una implementación rápida de instancias adicionales de la solución para un cliente en zonas geográficas nuevas o existentes.

El enfoque automatizado de un solo inquilino es similar al modelo de aPaaS SaaS simple. La diferencia principal entre los dos modelos es que en el enfoque automatizado de un solo inquilino implementa una instancia de IoT Central distinta para cada inquilino, mientras que si usa el modelo SaaS simple con aPaaS, debe implementar una instancia compartida de IoT Central con varias organizaciones de IoT Central.

Ventajas

• Es relativamente fácil de administrar y operar.
• Básicamente, se garantiza el aislamiento de inquilinos.

Riesgos:

• La automatización inicial puede ser complicada para el nuevo personal de desarrollo.
• Debe aplicar la seguridad de las credenciales entre clientes en una administración de implementaciones de nivel superior, o los riesgos pueden extenderse entre los clientes.
• Es posible que los costos sean mayores, ya que las ventajas de escalado de una infraestructura compartida entre los clientes no están disponibles.
• Si el proveedor de soluciones puede realizar el mantenimiento de cada instancia, es posible que tenga muchas instancias que mantener.

Aumento de la escala de SaaS

Al expandir la escala de una solución para realizar implementaciones muy grandes, existen desafíos específicos que surgen en función de los límites de servicio, los problemas geográficos y otros factores. Para obtener más información sobre las arquitecturas de implementación de IoT a gran escala, consulte Escalado horizontal de una solución de Azure IoT para admitir millones de dispositivos.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Creadores de entidad de seguridad:

• Michael C. Bazarewsky | Ingeniero de clientes sénior, FastTrack for Azure
• David Crook | Ingeniero de clientes principal, FastTrack for Azure

Otros colaboradores:

• John Downs | Ingeniero principal de software
• Arsen Vladimirskiy | Ingeniero de clientes principal, FastTrack for Azure

Pasos siguientes

• Revise las instrucciones para multiinquilinos y Azure Cosmos DB.
• Obtenga información sobre las rutas de acceso a datos frecuentes, flexibles y pasivas con IoT en Azure.
• Consulte las arquitecturas de referencia de Azure IoT.