MLOps con Microservizi: Uno Studio di Caso nel Dominio Marittimo

Informazioni Fondamentali

• ID Articolo: 2506.06202
• Titolo: MLOps with Microservices: A Case Study on the Maritime Domain
• Autori: Renato Cordeiro Ferreira, Rowanne Trapmann, Willem-Jan van den Heuvel
• Istituzioni: Jheronimus Academy of Data Science (JADS), Eindhoven University of Technology (TUe), Tilburg University (TiU)
• Classificazione: cs.SE cs.AI cs.LG
• Data di Pubblicazione: arXiv:2506.06202v2 cs.SE 11 Agosto 2025
• Link Articolo: https://arxiv.org/abs/2506.06202

Sintesi

Questo studio di caso descrive le sfide e gli insegnamenti derivati dalla costruzione del sistema Ocean Guard: un sistema abilitato al machine learning (MLES) per il rilevamento di anomalie nel dominio marittimo. L'articolo introduce innanzitutto le specifiche e l'architettura del sistema. Ocean Guard adotta un'architettura a microservizi che consente a più team di lavorare in parallelo. Successivamente, discute come gli sviluppatori hanno adattato la progettazione basata su contratti a MLOps per raggiungere questo obiettivo. Come MLES, Ocean Guard impiega contratti di codice, modello e dati per stabilire principi guida tra i servizi.

Contesto di Ricerca e Motivazione

Contesto del Problema

1. Accelerazione della trasformazione digitale marittima: Secondo l'Organizzazione Marittima Internazionale (IMO), le navi moderne sono diventate "centri dati galleggianti", equipaggiate con centinaia di sensori che generano grandi volumi di dati eterogenei
2. Ambiente operativo complesso: Il dominio marittimo è caratterizzato da movimento continuo transnazionale, quadri normativi diversificati e vulnerabilità alle condizioni meteorologiche
3. Sfide nell'elaborazione dei dati: Necessità di sistemi in grado di acquisire, elaborare e analizzare su larga scala diversi flussi di dati, mantenendo al contempo l'affidabilità operativa in ambienti con connettività variabile e condizioni in rapido cambiamento

Motivazione della Ricerca

1. Necessità di integrazione tecnologica: Combinare le migliori pratiche MLOps con l'architettura a microservizi per affrontare le esigenze di analisi predittiva, rilevamento di anomalie e ottimizzazione dei percorsi nel dominio marittimo
2. Collaborazione multidisciplinare: Supportare lo sviluppo parallelo di team multidisciplinari composti da ingegneri software, data scientist e ingegneri di machine learning
3. Scalabilità del sistema: L'architettura a microservizi è particolarmente adatta ai requisiti di modularità, scalabilità e resilienza del dominio marittimo

Contributi Principali

1. Propone un approccio di progettazione guidato da contratti applicabile a MLES: Estende il concetto di contratti di codice nei microservizi ai contratti di dati e modelli
2. Costruisce un'architettura completa di sistema per il rilevamento di anomalie marittimo: Sistema Ocean Guard basato su microservizi che supporta lo sviluppo parallelo di più team
3. Verifica l'applicazione del DDD in MLOps: Crea un linguaggio ubiquo attraverso il Domain-Driven Design, migliorando la comunicazione tra team multidisciplinari
4. Fornisce esperienza pratica nello sviluppo di MLES: Identifica e risolve tre sfide principali: accoppiamento, allineamento e comunicazione

Dettagli Metodologici

Specifiche del Sistema

Requisiti Funzionali

Funzionalità dell'Investigatore (Investigator):

• I1-I6: Visualizzazione geografica, filtri, identificazione tipo oggetto, recupero da più fonti dati, visualizzazione metadati, tracciamento traiettorie
• I7-I9: Evidenziazione anomalie, filtri anomalie, visualizzazione spiegazioni anomalie

Funzionalità del Rilevatore di Anomalie (Anomaly Detector):

• A1-A3: Rilevamento anomalie, enumerazione anomalie, spiegazione anomalie

Requisiti Non Funzionali

1. Interpretabilità: Utilizzo di modelli interpretabili o tecniche di spiegazione black-box (SHAP, LIME)
2. Compatibilità: Conformità agli standard UE, supporto per integrazione rapida con altri sistemi
3. Resilienza: Gestione di fonti dati ad alta capacità e velocità
4. Conformità: Aderenza al GDPR e all'AI Act europeo

Architettura del Sistema

Progettazione dei Cinque Sottosistemi

