MLOps con Microservicios: Un Estudio de Caso en el Dominio Marítimo

Información Básica

• ID del Artículo: 2506.06202
• Título: MLOps with Microservices: A Case Study on the Maritime Domain
• Autores: Renato Cordeiro Ferreira, Rowanne Trapmann, Willem-Jan van den Heuvel
• Instituciones: Jheronimus Academy of Data Science (JADS), Eindhoven University of Technology (TUe), Tilburg University (TiU)
• Clasificación: cs.SE cs.AI cs.LG
• Fecha de Publicación: arXiv:2506.06202v2 cs.SE 11 Aug 2025
• Enlace del Artículo: https://arxiv.org/abs/2506.06202

Resumen

Este estudio de caso describe los desafíos y lecciones aprendidas en la construcción del sistema Ocean Guard: un sistema habilitado por aprendizaje automático (MLES) para detección de anomalías en el dominio marítimo. El artículo presenta primero la especificación y arquitectura del sistema. Ocean Guard adopta un diseño de arquitectura de microservicios, permitiendo que múltiples equipos trabajen en paralelo. Luego se discute cómo los desarrolladores adaptaron el diseño basado en contratos para MLOps con este propósito. Como MLES, Ocean Guard adopta contratos de código, modelo y datos para establecer principios rectores entre servicios.

Contexto de Investigación y Motivación

Antecedentes del Problema

1. Aceleración de la Transformación Digital Marítima: Según la Organización Marítima Internacional (OMI), los buques modernos se han convertido en "centros de datos flotantes", equipados con cientos de sensores que generan grandes volúmenes de datos heterogéneos
2. Entorno Operativo Complejo: El dominio marítimo se caracteriza por movimiento continuo transfronterizo, marcos regulatorios diversos y susceptibilidad a condiciones climáticas
3. Desafíos en el Procesamiento de Datos: Se requieren sistemas capaces de ingerir, procesar y analizar diferentes flujos de datos a gran escala, manteniendo confiabilidad operativa en entornos con conectividad variable y condiciones que cambian rápidamente

Motivación de la Investigación

1. Necesidad de Convergencia Tecnológica: Integrar mejores prácticas de MLOps con arquitectura de microservicios para abordar necesidades de análisis predictivo, detección de anomalías y optimización de rutas en el dominio marítimo
2. Colaboración Multidisciplinaria: Necesidad de soportar desarrollo paralelo de equipos multidisciplinarios incluyendo ingenieros de software, científicos de datos e ingenieros de aprendizaje automático
3. Escalabilidad del Sistema: La arquitectura de microservicios es particularmente adecuada para los requisitos de modularidad, escalabilidad y resiliencia del dominio marítimo

Contribuciones Principales

1. Propuesta de un Enfoque de Diseño Impulsado por Contratos Aplicable a MLES: Extensión del concepto de contratos de código en microservicios a contratos de datos y contratos de modelos
2. Construcción de una Arquitectura Completa de Sistema de Detección de Anomalías Marítimas: Sistema Ocean Guard basado en microservicios que soporta desarrollo paralelo de múltiples equipos
3. Validación de la Aplicación de DDD en MLOps: Creación de lenguaje unificado mediante diseño dirigido por dominio para mejorar comunicación entre equipos multidisciplinarios
4. Provisión de Experiencia Práctica en Desarrollo de MLES: Identificación y resolución de tres desafíos principales: acoplamiento, alineación y comunicación

Explicación Detallada de Métodos

Especificación del Sistema

Requisitos Funcionales

Funcionalidad del Investigador (Investigator):

• I1-I6: Visualización geográfica, filtrado, identificación de tipos de objetos, recuperación de múltiples fuentes de datos, visualización de metadatos, seguimiento de trayectorias
• I7-I9: Resaltado de anomalías, filtrado de anomalías, visualización de explicaciones de anomalías

Funcionalidad del Detector de Anomalías (Anomaly Detector):

• A1-A3: Detección de anomalías, enumeración de anomalías, explicación de anomalías

Requisitos No Funcionales

1. Interpretabilidad: Uso de modelos interpretables o técnicas de explicación de caja negra (SHAP, LIME)
2. Compatibilidad: Cumplimiento de estándares de la UE, soporte para integración rápida con otros sistemas
3. Resiliencia: Manejo de fuentes de datos de alto volumen y alta velocidad
4. Conformidad: Cumplimiento de regulaciones europeas como GDPR y AI Act

Arquitectura del Sistema

Diseño de Cinco Subsistemas

1. Adquisición de Datos (Data Acquisition)
   • Proveedores terceros (1), sensores físicos (2), rastreadores de datos (3)
   • Almacenamiento de etiquetas (A) y almacenamiento de datos sin procesar (B)
