Plutôt que de vous expliquer ce qu'est DevOps, je vais vous donner l'objectif ultime de DevOps. C'est d'arriver à faire une dizaine de déploiements par jour. Si vous êtes sur un projet standard, vous faites un déploiement toutes les semaines si ça se passe bien et tous les 6 mois si ça se passe mal. Là, l'objectif est d'en faire plusieurs dizaines par jour. Pourquoi ? Ca permet de mettre en production des fonctions beaucoup plus rapidement et d'augmenter la satisfaction des utilisateurs.
2. Et donc tu es venu à DevOps petit à petit ? Quelle est ton histoire autour de DevOps ?
J'ai commencé par faire du code, j'étais développeur, et puis il y avait des problèmes en production, il y avait des bugs qu'on n'arrivait pas à reproduire. Tout ça m'a incité à travailler sur la mise en place des plateformes, leur déploiement, sur tous les outils qu'il y a autour pour essayer d'améliorer cette situation là et ça m'a naturellement conduit vers DevOps.
Le dernier en date, on a mis en place une usine d'intégration complète pour déployer une plateforme de Cloud, on avait un déploiement complètement automatisé de toute la plateforme. Des environnements de développement jusqu'aux environnements de production, c'était exactement le même système qui permettait de tout déployer. Autant sur le déploiement pur, que sur le plan release management, c'est à dire gestion des différentes versions des applicatifs, on avait une vingtaine d'applicatifs dans à peu près toutes les technos possibles, il y avait du java, du ruby, du php. On avait un environnement de développement complet, full automatisé, et géré en version.
4. D'autres aventures autour de DevOps dans ta petite histoire ?
On nous a demandé une fois de faire des tests de performance, sur du client lourd. Il fallait instancier X machine qui simulaient chacune un client. Et on voulait en simuler 400 ou 500, donc il fallait déployer 400 ou 500 machines. Cela implique un niveau d'automatisation et de configuration assez poussé, donc on a fait ça sur du cloud évidemment, c'était assez amusant.
5. Quelles sont les grandes lignes de DevOps ?
Un des premiers pans de DevOps, c'est "infrastructure as code", c'est à dire qu'on voit vraiment tout ce qui est infrastructure, déploiement et configuration des socles, comme du code ! Autant au point de vue gestion de version, c'est quelque chose sur lequel on va pouvoir faire des tests, c'est quelque chose qui va être reproductible. Au point de vue hard, on va pouvoir descendre le plus loin possible pour automatiser, au plus près du hard.
6. Donc plus de manipulation de machine en temps réel ?
Non, DevOps est venu du mur qu'il y a historiquement entre les équipes Opérations et les équipes Développement. Les équipes Opérations ont et auront toujours pour objectif d'avoir un truc qui marche, donc un objectif très fort de rationalisation. Alors que les équipes Développement, leur objectif, c'est de livrer au plus vite des fonctionnalités au client, donc un objectif d'innovation. Forcément, avec deux objectifs aussi différents, ça crée pas mal de frictions. DevOps travaille autour de ça pour réduire la fracture entre les équipes, et faire en sorte que ça livre plus vite.
7. Donc partage d'outils j'imagine ?
Entre autres, partage d'outils mais aussi partage de connaissances, et de façons de faire, d'habitudes de travail. On ne va pas juste automatiser le déploiement, on va faire en sorte que les développeurs fassent des opérations, et que les opérations fassent du développement. Par exemple, on va demander aux développeurs de fournir des métriques de monitoring pour son applicatif, pour ainsi pouvoir mieux monitorer son application en production.
8. Avant c'était fait comment ?
Avant, il y avait deux mondes séparés, c'était le monitoring système qui était fait par les équipes Opérations, mais qui est très bas niveau. Cela va remonter RAM, Cpu, Disque. Et il y avait un tout petit peu de monitoring applicatif, qui était fait en général par d'autres outils, et d'un point de vue purement applicatif. Alors qu'en fait, on a tout intérêt à rassembler les deux mondes, pour avoir toutes les métriques concernant l'application exactement au même endroit, pour pouvoir les corréler et voir ce qu'elles donnent ensemble.
9. Quels sont les axes de transformation pour rapprocher les Dev et les Ops ?
Le premier axe, est de les faire se parler. Ce qui est déjà souvent un sujet important. Comme je l'ai expliqué tout à l'heure, ils ont deux objectifs tout à fait différents, donc il faut qu'ils arrivent à se parler. Après, une fois qu'ils arrivent à se parler, il faut qu'ils arrivent à se transférer des responsabilités. C'est à dire que les opérationnels vont être moins responsables du déploiement, ce qui va être géré en partie par les équipes de développement. Et les équipes de développement vont être moins responsables de tout ce qui est configuration des socles parce que ça va être géré par les opérationnels. Donc on a une sorte de transfert et une re-répartition des responsabilités entre les deux groupes à faire.
10. Et ça marche bien, ça parait assez logique comme répartition ?
Ca dépend complètement des cultures. Vous avez par exemple des endroits où les opérationnels sont des gens qui pour déployer une application attendent un cahier d'installation de 40 pages d'opérations manuelles. Quand vous leur dites "on ne va plus faire comme ça, on va automatiser", on remet carrément en cause les fondements de leur boulot, donc c'est très très compliqué.
11. Ca prend du temps, c'est possible ?
Ca dépend des contextes, en général ça prend du temps. Par contre, à la fin tout le monde est très très content, mais ça passe par des phases de douleur. On peut noter qu'on a exactement la même chose de l'autre côté. C'est à dire qu'un développeur, quand on va lui dire "tu ne te contentes plus de développer, mais tu vas aller voir ce qu'il se passe en prod et tu vas débuguer en prod", ça lui fait bizarre. Faut qu'il apprenne des outils avec lesquels il n'a pas du tout l'habitude de travailler, faut qu'il apprenne d'autres choses, qu'il apprenne du réseau, de la performance, du système. Cela lui fait bizarre aussi ! Donc, les deux côtés doivent changer, doivent évoluer dans leur mentalité. Cela fait évoluer leur boulot pour qu'ils fassent autre chose. Donc c'est assez compliqué.
En fait, si on veut livrer 10 fois par jour, ça veut dire que les tests de recette, ils doivent être complètement automatisés, parce qu'on ne peut pas faire 10 recettes manuelles par jour. On doit pouvoir livrer l'ensemble en production avec juste des tests automatisés qui viennent de passer. Cela nécessite de travailler énormément sur les tests, de manière à ce qu'ils soient super fiables, et surtout que l'ensemble des équipes impliquées aient confiance dans ces tests.
13. Il y a des gens qui y arrivent ?
Puisqu'il y a des gens qui font 10 déploiements par jour, oui, il y a des gens qui y arrivent.
Oui, tout dépend de là où on part, des fois je suis intervenu dans une équipe où même faire des tests automatisés, c'était déjà une révolution. Donc, faire des tests automatisés qui couvrent la totalité du périmètre et qui sécurisent suffisamment pour faire une mise en production, c'est encore autre chose. Parce que là on touche en plus à de l'humain. C'est à dire que dans pas mal d'équipes, il va y avoir un chef, un manager, un release manager, un chef de projet, qui vont dire "Oui, on y va, go, on peut mettre en production". Là c'est un système automatisé qui passe des tests, qui va le dire, donc il y a un côté perte de contrôle à ne pas négliger. Et ce frein humain peut mettre un projet "DevOps" en échec.
C'est ça, c'est à la fois l'avantage et l'inconvénient des tests automatisés. Les tests automatisés, quand ils sont verts, on sait qu'ils sont verts, par contre est-ce qu'ils couvrent tout ou pas ? C'est un autre problème. Mais effectivement, les tests automatisés, normalement c'est quelque chose qui est reproductible, c'est un juge de paix. Soit ils sont verts, soit ils sont rouges. Il n'y a plus de "Oui, alors ce use-case là il passe à peut près sauf dans ce cas précis...", non, soit les tests sont verts, soit ils sont rouges.
16. C'est un gros changement culturel sur la base de tests à avoir ?
Le changement n'est pas forcément énorme, parce qu'il y a quand même beaucoup d'équipes actuellement qui font pas mal de tests. Par contre, il va falloir les faire évoluer ces tests, parce qu'on va vouloir tester pas seulement le code. On va vouloir tester toute l'infrastructure. C'est à dire qu'on va vouloir par exemple tester qu'une nouvelle architecture tient toujours, qu'elle fonctionne toujours et qu'elle permet de faire fonctionner l'application, que l'introduction d'un nouveau composant ne casse rien. Il y a pas mal d'équipes pour lesquelles les tests sont restreints, donc il va falloir élargir ces tests, pour leur faire intégrer par exemple la plateforme. Pour que ça teste l'ensemble de la plateforme, c'est à dire : le déploiement, l'infrastructure et l'applicatif. Donc ça fait élargir ces tests, mais on ne fait que continuer des systèmes de tests automatisés qui existent depuis longtemps. Il n'y a pas tellement besoin d'autre chose qu'actuellement. En fait, c'est très très simple, on va se mettre à la place de l'utilisateur final, et on va tester comme lui. C'est exactement comme on fait sur l'applicatif, mais on va le faire sur l'ensemble de la stack, de l'infra jusqu'au plafond.
On peut livrer plus souvent, donc on va avoir tendance à faire des livraisons qui sont plus petites, on livre une correction de bug ou une toute petite feature. Donc on va casser l'effet BigBang, parce que quand vous faites une mise en prod tous les 6 mois, en général c'est quasiment une version majeure avec son lot de correction de bugs, et son lot de nouvelles fonctions. Et là on va faire des micro releases à chaque fois pour limiter le risque et la compléxité de la mise en prod.
18. Et ça impacte la manière de développer finalement ?
Oui, pour prendre un exemple, quand vous faites du DevOps, vous êtes complètement obligés d'automatiser ce qui est gestion des schémas de la base de données, c'est quelque chose qui doit être quasiment built-in, et livré avec le code. Vous devez livrer vos schémas de base de données avec le code. Donc, il faut que les développeurs apprennent à faire ça et livrent le schéma avec le code, et leurs évolutions bien-sûr. Après, le niveau 2, c'est leur demander de décorréler les deux ! C'est à dire, en production si vous avez un cluster de 50 machines, vous ne pouvez pas garantir que les mises à jour se feront en même temps sur les 50, donc votre code devra être compatible quelque soit la version du schéma de base de données, qui est sur la base de données derrière. Donc ça a des impacts assez lourds sur les façons de développer, mais tout ça c'est dans l'optique de livrer plus vite, et ça force les développeurs à s'intéresser aux problématiques purement opérations, qui avant leur étaient masquées.
Oui, de nos jours tout va très très vite, il faut pouvoir déployer des nouvelles fonctions en production très très vite. Si vous regardez ce qu'il se fait autour du Lean Startup, on va pouvoir faire de l'AB Testing pour voir si telle fonction marche sur telle population d'utilisateurs, ou pas. Pour pouvoir faire de l'AB Testing, il faut tous les outils qui vont avec, et tous ces outils là sont des outils qui viennent de DevOps. Pour pouvoir déployer sur telle grappe de serveurs telle fonction, ou pour pouvoir segmenter les populations d'utilisateurs. Très très souvent, ce sont des outils qui viennent du monde de DevOps.
20. Ils se sont nourris l'un de l'autre ou l'un est né avant l'autre ?
Ils se nourissent les uns des autres. Un autre exemple est la culture de la mesure qui est très présente dans le monde des DevOps qui a infusé dans les deux sens avec Lean Startup. Avant de commencer quoi que ce soit en développement, on va vouloir savoir ce qu'on attend, on va chercher à quantifier un résultat avant de faire le développement, on va mesurer ce qu'on a obtenu pour voir si on est conforme à ce qu'on attendait ou pas, et pouvoir prendre des décisions. Cela tranche avec le système habituel où on dit "on va développer ça parce qu'on pense que les clients en ont besoin". Non, on va développer un MVP (Minimal Viable Product) et on va mesurer pour voir si ça correspond aux attentes. Et tout ça est rendu possible par l'outillage et tout ce qu'il y a autour de DevOps, et notamment tout ce qui est outils de graphing et analytics, qui s'intègrent très facilement.
Oui, c'est un univers qui est en pleine effervescence, il y a quasiment un outil nouveau tous les jours. Il y a des grandes catégories d'outils, comme tout ce qui est gestion de version comme Git, tout ce qui est config management Chef, Puppet, CFEngine.
22. Tu peux les présenter en 2/3 mots ? Car ces outils là ont l'air d'être au coeur de DevOps.
Alors, ces outils contribuent fortement à tout ce qui est Infrastructure as Code, par contre, ce ne sont pas du tout ces outils là qui vont vous aider à transformer vos équipes et faire évoluer les mentalités. Il ne faut pas se tromper de cible. DevOps, ce n'est pas l'automatisation des Ops. DevOps, c'est "on fait parler les devs avec les ops", et on utilise les valeurs de chacun au mieux. Donc, tous les outils Chef, Puppet, CFEngine, vont vous permettre de déployer vos socles applicatifs, vos serveurs de production, de manière automatisée.
23. Derrière des outils plutôt Ops, il a d'autres outils, plutôt Dev ?
Les devs apportent toute leur science de faire du logiciel et du release management, c'est à dire la notion de branche, la notion de taguer les versions, de faire du report entre branches, la notion de tests. En fait, pour arriver à faire des mises en production très rapprochées, vous devez pouvoir faire ça sur tous les environnements, c'est à dire que votre version avant de passer en prod, elle doit pouvoir passer en pré-prod, et en recette, et pour chacun de ces environnements, les tests vont passer. Mais pour ça, vous devez avoir un système de release management, basé sur du Git ou un outil équivalent, c'est quelque chose qui vient du dev. Mais cet outil va devoir piloter tout ce qui est ops. C'est à dire, piloter la création d'une machine virtuelle s'il faut mettre à disposition des environnements, créer les OS, configurer les OS et déployer les socles. Donc les développeurs apportent toute leur science de faire du release management pour les mettre au service des outils communs pour déployer les plateformes.
De tous les cas que j'ai vus, ça se construit de manière incrémentale. On ne va pas dire du jour au lendemain : "Je vais faire du DevOps et je vais avoir le système parfait du jour au lendemain". Pas de Big Bang, on commence par une petite partie, par exemple on peut dire, plutôt que de faire un déploiement sur une plateforme X à la main, je vais les faire en automatisé. On va scripter l'automatisation du déploiement de l'application. Après, on va enrichir les tests unitaires, on va rajouter des mesures business qui vont remonter dans le monitoring. Et tous les projets que j'ai vu arriver à terme, ce sont des projets où il y a eu des petits incréments sur les méthodes de développement.
25. Cela prend du temps, il faut être patient ou ça peut aller vite ?
C'est une question de culture, ça dépend du legacy, ça dépend de quoi vous partez. Si vous partez d'une feuille blanche, évidemment vous allez pouvoir mettre en place les outils beaucoup plus facilement. J'ai vu des endroits où on partait d'une feuille blanche avec une culture du management très "à l'ancienne" où ça a été très très compliqué. Pas du tout pour des problèmes techniques mais pour des problèmes de décision, qui prend les décisions, comment on met en prod, quels sont les cycles de release management. Les difficultés ne sont pas forcément où on les attend. En général, les difficultés liées aux outils sont assez facilement contournables. Les vrais problèmes sont des problèmes humains et des problèmes de relation.
26. Donc un chalenge culturel, mais comment on accompagne ces personnes là (Managers à l'ancienne) ?
Il faut être avec eux, il faut les écouter, il faut être à l'écoute de leurs douleurs. Dans une équipe, pour la faire passer à DevOps, on lui demande "où est-ce que tu as mal ?". Et très très souvent, en traitant ces douleurs, on va ourvir la porte à DevOps et ses pratiques d'automatisation.
27. Des petites anecdotes, des surprises ?
C'était il y a 6 ou 7 ans, c'était il y a très longtemps, le mot DevOps n'existait même pas. J'avais mis en place dans le monitoring système, une mesure Business, une seule. Et je me suis aperçu au bout de 3 semaines / 1 mois que tous les mecs du métier suivaient cette courbe là. C'était le nombre de commandes prises par jour, c'était vraiment une métrique, c'est là que je me suis rendu compte que les métriques CPU/Ram/Disque c'est bien, mais que les métriques métier "Nombre de commandes par jour", c'est encore mieux.
28. Et ça on les a très près du code, ça ne vient pas naturellement ?
En général, les développeurs ne pensent pas que les opérations ont déjà tous les outils pour collecter tout ça, et ils ne font pas le pas qui généralement est super simple techniquement pour pousser ces informations vers les outils de monitoring ops, et de la même façon les métiers ne vont pas voir les outils de monitoring ops. C'est pareil, on a une espèce de mur entre les deux où chacun a ses petits outils d'un côté alors qu'il y a un bénéfice énorme à tout mutualiser.
29. L'objectif est du métier à l'ops, pas que du dev à l'ops ? C'est mal nommé tout ça ;-)
On ne peut pas tout faire en même temps, on a déjà l'agile qui tente de rapprocher le métier avec les devs, on essaie de rapprocher les devs avec les ops.
30. Si on résume un peu DevOps ?
Si vous avez un seul truc à retenir, c'est une phrase qui a été dite à Amazon : "You build it, you run it". Les gens qui font leur code, c'est aussi eux qui vont l'opérer derrière, et rien que ça, ça résume l'ensemble de la transformation culturelle qui est nécessaire pour faire du DevOps. Tout ce qui est décision, automatisation, façon de gérer une équipe, et la gestion des problèmes.