1. Acquisizione Dati (Data Acquisition)
   • Fornitori terzi (1), sensori fisici (2), web scraper (3)
   • Archivio etichette (A) e archivio dati grezzi (B)
2. Addestramento Continuo (Continuous Training)
   • Pipeline di generazione dati sintetici (I), pipeline di aumento dati (II)
   • Pipeline di addestramento basato su regole (III), pipeline di addestramento basato su ML (IV)
   • Archivio metadati (F) e registro modelli (G)
3. Servizio (Serving)
   • Pipeline di previsione batch (VIII) e servizio API di previsione (8)
   • Archivio previsioni (H)
4. Monitoraggio (Monitoring)
   • Applicazione di governance (7) e archivio telemetria (I)
5. Consegna Continua (Continuous Delivery)
   • Pipeline CI (V), pipeline CD (VI), pipeline CD4ML (VII)
   • Registro artefatti (D)

Progettazione dell'Architettura API

Adotta Architettura Esagonale (Hexagonal Architecture):

1. Nucleo (Core): Implementa la logica di business, seguendo il pattern DDD
   • Entità (Entities), Oggetti Valore (Value Objects)
   • Aggregati (Aggregates), Servizi (Services)
2. Porte (Ports): Stabilisce contratti tra il nucleo e gli adattatori
   • Repository database, iniezione dipendenze, meccanismi di sicurezza, router web
3. Adattatori (Adapters): Comunica con dipendenze esterne
   • Adattatori di lettura: modelli, API terze parti, archivi, database, configurazione
   • Adattatori di output: web, cache

Configurazione Team e Flussi di Lavoro

Innovazioni Tecniche

Sviluppo Guidato da Contratti (Contract-Based Development)

1. Contratti di Codice (Code Contracts)

• Definizione: Documentazione del comportamento di interazione sincrona/asincrona tra due servizi tramite protocollo HTTP
• Scenari di applicazione:
  • Contratti tra web scraper e fonti dati esterne
  • Contratti tra servizio API di previsione e applicazione web

2. Contratti di Dati (Data Contracts)

• Definizione: Documentazione del formato atteso nei depositi dati, inclusi tipo, formato, distribuzione e protocolli di lettura/scrittura
• Scenari di applicazione:
  • Contratti tra produttore e consumatore dell'archivio etichette
  • Contratti multipartiti dell'archivio dati grezzi
  • Contratti tra pipeline di dati elaborati

3. Contratti di Modello (Model Contracts)

• Definizione: Documentazione degli input/output attesi del modello e formato di archiviazione
• Scenari di applicazione: Contratti tra pipeline di addestramento e servizio di previsione nel registro modelli

Linguaggio Ubiquo (Ubiquitous Language)

Crea vocabolario condiviso tra team attraverso DDD, migliorando:

• Comprensione tra stakeholder e sviluppatori
• Allineamento tra team
• Spiegazione di concetti di dati e modelli

Configurazione Sperimentale

Ambiente di Sviluppo

• Repository di codice: Gestione centralizzata del codice sorgente
• Strumenti di sviluppo: IDE (4) per ingegneria software strutturata, Notebook (5) per prototipazione interattiva e analisi
• CI/CD: Pipeline di integrazione continua, pipeline di consegna continua, pipeline di consegna continua ML

Architettura di Distribuzione

• Containerizzazione: Utilizzo di registro artefatti per gestire componenti software versionati
• Servizio di pianificazione: Coordina l'esecuzione di vari componenti
• Sistema di monitoraggio: Applicazione di governance monitora modelli e utilizzo del sistema

Sfide e Soluzioni

Tre Sfide Principali

1. Accoppiamento (Coupling)
   • Problema: La complessità del sistema causa effetti a cascata dalle modifiche ai componenti
   • Soluzione: Ridurre i problemi di integrazione attraverso progettazione guidata da contratti
2. Allineamento (Alignment)
   • Problema: Sfide di coordinamento con quattro team professionali che lavorano in parallelo
   • Soluzione: Definizione chiara dei confini, integrazione pipeline CI/CD
3. Comunicazione (Communication)
   • Problema: Difficoltà nel spiegare l'evoluzione del sistema a stakeholder con background tecnico diverso
   • Soluzione: Stabilire linguaggio ubiquo attraverso DDD

Efficacia delle Soluzioni

Lavori Correlati

Sviluppo del Campo MLOps

• Dal 2022: Molteplici architetture di riferimento MLES proposte
• SE4AI: Campo emergente di adattamento delle tecniche di ingegneria software per la creazione di sistemi AI
• Componentizzazione del sistema: MLES descritto come contenente molteplici componenti distribuibili tra servizi

