L'évolution DevOps dans le Cloud
Des outils comme Puppet et Chef ont permis d'appliquer la philosophie DevOps au Cloud. Mais lorsqu'il s'agit de gérer et d'analyser des applications Cloud, il reste des obstacles à franchir.
Le déploiement de logiciels débute par la structure d'une application. Au commencement, les applications étaient monolithiques et s'exécutaient dans une seule machine. Mais au fil des années, l'informatique distribuée a suscité de plus en plus d'intérêt. Ajoutez à cela le fractionnement des logiciels, qui facilite le développement et la réutilisation des différents composants, et un nouveau modèle est né.
Qu'on l'appelle architecture orientée services (service-oriented architecture - SOA), informatique modulaire ou services Web, ce nouveau modèle découpe les applications en petits morceaux qu'il connecte à l'aide d'interfaces de flux d'activité. Les développeurs doivent envoyer toutes les informations relatives à l'intégration et aux flux à ceux qui déploient et gèrent les applications. C'est cette communication entre développement et exploitation (ainsi que les processus qui la favorisent) qu'on a baptisée DevOps en 2009. Aujourd'hui, le terme de DevOps désigne également les outils qui exploitent des données de développement en temps réel pour automatiser le déploiement des applications.
Dans le Cloud, DevOps obéit à d'autres règles du jeu
Le Cloud computing redéfinit la méthode DevOps. Les problèmes d'intégration en particulier rendent les déploiements dans le Cloud plus compliqués que dans des applications sur site.
Le Cloud étant une ressource dynamique, les utilisateurs attendent une assistance en matière de basculement sur incident et de débordement de charge (Cloud bursting). Cela signifie que certains composants des applications voire certaines applications entières ne restent pas à leur emplacement de départ.
Par ailleurs, les flux d'activité et les connexions varient en fonction de la charge ou lorsqu'ils fonctionnent en mode de défaillance. Les outils de gestion du Cloud ont commencé à influencer les outils et principes DevOps, et vice versa.
Deux approches DevOps : scripts et modèles ou objets
Il existe deux approches répandues de DevOps : les scripts et les modèles ou objets.
Les modèles reposant sur des scripts ont dominé l'ère précédant le Cloud. Cependant, de nombreux gourous de DevOps reprochent aux scripts leur côté trop procédural, consistant à ne décrire que les étapes de déploiement et d'intégration, au détriment du produit final.
Sur le sujet
- Gartner : vers une adoption plus large des DevOps
- Les architectures orientées services (SOA) peuvent facilement migrer vers le cloud
- Quelles interactions entre AWS et une démarche DevOps
- SOA et développement : à quoi faut-il s’attendre en 2015
Bien qu'exigeant plus de travail, un modèle DevOps définissant un objectif final permet de prendre en compte des composants d'infrastructure et d'application plus diversifiés, ce qui le rend plus adapté au Cloud.
Cependant, les outils à base de scripts sont encore courants dans le Cloud. Mais deux autres outils leur disputent la suprématie : Puppet, qui incarne l'approche par modèles ou déclarative et Chef, qui adopte une approche procédurale ou impérative.
Chef est une structure DevOps impérative qui produit des « livres de recettes » basés sur Ruby. Quant à Chef, il constitue une solution puissante représentative du côté développement de DevOps, mais difficile à apprendre.
Contrairement à Chef, Puppet est généralement plus facile à maîtriser pour les administrateurs système. Puppet est une méthode déclarative fondée sur les modèles de données JSON. Grâce à son approche non procédurale, Puppet concilie les formes script et modèle de DevOps.
Autre avancée de DevOps dans le Cloud, la norme TOSCA (Topology and Orchestration Specification for Cloud Applications), développée par le consortium d'entreprises OASIS. Architecture ouverte reposant sur des modèles, TOSCA définit le déploiement et la gestion comme des attributs abstraits de profils hiérarchiques de composants. Il s'agit donc d'une norme idéale pour décrire des structures applicatives complexes. En outre, TOSCA a donné naissance à au moins une mise en oeuvre open source : OpenTOSCA.
L'impact futur de TOSCA est plus important que sa prise en charge actuelle. Le Cloud repose sur la concrétisation de ressources abstraites (machines, réseaux et services virtuels) sur des pools de ressources. Cette approche se prête bien à une modélisation par DevOps. Elle est par ailleurs favorisée par le dynamisme croissant des applications Cloud, qui influe à la fois sur l'exploitation et sur le développement.
L'élément moteur de la machine DevOps
D'après les experts,l'agilité est le ressort principal de DevOps. Tandis que le haut débit mobile et le Cloud sont, eux, les ressorts de l'agilité.
Dans le futur, une application Cloud se composera d'éléments assemblés de façon presque improvisée en réponse à des événements, tels qu'un travailleur mobile, une voiture sans chauffeur ou tout autre besoin en temps réel. S'il est sans doute plus facile de modéliser ces applications que d'écrire des scripts, dans les deux cas, elles impliquent une transformation du développement et de la gestion du cycle de vie pour s'adapter au Cloud. Par conséquent, la méthode DevOps doit jouer un rôle clé dans le processus de planification technologique d'une entreprise.
Bien que DevOps évolue sous l'influence du Cloud, il reste des problèmes à surmonter.
Par exemple, certains outils DevOps (même parmi les plus récents) sont décevants en matière de gestion de l'exécution des applications. De nombreux déploiements Cloud abordent la gestion dans une optique d'analyse couplée. Dans cette approche, le Cloud recueille des informations et fournit des solutions analytiques permettant de gérer le pool de ressources sans associer précisément certaines ressources à certaines applications.
Or, cela peut représenter un véritable défi avec des applications hautement dynamiques et personnalisées servant uniquement à répondre à la question d'un utilisateur. Il est difficile de déterminer les problèmes posés par ces applications lorsque les données de gestion ne sont disponibles que pour un pool de ressources sur une durée prolongée.
