Comparatif
MOS4 vs Balena
Balena livre des conteneurs Docker à une flotte. MOS4 est un runtime de micro services typés avec IPC protobuf natif, cycle de vie OCI cgroups v2 et primitives métier véhicule et industrielles. Les deux peuvent fonctionner côte à côte.
Frontière
Gestion de flotte de conteneurs vs runtime de micro services typés.
Balena compose des conteneurs qui dialoguent en TCP et sockets Unix. MOS4 compose des micro services typés qui dialoguent via un bus protobuf natif.
flowchart LR
subgraph Bal["Balena — flotte de conteneurs"]
B1[Conteneur A]
B2[Conteneur B]
B1 <-.TCP / sockets.-> B2
end
subgraph M["MOS4 — micro services typés"]
M1[Micro service A]
M2[Micro service B]
M1 <-->|bus protobuf| M2
end Côte à côte
Comparaison des capacités.
Source — colonne Balena depuis balena.io; MOS4 depuis /fr/architecture.
SDK
Cinq langages, budgets d’image imposés en CI.
MCM livre des conteneurs OCI prêts à déployer en Python, Rust, Go, C et C++ couvrant l’appel de service streaming, le request-response et le pub/sub d’événements contre un bridge MQTT GNSS. Chaque paire langage-scénario a un budget de taille d’image imposé en CI — 15 cellules de matrice, points de départ de référence testés.
FAQ
Les questions qu’on nous pose le plus.
-
MOS4 peut-il tourner dans un conteneur Balena ?
Exécuter MOS4 à l’intérieur d’un conteneur géré par Balena est un schéma de coexistence que des équipes ont exploré. Ce n’est pas une topologie de déploiement supportée par Munic. Le chemin recommandé est MOS4 comme runtime principal avec sa propre gestion de workloads OCI. Parlez à l’ingénierie pour discuter de votre topologie spécifique.
-
Pourquoi utiliser un IPC protobuf typé plutôt que du TCP entre conteneurs ?
Le schéma est vérifié au build par buf lint et cargo build, pas au runtime après un redémarrage de conteneur. Un composant qui appelle incorrectement une interface échoue à la compilation. Le format de fil est le même que les composants s’exécutent sur un seul device ou sur plusieurs.
-
Perd-on l’isolation conteneur avec MOS4 ?
Non. mos-container-manager (MCM) impose les limites CPU, mémoire et I/O par conteneur via les cgroups v2 Linux comme contrat au démarrage. La supervision de conteneur interroge l’endpoint /metrics de chaque conteneur. Les namespaces Linux restent disponibles.
-
Comment se compare l’OTA de flotte ?
Balena livre des images de conteneur — l’unité de mise à jour est le conteneur complet. mos-update livre des paquets delta par composant : signés Ed25519, partitions A/B, rollback automatique via bootcount. La plus petite unité remplaçable est un service unique, pas une image complète. OTA par cohortes et canary via le compagnon cloud Munic.
-
MOS4 est-il la bonne réponse si je n’ai besoin que de gestion de flotte de conteneurs ?
Si vous avez seulement besoin de livrer des images Docker à une flotte, Balena est la réponse plus simple. MOS4 est la bonne réponse quand le programme a besoin d’IPC de composants typé, de primitives métier véhicule ou industrielles, d’inférence IA on-device ou d’OTA à granularité composant.
-
Puis-je réutiliser des fichiers Docker Compose existants ?
Oui. MCM parse les fichiers Docker Compose v3, donc les équipes avec des workflows de développement basés sur Compose peuvent les apporter sur les cibles embarquées sans apprendre une nouvelle syntaxe de configuration.
Gardez votre fleet manager, ajoutez un runtime typé.
Un appel de 30 minutes avec l’ingénierie. Nous mappons MOS4 sur vos devices Linux embarqués existants.