Si vous voulez faire évoluer vos pratiques et en tirer des bénéfices, vos outils doivent être à la hauteur
Quand j’ai commencé à travailler dans les années 2000, les dinosaures dominaient le monde les projets étaient en train de changer. Grâce aux tests automatisés, à l'extreme programming et aux nouveaux outils qui arrivaient comme les serveurs d’applications et Subversion, on allait apprendre à développer mieux et plus vite.
Les middlewares d’entreprise faisaient partie des points qui posaient problème : ils étaient lourds et inadaptés à nos nouvelles manières de travailler, et ont commencé à devenir des goulets d’étranglement.
Presque 15 ans plus tard, avec les pratiques agiles et le devops, le monde du développement a bien changé. Malheureusement, ce n’est pas le cas pour un certain nombre d’outils : ils ont enrichi leurs fonctionnalités, mais ne se sont pas transformés.
Parfois non industrialisables, non testables ou difficiles à intégrer dans votre SI : ces outils peuvent désormais constituer un vrai frein pour votre capacité à faire. Un environnement technique est toujours nivelé par le bas : le plus mauvais outil dicte ses contraintes à toute la chaîne, du développement à l’exploitation. L’utilisation d’une seule mauvaise brique peut donc avoir des conséquences très lourdes.
S’il est parfois possible de contourner ces restrictions, cela nécessite souvent des rustines fragiles. Rappelez-vous que les outils sont sensés vous aider et non se mettre sur votre route pour vous empêcher de travailler. Avec ces logiciels souvent très complexes, on pense surtout aux fonctionnalités qu’ils promettent et on oublie souvent leurs inconvénients alors que ceux-ci sont pourtant très importants.
Prendre conscience des différents types de limitations peut vous aider dans deux situations :
En revanche, cet article ne vous aidera pas à savoir si ce genre d’outil est encore nécessaire, il s’agit d’un autre sujet qui mérite d’être traité à part.
C’est un groupe aux limites assez floues mais qu’on peut délimiter par un certain nombre de caractéristiques :
Les exemples les plus caractéristiques sont les middlewares d’entreprise : appliances de sécurité, brique de transfert de fichiers, bus de messages, bus d’entreprises, ETL, outils d’API management et appliances de sécurité. De nombreuses autres briques logicielles suivent tout ou partie des mêmes règles, par exemples les serveurs d’applications ou les base de données.
Les logiciels d’entreprises sont un des domaines où les logiciels propriétaires sont encore très représentés. Selon les pratiques des éditeurs, cela peut avoir des conséquences sur leur utilisation.
Nous comprenons que l’éditeur veuille s’assurer que ses logiciels soient dûment utilisés, mais il faut que cela soit fait proprement.
L’idéal est un fichier de licence fixe à copier sur les serveurs, que cela soit un fichier unique ou un fichier par environnement : avec des outils de déploiement, il n’y a pas de dégradation par rapport à un outil ouvert.
La capacité des outils de middleware à être élastique est maintenant souvent mise en avant (et on en reparlera plus bas). Si ce sujet est important pour vous, vérifiez que l’ajout de nœuds dans un cluster ne nécessitera pas de changer en même temps le fichier de licence dans chacun des serveurs, y compris les serveurs existants.
Depuis que les dongle matériels ont quasiment disparu, la pire situation est un "serveur de licences" que l’outil appelle pour valider sa licence.
Deux cas se posent.
Le prix est d’abord un critère de choix pour sélectionner la solution, mais il peut aussi avoir des conséquences sur son utilisation.
Si le prix est payé par serveur ou par processeur, vous aurez intérêt à diminuer le nombre d’instances pour économiser. Il en résulte souvent une tentation de mutualiser les serveurs au-delà du raisonnable. Le cas qu’on rencontre couramment est celui des serveurs d’applications Java. Les limitations du modèle J2E font que — malgré ce qu’en disent certains éditeurs — utiliser un seul serveur pour plusieurs applications pose beaucoup de difficultés : ressources non isolées, fuites mémoires… Les utilisateurs qui ont le choix utilisent systématiquement un serveur par application, les seuls qui mutualisent leurs serveurs sont ceux qui le font pour limiter leurs coûts de licence, et leur système est moins fiable en contrepartie.
On peut aussi être amené à mutualiser les environnements : en fonction de la pression sur les prix, on mutualisera les serveurs de plusieurs environnements au lieu de les isoler.
Les problèmes que cela pose dépendent de la manière dont la mutualisation est mise en œuvre :
Être forcé d’utiliser deux outils
Pour des raisons de coûts, il est parfois nécessaire d’utiliser deux outils différents. Cela peut arriver dans deux cas.
Cette approche repose sur l’idée que, pour les besoins les plus importants, seule peut convenir une solution vendue par un grand éditeur. Il s’agit d’une survivance des années 2000 où les solutions open source ou vendues par des petits éditeurs étaient souvent moins avancées, et leur support réputé moins fiable. Étant donné le prix de la solution critique, il n’est malheureusement pas possible de l’utiliser partout. Il est donc nécessaire de choisir une deuxième solution pour les autres besoins, ce qui complexifie votre système et augmente son coût.
Si, pour certains éditeurs, les licences ne sont nécessaires que pour la production, pour d’autres, il en faut une pour tous les serveurs. Même si les prix sont alors souvent dégressifs en fonction de l’usage, par exemple les instances de recette à moitié prix, cela peut vite faire monter l’addition quand les environnements se multiplient.
La solution alors choisie est d’utiliser l’outil propriétaire pour la production et la pré-production, et un outil open source pour les autres usages, du développement à la recette. Cela se voit beaucoup pour les serveurs d’application Java, et parfois pour des bases de données SQL.
Cela ajoute des bugs supplémentaires qui sont à corriger par l’équipe, bugs détectés très tard dans le cycle du projet et qui ne peuvent pas être testés avant la pré-production.
La qualité de service attendu des systèmes a beaucoup monté ces dernières années, et par conséquent les prérequis en termes d’architecture.
La haute disponibilité fait désormais partie des fonctionnalités standard exigées des produits, mais une subtilité est tout de même à vérifier : dans le cas où, en plus des serveurs d’exécution, existe un serveur d’administration, celui-ci peut ne pas être en haute disponibilité. Même si la criticité est moindre (quand le serveur d’administration est indisponible, le système devrait continuer à fonctionner le temps qu’il soit réparé), il s’agit tout de même d’un point de fragilité.
L’autre élément à examiner est la scalabilité. Même si on parle beaucoup d’élasticité, on a rarement besoin d’ajouter ou de supprimer des instances à tout bout de champs. Par contre une augmentation de trafic peut nécessiter d’ajouter une instance d’ici quelques mois et il est important d’en connaître les impacts.
Si beaucoup de produits revendiquent désormais cette propriété, certains prennent des libertés avec sa définition courante : selon les outils, changer le nombre d’instances peut se faire à chaud et être totalement transparent, diminuer les performance pendant le rééquilibrage de données, voire nécessiter un arrêt complet.
Pour l’hébergement, la virtualisation est désormais la règle. Un logiciel qui nécessite d’être hébergé sur du bare metal aura donc besoin d’une bonne raison pour cela. Encourager l’utilisation du bare metal pour gagner des performances est un chose, la forcer en est une autre.
En dehors de quelques systèmes de niche (sécurité, très haute performance), les appliances physiques sont désormais une espèce disparue et avec elles, le besoin de déplacer et de recabler des serveurs quand une configuration changeait. Le remplacement par des appliances virtuelles supprime la contrainte physique, mais pas les autres :
Il s’agit donc toujours d’un pis-aller.
En cas d’appliance logique :
L’avenir dans ce domaine est probablement d’aller vers du Docker : l’éditeur gardera la main sur l’installation et les projets.
Pour l’installation, l’outil doit être fourni sous forme d’un package adapté à votre distribution (deb, rpm…). Pour être facilement exploitable, le mieux est de respecter la norme LSB : par exemple, vous trouverez facilement les différents fichiers.
Pour la configuration du socle du logiciel, des recettes de déploiement type Chef / Puppet / Ansible sont désormais la norme. S’ils sont fournis pour un outil qui n’est pas celui que vous utilisez, le portage ne devrait pas être compliqué à condition que l’éditeur ait bien fait son travail.
Pour être facilement utilisables, les fichiers de configurations doivent respecter certains critères :
Sur le papier, une des fonctionnalités les plus mises en avant des middlewares d’entreprise était un outil graphique permettant d’utiliser le logiciel sans recourir au terminal ou éditer de fichiers.
Si ce but est louable, la manière dont il est souvent mis en pratique pose problème.
D’abord, sous prétexte de ne pas avoir besoin d’éditer de fichiers, les fichiers générés par ces outils sont souvent des fichiers binaires. Il est donc impossible d’éditer les fichiers directement et tout doit passer par l’éditeur fourni. Tous les workflows automatiques reposant sur la capacité à modifier des fichiers textuels sont inapplicables, comme le report de modifications entre branches via un outil de gestion de version ou entre environnements via un outil de déploiement. Remplacer ces opérations qui s’automatisent facilement par des opérations manuelles coûte du temps et présente des risques : vous pouvez dire adieu à votre pipeline de déploiement automatisé et bonjour aux régressions.
Il reste possible de s’en sortir en utilisant un outil comme Selenium ou Sikuli pour piloter la saisie de la configuration dans l’outil graphique, mais il s’agit d’une approche coûteuse et fragile à n’utiliser qu’en dernier ressort.
Ensuite les outils utilisant cette approche sont conçus pour être utilisés par une seule personne à la fois. Dans les organisations où un groupe de personne bien identifié est en charge de chaque outil, cette limite est acceptable. On fait une demande à l’équipe en question, qui s’en charge dès qu’elle le peut, en jonglant entre les priorités et ses ressources souvent limitées. Avec le raccourcissement des cycles de développement, ce type de fonctionnement devient invivable : tout est fait pour limiter les dépendances entre équipes et favoriser l’autonomie des équipes. Ce type d’outil devient donc inadapté : pas question de devoir réserver son tour pour avoir le droit de configurer un outil. Les middlewares étant souvent transverses, impossible non plus d’avoir une instance par équipe.
Pour les outils ne fournissant que de l’infrastructure, des tests d’intégrations sont suffisant. En revanche, les outils embarquant du code ou du pseudo-code comme les ESB doivent fournir des fonctionnalités permettant d’écrire des tests unitaires automatisés. Ces tests doivent pouvoir se greffer dans votre usine de build, c’est-à-dire :
Derniers prérequis : l’exploitabilité de la solution. Sur les outils d’entreprise, l’outil graphique de configuration dont on a parlé plus haut s’accompagnait souvent d’une console d’administration intégrée. Celle-ci fournissait du monitoring et des logs centralisés à une époque où ils étaient encore l’exception. Ce n’est plus le cas désormais, et malheureusement — comme pour la configuration — quand on choisit de ne pas utiliser l’outil fourni pour regarder sous le capot, les choses ne sont pas si rose.
L’application doit pouvoir se monitorer aussi facilement que les autres briques de votre SI :
Pour être utile, un log doit être accessible et lisible et s’intégrer dans votre chaîne de traitement existante, ce qui nécessite :
Gardez espoir
En lisant cet article vous risquez un coup de blues, surtout s’il vous rappelle des souvenirs. Rassurez vous, la situation n’est pas si terrible et elle a même tendance à s’améliorer :
Pour les logiciels plus anciens, la situation est plus sombre. Au cœur des SI, ils sont difficiles à remplacer, et les éditeurs le savent. Ils font donc peu d’efforts pour faire évoluer leurs produits sur ces sujets. Pour améliorer les choses, la meilleure manière sera d’introduire un nouvel outil, souvent par le biais d’un besoin incompatible avec le système existant, puis de travailler à réduire l’emprise de l’outil historique.
Des outils de middleware peuvent être un vrai frein pour votre capacité à livrer mieux et plus vite. Lorsque vous choisissez un tel outil, il faut absolument vérifier ces prérequis :