1. Constat de départ
C’est un mot que l’on entend partout, du moment que l’on travaille dans l’informatique (ou pas très loin). C’est un terme qui a le vent en poupe et qui génère beaucoup de fantasmes. On en a même tiré un métier :
“Le devops”
Sauf que non. Ça n’existe pas, conceptuellement, le métier de devops. Le devops n’en est pas un, mais une philosophie de travail. C’est quelquechose qui vient se rajouter par-dessus un métier, qui vient en plus. C’est une nouvelle façon d’envisager ce métier, qui est soit développeur, soit administrateur ou technicien système (ou testeur/intégrateur éventuellement)
Devops est à comparer à agile. on ne dit pas de quelqu’un : “tiens, regarde, on vient d’embaucher un agile” :
un “agile”, ça n’existe pas.
Le devops est un changement de vision sur des métiers qui existent depuis longtemps et qui ont peiné à se réinventer jusqu’à arriver au point d’avoir des objectifs diamétralement opposés.
Les ops (équipes systèmes) ont pour vision la stabilité et la performance de leurs infrastructures. Une belle plateforme est une plateforme qui ne plante pas et qui rend efficacement et rapidement le service pour lequel elle a été définie. Toute évolution peut venir perturber ce fragile équilibre et cette harmonie difficile a trouver. La vision est au long terme. L’ops est pris entre les développeurs et les utilisateurs finaux de la plateforme. Si ça plante, c’est lui qui se fait engueuler.
Le développeur, quand a lui, a pour mission de faire évoluer la plateforme. Il doit suivre les besoins marketing pour créer de nouvelles choses qui feront grandir l’entreprise. On lui donne, de plus, bien souvent peu de temps pour réussir à créer ces nouvelles fonctionnalités, ce qui se traduit souvent par des choses livrées et mal finies. Ces choses mal finies mettent en péril la stabilité de la plateforme si chèrement pacifiée par les ops, ce qui les rend d’autant plus méfiant à l’idée d’intégrer des nouveautés. Les dev deviennent donc une source d’instabilité pour les ops autant que les ops sont un frein à la mise en production du travail des dév.
Un mur se dresse donc entre ces deux métiers. Il faut l’abattre. La philosophie devops part de là.
2. Définition
Les 4 piliers dun devops : **le CAMS**
C pour CULTURE
Le devops est avant tout une culture qui se nourrit de ce qu’il y a de mieux dans les cultures de développement et d’exploitation. On prend le meilleur des deux mondes et on en crée un nouveau qui tiendra compte des spécificités de chacun de ceux dont il est issu.
Le devops tend à créer une culture d’entreprise autour de ce qui en fait sa richesse.
A pour AUTOMATISATION
Tout ce qui peut être automatisé doit l’être. Les actions humaines génératrices d’erreurs, sur lesquelles on ne capitalise pas (en plus!) sont à proscrire. A quoi bon écrire un process qui sera joué par des humains ? Autant directement écrire des scripts et utiliser des outils qui feront le travail sans nous. Nous aurons tout le loisir de faire évoluer itérativement ces scripts/outils en les améliorant à chaque fois.
On fera également gagner du temps aux équipes en leur supprimant le travail rébarbatif et pour lequel les membres de l’équipe ont peu d’intérêt/de valeur ajoutée, les laissant intervenir sur les périmètres où ils/elles sont les plus efficaces.
M pour MESURER
Faire tourner des applications en production sans savoir si elles tournent vraiment et sont efficaces se résume à faire de la magie sans pour autant maitriser quoi que ce soit. On est à la merci d’à peu près tout ce qui peut arriver (parfois, on n’est même pas au courant que celà disfonctionne) et condamnés à réagir en catastrophe à tout ce qui n’est pas prévu.
En plaçant les bonnes sondes et récupérant les bonnes métriques, on peut anticiper les problèmes à venir et connaître les points à améliorer pour la bonne performance des applications.
S pour PARTAGER (Share en anglais)
Un des axes importants du devops tient dans le fait que rien ne se fait tout seul (c’est d’ailleurs pour celà que ce n’est ni un métier, ni un rôle d’équipe). En effet, le but avoué de la démarche est de mettre en commun les compétences des uns et des autres pour atteindre le but commun, qui est de fournir le meilleur produit possible.
Il n’y a pas de “chasse gardée” d’une équipe ou d’une personne. Le partage des compétences inter-équipe tend à amener les gens à développer un langage commun, une intelligence collective, et donc, une culture commune.
Pourquoi conserver des méthodes qui ne marchent pas ?
3. Le devops : la recherche d’efficacité
Au travers des éléments cités, on se rend compte que la philosophie devops est principalement une recherche d’intelligence collective. Dans la même veine que les méthodes agiles, le but est de rendre plus propre et plus efficace la création d’application et leur maintenance en prenant dès le début des projets l’ensemble de leur cycle de vie en compte avant d’écrire la moindre ligne de code ou de configuration.
On se demande souvent pourquoi les applications développées par les grandes structures publiques ont souvent des résultats décevants au moment de leur mise en production. Le principal problème est à chercher dans les communications inter-équipes qui sont défaillantes, voire totalement absentes. Comment arrive-t-on à produire si mal avec autant de bons développeurs, chefs de projets et équipes d’infrastructure ? Comment faisons-nous si peu avec des budgets pharaoniques ? Comment des start-up de quelques dizaines d’employés au maximum deviennent-elles des licornes qui ridiculisent des grosses entreprises ?
La communication
Les équipes sont trop grandes, trop éparpillées, et du coup, pas assez concernées. Les uns découvrent trop tard les modifications/spécifications des autres et doivent s’adapter avec des solutions bancales voire des annulations de fonctionnalités importantes.
Pour introduire une peu de “devops” dans tout celà, il faut obligatoirement réduire les périmètres et intégrer directement des équipes multidisciplinaires. Et comme chacun sait, une start-up aura toujours plus de facilité qu’une grosse structure à atteindre ce but.
4. Les outils devops
Qui dit “bonnes méthodes” implique également d’y associer les bons outils. L’écosystème est riche, les concepts nombreux et la concurrence rude. Il faut donc choisir d’abord ce que l’on veut faire avant de choisir avec quel outil. Tout ceci nécessite une certaine expérience, et donc les profils devops junior n’auront souvent pas le recul nécessaire pour pouvoir faire plus qu’une wishlist des technos avec lesquelles ils aimeraient jouer. (lire mon article L’enfer du recrutement des profils DevOps)
L’infrastructure as code semble un bon point de départ à comprendre pour mieux appréhender les concepts du devops, et de l’infrastructure plus ou moins managée ou virtualisée des différents clouds.
Les clouds, ou “l’ordinateur de quelqu’un d’autre” sont aussi une recherche d’efficacité, car cela évite d’avoir les compétences systèmes bas niveau, en se concentrant sur le l’infra as a service ou l’on paye pour des compétences que l’on n’a pas. A partir d’une certaine volumétrie, acquérir ces compétences évitera cependant de voir ses facture de cloud exploser (AWS est notamment assez opaque sur ses factures et frais). Les facture de cloud à 5 voire 6 chiffres peuvent arriver assez rapidement.
La CI/CD est constituée de
- L’intégration continue (CI)
La CI est l’intégration du code jusqu’à l’application compilée/définitive. C’est la gestion des branches et des tests sur ces branches pour valider que le code est propre et l’application fonctionnelle. Une chaine de tests sera appliquée sur le code pour en faire l’application. La cible de la CI est Le livrable
- Le déploiement continu (CD)
La CD est le déploiement automatisé de ces applications sur des environnements, qu’ils soient de test ou de production. On transforme une application en service via des scripts ou de la configuration d’infra. l’infra système pourra même être crée à la volée avec les besoins applicatifs. La cible de la CD est L’application en fonctionnement dans une environnement défini
5. Conclusion
Devops n’est pas un métier. Devops n’est pas un rôle. Personne ne porte la casquette de devops comme personne ne fait de l’agilité tout seul. C’est une philosophie d’équipe et une recherche d’efficacité. Il existe de nombreux outils, mais qui ne servent à rien sans les concepts qui les portent. Utiliser les outils sans se soucier des besoins qui les ont créés revient à mettre un enfant de 5 ans au volant d’une voiture: il saura appuyer sur les pédales, tourner le volant, mais cela risque de se terminer en un coûteux crash…
A l’inverse, trouvez la bonne carte, voir le bon GPS et vous irez très loin en un minimum de temps !