A la rencontre des DevOps

Inventé en 2009 par le belge Patrick Debois et d’abord confiné au milieu des sociétés web, le terme de DevOps suscite de plus en plus l’intérêt des entreprises classiques. Selon une enquête réalisée par CA technologies en 2013, 80% des entreprises suisses connaissent le concept et plus de la moitié appliquent ou prévoient d’appliquer cette «méthodologie». Méthodologie? Processus? Boîte à outils? Fonction? Les interprétations du terme DevOps divergent. A entendre les principaux intéressés, c’est-à-dire les DevOps eux-mêmes, il s’agit avant tout d’une culture de collaboration entre les équipes de développement – les Dev – et d’exploitation – les Ops. «Le rôle d’un ingénieur DevOps est d’amener le développement vers l’exploitation et inversement», avance ainsi Reynald Borer, qui exerce cette fonction chez Smallrivers, la start-up lausannoise derrière le service Paper.li. Egalement très actif dans le domaine, Pierre-Yves Ritschard, CTO de la plateforme cloud Exoscale, voit dans le mouvement DevOps «une transformation de la manière d’opérer l’IT». Bien que différentes, ces diverses définitions du mouvement DevOps pointent bel en bien un même phénomène: les développeurs et les spécialistes de l’infrastructure vivent le plus souvent sur des planètes différentes et les rapprocher conduit à un changement profond du fonctionnement de l’IT avec un impact positif sur le business.

Rapprochement entre les contraires

Traditionnellement, sur la planète des développeurs, l’important ce sont les applications et l’ajout continuel de fonctionnalités pour répondre aux demandes des métiers et des clients finaux. Pour caricaturer, plus les changements sont rapides et fréquents, plus on est heureux – une tendance exacerbée lorsque l’on pratique une méthode Agile. Avec souvent peu d’intérêt pour ce qui se passe en aval une fois la release prête. «L’équipe de développement vit dans un environnement séparé, crée les livrables et les «balance» à la production qui doit se débrouiller», explique Pierre-Yves Ritschard d’Exoscale.

Sur l’autre planète, celle des spécialistes de l’infrastructure, le mot d’ordre est la stabilité et la continuité. De sorte que chaque changement est vu comme un danger. La relation entre les Dev et les Ops apparaît ainsi comme l’un des lieux où se négocie douloureusement l’antagonisme de toute entreprise entre les impératifs d’innovation et de stabilité.

En même temps, l’évolution du métier des développeurs et des spécialistes de l’infrastructure et les défis qu’ils ont à relever les poussent à se rapprocher. Les développeurs sont notamment demandeurs d’environnements et d’outils leur permettant de tester leur application dans des conditions réelles avant sa mise en production, et d’indicateurs sur son fonctionnement et sa performance une fois en production. De leur côté, de nombreux responsables d’infrastructure développent des compétences de programmation (scripts) et cherchent à automatiser et à fluidifier la mise en production de serveurs, voire d’applicatifs. Certains se sentent aussi frustrés par des déploiements bigbang douloureux et cherchent à agiliser les opérations sur des environnements toujours plus complexes. «Il s’agit de développer des synergies avec le développement agile, de s’intéresser aux projets avant que l’on nous les livre, de communiquer nos prérequis», explique Guillaume Hayoz, Head of IT Operations auprès de la banque en ligne Swissquote.

Des initiatives bottom-up s’appuyant sur des outils

Ces problèmes concrets font que les initiatives de rapprochement entre Dev et Ops émergent souvent du terrain, de collaborateurs curieux ou conjuguant des expériences dans le développement et dans l’infrastructure, ou tout simplement de rencontres informelles et de hasard. A l’image de l’anecdote que relate Nicolas Rémond, Software Architect chez SecuTix: «C’est une histoire d’amitié. Mon collègue (Reynald Borer, ndlr) travaillait dans l’exploitation et moi au développement. On se racontait nos problèmes respectifs et l’on voyait que quelque chose manquait à l’intersection. Un jour, nous sommes tombés sur un post sur le blog de la boutique d’artisanat en ligne Etsy qui parlait de métriques et de data driven engineering, on s’est dit c’est comme ça qu’il faut faire. C’était aussi la première fois que l’on voyait le terme DevOps. Une fois que l’on peut mettre un terme sur ce qui nous intéresse, on peut le chercher sur Google et accéder à une communauté».

