Développer pour le déploiement distribué

Source: Dev.to

Bonnes pratiques et considérations

Introduction

L’idée de cet article m’est venue, en début d’année, après ma publication sur les éléments à considérer quand on démarre un projet de développement et en discutant avec des collègues qui commençaient à apprendre un environnement cloud.

Les applications sont maintenant souvent déployées dans des environnements distribués, que ce soit via des fournisseurs cloud (AWS, Azure, GCP), des orchestrateurs comme Kubernetes, des services managés, des fonctions serverless, ou même des infrastructures on‑premise distribuées.

Le développement d’applications destinées à ces environnements distribués nécessite de prendre en considération plusieurs aspects spécifiques.

Voici une liste de pratiques et de considérations clés pour développer des applications distribuées résilientes et scalables.

Pour les fins de cet article, nous énoncerons principalement des considérations pour les services à durée de vie prolongée. La plupart de ces considérations s’appliquent également aux fonctions serverless et aux applications événementielles.

---

Multiples instances jetables pour rendre un même service

Plusieurs clones, une seule mission

La considération la plus importante est que votre application doit être conçue pour fonctionner dans un environnement où plusieurs instances peuvent être exécutées simultanément. Cela signifie qu’une instance ne doit pas interférer avec une autre et qu’il faut éviter la duplication de traitement. Votre application ne doit pas dépendre d’un état local ou de ressources spécifiques à une instance, car ces éléments ne sont pas garantis d’être disponibles ou persistants entre les instances ou les redémarrages.

Que ce soit pour scaler horizontalement (ajouter plus d’instances) ou pour la résilience (redémarrer une instance défaillante), le nombre d’instances change en fonction de la charge réelle ou anticipée, de l’heure, etc. Votre application doit donc être capable de gérer plusieurs instances sans conflit.

Elle sera aussi probablement démarrée sans intervention humaine. Vous devez donc garder ces aspects en tête lors de la conception et du développement.

---

Architecture derrière un load balancer / reverse proxy

Comme une répartitrice d’appels en centre de services : chaque requête est envoyée au bon département — facturation, support, ou comptes — selon ce qu’elle demande.

Dans la plupart des cas, les instances de votre application seront déployées derrière un load balancer (équilibreur de charge). Le load balancer distribue le trafic entrant entre les différentes instances.

L’utilisation de sticky sessions permet de faire en sorte que le load balancer renvoie le trafic qui revient à la même instance. Mais il se peut que l’instance qui a fait le traitement initial ne soit plus disponible (scale‑down, mise à jour, etc.) ou que le load balancer ne supporte pas les sessions sticky. Dans ce cas, votre application doit être capable de prendre le relais d’une requête sans avoir répondu à la requête précédente dans le workflow.

Dans les architectures modernes, le load balancer ou l’API Gateway peut aussi router vers des services différents selon la requête :

• Par chemin (path‑based routing) : /api/users → service Utilisateurs, /api/orders → service Commandes
• Par hôte (host‑based routing) : api.example.com → API, static.example.com → ressources statiques
• Par en‑tête ou version d’API (header/version routing) : X-Client: mobile ou Accept: application/vnd.company.v2+json
• Par méthode ou port (rare), selon les contraintes techniques

Les conséquences côté développement sont que vous devez éviter les hypothèses d’état de session local, car une requête peut arriver à un autre service ou à une autre instance. Il devient très utile de propager les identifiants de corrélation pour tracer la requête à travers plusieurs services.

---

Externaliser la configuration

Externaliser la configuration, c’est comme insérer une carte SIM dans un téléphone : même appareil, réglages adaptés au réseau. En changeant de SIM, on peut changer de fournisseur — Bell, Vidéotron, Orange — sans toucher au téléphone lui‑même.

Séparer la configuration de l’application du code permet de modifier les paramètres sans recompilation. Une pratique très courante est d’utiliser des variables d’environnement. Voir la recommandation du 12‑factor app (section Config).

Les fournisseurs cloud offrent des services d’externalisation de la configuration :

• AWS Systems Manager Parameter Store
• Azure App Configuration
• GCP Secret Manager

Il est aussi possible de déployer votre propre service de configuration, comme Consul, etcd ou Spring Cloud Config. Vous devrez alors adapter votre application pour qu’elle récupère la configuration à partir de ces services.

Le choix dépendra de votre stratégie de déploiement : un seul fournisseur cloud, plusieurs fournisseurs, ou la possibilité de changer de fournisseur à l’avenir. Une solution agnostique au fournisseur évite le vendor lock‑in.

---

Feature flags et configuration dynamique

Les feature flags permettent d’activer ou désactiver des fonctionnalités sans recompilation ni redéploiement (si l’application est conçue pour les prendre en compte à la volée). Ils sont utiles pour :

• Déploiements progressifs : activer une nouvelle fonctionnalité pour un pourcentage d’utilisateurs ou certains groupes.
• A/B testing : tester différentes versions d’une fonctionnalité.
• Kill switch : désactiver rapidement une fonctionnalité problématique en production.
• Environnements spécifiques : activer des fonctionnalités seulement dans dev ou QA, pas en production.

Des outils comme LaunchDarkly, Unleash, Split.io ou AWS AppConfig peuvent être utilisés pour gérer les feature flags.

---

Gestion des secrets

Ne jamais stocker des secrets (mots de passe, clés API, certificats) directement dans le code ou dans des fichiers de configuration versionnés. Utilisez plutôt des services de gestion des secrets :

• AWS Secrets Manager
• Azure Key Vault
• GCP Secret Manager
• Kubernetes Secrets (avec chiffrement au repos activé)
• HashiCorp Vault
• SOPS (pour chiffrer les fichiers de configuration)

Ces solutions offrent : chiffrement des secrets au repos et en transit, contrôle d’accès granulaire, rotation automatique des secrets, et audit des accès.

---

Sauvegarde de fichiers de travail ou téléversés

Écrire sur le disque local en cloud, c’est laisser vos notes sur la table du café : ça… (texte incomplet).