MLOps with Microservices: A Case Study on the Maritime Domain

Basic Information

• Paper ID: 2506.06202
• Title: MLOps with Microservices: A Case Study on the Maritime Domain
• Authors: Renato Cordeiro Ferreira, Rowanne Trapmann, Willem-Jan van den Heuvel
• Institutions: Jheronimus Academy of Data Science (JADS), Eindhoven University of Technology (TUe), Tilburg University (TiU)
• Classification: cs.SE cs.AI cs.LG
• Publication Date: arXiv:2506.06202v2 cs.SE 11 Aug 2025
• Paper Link: https://arxiv.org/abs/2506.06202

Abstract

This case study describes the challenges and lessons learned in building Ocean Guard, a machine learning-enabled system (MLES) for anomaly detection in the maritime domain. The paper first introduces the system specifications and architecture. Ocean Guard adopts a microservices architecture design that enables multiple teams to work in parallel. It then discusses how developers adapted contract-based design for MLOps to achieve this goal. As an MLES, Ocean Guard employs code, data, and model contracts to establish guiding principles for inter-service communication.

Research Background and Motivation

Problem Context

1. Accelerated Maritime Digital Transformation: According to the International Maritime Organization (IMO), modern vessels have become "floating data centers" equipped with hundreds of sensors that generate vast amounts of heterogeneous data
2. Complex Operational Environment: The maritime domain is characterized by continuous cross-border movement, diverse regulatory frameworks, and susceptibility to weather impacts
3. Data Processing Challenges: Systems must be capable of ingesting, processing, and analyzing different data streams at scale while maintaining operational reliability in environments with rapidly changing connectivity and conditions

Research Motivation

1. Technology Integration Requirements: Combining MLOps best practices with microservices architecture to address maritime domain needs for predictive analytics, anomaly detection, and route optimization
2. Multi-Team Collaboration: Supporting parallel development by multidisciplinary teams including software engineers, data scientists, and machine learning engineers
3. System Scalability: Microservices architecture is particularly suited to the maritime domain's requirements for modularity, scalability, and resilience

Core Contributions

1. Proposed a contract-driven design approach applicable to MLES: Extended the concept of code contracts from microservices to data contracts and model contracts
2. Constructed a complete maritime anomaly detection system architecture: The Ocean Guard system based on microservices supports parallel development by multiple teams
3. Validated the application of DDD in MLOps: Created a ubiquitous language through domain-driven design to improve communication across multidisciplinary teams
4. Provided practical experience in MLES development: Identified and addressed three major challenges: coupling, alignment, and communication

Methodology Details

System Specifications

Functional Requirements

Investigator Functionality:

• I1-I6: Geographic display, filtering, object type identification, multi-source data retrieval, metadata viewing, trajectory tracking
• I7-I9: Anomaly highlighting, anomaly filtering, anomaly explanation viewing

Anomaly Detector Functionality:

• A1-A3: Anomaly detection, anomaly enumeration, anomaly explanation

Non-Functional Requirements

1. Interpretability: Using interpretable models or black-box explanation techniques (SHAP, LIME)
2. Compatibility: Adhering to EU standards and supporting rapid integration with other systems
3. Resilience: Handling high-capacity, high-velocity data sources
4. Compliance: Conforming to European regulations such as GDPR and the AI Act

System Architecture

Five Subsystem Design

1. Data Acquisition
   • Third-party providers (1), physical sensors (2), data crawlers (3)
   • Label storage (A) and raw data storage (B)
2. Continuous Training
   • Synthetic data generation pipeline (I), data augmentation pipeline (II)
   • Rule-based training pipeline (III), ML-based training pipeline (IV)
   • Metadata storage (F) and model registry (G)
3. Serving
   • Batch prediction pipeline (VIII) and API prediction service (8)
   • Prediction storage (H)
4. Monitoring
   • Governance application (7) and telemetry storage (I)
5. Continuous Delivery
   • CI pipeline (V), CD pipeline (VI), CD4ML pipeline (VII)
   • Artifact registry (D)

API Architecture Design

Employing Hexagonal Architecture:

1. Core: Implements business logic following DDD patterns
   • Entities, Value Objects
   • Aggregates, Services
2. Ports: Establish contracts between core and adapters
   • Database repositories, dependency injection, security mechanisms, web routers
3. Adapters: Communicate with external dependencies
   • Input adapters: Models, third-party APIs, storage, databases, configuration
   • Output adapters: Web, caching

Team Configuration and Workflow

Technical Innovation Points

Contract-Based Development

1. Code Contracts

• Definition: Documenting synchronous/asynchronous interaction behavior between two services via HTTP protocol
• Application Scenarios:
  • Contracts between data crawlers and external data sources
  • Contracts between API prediction services and web applications

2. Data Contracts

