Platform · Micro Services
Isolated. Observable. Code-generated.
Every MOS4 micro service declares a versioned typed contract generated at build time — ready to consume over GraphQL mesh, web services, or push API from the cloud. The registry enforces isolation and startup ordering; observability ships with zero per-service configuration.
Integrate from the cloud
Three surfaces. One consistent API layer.
The Munic store exposes every connected device through a unified cloud API. Pick the surface that fits your stack — all three share the same underlying typed service contracts from the device.
GraphQL mesh
Query and subscribe to device-side micro service state through a unified GraphQL schema. Traverse relationships across fleet and device in a single request.
Web services
REST-style endpoints surface every registered micro service operation — no SDK, no device-side code required. Integrate from any backend language or cloud function.
Push API
Receive real-time event streams from any device-side micro service. Subscribe once; data flows as services emit it — no polling loop required.
Full integration guide and API reference: store.munic.io — Get Started.
Typed contracts
Generated at build time. No hand-written stubs.
Every micro service declares a versioned interface string — for example, mos.services.gnss.GnssService@1.0.0. That contract drives code generation for the full client and server surface. Cloud-side consumers receive a stable, versioned schema; device-side maintainers never write stubs manually.
What each contract produces
- · Server trait scaffold
- · Proxy (client-side caller)
- · Direct client
- · Fake — test double, CI-runnable without hardware
- · Metrics module
- · Compliance test suite
Stable versioned surfaces
Interface versioning is enforced at registration time. Cloud integrators consume a typed contract that changes only on an explicit version bump — no silent breaking changes across 52 micro services. Build your integration with the MOS4 SDK for full contract tooling.
Registry-enforced isolation
Startup ordering enforced at registration time.
The platform registry resolves providers as they register. Each micro service declares a numeric startup priority (0–10); the registry builds a dependency graph and enforces it — no micro service can call a required interface before its provider has registered.
Process isolation
Each micro service is a separate Linux process. One crash cannot corrupt another service's memory. Capabilities are minimal by construction.
Interface validation
Illegal lifecycle transitions are rejected by the registry. No ambient shared mutable state crosses micro service boundaries.
Container resource isolation
CPU, memory, and I/O limits enforced at container start time. Container resource budget: less than 5% CPU/RAM overhead and approximately 10 MB RSS.
SDK reach
Any language — no SDK adoption required.
Four container mount profiles let 6 SDK languages — Python, Rust, C, C++, Go, and Lua — run alongside micro services. Any container can reach any MOS4 micro service over the MQTT (Message Queuing Telemetry Transport) bridge — JSON topic schema is sufficient, no typed-interface adoption needed. Explore the no-code tools for configuration and fleet management without writing code.
| Profile | Typical language | Bind-mount scope | Resource limits |
|---|---|---|---|
| SHELL | Shell scripts | Minimal host paths | CPU + RAM |
| PYTHON | Python 3 | Python runtime + libs | CPU + RAM |
| NATIVE | C / C++ / Go / Rust | Native libs | CPU + I/O |
| STATIC | Static binary | Minimal — static only | CPU + RAM |
System-layer substitution: a CPython 3.12 update propagates to all Python containers via one
digest bump in system-layers.toml — zero customer rebuilds.
Out-of-band tooling
mcm CLI and ROS2 (Robot Operating System 2) sidecar gateway.
Two tools extend the micro service graph without modifying the application layer: a pre-installed container management CLI and a ROS2 gateway for robotics workloads.
mcm standalone CLI
The mcm container management CLI ships pre-installed on production images — no
separate installation step required. Inspect running containers, trigger updates, and manage
system-layer digests directly from the device or a remote session.
ROS2 sidecar gateway
The ROS2 gateway bridges DDS (Data Distribution Service) graphs into MOS4 without a separate integration layer. ROS2 sidecar containers connect external DDS graphs and container-hosted ROS2 nodes directly to the micro service graph. See the service catalog for the mos-ros2 entry.
AI platform micro services
Kiosk-IA micro services in the catalog.
Five micro services form the MOS4 AI Language platform — on-device LLM, retrieval, tool gateway, voice, and kiosk orchestration. All follow the same typed-contract and event-bus pattern as the rest of the catalog.
mos-llm
On-device small language model service with quantised inference, event-bus token-stream topic, refuse-preferred system prompt, and opt-in cloud fallback.
mos-rag
Retrieval-Augmented Generation with cosine similarity thresholds and a refuse gate. Calibrated 50-question benchmark. BGE-small embedding on-device.
mos-mcp
Model Context Protocol gateway. Exposes a typed allow-list of tools the LLM may call. Default list is minimal; escalation requires operator configuration.
mos-voice
On-device speech-to-text (Whisper-tiny) and text-to-speech (Piper). Mandatory vocabulary boost for domain-specific terms. Acceptance criterion: word error rate ≤ 15% at 70–75 dB.
mos-kiosk
Kiosk orchestration micro service. Coordinates the LLM, RAG, MCP, and voice pipeline for a voice-first Q&A surface with per-answer audit manifest.
Observability
Automatic for every registered micro service.
Response-time histograms, error counters, component uptime, and lifecycle event traces are emitted automatically for every service call — OTLP (OpenTelemetry Protocol) export and W3C Trace Context propagation included with zero per-service configuration. Full details on the Operations page.
FAQ
Frequently asked questions
-
Can Python and Go services call MOS4 micro services without adopting the Rust SDK?
Yes. The in-process MQTT broker accepts any standard MQTT client without adopting the MOS4 SDK or .proto files. JSON topic schema is sufficient. A Python container can reach any micro service via the broker — fully validated end to end.
-
How does startup ordering work, and how does it relate to the layer diagram?
The framework assigns each micro service a numeric startup priority (0–10) and enforces it in the registry — no service starts until its required providers are registered. The L0–L7 labels in the architecture diagram are a conceptual grouping, not the same as the numeric ordering. They are two separate concepts.
-
What does code generation produce for each micro service?
For every declared interface, the build step generates a server trait scaffold, a proxy (client-side caller), a direct client, a test-double fake (CI-runnable without hardware), a metrics module, and a compliance test suite. No hand-written stubs across 52 micro services.
-
What is the container resource budget?
Less than 5% CPU/RAM overhead and approximately 10 MB RSS per container — enforced by Linux cgroups v2 at container start time.
-
How does the cloud-side API access work?
The Munic store exposes a GraphQL mesh, web services, and a push API for cloud-side integrators. Reference: https://store.munic.io/documentations/get_started. For device-side automation, the MessageGate JSON channel can call any registered micro service at runtime.
-
What languages can run inside containers?
Python, C, C++, Go, Rust, and Lua. Four mount profiles (SHELL, PYTHON, NATIVE, STATIC) control which host paths are bind-mounted. The system-layer substitution mechanism propagates a CPython 3.12 runtime update to all Python containers via one digest bump — no customer image rebuild.
Build on typed contracts.
Talk to engineering about your cloud integration architecture, or read the SDK docs to start building.