Le coût caché de l'orchestration avec état

SchemaBridge Team · 2026-02-02 · Distributed Systems, Immutable Infrastructure, Orchestration, Anti-Patterns, Reliability

Pourquoi vos outils internes « simples » pourraient être votre plus grand risque de fiabilité, et comment l'application des principes d'Infrastructure Immuable à la logique applicative peut vous sauver.

Dans le monde des microservices, nous sommes obsédés par le découplage. Nous utilisons des files d'attente, nous adoptons des architectures orientées événements, et nous découpons les monolithes. Pourtant, à l'intérieur de nos moteurs d'orchestration, nous commettons souvent le péché capital des systèmes distribués : Nous écrivons des boucles avec état.

Chez SchemaBridge, nous avons récemment revu en profondeur nos workflows système principaux. Ce faisant, nous nous sommes retrouvés confrontés aux mêmes anti-patterns qui affligent de nombreuses organisations d'ingénierie. Ceci n'est pas seulement une histoire à propos de nos notes de version ; c'est une étude de cas sur l'application des principes d'Infrastructure Immuable à la couche applicative.

L'anti-pattern de la « boucle »

Prenons le classique « Poller » (scrutateur) :

while not deployment.is_ready():
    sleep(60)
    check_status()

Ce code suppose un univers stable. Il suppose que le processus de scrutation vivra éternellement. En réalité, il s'agit d'un artefact de Monolithe Distribué. Comme indiqué dans la [AWS Builders' Library], s'appuyer sur un état synchrone de longue durée crée des processus « zombies » et des modes de défaillance imprévisibles.

La solution : le chaînage récursif

Nous sommes passés d'une boucle interne while à un modèle d'exécution récursif, similaire au Continuation Passing Style utilisé en programmation fonctionnelle ou au Saga Pattern dans les transactions distribuées.

Pattern : l'étape A n'« attend » pas l'étape B. L'étape A génère l'étape B en tant que nouveau workflow indépendant.
Résultat : aucun état « en attente ». Si l'orchestrateur meurt, l'état de la base de données (l'étape B est mise en file d'attente) reste la source de vérité.

Logique immuable : le versioning s'appuie sur une identité « adressable par le contenu »

Le versioning est réputé difficile. Lorsque vous mettez à jour une définition de workflow, qu'advient-il des exécutions potentiellement déjà en cours ?

L'anti-pattern : les « mises à jour en place ». Vous déployez du nouveau code, et les exécutions existantes se mettent soudainement à se comporter différemment.
La norme du secteur : l'Infrastructure Immuable. Tout comme nous ne nous connectons pas en SSH aux serveurs pour les corriger (nous les remplaçons), nous ne devrions pas corriger des définitions de workflow en cours d'exécution.

Nous avons implémenté le hachage canonique du DSL.

En hachant l'arbre syntaxique abstrait (AST) de la logique de notre workflow, nous traitons chaque version comme une entité unique, adressable par son contenu. Cela s'aligne sur les stratégies utilisées par temporal.io et d'autres moteurs modernes : l'identité de l'exécution est liée à l'identité du code.

Verrouiller le « mode Dieu »

Enfin, nous avons abordé la sécurité des outils internes. Il est courant de donner un accès root aux scripts internes de « nettoyage ». Cela viole le principe du moindre privilège.

Nous avons découvert que notre propre outil interne de « déploiement progressif » avait la capacité d'écraser des ID système critiques. Nous avons verrouillé cela à l'aide d'un pattern « Sudo » où seuls les acteurs système vérifiés cryptographiquement peuvent demander des ID logiques spécifiques.

Conclusion

Si votre orchestration repose sur sleep(), vous vous battez contre le cloud.

En adoptant la récursion, l'immuabilité et une identité stricte, nous passons d'une orchestration « fondée sur l'espoir » à une orchestration « fondée sur la preuve ».

Pour aller plus loin :