ClubEnsayos.com - Ensayos de Calidad, Tareas y Monografias
Buscar

DevOps Contract for Assuring Execution of IoT Microservice


Enviado por   •  27 de Noviembre de 2022  •  Resúmenes  •  7.448 Palabras (30 Páginas)  •  93 Visitas

Página 1 de 30

RESUMEN

La creciente disponibilidad de la infraestructura de borde e IoT como servicio nos permite desarrollar componentes ligeros de IoT e implementarlos en infraestructuras de borde / IoT, lo que permite análisis y controles de borde. Este documento presenta el desarrollo de contratos de servicio para microservicios de IoT desde las perspectivas de DevOps.  Analizamos a las partes interesadas y presentamos nuestros métodos para apoyar a las partes interesadas a programar contratos de servicios de IoT. Abordamos la diversidad de contratos de servicios mediante el uso de lenguajes comunes para datos y programación de IoT. Integramos el ciclo de vida de desarrollo y operación de los contratos de IoT con componentes de software de IoT y con servicios de Soporte de DevOps. Para ilustrar nuestro enfoque, utilizamos una aplicación de mantenimiento de la estación de transceptor base del mundo real con Raspberry Pi, Java, JavaScript, JSON y otros microservicios.

  1. Introducción

 El auge del dispositivo IoT como servicio , la infraestructura de IoT como servicio y la infraestructura de borde como servicio [1] ha creado varios desafíos para el desarrollo de software. Hemos observado dos flujos de desarrollo principales en las ofertas de servicios de IoT: (i) las infraestructuras de IoT proporcionan datos y servicios que uno puede consumir a través de la suscripción de los datos y servicios o (ii) uno puede implementar sus propios componentes de software, como un microservicio o una función sin servidor, en infraestructuras de IoT para realizar ciertas funciones para sus servicios. Independientemente de qué modelos, el contrato / acuerdo entre el consumidor y el proveedor de infraestructura ioT / edge es crucial. Sin embargo, si bien los contratos han sido razonablemente respaldados para el caso en que el consumidor accede a datos y servicios a través de API remotas (REST/MQTT), el soporte contractual para el segundo caso para permitir que el cliente implemente y ejecute sus servicios no ha sido bien investigado. El primer caso es popular en parte porque podemos utilizar muchos modelos de contratos y control de acceso existentes, como contratos de datos como servicio, contratos de servicios web, controles de suscripción de datos y monitoreo de acceso remoto [2–4]. En el segundo caso, es bastante complicado porque, al igual que la infraestructura en la nube en la que uno puede comprar máquinas virtuales / contenedores y ejecutar sus microservicios, el consumidor puede ejecutar su código en puertas de enlace de IoT y servidores de borde en las infraestructuras de IoT / borde. El consumidor también puede utilizar componentes virtualizados como Docker para ejecutar su código [5,6]. El enfoque actual en la computación perimetral y la computación en la niebla ha introducido varios marcos para la implementación y ejecución de componentes en infraestructuras de borde / IoT bajo demanda, como [5,7–9]. Sin embargo, se ha dedicado poco esfuerzo a examinar los contratos de servicio a lo largo de las fases existentes del desarrollo de software de IoT en el contexto de IoT-as-a-service, donde IoT e infraestructuras de borde se pueden proporcionar bajo principios de pago por uso bajo demanda. Creemos que, dado el creciente desarrollo y ejecución de componentes de software en las infraestructuras IoT /edge, necesitamos dedicar más esfuerzo a mejorar el contrato de servicio en el desarrollo de software IoT.

 Pocos trabajos han comenzado a abordar los problemas mencionados anteriormente, pero bastante prematuros. Los enfoques tradicionales, como el uso de lenguajes de políticas predefinidos, son demasiado estáticos, ya que los términos del contrato y las especificaciones de restricción se definen solo en el momento en que implementamos el código. Otros modelos como el control de acceso de IoT también utilizan políticas bastante estáticas [10]. Además, las sintaxis de políticas están predefinidas para permitir solo la creación de instancias de variables / métricas, por lo que es difícil hacer frente a la diversidad de dispositivos y tareas de IoT. En nuestro trabajo, consideramos el caso en el que uno desarrollará un servicio de software de IoT, llamado IoT (micro)servicios, a partir de varios componentes, llamados unidades de IoT, e implementará dichos servicios en la infraestructura como servicio de IoT. La pregunta clave es cómo apoyar el desarrollo de contratos, y las pruebas y el despliegue de los mismos lo antes posible, como en los fenómenos DevOps y Security DevOps y en Site Reliability Engineering [11]. Los desafíos para los contratos en IoT se deben a las diversas API subyacentes para datos y control que deben integrarse bien con el desarrollo y la operación de unidades / servicios de IoT. Si bien podemos aprovechar estructuras y categorías de contratos bastante comunes del trabajo relacionado, no es suficiente comenzar la integración y el desarrollo del contrato solo cuando se implementan componentes de IoT en la infraestructura. En este documento examinamos la siguiente pregunta clave: si un desarrollador sigue DevOps para unidades / microservicios de IoT, ¿cuáles serían los pasos / métodos para hacer contratos de servicios w.r.t para dicho software de IoT?

