Concevoir un logiciel pour un environnement cloud native

Définir le comportement nécessaire

Les pratiques cloud native favorisent un développement et une exploitation reproductibles dans des environnements publics, privés ou hybrides. La CNCF met l’accent sur des systèmes qui restent administrables, observables et résilients lorsqu’ils évoluent. Les conteneurs et l’orchestration peuvent soutenir cette approche. Ils ne garantissent pas toutes ces propriétés à eux seuls.

Partons d’un service de rapports fictif. Un outil IA crée un endpoint, un worker et une image de conteneur. Une démonstration produit le bon PDF. Avant la production, l’équipe doit répondre à une autre question : que se passe-t-il si la plateforme remplace le worker pendant une tâche ?

C’est une question de conception applicative autant que d’infrastructure. Un redémarrage peut rétablir un processus tout en perdant son travail inachevé.

Séparer le processus de l’état durable

Le prototype conserve les tâches en attente et les rapports terminés sur le disque du conteneur. Le remplacement du conteneur peut supprimer les deux. Ajouter des workers peut aussi donner des réponses différentes selon celui qui reçoit la requête.

La conception révisée utilise un stockage durable des tâches et un stockage objet approuvé. Une requête enregistre une identité de tâche. Un worker prend en charge la tâche, crée son résultat et enregistre son emplacement. Les contrôles d’accès s’appliquent toujours lorsqu’un utilisateur télécharge le rapport.

Gardez les secrets hors de l’image. Fournissez-les par le système approuvé de gestion des secrets. Consignez quels changements de configuration exigent une nouvelle livraison ou un redémarrage du processus.

Concevoir les nouvelles tentatives avant d’ajouter des workers

Supposons que le worker enregistre un PDF, puis s’arrête avant d’acquitter la tâche. La file livre à nouveau la tâche. Une seconde tentative ne doit pas créer une deuxième facturation au client ni envoyer des messages de fin contradictoires.

Utilisez une opération idempotente lorsque cela convient. Répéter la même requête logique doit préserver l’effet prévu. Définissez une identité stable de requête, enregistrez durablement le résultat et vérifiez ce qui se passe à chaque point de défaillance. AWS décrit cette technique dans son guide des nouvelles tentatives sûres.

Les nouvelles tentatives ont aussi besoin de limites. Utilisez un délai maximal, un nombre maximal de tentatives et une attente qui évite les répétitions simultanées. Conservez les travaux échoués pour examen au lieu de les relancer indéfiniment.

Rendre l’état souhaité vérifiable

Une configuration déclarative décrit le déploiement souhaité. Un contrôleur travaille à maintenir cet état. Par exemple, un Deployment Kubernetes gère les réplicas de l’application et les mises à jour contrôlées. L’application doit toujours gérer correctement le remplacement.

Versionnez l’infrastructure et la configuration applicative. Examinez les modifications dans la procédure normale de livraison. Observez l’achèvement réel des tâches, l’ancienneté des tâches en attente, les échecs et les limites des dépendances. Un processus en cours d’exécution peut malgré tout être incapable de produire un rapport.

Choisir une plateforme que l’équipe peut exploiter

Le cloud native n’impose pas de transformer chaque application en microservices. Une application modulaire sur un environnement d’exécution managé peut satisfaire ses exigences. Davantage de services signifie davantage d’interfaces, de décisions de déploiement et de travail d’exploitation.

Donnez à l’agent de développement le contrat réel de la plateforme : environnement d’exécution pris en charge, méthode d’identité, services de données, règles de déploiement et preuves requises. Testez les comportements d’interruption et de remplacement en plus des requêtes réussies. Poursuivez avec la disponibilité et les domaines de défaillance.