We are all DevOps

Par :
Benjamin Rabiller et Edouard Ly

ven, 02/12/2016 - 19:25

« Le DevOps, c'est l'affaire de tous. » Katherine Daniel VelocityConf 2015 @beerops 

Le monde des Dev et celui des Ops

La séparation historique des deux mondes

Historiquement il n'y avait de spécialisation entre Dev et Ops. Parmi ces anciens profils on y trouvait des développeurs très aguerris car étant passés par une expérience d'Ops. Au fil du temps, les développeurs et les opérationnels se sont séparés. La spécialisation, nécessaire pour maintenir des systèmes de plus en plus complexes, a fait émerger deux mondes. 

L'éloignement entre Dev et Ops s'ést accentué lors de délocalisation importante des développements à l'étranger dans le but de réduire les coûts des projets. Les années de pratique de cette méthode ont démontré une certaine inefficacité de livraison des projets et beaucoup de sociétés en sont revenues.

Les Dev et les Ops, la rupture

Culturellement, le Dev et l'Ops sont aux opposés. En règle général, les développeurs veulent changer et répondre aux besoins métiers rapidement. Ils préfèrent l'utilisation des nouvelles technologies émergentes.

Alors que les Ops cherchent plutôt à rendre une plateforme stable et donc à limiter les changements. Ils préfèrent l'utilisation de technologies éprouvées.

Par nature, l'Ops va se concentrer particulièrement sur des exigences de qualité. Ce travail va nécessairement augmenter la durée des déploiements et les coûts. 

Dans le déroulement d'un projet, chacun des acteurs a un rôle et des objectifs différents d'où naissent conflits d'intérêt chroniques.

Deux mondes, deux silos qui travaillent sur les composants d'un projet web, mais qui ne se parlent pas. Le résultat des applications déployées sur infrastructure cible sera potentiellement non performant ou bien tout simplement inutilisable.

Une fois l'application mise en production, en cas d'incident, qui est responsable ? Comment identifier au mieux les points de contention ? Comment partager les responsabilités entre Dev et Ops ? Chacun se renvoie la faute, rares sont ceux qui prennent leurs responsabilités.

Le DevOps, de la théorie à la pratique

Les bonnes pratiques pour intégrer le DevOps dans la vraie vie

Lors du lancement d'un projet, il est important d'intégrer une compétence Ops dans le projet. Elle aura une double compétence qui permettra également développer une partie du code. Son intégration aux différents workshops est essentielle pour ses connaissances en architecture et infrastructure, qui en feront une plus-value pour le développement.

Cette personne devra être capable d'identifier les problèmes opérationnels durant les différentes phases du projet pour alerter si nécessaire les différents membres des équipes de développement. En effet, une application peut très bien fonctionner sur un environnement de développement mais pourra tout simplement ne plus fonctionner une fois soumise à un trafic public. C'est à ce moment précis que l'Ops doit intervenir pour mettre en exergue ces potentiels points critiques pour l’opérationnel et donc l'exploitation, une fois mis en production.

La communication entre les membres de l'équipe et de la personne en charge de l'Ops devra permettre d'établir en amont de la mise en production, les différents points critiques pour le métier, qui devront être monitorés.

Le pair programming ou bien le pair Ops-engineering est un point qui mérite d'être abordé. Les pairs Ops ou Dev pourront se challenger et donc potentiellement améliorer la qualité du travail rendu.

Il doit y avoir un réel partage des connaissances entres les différentes équipes. Le retour d'expérience de chacun est plus qu'important. Cela peut aussi avoir une influence sur les différents choix techniques qui seront réalisés. 

Dans le but de faire du DevOps une réalité, il faut savoir exploiter de la manière la plus judicieuse et intelligente qu'il soit, les outils à disposition. Tout d'abord, explorons les outils organisationnels.

On pense tout de suites aux méthodes agiles (Dev) et aux méthodes ITIL (Ops). ITIL est important dans le monde de l'informatique. Un grand nombre de personnes ont été formées et ont eu l'occasion de lire et de pratiquer les livres ITIL dans l'objectif d'améliorer la gestion de l’informatique en entreprise. Même si ces méthodes peuvent paraître rigides, elles ne sont pas forcément incompatibles avec les méthodes agiles. 