En este trabajo, llamamos a nuestro enfoque DevOps Contract for IoT microservises. Nos centramos en la gestión de la ejecución y los aspectos de seguimiento en los contratos de servicios (por ejemplo, no nos centramos en la penalización o la compensación). Presentamos un conjunto de microservicios, plantillas y técnicas para construir contratos de IoT a partir de modelos de contrato y asignarlos a unidades de IoT. Presentamos bloques de construcción para la creación de contratos, así como para la aplicación utilizando lenguajes comunes para datos y programación, como JSON y Javascript. Nuestros servicios de tiempo de ejecución para DevOps Contract incluyen funciones de registro, implementación, aplicación y monitoreo. También integramos nuestro trabajo con tecnologías blockchain para respaldar activos verificables y registros de violación en contratos de IoT. Para ilustrar nuestro trabajo, utilizaremos el caso del mantenimiento de la infraestructura utilizando software IoT para estaciones transceptores base. El resto de este documento es el siguiente. En la sección 2 se presenta la motivación y el enfoque. Presentamos nuestro enfoque de contrato de DevOps en la Sección 3. Presentamos los componentes básicos de los contratos en la Sección 4 y para la aplicación en la Sección 5. La Sección 6 presenta nuestro prototipo y evaluación de tiempo de ejecución. El trabajo relacionado se discute en la Sección 7. Concluimos el documento y esbozamos la labor futura en la Sección 8.

  1. Motivación y enfoque

 Similar a DevOps en la nube, un proceso típico de DevOps para componentes en infraestructura como servicio de borde / IoT generalmente incluye muchas tareas: escribir, probar e implementar componentes [12] y estas tareas se pueden llevar a cabo a través de herramientas de CI / CD. Sin embargo, debido a la complejidad de las infraestructuras y dispositivos de IoT subyacentes, IoT requiere muchas colaboraciones entre varias partes interesadas para ofrecer el software adecuado [13]. En un entorno de desarrollo típico, el código de los componentes de IoT se desarrolla y gestiona en la nube, siendo probado y empujado al IoT/edge. En tiempo de ejecución, para aplicar los principios clave de la ingeniería de confiabilidad del sitio [11] y los acuerdos de nivel de servicio (SLA) [14] a los componentes de IoT que se ejecutan en infraestructuras de IoT, tanto las infraestructuras como los proveedores de IoT deben admitir y garantizar varios indicadores de nivel de servicio (SLA) y objetivos de nivel de servicio (SLO) para sus SLA de alto nivel. Dichos SLA y SLO son los elementos clave de nuestros contratos de servicio para IoT. Un gran desafío relevante para el contrato de servicio se debe a la diversidad de la infraestructura subyacente de borde / IoT. Por ejemplo, escribir un componente que acceda al estado de un generador de energía puede requerir diferentes conjuntos de API para diferentes generadores de energía e infraestructuras de IoT. Además, en IoT accedemos a muchos tipos de datos, que requieren contratos de servicio para hacer frente a los derechos de acceso a los datos y las restricciones de calidad de los datos. Los contratos de servicio deben incluir restricciones comunes de control de rendimiento y ejecución en la mayoría de las infraestructuras de IoT.

...

Descargar como (para miembros actualizados)  txt (47.9 Kb)   pdf (975.1 Kb)   docx (889.6 Kb)  
Leer 29 páginas más »
Disponible sólo en Clubensayos.com