Développer pour le déploiement distribué : Bonnes pratiques et considérations
Par Patrick Turcotte
- 28 minutes de lecture - 5762 mots1. 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 Projet Green Field 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érations 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.
2. Multiples instances jetables pour rendre un même service
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 de votre application ne doit pas interférer avec une autre instance, et qu’il faut éviter la duplication de traitement. De plus, 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), parce que le nombre d’instances change en fonction de la charge réelle ou anticipée, en fonction de l’heure, etc., votre application doit être capable de gérer plusieurs instances sans conflit.
Elle sera aussi probablement démarrée sans intervention humaine. Vous devez donc conserver ces aspects en tête lors de la conception et du développement de votre application.
3. Architecture derrière un load balancer/reverse proxy
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 de votre application. L’utilisation de sticky sessions permet de faire en sorte que le load balancer va envoyer 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, cela signifie que 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), ex.:
/api/users→ service Utilisateurs,/api/orders→ service CommandesPar hôte (host-based routing), ex.:
api.example.com→ API,static.example.com→ ressources statiquesPar en-tête ou version d’API (header/version routing), ex.:
X-Client: mobileouAccept: application/vnd.company.v2+jsonPar méthode ou port (rare), selon les contraintes techniques
Les conséquences du 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.
4. Externaliser la configuration
Un aspect important du développement pour le déploiement distribué (dont le cloud) est de séparer la configuration de l’application du code lui-même. Cela permet notamment de modifier la configuration sans avoir à recompiler l’application.
Une pratique très courante est d’utiliser des variables d’environnement pour fournir la configuration à l’application. Voir https://12factor.net/fr/config
Les différents fournisseurs cloud offrent aussi un service d’externalisation de la configuration, comme AWS Systems Manager Parameter Store, Azure App Configuration ou GCP Secret Manager. Ces services permettent de stocker et de gérer la configuration de manière sécurisée et centralisée. Il est aussi possible de déployer votre propre service de configuration, comme Consul, etcd ou Spring Cloud Config. Par contre, vous devrez adapter votre application pour qu’elle puisse récupérer la configuration à partir de ces services.
Le choix final que vous ferez dépendra de si vous prévoyez déployer votre application dans un seul fournisseur cloud ou dans plusieurs ou s’il est possible que vous changiez éventuellement de fournisseur. Il est probablement plus prudent d’utiliser une solution agnostique au fournisseur cloud pour éviter le vendor locking, c’est-à-dire de ne pouvoir déployer que sur un seul fournisseur.
5. Feature flags et configuration dynamique
Les feature flags (drapeaux de fonctionnalités) permettent d’activer ou désactiver des fonctionnalités sans recompiler l’application, ou même la redéployer si vous mettez en place une façon d’en prendre compte pendant que l’application roule. Cette stratégie peut être très utile, notamment pour les cas d’utilisation suivants.
Déploiements progressifs : Activer une nouvelle fonctionnalité pour un pourcentage d’utilisateurs ou certains groupes d’utilisateurs
A/B testing : Tester différentes versions d’une fonctionnalité
Kill switch : Désactiver rapidement une fonctionnalité problématique en production sans redéployer
Environnements spécifiques : Activer des fonctionnalités seulement dans certains environnements, comme dev ou qa mais pas en production pour valider avant le déploiement complet sans devoir gérer plusieurs branches de code.
Des outils comme LaunchDarkly, Unleash, Split.io, ou AWS AppConfig peuvent être utilisés pour gérer les feature flags.
6. Gestion des secrets
Ne jamais stocker des secrets (mots de passe, clés API, certificats) directement dans le code ou dans les fichiers de configuration versionnés.
Utilisez plutôt des services de gestion des secrets qui offrent des fonctionnalités de sécurité avancées, comme des services clouds dédiés (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager), le système d’encryption de votre orchestrateur (Kubernetes Secrets avec encryption at rest activée), ou des outils tiers comme HashiCorp Vault ou SOPS.
Ces solutions offrent plusieurs avantages, comme l’encryption des secrets au repos et en transit, un contrôle d’accès granulaire, la rotation automatique des secrets, et l’audit des accès.
7. Stockage de fichiers de travail ou téléversés
Imaginons une application qui génère un rapport (PDF, Excel, etc.) à partir de données fournies par l’utilisateur.
Dans un scénario "classique", l’application pourrait générer le rapport sur le disque dur local de l’instance, puis le rendre disponible pour téléchargement.
Par contre, dans un environnement à multiple instance, il faut mettre ce fichier soit dans un stockage partagé, un volume réseau, ou, au pire, la base de données.
Les fournisseurs offrent des services de stockage, comme AWS S3, AWS EFS, Azure Blob Storage, Azure Files, GCP Cloud Storage ou GCP Filestore, qui peuvent être utilisés pour stocker ces fichiers intermédiaires.
8. Tâches périodiques / Cron Job
Les tâches périodiques, comme l’envoi de courriel de rappel, la création de rapports ou la purge de données sont fréquentes dans les applications.
Dans un environnement distribué, il est important de s’assurer que ces tâches ne sont pas exécutées simultanément par plusieurs instances de l’application.
Pour y arriver, il faut réfléchir à une façon de synchroniser l’exécution de ces tâches. Plusieurs approches sont possibles :
Utiliser un service de planification externe, comme AWS CloudWatch Events, Azure Logic Apps ou GCP Cloud Scheduler, pour déclencher les tâches périodiques.
Utiliser un mécanisme de verrouillage distribué, comme une entrée dans une base de données ou un service de cache distribué (Redis, Memcached) pour s’assurer qu’une seule instance exécute la tâche à un moment donné.
Utiliser une bibliothèque de planification comme Quartz Scheduler ou autre similaire.
Il peut être intéressant de développer une mécanique qui permet de lancer des tâches spécifiques, qui peuvent être appelées par le service de planification externe ou par un job interne avec un verrouillage distribué. Par exemple de créer des endpoints HTTP sécurisés qui déclenchent les tâches périodiques. Dans ce cas, des endpoints complémentaires pour obtenir le statut des tâches peuvent aussi être utiles pour le monitoring.
L’important, c’est de faire en sorte que les tâches périodiques soient exécutées de manière fiable et sans conflit entre les différentes instances de l’application.
9. Gestion de l’état et des sessions
Dans un environnement distribué avec plusieurs instances, la gestion de l’état utilisateur (sessions) devient critique. Si un utilisateur se connecte à une instance et que sa prochaine requête est routée vers une autre instance, l’application doit pouvoir récupérer les informations de la session.
Plusieurs approches existent :
Sessions stateless : Utiliser des tokens JWT (JSON Web Tokens) qui contiennent toutes les informations nécessaires. Le client transmet le token à chaque requête. Il peut le transmettre par header, par cookie, ou dans le corps de la requête.
Cache distribué : Stocker les sessions dans un cache distribué comme Redis ou Memcached, accessible par toutes les instances.
Sticky sessions : Configurer le load balancer pour router toujours le même utilisateur vers la même instance (moins recommandé car crée des dépendances et ne fonctionnera pas si l’instance est arrêtée).
Base de données : Stocker les sessions dans la base de données (moins performant mais plus simple).
La meilleure approche dépend de vos besoins spécifiques, mais les sessions stateless (JWT) ou le cache distribué (Redis, Memcached) souvent généralement préférés. Les sessions stateless permettent de réduire la dépendance à un stockage centralisé et facilitent le scaling horizontal. Par contre, la révocation immédiate des sessions peut être plus complexe avec JWT. De l’autre côté, l’utilisation d’un cache distribué offre une gestion centralisée des sessions, mais introduit une dépendance supplémentaire et peut nécessiter une infrastructure plus complexe.
10. Persistance et transactions de base de données
Dans un environnement distribué, la gestion des transactions de base de données nécessite une attention particulière.
Connexions à la base de données : Utilisez un pool de connexions pour optimiser l’utilisation des ressources. Configurez le nombre maximum de connexions en fonction du nombre d’instances.
Transactions distribuées : Évitez les transactions distribuées (2PC - Two-Phase Commit) autant que possible, car elles sont complexes et réduisent la performance. Privilégiez le pattern Saga pour gérer les transactions sur plusieurs services.
Idempotence : Concevez vos opérations de base de données pour être idempotentes, c’est-à-dire qu’elles produisent le même résultat même si elles sont exécutées plusieurs fois.
Retry et resilience : Implémentez des mécanismes de retry pour gérer les échecs temporaires de connexion à la base de données.
10.1. Migrations de schéma de base de données
Les migrations de schéma dans un environnement distribué nécessitent une planification minutieuse.
Migrations forward-compatible : Les changements doivent être compatibles avec l’ancienne version pendant le déploiement, on peut ainsi déployer les nouvelles instances avant de retirer les anciennes ou même faire un retour en arrière applicatif si nécessaire.
Outils de migration : Utilisez Liquibase, Flyway, ou des outils natifs (Alembic pour Python, migrate pour Go)
Déploiements testés : Pour les changements, particulièrement les changements majeurs, il est important de tester la migration de la base de données avant d’appliquer à la production
Migrations à l’arrêt vs au démarrage : Décidez si les migrations s’exécutent avant ou pendant le déploiement
Rollback : Préparez toujours un plan de rollback pour les migrations complexes
10.2. Patterns pour les changements de schéma
Il existe certains patterns courants pour gérer les changements de schéma de base de données dans un environnement distribué. Ils permettent de minimiser les interruptions de service et de garantir la compatibilité entre les versions.
Expand-Contract Pattern :
Expand : Ajoutez la nouvelle colonne/table
Dual-write : Écrivez dans l’ancienne et la nouvelle structure
Migrate : Migrez les anciennes données
Contract : Supprimez l’ancienne structure
Versioning des changements : Quand les changements de schéma affectent l’API, utilisez le versioning (v1, v2)
11. Mise en cache et performance
Le cache est crucial pour la performance dans un environnement distribué. Obtenir une information en mémoire est beaucoup plus rapide que d’aller la chercher dans une base de données ou un service externe.
11.1. Types de cache
Il existe plusieurs types de cache que vous pouvez utiliser.
Cache en mémoire local : Rapide mais non partagé entre instances (Caffeine, Guava Cache)
Cache distribué : Partagé entre toutes les instances (Redis, Memcached, Hazelcast)
CDN : Pour les ressources statiques (CloudFront, Azure CDN, Cloud CDN, autres)
HTTP caching : Utilisez les headers HTTP (Cache-Control, ETag) pour le cache côté client
Reverse proxy cache : Cache comme varnish
11.2. Stratégies de cache
La stratégie de cache dépendra de vos besoins spécifiques.
Cache-aside : L’application vérifie le cache, puis la base de données si nécessaire
Write-through : Les données sont écrites dans le cache et la base de données simultanément
Write-behind : Les données sont écrites dans le cache d’abord, puis dans la base de données de façon asynchrone
Invalidation : Définissez des stratégies claires pour invalider le cache (TTL, événements)
11.3. Invalidation et nettoyage du cache
L’un des défis les plus importants avec le cache est de savoir quand le nettoyer ou l’invalider. Un cache obsolète peut causer des bugs difficiles à diagnostiquer.
TTL (Time-To-Live) : Définissez une durée de vie maximale pour chaque entrée du cache. Après ce délai, l’entrée est automatiquement supprimée ou marquée comme expirée.
Invalidation par événement : Lorsque des données sont modifiées dans la base de données, invalidez ou mettez à jour les entrées de cache correspondantes. Utilisez des event listeners ou des patterns pub/sub.
Cache tagging : Associez des tags aux entrées de cache pour pouvoir invalider plusieurs entrées liées d’un coup (par exemple, toutes les entrées liées à un utilisateur spécifique).
Versioning : Incluez une version dans la clé de cache. Quand vous déployez un changement de format, incrémentez la version pour invalider automatiquement les anciennes entrées.
Flush sélectif vs global : Évitez de vider tout le cache (flush) sauf en cas d’urgence. Préférez l’invalidation ciblée pour maintenir les performances.
Cache warming : Après un vidage ou au démarrage, préremplissez le cache avec les données les plus utilisées pour éviter une charge soudaine sur la base de données.
Certaines considérations sont importantes pour l’invalidation et le nettoyage de la cache pour les environnements distribués. Si vous utilisez un cache distribué (Redis, Memcached), l’invalidation sera visible par toutes les instances. Par contre, si vous utilisez un cache local en mémoire, chaque instance aura son propre cache. Vous devrez propager les événements d’invalidation à toutes les instances (via pub/sub ou message queue). Documentez clairement votre stratégie d’invalidation pour chaque type de données cachées.
11.4. Autres considérations importantes
Attention au thundering herd : quand plusieurs instances tentent de recharger le même cache expiré simultanément. On revient ici avec la notion selon laquelle plusieurs instances tentent de faire la même chose en même temps. On peut mettre en place une stratégie de grace mode pour mitiger le problème.
Utilisez des clés de cache bien structurées pour faciliter l’invalidation ciblée
Surveillez le taux de hit/miss du cache pour optimiser la configuration
Loggez les invalidations de cache pour faciliter le debugging
12. Considérations pour l’équipe devops
L’équipe qui va déployer et gérer l’application a des besoins spécifiques qui doivent être pris en compte dès le début du développement.
12.1. Observabilité : Logs, métriques et traces
L’observabilité est cruciale dans un environnement distribué où il peut être difficile de diagnostiquer les problèmes.
12.1.1. Logging structuré
Utilisez un format de log structuré tel JSON pour faciliter la recherche et l’analyse. Incluez un identifiant de corrélation (correlation ID) dans chaque log pour tracer une requête à travers plusieurs services et instances. Centralisez vos logs dans un système comme AWS CloudWatch, Azure Monitor, GCP Cloud Logging, ELK Stack (Elasticsearch, Logstash, Kibana), Datadog ou Loki.
Évitez de logger des informations sensibles (mots de passe, tokens, données personnelles). Évitez aussi de logger trop d’informations pour ne pas noyer les logs importants. Si possible, utilisez des bibliothèques de logging qui supportent la reconfiguration dynamique du niveau de log (DEBUG, INFO, WARN, ERROR) sans redémarrer l’application.
12.1.2. Métriques
Exposez des métriques sur la santé et la performance de votre application (temps de réponse, nombre de requêtes, taux d’erreur, utilisation CPU/mémoire). Utilisez des outils comme Prometheus, Grafana, ou les outils natifs de votre plateforme de déploiement pour collecter et visualiser ces métriques. Configurez des alertes basées sur ces métriques pour être notifié des problèmes.
12.1.3. Tracing distribué
Implémentez le tracing distribué avec des outils comme Jaeger, Zipkin ou AWS X-Ray pour suivre le parcours d’une requête à travers vos différents services. Utilisez OpenTelemetry comme standard pour instrumenter votre application.
12.2. Health checks et readiness probes
Les orchestrateurs comme Kubernetes et les load balancers ont besoin de savoir si une instance de votre application est en bonne santé et prête à recevoir du trafic.
Il existe généralement trois types de probes. Le Liveness probe indique si l’application est vivante et fonctionne. Si elle échoue, l’orchestrateur redémarre l’instance. Le Readiness probe indique si l’application est prête à recevoir du trafic. Par exemple, si les connexions à la base de données ne sont pas encore établies, l’instance n’est pas prête. Le Startup probe, pour les applications qui prennent du temps à démarrer, évite que la liveness probe ne tue l’application prématurément.
Implémentez des endpoints HTTP dédiés (par exemple /health et /ready) qui retournent le statut approprié.
12.3. Exposition d’informations
Exposez des informations sur votre application (version, git commit, environnement, etc.) sur le endpoint /info.
12.4. Graceful shutdown
Lorsqu’une instance de votre application est arrêtée (mise à jour, scaling down, etc.), elle doit se terminer proprement :
Arrêter d’accepter de nouvelles requêtes
Terminer le traitement des requêtes en cours
Fermer proprement les connexions aux bases de données et aux services externes
Libérer les ressources
Implémentez un signal handler (SIGTERM) pour gérer l’arrêt gracieux de votre application. La plupart des orchestrateurs envoient un SIGTERM avant de forcer l’arrêt avec SIGKILL.
12.5. Gestion des dépendances et vulnérabilités
La gestion proactive des dépendances est cruciale pour la sécurité et la stabilité :
Scan régulier : Utilisez des outils comme Dependabot, Snyk, ou OWASP Dependency-Check pour identifier les vulnérabilités dans vos dépendances Mises à jour automatisées : Configurez des pull requests automatiques pour les mises à jour de sécurité Versioning sémantique : Respectez le versioning sémantique pour vos propres bibliothèques Lockfiles : Utilisez des fichiers de verrouillage (package-lock.json, uv.lock, Pipfile.lock, go.sum, pom.xml) pour garantir la reproductibilité Audit régulier : Faites des audits de sécurité réguliers de vos dépendances
12.6. CI/CD et pipelines de déploiement
L’automatisation du déploiement est essentielle pour le cloud, elle est aussi très utile quand on déploie sur des serveurs traditionnels. Elle permet de réduire les oublis, les erreurs humaines et d’accélérer les mises à jour.
Intégration continue : Exécutez les tests automatiquement à chaque commit (GitHub Actions, GitLab CI, Jenkins, CircleCI).
Tests : Incluez des tests unitaires, d’intégration, et end-to-end dans votre pipeline.
Build d’images : Automatisez la création des images de conteneur.
Scan de sécurité : Intégrez le scan de sécurité des images et des dépendances dans le pipeline.
Déploiement progressif : Utilisez des stratégies comme blue/green deployment, canary deployment, ou rolling updates pour minimiser les risques.
Rollback automatique : Configurez un rollback automatique si les health checks échouent après un déploiement.
Infrastructure as Code : Gérez votre infrastructure avec Terraform, CloudFormation, Pulumi, ou ARM templates.
Faites en sorte que votre pipeline injecte la version de l’image dans les variables d’environnement de l’application.
12.7. Conteneurisation et images
La conteneurisation est quasi-universelle dans le déploiement distribué :
Images légères : Utilisez des images de base minimales (Alpine, distroless) pour réduire la taille et la surface d’attaque.
Multi-stage builds : Utilisez des builds multi-étapes pour séparer la compilation de l’exécution et réduire la taille finale.
Scan de sécurité : Scannez vos images pour détecter les vulnérabilités (Trivy, Snyk, Clair).
Versioning : Versionnez vos images et évitez d’utiliser le tag latest en pré-production ou en production.
Non-root user : Exécutez vos conteneurs avec un utilisateur non-root pour la sécurité.
Pipelines : Automatisez la construction, le test et le déploiement de vos images via des pipelines CI/CD.
Assurez-vous d’exposer la version de l’image dans les variables d’environnement de l’application.
12.8. Optimisation des coûts (cloud)
Le cloud peut devenir coûteux si on ne fait pas attention.
Auto-scaling intelligent : Configurez l’auto-scaling basé sur des métriques réelles (CPU, mémoire, nombre de requêtes).
Right-sizing : Choisissez la taille d’instance appropriée pour votre charge de travail. Ne sur-provisionnez pas.
Utilisation de spot instances : Pour les charges de travail non-critiques ou les environnements de test, utilisez des instances spot/préemptibles.
Shutdown automatique : Arrêtez les environnements de développement et de test en dehors des heures de travail.
Monitoring des coûts : Utilisez les outils de monitoring des coûts fournis par votre cloud provider.
12.9. Gestion des ressources et limites
Définir correctement les ressources allouées à votre application est essentiel.
Requests et Limits : Dans Kubernetes, définissez des requests (ressources garanties) et des limits (ressources maximales) pour CPU et mémoire
Memory leaks : Surveillez activement les fuites mémoire qui peuvent causer des redémarrages fréquents
JVM tuning : Pour les applications Java, configurez correctement le heap size et le garbage collector en fonction des ressources allouées
Connection pools : Dimensionnez correctement vos pools de connexions (DB, HTTP clients) en fonction du nombre d’instances et de la charge
Thread pools : Configurez les thread pools pour éviter l’épuisement des threads et les blocages
13. Développement local et environnement de dev
Développer pour un environnement distribué ne signifie pas que tout doit se faire dans cet environnement.
13.1. Émulation locale des services distribués
LocalStack : Émule les services AWS localement (S3, DynamoDB, SQS, etc.) Azurite : Émulateur pour Azure Storage Docker Compose : Orchestrez localement vos services (base de données, cache, message queues) Testcontainers : Lancez des conteneurs pour vos tests d’intégration Minikube/Kind : Exécutez Kubernetes localement pour tester vos déploiements
13.2. Configuration locale vs déploiement distribué
Utilisez des profils de configuration différents pour le développement local vs déploiement distribué. Évitez de dépendre de services cloud spécifiques pendant le développement local quand possible. Documentez clairement les étapes pour configurer l’environnement de développement local, idéalement avec des scripts d’automatisation. Utilisez des variables d’environnement avec des valeurs par défaut pour simplifier la configuration locale. Si vous devez utiliser des secrets, utilisez des fichiers .env locaux ou des services de gestion des secrets adaptés au développement comme SOPS. Voir l’article que j’ai rédigé à ce sujet : SOPS - Secrets encryptés dans un dépôt GIT
13.3. Hot reload et développement rapide
Utilisez des outils de hot reload (Spring Boot DevTools, Nodemon, Air pour Go) pour accélérer le cycle de développement. Configurez des volumes montés dans Docker pour un rechargement rapide du code. Utilisez des outils comme Skaffold ou Tilt pour le développement continu sur Kubernetes.
14. Tests pour applications distribuées
Tester des applications distribuées nécessite une approche différente.
14.1. Tests unitaires
Tests isolés de la logique métier
Mockez les dépendances externes (base de données, services tiers)
Utilisez des frameworks de test adaptés à votre langage
14.2. Tests d’intégration
Testcontainers : Lancez des conteneurs Docker pour tester avec de vraies dépendances
Tests de base de données : Testez les requêtes SQL et les migrations avec une vraie base de données
Tests d’API : Testez vos endpoints REST/gRPC avec des outils comme RestAssured, Supertest
14.3. Tests end-to-end
Testez le système complet dans un environnement similaire à la production
Utilisez des outils comme Selenium, Cypress, Playwright pour les applications web
Automatisez ces tests dans votre pipeline CI/CD
14.4. Tests de charge et de performance
Load testing : Testez le comportement sous charge normale (Apache JMeter, Gatling, k6)
Stress testing : Testez les limites du système
Spike testing : Testez la réponse à des pics soudains de trafic
Soak testing : Testez la stabilité sur une longue période pour détecter les fuites mémoire
14.5. Tests de chaos engineering
Si nécessaire, intégrez des tests de chaos engineering pour valider la résilience de votre application :
Testez la résilience en introduisant des défaillances volontaires
Utilisez des outils comme Chaos Monkey, Gremlin, ou LitmusChaos
Simulez des pannes de serveurs, des latences réseau, des bases de données indisponibles
14.6. Tests de régression visuelle
Pour les applications frontend, testez que l’interface n’a pas changé de façon non intentionnelle
Utilisez des outils comme Percy, Chromatic, ou Applitools
15. Communication entre services
Si votre application est composée de plusieurs microservices ou composants qui doivent communiquer entre eux, il est crucial de choisir les bons protocoles et patterns de communication.
API REST : Standard et simple, utilisez HTTP/HTTPS avec des formats JSON.
gRPC : Plus performant que REST, utilise Protocol Buffers et HTTP/2.
Message queues : Pour la communication asynchrone, utilisez RabbitMQ, Apache Kafka, AWS SQS, Azure Service Bus, Postgres Notify, ou GCP Pub/Sub.
Service mesh : Pour gérer la communication entre services (Istio, Linkerd) avec features comme le load balancing, le circuit breaking, et le mTLS.
Certaines considérations importantes sont à ne pas négliger. Utilisez des timeouts pour toutes les communications inter-services. Implémentez des retry avec backoff exponentiel. Utilisez des circuit-breakers pour éviter les cascades de défaillances. Propagez les correlation ID*s pour le *tracing distribué.
15.1. Résilience et gestion des erreurs
Dans un environnement distribué, les erreurs sont inévitables. Votre application doit être conçue pour être résiliente.
Circuit breaker : Évite de surcharger un service défaillant en "ouvrant le circuit" après un certain nombre d’échecs.
Retry avec backoff exponentiel : Réessaie les opérations échouées avec un délai croissant entre chaque tentative.
Timeout : Définissez des timeouts pour toutes les opérations réseau pour éviter d’attendre indéfiniment.
Bulkhead : Isolez les ressources pour qu’une défaillance dans une partie du système n’affecte pas les autres.
Fallback : Prévoyez un comportement de secours quand une opération échoue (cache, valeur par défaut, mode dégradé).
Des bibliothèques comme Resilience4j (Java), Polly (.NET) ou Hystrix facilitent l’implémentation de ces patterns.
15.2. Patterns de conception à considérer
Plusieurs patterns architecturaux sont particulièrement adaptés aux déploiements distribués :
Strangler Fig Pattern : Migrez progressivement une application monolithique vers des microservices en "étranglant" l’ancien système
Backend for Frontend (BFF) : Créez des API spécifiques pour chaque type de client (web, mobile, etc.)
API Gateway : Point d’entrée unique pour tous vos services, gérant l’authentification, le routage, le rate limiting
Event Sourcing : Stockez tous les changements d’état comme une séquence d’événements
CQRS (Command Query Responsibility Segregation) : Séparez les opérations de lecture et d’écriture pour optimiser chacune indépendamment
Sidecar Pattern : Déployez des fonctionnalités auxiliaires (logging, monitoring) dans un conteneur séparé mais adjacent
Il est important de bien comprendre ces patterns, dans quel contexte les utiliser et de les adapter à vos besoins spécifiques.
15.3. Anti-patterns à éviter
Distributed Monolith : Microservices trop couplés qui doivent être déployés ensemble. L’indépendance relative entre les services est cruciale.
Chatty Services : Trop de communication entre services, créant de la latence, pensez à regrouper les appels, à la caching, ou à utiliser des messages asynchrones.
Tight Coupling : Services dépendant fortement les uns des autres, rendant les changements et le déploiement difficiles. Pensez à utiliser des interfaces claires et des contrats stables.
Data Ownership Violations : Services accédant directement à la base de données d’autres services. Si vous choisissez de considérer la base de données comme un service, chaque service doit gérer son propre schéma de données. De plus, s’il est plus efficace pour un service d’accéder directement à la base de données d’un autre service, pensez à exposer l’information sous la forme d’une vue qui devient le contrat entre les deux services.
Ignorer la loi de fallacies of distributed computing : Supposer que le réseau est fiable, la latence nulle, la bande passante infinie, etc.
16. Sécurité
Tant dans un déploiement distribué traditionnel que dans le cloud, la sécurité est une responsabilité partagée par les développeurs et l’équipe devops, et doit être intégrée dès le début.
Principe du moindre privilège : Donnez uniquement les permissions nécessaires aux applications et aux utilisateurs.
Encryption : Chiffrez les données au repos et en transit (TLS/HTTPS).
Authentification et autorisation : Utilisez des standards comme OAuth2/OIDC pour l’authentification, JWT pour les tokens.
Scan de vulnérabilités : Scannez régulièrement vos dépendances et vos images.
WAF : Utilisez un Web Application Firewall pour protéger contre les attaques courantes.
DDoS protection : Activez la protection DDoS offerte par votre cloud provider. Sinon, regardez ce que vous pouvez mettre en place vous-même.
Audit logs : Conservez des logs d’audit pour toutes les opérations sensibles.
17. Environnements multiples
Maintenez plusieurs environnements pour différents stades du cycle de vie. Ils permettent une liberté pour tester et valider les changements avant de les déployer aux testeurs, puis en production.
Local : Pour le développement individuel
Développement : Pour s’assurer que les nouvelles fonctionnalités fonctionnent ensemble, que ça déploie correctement, pour permettre aux développeurs de tester des intégrations.
Test/QA : Pour les tests d’intégration et d’acceptation
Staging/Pre-prod : Une copie de la production pour les tests finaux par un groupe restreint d’utilisateurs, souvent du côté du client, avant le déploiement en production
Production : L’environnement de production
Utilisez l’Infrastructure as Code est une excellente pratique pour garantir que tous les environnements sont configurés de manière cohérente. Ça évite aussi qu’une configuration manuelle soit oubliée dans un environnement ou qu’une configuration essentielle soit omise ou différente entre les environnements.
18. Conclusion
Développer pour des environnements distribués n’est pas simplement une question de déploiement dans un fournisseur cloud ou dans des serveurs de l’organisation. Il faut penser à certains aspects spécifiques du développement pour s’assurer que l’application fonctionne correctement dans une architecture distribuée.
Ce petit guide couvre plusieurs des considérations les plus importantes, mais il en existe d’autres en fonction des besoins spécifiques de chaque application. Il n’est certes pas exhaustif, mais j’espère qu’il servira de point de départ pour ceux qui débutent dans le développement pour le déploiement distribué.
L’adoption de ces pratiques peut sembler lourde au début, mais elle apporte de nombreux avantages : meilleure scalabilité, résilience accrue, facilité de maintenance, et réduction des coûts à long terme. L’important est de commencer progressivement et d’adapter ces principes aux besoins réels de votre application.
Si vous voulez aller plus loin, les principes des 12-Factor App, une méthodologie bien établie pour construire des applications SaaS (Software as a Service) modernes est un bon point de départ.
Cet article fait partie du Advent of Tech 2025 @ Onepoint, une série d’articles tech publiés par Onepoint pour patienter jusqu’à Noël.
Voir tous les articles du Advent of Tech 2025