Dans la pratique, ces initiatives se réalisent différemment selon le type et la taille de l’entreprise. «Dans une petite structure, le développement est naturellement proche de l’infrastructure, et l’on peut parler de fonction DevOps, tandis que dans les grandes sociétés il s’agit plutôt d’une collaboration entre les équipes», relève Reynald Borer, qui travaille aujourd’hui avec une dizaine de personnes chez Smallrivers, alors qu’il officiait auparavant chez SecuTix avec 80 collaborateurs IT.

Dans les départements IT plus classiques, cette collaboration nécessite aussi l’appui du management. «Nous avons la chance d’avoir une hiérarchie bienveillante et des personnes très intelligentes dans les équipes qui se rendent compte que l’on n’arrive à rien si l’on ne travaille pas ensemble», souligne ainsi Guillaume Lederrey, Solution Designer dans une multinationale suisse de produits de grande consommation.

Chez Swissquote, la collaboration DevOps prend notamment la forme d’équipes ad hoc: «Ce qui marche le mieux, c’est de créer des task forces avec des collaborateurs du développement et des opérations qui travaillent ensemble pendant une à trois semaines à la résolution d’un problème», explique Guillaume Hayoz, responsable des opérations de la banque en ligne. 

D’autre part, et même s’ils insistent sur le fait que le DevOps est un état d’esprit, les adeptes du concept dérivent rapidement avec enthousiasme sur les technologies qu’ils emploient et qui jouent un rôle considérable dans le développement de l’approche. «C’est un changement de culture, mais supporté par des outils», argumente Pierre-Yves Ritschard d’Exoscale. La collaboration et les processus entre développeurs et chargés d’infrastructure se matérialisent ainsi via des solutions d’intégration continue (Jenkins), de configuration et de déploiement (Chef, Pallet, Puppet), de testing (Gatling, Selenium) ou de monitoring (Graphite, Nagios). «Ces outils présentent l’avantage d’imposer un langage commun aux développeurs et aux responsables de l’infrastructure. Ils évitent les problèmes d’interprétation», explique Guillaume Lederrey.

Moins d’erreurs, plus de productivité

Du point de vue du fonctionnement de l’informatique de l’entreprise, le développement d’un environnement DevOps apporte divers avantages, à commencer par une productivité accrue des équipes. Selon une enquête de ZeroTurnaround effectuée l’an dernier auprès de 620 ingénieurs, les DevOps consacrent davantage de temps à des tâches productives que les responsables d’opération traditionnels. Ils passent par exemple en moyenne deux heures de plus par semaine à l’automatisation de tâches répétitives et à l’amélioration de l’infrastructure, et deux heures de moins à faire du support ou à éteindre des feux. Une conséquence directe de tests et de monitoring automatisés effectués en continu et donc d’applications mieux préparées pour la production. «Aujourd’hui, nous créons quatre fois par jour un environnement neuf sur lequel nous effectuons toute une batterie de tests. Grâce à cela, nous sommes devenus plus confiants pour la mise en production», explique Nicolas Rémond de SecuTix. Idem pour l’automatisation des processus de release, de provisionnement et de déploiement qui réduit les erreurs humaines, seconde cause de défaillance des applicatifs. Par ailleurs, ces pratiques diminuent le temps nécessaire à la remise en production suite à un problème. Selon le rapport de ZeroTurnaround les équipes fonctionnant en mode DevOps sont deux fois plus nombreuses à pouvoir restaurer un système en moins de 10 minutes que celles avec des processus traditionnels.

La vitesse, principal atout business

