MLOps with Microservices: A Case Study on the Maritime Domain

TL;DR

This work investigates Ocean Guard, an ML-enabled system for maritime anomaly detection developed as a microservices-based platform. It applies contract-based design across code, data, and models to enable parallel development by four specialized teams, guided by a hexagonal API and Domain-Driven Design. The study demonstrates how contract-based development and ubiquitous language mitigate coupling, alignment, and communication challenges in ML-driven, regulated, and data-intensive domains. The practical impact lies in providing a blueprint for scalable, explainable, and compliant MLOps in complex operational environments like maritime logistics.

Abstract

This case study describes challenges and lessons learned on building Ocean Guard: a Machine Learning-Enabled System (MLES) for anomaly detection in the maritime domain. First, the paper presents the system's specification, and architecture. Ocean Guard was designed with a microservices' architecture to enable multiple teams to work on the project in parallel. Then, the paper discusses how the developers adapted contract-based design to MLOps for achieving that goal. As a MLES, Ocean Guard employs code, model, and data contracts to establish guidelines between its services. This case study hopes to inspire software engineers, machine learning engineers, and data scientists to leverage similar approaches for their systems.

Figures (2)

• Figure 1: System Architecture of the Ocean Guard tool This architecture follows the same notation introduced by Ferreira et al.Ferreira2025ASystems. Rectangles represent either applications or services, which execute continuously. Stacked rectangles represent pipelines, which execute a task on demand. Lastly, cylinders represent data storage, which may be databases of any type. Components are connected by arrows. Black arrows with a hollow tip illustrate the execution flow. They start and end in a component. Labeled arrows represent the trigger that starts a workflow, whereas unlabeled arrows represent the continuation of an existing workflow. Colored arrows with a filled tip illustrate the data flow. They appear in two types: solid arrows going to and from a data storage represent write and read operations, respectively; dotted arrows represent a sync or async request-response communication between components. Components are colored according to the data they produce: raw data, source code, executable artifacts, ML-specific data, ML models, ML training metadata, and ML model predictions. The remaining standalone componentsorchestrate the execution of others. Components are also grouped into subsystems, with their background colored according to the teams responsible for their development. Numbers, roman numeralsand lettersare used as labels throughout \ref{['sec:system_architecture']}.
• Figure 2: Component Architecture of the Ocean Guard API. It follows the hexagonal architecture Martin:CleanArchitecture:2017. The purple hexagonrepresents the Business Logic, where Domain-Driven Design patterns such as Entities, Value Objects, Aggregates, and ServicesEvans:DomainDrivenDesign:2003 are implemented. The blue hexagonrepresents the Dependencies, where the Ports and Adapters pattern is implemented as an Anti-Corruption Layer against external dependencies Martin:CleanArchitecture:2017. Rectangles illustrate the external dependencies themselves, with a green rectanglerepresenting a Driving Dependency -- which initiates actions in the API -- while an orange rectanglerepresenting a Driven Dependency -- whose actions are initiated by the API. Lastly, yellow circlesrepresent the Ports and red circlesrepresent the Adapters, one per dependency. Solid arrows, going from a port to an adapter represent the inside-out dependency flow, going from the Core to the Ports then to the Adapters.