Docker, les questions à se poser pour se lancer dans le déploiement d'applications distribuées

Les applications distribuées sont souvent citées comme la panacée des architectures logicielles, mais la réalité est que ces solutions techniques ne sont pas adaptées à tous les usages. Elles excellent lorsque les solutions doivent supporter des changements d’exigences rapides, lorsque la performance et la capacité à monter en charge sont des critères de succès essentiels et lorsqu’un découpage fonctionnel est possible. Leur mise en œuvre à l’aide de conteneurs et en déploiement continu est une évidence, mais quelques points de réflexion préliminaire sont essentiels de façon à ce que cette étape ne vienne pas effacer les bénéfices de l’architecture distribuée.

Notre expert Jean-Philippe Gouigoux vous partage dans cet article les questions que nous devrions tous nous poser avant de nous lancer.

La taille des modules de déploiement est-elle adaptée ?

« Un conteneur, un processus » est une règle fondamentale que Docker pousse à respecter, mais encore faut-il que ce processus soit bien aligné avec un domaine de fonctionnalité correctement défini, respectant ainsi le principe de responsabilité unique.

Une approche de type Domain Driven Design permettra de s’assurer que les services sont bien découpés. L’utilisation de standards HTTP et métiers sur les API permettra également de définir une granularité correcte, gage principal d’évolutivité de la plateforme et de capacité à interopérer.

Les dépendances entre les modules sont-elles maîtrisées ?

Une fois les modules correctement découpés, une grosse partie du travail est réalisée car le plat de spaghettis qu’on constate souvent dans les monolithes ne se reproduira dans ces architectures distribuées que si le découpage est technique au lieu d’être fonctionnel.

Mais l’évolution de l’ensemble peut rapidement être contrainte si l’architecture introduit d’autres points de blocage, comme un middleware centralisé, un système d’authentification propriétaire, une gestion de la supervision contraignante pour les services, etc.

Le choix de l’orchestrateur est-il le bon ?

Le choix de Kubernetes paraît être une évidence pour toute application basée sur Docker, mais la complexité de la plateforme nécessite de se reposer la question d’approches plus simples. Si les tenants applicatifs nécessitent des centaines de conteneurs, que le déploiement doit être réalisé en cloud hybride, que les variations sont très fortes, alors il faut effectivement passer le pas et se former. Mais pour une application de gestion avec quelques dizaines de conteneurs et qui n’occupent que quelques serveurs, Docker Swarm est une approche simple et extrêmement efficace pour tous les besoins standards d’un orchestrateur.

Les fonctionnalités secondaires de l’application ont-elles bien été prises en compte ?

Gestion du multitenant, de la performance, de la robustesse, capacité de mettre à jour les versions à chaud, reprise sur incident, sécurité, etc. : toutes ces caractéristiques s’ajoutent au fonctionnement purement métier de l’application et ont un fort impact sur la façon dont l’application sera décomposée en services.

Des tests automatisés des conteneurs dans l’usine logicielle permettront de vérifier que des failles n’ont pas été introduites et que les nouvelles versions des services ne s’accompagnent pas de régressions. Une prise en main des fonctionnalités de rolling upgrade de l’orchestrateur permettra de limiter les surprises lors des premières mises à jour.

Peut-on vérifie opérationnellement que l’architecture fonctionne correctement ?

La meilleure architecture du monde peut très bien aboutir à un échec si elle n’est pas assez souple pour être ajustée. Et pour savoir comment il est nécessaire de l’ajuster, il est indispensable de savoir précisément ce qui se passe à l’intérieur.

Tous les conseils précédents ne serviront à rien si l’application distribuée et son déploiement ne sont pas étroitement surveillés par des mécanismes de supervision. La gestion des logs, le monitoring et les alertes à niveaux multiples doivent être inclus dès le début de la conception.

En conclusion

Si un conseil est plus important que tous les autres, c’est clairement de déployer dès les tous premiers sprints de conception de votre application distribuée.

Même si le contenu fonctionnel est ridiculement faible, montez un cluster Docker, quitte à ce qu’il ne contienne qu’un seul nœud ; automatisez tout de suite le déploiement de A à Z ; bref, investissez sur les outils dès le début pour que le gain de temps se cumule sur la totalité de la durée du projet. Aucune application n’est trop petite pour mériter d’être gâchée par un déploiement mal conçu et réalisé à la dernière minute.

Ingénieur en Génie des Systèmes Mécaniques (Université de Technologie de Compiègne), diplômé de l’université de Cranfield en Angleterre (Master of science, spécialité Advanced Automation and Design), Jean-Philippe GOUIGOUX est aujourd’hui directeur technique d’un groupe d’éditeurs logiciels métier.
Certifié TOGAF, il se spécialise en urbanisation des systèmes d’information et sait le valoriser à la fois dans son environnement professionnel avec la mise en place d’API normalisées permettant des intégrations puissantes et peu coûteuses, ainsi que dans le cadre de la recherche académique sur les architectures de micro-services.
Jean-Philippe GOUIGOUX est reconnu Microsoft MVP (Most Valuable Professional) dans diverses spécialités depuis 2011. Il intervient régulièrement en université ou lors de conférences sur des sujets informatiques variés tels que la gestion de données, Docker ou la performance en .NET. Passionné par le partage de ses connaissances, il est auteur de plusieurs livres et vidéos parus aux Éditions ENI.

Jean-Philippe GOUIGOUX

Notre expert sur Docker