2. Entrenamiento Continuo (Continuous Training)
   • Tubería de generación de datos sintéticos (I), tubería de aumento de datos (II)
   • Tubería de entrenamiento basada en reglas (III), tubería de entrenamiento basada en ML (IV)
   • Almacenamiento de metadatos (F) y registro de modelos (G)
3. Servicio (Serving)
   • Tubería de predicción por lotes (VIII) y servicio de predicción API (8)
   • Almacenamiento de predicciones (H)
4. Monitoreo (Monitoring)
   • Aplicación de gobernanza (7) y almacenamiento de telemetría (I)
5. Entrega Continua (Continuous Delivery)
   • Tubería CI (V), tubería CD (VI), tubería CD4ML (VII)
   • Registro de artefactos (D)

Diseño de Arquitectura API

Adopción de Arquitectura Hexagonal (Hexagonal Architecture):

1. Núcleo (Core): Implementación de lógica empresarial siguiendo patrones DDD
   • Entidades (Entities), Objetos de Valor (Value Objects)
   • Agregados (Aggregates), Servicios (Services)
2. Puertos (Ports): Establecimiento de contratos entre núcleo y adaptadores
   • Repositorios de base de datos, inyección de dependencias, mecanismos de seguridad, enrutador web
3. Adaptadores (Adapters): Comunicación con dependencias externas
   • Adaptadores de lectura: modelos, APIs de terceros, almacenamiento, base de datos, configuración
   • Adaptadores de salida: web, caché

Configuración de Equipos y Flujo de Trabajo

Puntos de Innovación Técnica

Desarrollo Impulsado por Contratos (Contract-Based Development)

1. Contratos de Código (Code Contracts)

• Definición: Documentación del comportamiento de interacción síncrona/asíncrona entre dos servicios a través del protocolo HTTP
• Escenarios de Aplicación:
  • Contrato entre rastreador de datos y fuentes de datos externas
  • Contrato entre servicio de predicción API y aplicación web

2. Contratos de Datos (Data Contracts)

• Definición: Documentación del formato esperado en almacenamiento de datos, incluyendo tipos, formato, distribución y protocolos de lectura/escritura
• Escenarios de Aplicación:
  • Contrato entre productor y consumidor de almacenamiento de etiquetas
  • Contrato multipartidista de almacenamiento de datos sin procesar
  • Contrato entre tuberías de datos procesados

3. Contratos de Modelos (Model Contracts)

• Definición: Documentación de entrada/salida esperada del modelo y formato de almacenamiento
• Escenarios de Aplicación: Contrato entre tuberías de entrenamiento y servicio de predicción en registro de modelos

Lenguaje Unificado (Ubiquitous Language)

Creación de vocabulario compartido entre equipos mediante DDD, mejorando:

• Comprensión entre partes interesadas y desarrolladores
• Alineación entre equipos
• Explicación de conceptos de datos y modelos

Configuración Experimental

Entorno de Desarrollo

• Repositorio de Código: Gestión centralizada de código fuente
• Herramientas de Desarrollo: IDE (4) para ingeniería de software estructurada, Notebooks (5) para prototipado interactivo y análisis
• CI/CD: Tubería de integración continua, tubería de entrega continua, tubería de entrega continua para ML

Arquitectura de Implementación

• Containerización: Uso de registro de artefactos para gestionar componentes de software versionados
• Servicio de Programación: Coordinación de ejecución de componentes
• Sistema de Monitoreo: Aplicación de gobernanza que monitorea uso de modelos y sistemas

Desafíos y Soluciones

Tres Desafíos Principales

1. Acoplamiento (Coupling)
   • Problema: La complejidad del sistema causa que modificaciones de componentes tengan impactos en cascada
   • Solución: Reducción de problemas de integración mediante diseño impulsado por contratos
2. Alineación (Alignment)
   • Problema: Desafíos de coordinación en trabajo paralelo de cuatro equipos profesionales
   • Solución: Definición explícita de límites, integración de tuberías CI/CD
3. Comunicación (Communication)
   • Problema: Dificultad en explicar evolución del sistema a partes interesadas con diferentes antecedentes técnicos
   • Solución: Establecimiento de lenguaje unificado mediante DDD

Efectividad de Soluciones

Trabajo Relacionado

Desarrollo del Campo MLOps

• Desde 2022: Múltiples arquitecturas de referencia MLES propuestas
• SE4AI: Campo emergente de adaptación de técnicas de ingeniería de software para creación de sistemas de IA
• Componentización de Sistemas: MLES descrito como conteniendo múltiples componentes distribuibles entre servicios