La nouvelle manière d’opérer l’IT stimulée par la collaboration et les outils DevOps a aussi un impact clair sur l’entreprise: sa vitesse d’exécution et d’innovation. Dans de nombreux secteurs, et particulièrement dans les services, l’informatique joue un rôle clé dans la course à la concurrence et à qui offrira en premier davantage de valeur aux clients. De sorte que, dans bon nombre d’entreprises, les départements IT sous pression n’arrivent plus à suivre et à livrer à temps, en raison notamment d’environnements toujours plus complexes. Selon une enquête de Forrester, dans plus de la moitié des entreprises le taux de succès des changements IT est inférieur à 80%. Sans compter que les changements effectués par l’IT prennent trop de temps et ne sont pas assez fréquents. Dans 69% des organisations, il faut un intervalle minimum d’une semaine entre deux changements apportés à l’infrastructure.

Cette situation explique sans doute pourquoi la livraison accélérée de services IT est la priorité numéro un des CIO, suivie par la qualité des services. Pour les analystes de Forrester, cette augmentation de la vitesse et de la qualité passe forcément par une automatisation accrue des opérations IT et la mise en œuvre d’une approche DevOps, inspirée de ce que font les géants du web. Des sociétés qui atteignent parfois des performances stupéfiantes, comme Amazon, qui met du nouveau code en production toutes les 11,6 secondes! Plus raisonnables, les sociétés suisses dans lesquelles œuvrent les DevOps cités dans cet article déploient aussi à grande vitesse: Smallrivers et SecuTix déploient environ deux releases par semaine et, chez Swissquote, on travaille sur des sprints de deux semaines pour chaque applicatif, avec au final plusieurs dizaines de releases par semaine. 

Dépasser les obstacles

Bien entendu, des obstacles aux initiatives DevOps existent. A commencer par les coûts et le manque de business case. Pour 45% des décideurs IT interrogés par Forrester, les bénéfices de l’automatisation n’excèdent pas les investissements nécessaires en outils et en compétences (formation, engagement). «Il n’est pas simple d’expliquer l’avantage de l’automatisation par rapport à deux heures d’installation manuelle, avec des scripts prêts à l’emploi. Lorsque le nombre d’installations a augmenté, on nous a écoutés», explique ainsi Nicolas Rémond de SecuTix. De plus, pour les sociétés classiques, la demande en innovations logicielles ne semble par justifier une telle fréquence de releases. «Nous n’avons que quatre à cinq releases majeures par an», concède ainsi Guillaume Lederrey. L’ingénieur s’empresse néanmoins d’ajouter qu’il y a aussi beaucoup d’autres releases à déployer, notamment pour des projets marketing: «Notre environnement hétérogène nous contraints à une approche évolutive. Mais, il est tout à fait possible de commencer par des petits bouts d’automatisation.»

Par ailleurs, des sociétés rompues à ITIL peuvent craindre que la gouvernance des services IT ne pâtisse de l’effet DevOps, avec des développeurs aux commandes de l’infrastructure. Ce n’est pas l’avis de Guillaume Hayoz, qui gère les opérations IT de la banque en ligne Swissquote et doit donc répondre à un cadre règlementaire particulièrement strict: «Avant de mettre en place une approche DevOps, nous nous sommes penchés sur ITIL, mais sa lourdeur n’était pas adéquate pour l’agilité dont nous avons besoin. Notre fonctionnement DevOps n’a jamais été un problème lors des audits technologiques auxquels nous sommes soumis».

En fin de compte, pour tous les spécialistes rencontrés dans le cadre de cet article, la mise en œuvre d’une approche DevOps apporte des gains de productivité, de qualité et de vitesse, qui justifient la démarche, et ce même pour les entreprises dont le web n’est pas l’activité principale. «Tôt ou tard l’IT traditionnelle va être confrontée aux mêmes problèmes: que fait-on lorsque l’on a un bug? Et pourquoi attendre six mois pour le corriger? Plus on attend, plus le risque s’installe», argumente Nicolas Rémond de SecuTix. Les DevOps voient enfin dans ce mouvement le prolongement naturel d’Agile, du développement aux opérations. «Le DevOps, c’est en quelque sorte l’extension du Definition of Done», conclut Pierre-Yves Ritschard d’Exoscale.