Les organisations sont de plus en plus nombreuses à opter pour DevOps afin d'accompagner leur transformation numérique. Mais savez-vous dans quoi vous mettez les pieds ? Voici une vision honnête et sans fard de ce qui vous attend, proposée par l'un des experts de CIO Etats-Unis.
Au commencement, il y avait le code et le développeur qui l'avait écrit. Les développeurs étaient responsables de tout. Ils concevaient la logique et appuyaient ensuite sur les boutons pour la faire fonctionner sur le serveur. Au fur et à mesure que les équipes se sont étendues et que le travail s'est différencié, cela a changé. Certains sont restés du côté du code (les devs) tandis que d'autres se sont consacrés aux machines (les ops).
Aujourd'hui, grâce au cloud et à l'avènement des microservices, les applications sont devenues une constellation de douzaines, voire de milliers de composants fonctionnant sur des machines séparées. Chacun des composants est techniquement indépendant, mais toutes les machines doivent travailler de concert. Pour s'assurer qu'elles y parviennent, la meilleure façon est d'utiliser des scripts automatisés. C'est là que DevOps entre en scène.
La mission principale de l'équipe DevOps consiste à fournir toute l'orchestration de haut niveau pour ces applications à multiples facettes. S'ils ont rarement besoin d'aller dans les recoins obscurs des architectures applicatives, ils doivent faire en sorte que toutes les parties marchent bien ensemble.
De plus, ce rôle demeure assez nouveau, avec des responsabilités qui ne sont pas forcément clairement définies et établies, et un panel de compétences encore en évolution. Certains pros de DevOps reflètent parfaitement la description du poste, en mêlant programmation et opérations, mais beaucoup d'équipes considèrent que le simple maintien en conditions opérationnelles des serveurs représente en soi suffisamment de travail. Configurer ces derniers requiert en effet de prêter une attention poussée aux détails, tout ceci alors même que l'équipe de développement continue de changer le code, et donc la façon dont il s'exécute.
Alors que davantage d'organisations se tournent vers DevOps pour accompagner leur transformation numérique, il est important d'avoir une vision lucide de la réalité. Voici quelques vérités peu connues sur ce domaine en pleine émergence qu'est DevOps.
Mettre en oeuvre DevOps n'est pas programmer - mais un peu quand même
Beaucoup de managers pensent que DevOps n'est pas de la programmation, et ils ont raison. Les métiers ont divergé et l'essentiel du travail consistant à manipuler des octets et des structures de données est assigné aux développeurs, qui vivent dans un monde d'abstraction différent. D'un point de vue stratégique, il est judicieux de décharger les programmeurs de la responsabilité de maintenir le bon fonctionnement des systèmes, car ils sont déjà plongés dans les méandres des architectures applicatives modernes.
Mais les membres des équipes DevOps doivent tout de même écrire des morceaux de code. Ils doivent toujours être capables de réfléchir de façon abstraite sur des structures de données cachées. Juste pour que tout fonctionne, il faut des lignes de commandes sans fin, qui peuvent généralement être regroupées et simplifiées dans des scripts shell. Même si certains puristes du code considèrent qu'il ne s'agit pas de programmation, malgré les appels de fonctions, les paramètres et les variables, en réalité ce travail nécessite beaucoup de compétences similaires à celles des développeurs.
Guider les développeurs est un travail à part entière
Même si les pros de DevOps n'écrivent pas le code, ils finissent toujours par gérer les programmeurs, et cela représente souvent quasiment autant de travail. Chaque développeur apporte sa pierre à l'édifice. Chacun veut mettre son conteneur en production immédiatement afin de pouvoir rayer cette tâche de sa liste. Est-ce que le code marche bien ? Ils en sont persuadés. Mais est-ce que tout ne risque pas de planter à terme ? Faire en sorte que les développeurs ne cassent pas ce qui marche est la grande avancée de DevOps.
DevOps prend peu à peu le dessus
Quand les applications étaient monolithiques, les programmeurs avaient entièrement le contrôle. Maintenant que les applications sont fréquemment découpées en douzaines, voire en centaines de microservices, la responsabilité de leur bon fonctionnement s'est déportée sur DevOps. Certes, il y a toujours des architectes et des développeurs qui décident de la façon dont les services vont communiquer entre eux, mais les pros de DevOps sont chargés de concrétiser ces interconnexions, ce qui représente une pièce de plus en plus importante du puzzle.
Nous ne comptons pas la petite monnaie
Les fournisseurs de cloud ont été malins quand ils ont choisi de tarifer leurs machines à partir de quelques centimes de l'heure. Qui ne possède pas un peu de petite monnaie au fond de ses poches ? Mais ces menues dépenses s'additionnent alors que le nombre d'instances cloud grandit, et l'on commence à compter les heures. Un mois de 30 jours représente 720 heures, et une machine qui coûte seulement 1 dollar de l'heure revient finalement à 8 760 $ (plus de 7 905 €) à l'année. Soudainement, acheter votre propre serveur commence à sembler meilleur marché.
Après avoir reçu quelques factures salées, certaines équipes nomment des auditeurs DevOps dont le seul rôle est de surveiller la prolifération des machines, afin de trouver des façons de faire des économies. Ils passent au crible les décisions en file d'attente, et commencent à dire non. Ils comptent le moindre centime car ils savent que c'est nécessaire pour respecter les budgets.
Il existe seulement quelques leviers pour booster la performance
Ce travail de gestion du cloud est d'autant plus difficile que l'équipe DevOps a souvent peu de leviers à sa disposition. Une fois que les programmeurs soumettent leur code et montent les conteneurs, le rôle de l'équipe DevOps est de faire fonctionner ces derniers. Si le code semble lent, ils peuvent tenter d'ajouter davantage de ressources virtuelles, des CPUs ou de la RAM. Si c'est toujours lent, ils peuvent encore ajouter davantage de machines dans le pod (groupe) afin de répartir la charge. Et c'est à peu près tout.
En coulisses, les démolitions s'enchaînent
L'un des enjeux méconnus provient du fait que les ordinateurs cherchent sans cesse à masquer leurs erreurs. Un jour, j'ai hérité d'une collection de conteneurs qui plantaient toutes les quelques heures. Peut-être était-ce dû à un échec de connexion à la base de données. Peut-être que cela venait d'un paramètre mal configuré. La réponse était sans doute enfouie au fin fond d'un fichier de log, mais je ne l'ai jamais trouvée. Kubernetes était suffisamment sympa pour démarrer une autre instance et le pod continuait de fonctionner et de répondre aux requêtes. C'était un bel exemple d'une architecture résistante aux pannes, même si en interne c'était un vrai bazar.
Parfois, sous la surface, les conteneurs et les instances n'arrêtent pas de planter. Néanmoins, tant que le travail est fait pour les utilisateurs et les clients, il est souvent plus facile pour tout le monde de regarder ailleurs et d'ignorer toute cette démolition virtuelle.
Les bases de données dominent le monde
Nous pouvons nous agiter sur le code maison, plaisanter en mettant un peu d'AJAX par ci, de CSS par-là, mais à la fin, toutes les données finissent hébergées dans une base. La base de données classique reste le soleil autour duquel le code orbite. C'est l'unique source de vérité. Si l'équipe peut la maintenir en état de marche, apte à répondre aux requêtes, l'essentiel du boulot est fait. Les utilisateurs peuvent tolérer quelques sections mal alignées ou des mises en page exotiques, pas des bases de données corrompues. Il m'est arrivé un jour de faire un audit de code pour une équipe qui utilisait les derniers packages Node.js, en mettant sans cesse leur stack à jour pour rester à la pointe. Mais la base de données avait plus de dix ans. Personne ne voulait y toucher.
Nous n'en savons pas plus que ce que nous voyons sur le fonctionnement du code
Aujourd'hui, le niveau d'instrumentation peut atteindre un niveau exceptionnel. Nous voyons les données gravir les différentes briques applicatives comme les marins sentent le vent monter. Au gré des fluctuations du nombre de pods, nous savons quand tout fonctionne bien et quand on s'approche des limites. Si nous sommes responsables d'une application d'e-commerce, nous serons les premiers à savoir quand les promotions font mouche, car la charge pour cette partie de l'application va grimper.
Mais l'instrumentation ne nous en dira pas plus que ça. Les nombres résument la charge moyenne et le temps de réponse pour chaque composant, mais sans donner d'explication. Il revient aux développeurs de savoir ce qui se passe à l'intérieur d'un composant. Seuls eux peuvent isoler des bugs et trouver des solutions.
Certains représentants des métiers aimeraient bien voir en nous une équipe tech toute puissante et omnisciente, capable de comprendre toute la pile de haut en bas. Même s'il existe quelques superhumains, dans beaucoup d'entreprises la tâche est trop grande, et les lignes de code trop nombreuses. Il est préférable de trouver une façon simple pour permettre aux équipes DevOps et aux développeurs de collaborer.
Au fond, tout reste un peu mystérieux
Les ordinateurs sont des machines totalement logiques, où le code évolue de façon prédictible et déterministe. Tout bug possède une cause. Nous pouvons dégainer les débuggeurs, parcourir les fichiers de log et passer le code au crible, mais qui a le temps ?
De la même façon que 90% des problèmes du support technique peuvent être résolus en éteignant et en redémarrant les terminaux, l'essentiel de DevOps revient à peu ou prou à faire de même. Certes, nous utilisons des mots comme « conteneurs » et « instances », et nous avons des tableaux de bord sans fin pour surveiller ce qui se passe, mais à la fin, il est souvent plus simple et rapide de passer l'éponge, et comme la chanteuse Iris Dement le suggérait, « de garder un peu de mystère ».
Comments