Architettura a Microservizi

• Dal 2015: Emergere dello stile architetturale a microservizi, affrontando sfide di modularità, scalabilità e resilienza
• Applicabilità marittima: Componenti specializzati gestiscono diverse fonti dati marittimi e esigenze analitiche

Conclusioni e Discussione

Conclusioni Principali

1. Validità dell'architettura: L'architettura a microservizi supporta con successo lo sviluppo parallelo di MLES da parte di team multidisciplinari
2. Estensione dei contratti: Il concetto di contratti di codice nei microservizi è stato esteso con successo alle dimensioni di dati e modelli
3. Applicabilità del DDD: Il Domain-Driven Design migliora efficacemente la comunicazione e il coordinamento tra team multidisciplinari
4. Affrontamento delle sfide: La progettazione guidata da contratti e il linguaggio ubiquo risolvono efficacemente le sfide di accoppiamento, allineamento e comunicazione

Limitazioni

1. Restrizioni di sensibilità: A causa della sensibilità del progetto, l'articolo non affronta modelli dati specifici e tecniche di rilevamento anomalie
2. Vincoli accademici: Team di ricerca e innovazione composti da studenti, soggetti a scadenze accademiche
3. Fase di implementazione: Il sistema è ancora in sviluppo, mancano validazioni a lungo termine in ambiente di produzione

Direzioni Future

1. Completamento funzionale: Continuare lo sviluppo per soddisfare tutti i requisiti funzionali e non funzionali
2. Esplorazione tecnologica: Continuare l'esplorazione di tecnologie all'avanguardia e pratiche con team di ricerca e innovazione
3. Evoluzione architetturale: Guidare il processo di sviluppo basato sui metodi di contratto stabiliti e sul linguaggio ubiquo

Valutazione Approfondita

Punti di Forza

1. Alto valore pratico: Fornisce uno studio di caso completo sulla combinazione di MLOps e microservizi
2. Innovazione metodologica: L'estensione della progettazione guidata da contratti alle dimensioni di dati e modelli è originale
3. Architettura completa: La progettazione dell'architettura del sistema è comprensiva, coprendo tutti gli aspetti di MLES
4. Collaborazione tra team: Risolve con successo le sfide dello sviluppo parallelo di team multidisciplinari
5. Guida pratica: Fornisce esperienza e insegnamenti applicabili a progetti simili

Limitazioni

1. Profondità tecnica limitata: A causa delle restrizioni di sensibilità, mancano dettagli specifici su algoritmi ML e elaborazione dati
2. Valutazione insufficiente: Mancano valutazioni quantitative di prestazioni del sistema e scalabilità
3. Assenza di validazione a lungo termine: Il sistema non ha ancora funzionato a lungo termine in ambiente di produzione
4. Analisi comparativa insufficiente: Manca il confronto con altre soluzioni di architettura MLES

Impatto

1. Contributo al dominio: Fornisce importante riferimento pratico per la combinazione di MLOps e microservizi
2. Valore metodologico: L'estensione della progettazione guidata da contratti ha ampia applicabilità
3. Pratica ingegneristica: Fornisce modelli efficaci per la collaborazione tra team in MLES complessi
4. Riproducibilità: La progettazione dell'architettura e la metodologia hanno buona riproducibilità

Scenari Applicabili

1. Sviluppo MLES multiteam: Sistemi di machine learning che richiedono lo sviluppo parallelo di team multidisciplinari
2. Elaborazione dati complessa: Architettura di sistema che coinvolge dati eterogenei da molteplici fonti
3. Requisiti di conformità elevati: Applicazioni industriali che devono soddisfare requisiti normativi rigorosi
4. Sistemi scalabili: Architetture ML altamente modularizzate e scalabili

Bibliografia

L'articolo cita 17 riferimenti importanti, coprendo:

• Ricerca sulla trasformazione digitale marittima
• Migliori pratiche di architettura a microservizi e MLOps
• Metodologie di ingegneria software (DDD, architettura esagonale)
• Ingegneria dei sistemi di machine learning (SE4AI)

Riepilogo: Attraverso lo studio di caso Ocean Guard, questo articolo dimostra con successo l'applicazione dell'architettura a microservizi in MLOps, in particolare il valore della progettazione guidata da contratti nella collaborazione tra team. Sebbene limitato da restrizioni di sensibilità nel non approfondire i dettagli tecnici, il suo contributo metodologico e il valore della guida pratica sono significativi, fornendo preziosa esperienza di progettazione architettonica e collaborazione tra team per progetti MLES complessi simili.