• Definition: Documenting expected data format in storage, including type, format, distribution, and read/write protocols
• Application Scenarios:
  • Contracts between producers and consumers of label storage
  • Multi-party contracts for raw data storage
  • Contracts between pipelines processing data

3. Model Contracts

• Definition: Documenting expected model input/output and storage format
• Application Scenarios: Contracts between training pipelines and prediction services in the model registry

Ubiquitous Language

Creating shared vocabulary across teams through DDD, improving:

• Understanding between stakeholders and developers
• Alignment between teams
• Interpretation of data and model concepts

Experimental Setup

Development Environment

• Code Repository: Centralized source code management
• Development Tools: IDEs (4) for structured software engineering, Notebooks (5) for interactive prototyping and analysis
• CI/CD: Continuous integration pipeline, continuous delivery pipeline, ML continuous delivery pipeline

Deployment Architecture

• Containerization: Using artifact registries to manage versioned software components
• Scheduling Service: Coordinating execution of various components
• Monitoring System: Governance application monitoring model and system usage

Challenges and Solutions

Three Major Challenges

1. Coupling
   • Problem: System complexity causes component modifications to have cascading effects
   • Solution: Reducing integration issues through contract-driven design
2. Alignment
   • Problem: Coordination challenges from four professional teams working in parallel
   • Solution: Clear boundary definition and CI/CD pipeline integration
3. Communication
   • Problem: Explaining system evolution to stakeholders with different technical backgrounds
   • Solution: Establishing ubiquitous language through DDD

Solution Effectiveness

Related Work

MLOps Field Development

• Since 2022: Multiple MLES reference architectures have been proposed
• SE4AI: Emerging field of software engineering techniques adapted for AI system creation
• System Componentization: MLES described as containing multiple components distributable across services

Microservices Architecture

• Since 2015: Rise of microservices architectural style addressing modularity, scalability, and resilience challenges
• Maritime Applicability: Specialized components handling different maritime data sources and analytical needs

Conclusions and Discussion

Main Conclusions

1. Architecture Effectiveness: Microservices architecture successfully supported parallel MLES development by multidisciplinary teams
2. Contract Extension: Successfully extended the concept of code contracts from microservices to data and model dimensions
3. DDD Applicability: Domain-driven design effectively improved communication and coordination across multidisciplinary teams
4. Challenge Resolution: Contract-driven design and ubiquitous language effectively addressed coupling, alignment, and communication challenges

Limitations

1. Sensitivity Constraints: Due to project sensitivity, the paper does not address specific data models and anomaly detection techniques
2. Academic Constraints: Research and innovation teams composed of students face academic deadline limitations
3. Implementation Stage: The system is still under development, lacking long-term validation in production environments

Future Directions

1. Feature Completion: Continue development to meet all functional and non-functional requirements
2. Technology Exploration: Continue exploring frontier and practical technologies with research and innovation teams
3. Architecture Evolution: Guide development process based on established contract methods and ubiquitous language

In-Depth Evaluation

Strengths

1. High Practical Value: Provides a comprehensive case study of combining MLOps with microservices
2. Methodological Innovation: Extending contract-driven design to data and model dimensions is original
3. Complete Architecture: System architecture design is comprehensive, covering all aspects of MLES
4. Team Collaboration: Successfully addresses challenges of parallel development by multidisciplinary teams
5. Practical Guidance: Provides valuable experience and lessons for similar projects

Weaknesses

1. Limited Technical Depth: Lacks specific ML algorithms and data processing details due to sensitivity constraints
2. Insufficient Evaluation: Lacks quantitative assessment of system performance and scalability
3. Missing Long-Term Validation: System has not undergone long-term production environment validation
4. Insufficient Comparative Analysis: Lacks comparative analysis with other MLES architecture approaches

Impact

1. Domain Contribution: Provides important practical reference for combining MLOps and microservices
2. Methodological Value: Extension of contract-driven design has broad applicability
3. Engineering Practice: Provides effective patterns for team collaboration in complex MLES
4. Reproducibility: Architecture design and methodology have good reproducibility

Applicable Scenarios

1. Multi-Team MLES Development: Machine learning systems requiring parallel development by multiple professional teams
2. Complex Data Processing: System architecture design involving multi-source heterogeneous data
3. High Compliance Requirements: Industry applications requiring strict regulatory compliance
4. Scalable Systems: ML system architectures requiring high modularity and scalability

References

The paper cites 17 important references covering:

• Maritime digital transformation research
• Microservices architecture and MLOps best practices
• Software engineering methodologies (DDD, hexagonal architecture)
• Machine learning systems engineering (SE4AI)

Summary: Through the Ocean Guard case study, this paper successfully demonstrates the application of microservices architecture in MLOps, particularly the value of contract-driven design in multi-team collaboration. Although technical details are limited by sensitivity constraints, its methodological contributions and practical guidance are significant, providing valuable architectural design and team collaboration experience for similar complex MLES projects.