Les méthodes agiles sont d’apparence plus appropriée pour le développement de logiciels. En effet, le développement d'une application ou d'un site web réalisé dans un processus itératif et incrémental permet de donner davantage de visibilité au client, mais aussi de vélocité au projet. L'idée est de fixer un premier objectif à court terme et d'adapter la suite avec ce qui aura été produit et les difficultés rencontrées. Très clairement, cela peut permettre d’accélérer le "time to market".

Les outils à disposition

Parlons maintenant des outils informatiques à notre disposition. Tout d'abord la virtualisation qui permet maintenant de gérer son infrastructure comme du code, on parle alors d'"infra as code".

Dans cette continuité, les outils d'industrialisation tels que Puppet, Chef ou encore Ansible permettent d'installer rapidement, de manière automatisée et fiable l'ensemble des middlewares nécessaires à l'exécution du code applicatif. 

On peut alors mettre en place plus aisément une intégration et un déploiement continu.

Vient ensuite la mise en place du monitoring 2.0. L'époque où les administrateurs système étaient en charge de récolter les métriques systèmes tels que le load, la mémoire vive ou encore le nombre de connexions TCP sur les serveurs est terminée. Avant même de passer en production, il faut récupérer des métriques métiers tels que les temps de réponse des APIs, le taux de transformation d'un site e-commerce… et corréler l'ensemble de ces informations avec tout d'abord les métriques systèmes, mais aussi avec les événements ayant eu lieu sur la plateforme. De nouveaux outils tels que Grafana permettent de mettre en place des annotations sur les graphiques, inscrites lors de chaque déploiement applicatif ou modification sur les serveurs (upgrade php, OS, etc ...) via un des outils d'industrialisation cités plus haut. 

Les outils d'Application Performance Management (APM) tel que NewRelic permettent, quant à eux, d'aider les développeurs et les administrateurs système à mieux comprendre les problèmes de performances sur l'infrastructure, l'application ou encore à l'investigation lors des incidents en donnant plus de détails sur le fonctionnement de l'applicatif et les potentiels goulots d’étranglement. 

Les bénéfices apportés par le mouvement du DevOps

Dans le cycle de développement

Le DevOps, en plus d'être une philosophie, est une pratique qui rassemble les personnes mais aussi les méthodes (agiles vs ITIL) et les outils utilisés par les différentes parties.

Dans certains cas, le DevOps n'est pas nécessairement utile. Des projets se prêtent plus à sa pratique que d'autres.

Il faut surtout voir le DevOps comme une vision, une pratique qui va aider le développement des projets au quotidien.

L'émergence des conteneurs Linux est en train de faciliter grandement le travail des développeurs. A l'heure actuelle, Docker est la technologie la plus en vogue sur ce sujet. Elle permet de gérer/orchestrer le déploiement de conteneurs Linux basés sur LXC (Linux Container).

Son utilisation est de plus en plus forte et prend de plus en plus d'importance. Un conteneur offre un nombre d'avantages conséquents. Tout d'abord, la portabilité et la réversibilité qui ouvrent la voie au multicloud. La simplicité, Docker propose un hub qui est le référentiel d'images dans lesquelles des middleware sont déjà installés (Redis, Nginx, MySQL, etc ...). 

Le retour sur investissement

Avec les outils technologiques à notre disposition et l'utilisation des méthodes organisationnelles, nous allons pouvoir déployer beaucoup plus souvent, perdre beaucoup moins de temps, éviter un grand nombre de problème et pouvoir revenir en arrière plus vite (rollback).

Le DevOps c'est travailler ensemble. Adieu donc à l'époque des Rock Star qui gardent jalousement le savoir dans son coin de peur de se faire détrôner. Nous aurons toujours besoin de leader mais ce leader doit aider son équipe à monter en compétence à s’organiser correctement. 

A propos de l'auteur

Benjamin Rabiller et Edouard Ly