Arquitectura de Microservicios

• Desde 2015: Surgimiento del estilo de arquitectura de microservicios, abordando desafíos de modularidad, escalabilidad y resiliencia
• Aplicabilidad Marítima: Componentes especializados manejando diferentes fuentes de datos marítimos y necesidades analíticas

Conclusiones y Discusión

Conclusiones Principales

1. Validez de la Arquitectura: La arquitectura de microservicios soportó exitosamente desarrollo paralelo de MLES por equipos multidisciplinarios
2. Extensión de Contratos: El concepto de contratos de código en microservicios se extendió exitosamente a dimensiones de datos y modelos
3. Aplicabilidad de DDD: El diseño dirigido por dominio mejoró efectivamente comunicación y coordinación entre equipos multidisciplinarios
4. Respuesta a Desafíos: El diseño impulsado por contratos y lenguaje unificado resolvieron efectivamente desafíos de acoplamiento, alineación y comunicación

Limitaciones

1. Restricciones de Sensibilidad: Debido a sensibilidad del proyecto, el artículo no aborda modelos de datos específicos y técnicas de detección de anomalías
2. Restricciones Académicas: Equipos de investigación e innovación compuestos por estudiantes, sujetos a plazos académicos
3. Fase de Implementación: El sistema aún está en desarrollo, careciendo de validación a largo plazo en entorno de producción

Direcciones Futuras

1. Perfeccionamiento Funcional: Desarrollo continuo para satisfacer todos los requisitos funcionales y no funcionales
2. Exploración Tecnológica: Exploración continua de tecnología de vanguardia y práctica con equipos de investigación e innovación
3. Evolución de Arquitectura: Evolución de procesos de desarrollo guiada por métodos de contratos establecidos y lenguaje unificado

Evaluación Profunda

Fortalezas

1. Alto Valor Práctico: Proporciona estudio de caso completo de combinación de MLOps con microservicios
2. Innovación Metodológica: La extensión de diseño impulsado por contratos a dimensiones de datos y modelos es original
3. Arquitectura Completa: Diseño de arquitectura de sistema integral, cubriendo todos los aspectos de MLES
4. Colaboración de Equipos: Resolución exitosa de desafíos de desarrollo paralelo multidisciplinario
5. Orientación Práctica: Proporciona experiencia y lecciones aplicables a proyectos similares

Insuficiencias

1. Profundidad Técnica Limitada: Restricciones de sensibilidad resultan en falta de detalles específicos de algoritmos ML y procesamiento de datos
2. Evaluación Insuficiente: Falta de evaluación cuantitativa de rendimiento del sistema, escalabilidad, etc.
3. Ausencia de Validación a Largo Plazo: Sistema aún no ha operado a largo plazo en entorno de producción
4. Análisis Comparativo Insuficiente: Falta de análisis comparativo con otras soluciones de arquitectura MLES

Impacto

1. Contribución Disciplinaria: Proporciona referencia práctica importante para combinación de MLOps y microservicios
2. Valor Metodológico: La extensión de diseño impulsado por contratos tiene amplia aplicabilidad
3. Práctica de Ingeniería: Proporciona modelo efectivo para colaboración de equipos en MLES complejos
4. Reproducibilidad: Diseño de arquitectura y metodología poseen buena reproducibilidad

Escenarios Aplicables

1. Desarrollo MLES Multidisciplinario: Sistemas de aprendizaje automático requiriendo desarrollo paralelo de múltiples equipos profesionales
2. Procesamiento de Datos Complejo: Diseño de arquitectura de sistemas involucrando múltiples fuentes de datos heterogéneos
3. Requisitos de Conformidad Elevada: Aplicaciones de industria requiriendo cumplimiento de requisitos regulatorios estrictos
4. Sistemas Altamente Escalables: Arquitectura de sistemas ML requiriendo alto grado de modularidad y escalabilidad

Referencias

El artículo cita 17 referencias importantes, cubriendo:

• Investigación relacionada con transformación digital marítima
• Mejores prácticas de arquitectura de microservicios y MLOps
• Metodología de ingeniería de software (DDD, arquitectura hexagonal)
• Ingeniería de sistemas de aprendizaje automático (SE4AI)

Resumen: A través del estudio de caso Ocean Guard, este artículo demuestra exitosamente la aplicación de arquitectura de microservicios en MLOps, particularmente el valor del diseño impulsado por contratos en colaboración multidisciplinaria. Aunque las restricciones de sensibilidad impiden profundizar en detalles técnicos, sus contribuciones metodológicas y valor de orientación práctica son significativos, proporcionando experiencia valiosa en diseño de arquitectura y colaboración de equipos para proyectos MLES complejos similares.