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.

Flotte de conteneurs Balena à gauche, runtime de micro services typés MOS4 à droite, reliés par une poignée de main pointillée — ambre sur la poignée de main

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.

Modèle d’IPC Balena Communication conteneur à conteneur sur TCP ou sockets Unix. Le schéma est défini par l’application au runtime. MOS4 Bus protobuf typé. Schéma vérifié au build par buf lint et cargo build. Un micro service qui appelle incorrectement une interface échoue à la compilation, pas après un redémarrage de conteneur.
Cycle de vie OCI Balena BalenaEngine gère le pull, le démarrage, l’arrêt et le redémarrage des conteneurs. MOS4 mos-container-manager (MCM) : runtime de production crun, limites CPU/mémoire/IO en cgroups v2 imposées comme contrat au démarrage, supervision de conteneur via polling /metrics.
Mises à jour de couche système Balena La mise à jour de l’image de base requiert une reconstruction et un redéploiement du conteneur client. MOS4 Couches système : l’opérateur bump un seul digest dans system-layers.toml ; MCM substitue la couche annotée au moment du compose pour tous les conteneurs clients. Pas d’action client requise.
Primitives véhicule / industrielles Balena Agnostique au domaine. Les clients apportent leurs propres bibliothèques de protocoles dans les conteneurs. MOS4 obdstacks-v2 (16 protocoles : CAN, CAN-FD, DoIP, UDS, J1939, ISOBUS, et plus), mos-gnss, mos-modem, mos-ai-runtime et 48 micro services métier supplémentaires livrés avec la plateforme — 52 dans le catalogue de production.
Cycle de vie de composant Balena Redémarrage de conteneur et swap d’image. MOS4 Hooks de cycle de vie on_start / on_stop / on_idle_in / on_idle_out, démarrage ordonné par dépendances, application du watchdog, hot-swap — remplacement de composant à chaud sans redémarrer le bundle.
OTA flotte Balena BalenaCloud : déploiement progressif d’images de conteneur. L’unité de mise à jour est le conteneur. MOS4 mos-update : paquets delta signés Ed25519, partitions A/B, rollback automatique via bootcount, compteur de retry persistant entre les cycles d’alimentation. OTA par cohortes et canary via le compagnon cloud Munic. L’unité de mise à jour est un composant unique.
Budget conteneur Balena Surcharge runtime conteneur par workload, dépendant du moteur de conteneur et de la taille d’image. MOS4 Enveloppe budget conteneur MCM : moins de 5 % de surcharge CPU/RAM et environ 10 Mo de RSS par conteneur, selon le profil de référence SDK.
CLI on-device Balena CLI balena pour opérations flotte à distance. MOS4 CLI on-device mcm (binaire statique) : pull, GC, inspection de config, dry-run de spec OCI. Fonctionne sans le démon MOS4 — utile aux phases de test manufacturing et post-mortem.

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.

Vous construisez sur MOS4 ?

Une réponse de l'équipe d'ingénierie, ~24 h. Pas de pitch, pas de NDA.

Parler à l'équipe