Alors que les organisations se tournent vers le DevOps pour le développement, la livraison et l’intégration continus des fonctions métier, un contrôle rigoureux est essentiel.
Les organisations délaissent les méthodes de développement logiciel traditionnelles en cascade, où le code est produit sur des périodes définies et combiné à la gestion des systèmes opérationnels et des applications, au profit d’approches plus agiles.
Face à un besoin croissant de mise en service rapide des fonctionnalités via l’intégration continue, le développement continu et la livraison continue, de nombreuses entreprises cherchent à adopter une démarche DevOps.
Le DevOps vise à fédérer les équipes de développement, de test et d’exploitation afin de fluidifier la circulation du code et des applications fonctionnelles entre ces trois domaines.
Cependant, ce processus exige un contrôle strict et des boucles de rétroaction efficaces pour garantir son bon fonctionnement et maximiser les résultats positifs pour l’entreprise, tout en minimisant les impacts négatifs.
Une transition menée par les développeurs
Le problème pour les organisations réside dans la croissance rapide du DevOps, qui s’opère de manière ascendante, plutôt que d’être pilotée par la direction.
De nombreux outils DevOps sont disponibles en tant que logiciels libres ; aucun obstacle n’empêche un membre de l’organisation de télécharger l’outil qui lui convient et de commencer à l’utiliser.
Pour de nombreux développeurs et opérateurs, c’est une opportunité à ne pas manquer. Les développeurs recherchent des systèmes en aval qu’ils peuvent intégrer à leurs environnements de développement intégrés (IDE) existants, qu’il s’agisse de systèmes commerciaux comme IBM Rational Software Architect ou Microsoft Visual Studio, ou de systèmes libres comme Eclipse.https://www.eclipse.org/downloads/)** ou Anjuta, ou des logiciels de gestion de projets tels qu’Atlassian Jira Software ou CA PPM.
Cela a entraîné une utilisation accrue d’[outils tels que Jenkins](https://searchitoperations.techtarget.com/tip/Secure-Jenkins-for-fast-and-safe-app-deliveryChef et Puppet sont utilisés par les développeurs et les équipes d’exploitation. Jenkins fournit un ensemble de processus automatisés pour la gestion des versions logicielles, avec des plugins compatibles avec les outils de gestion de versions existants tels que Perforce, CVS, Subversion, Git et Accurev, ainsi que des processus simplifiés pour le déploiement continu. À leurs débuts, Chef et Puppet étaient davantage axés sur les opérations (Ops) du DevOps, utilisant les principes de la gestion de la configuration pour créer des packages fonctionnels pouvant être automatiquement déployés dans l’environnement opérationnel.
Options en expansion
Les capacités de ces outils se sont considérablement améliorées depuis leur arrivée sur le marché en 2005 (Puppet), 2009 (Chef) et 2011 (Jenkins, qui était essentiellement la continuation des travaux menés dans le cadre du projet Hudson, lancé par Sun en 2004 et désormais propriété d’Oracle).
Leurs fonctionnalités se recoupent aujourd’hui bien plus qu’il y a quelques années, et le besoin d’intégrer d’autres outils spécifiques pour créer un environnement DevOps complet est moindre.
Un soutien accru au travail d’équipe et à des boucles de rétroaction complètes signifie que les outils initialement conçus pour les individus prennent désormais pleinement en charge les groupes, même répartis sur plusieurs sites et travaillant entre différentes entreprises, comme les contractuels et les consultants.
Outre ces trois outils majeurs, d’autres sont disponibles sous diverses licences open source et couvrent le même domaine, tels qu’Ansible et Salt, ainsi que des outils intégrés aux systèmes de gestion de conteneurs comme Docker et Kubernetes. Pour une approche intégrée à Ubuntu et prise en charge par les entreprises, Canonical propose sa propre distribution de Kubernetes via JuJu.https://www.computerweekly.com/blog/Open-Source-Insider/AppScale-FastStart-for-Google-Compute-Engine-AWSKubernetes s’impose rapidement comme un acteur majeur de l’orchestration de conteneurs, notamment dans les environnements DevOps. Il est soutenu par la Cloud Native Computing Foundation (CNCF), qui compte parmi ses membres des entreprises telles qu’Amazon Web Services (AWS), Google, Microsoft, IBM, Intel, Twitter et bien d’autres.
Cloud Foundry est un autre système open source, également disponible en version commerciale, comme la plupart des outils open source mentionnés. Il offre un ensemble de fonctionnalités d’automatisation parfaitement adaptées au DevOps, permettant une prise en charge optimale des systèmes en amont et en aval. Bien que Cloud Foundry soit également membre de la CNCF, il présente certaines similitudes avec Kubernetes, mais sa portée est bien plus vaste, s’étendant au-delà des environnements conteneurisés. Un projet distinct au sein de Cloud Foundry, appelé KuBo (Kubernetes on BOSH), fournit une pile Cloud Foundry/Kubernetes intégrée pour les développeurs travaillant avec du code applicatif hétérogène, des machines virtuelles (VM) ou des environnements conteneurisés.
Trop d’outils
Gérer une situation où les développeurs et les administrateurs système utilisent chacun leurs propres outils, créant ainsi un environnement informatique hétérogène, peut s’avérer problématique pour les organisations. Deux solutions sont possibles.
Premièrement, imposer une approche prescriptive : définir un ensemble d’outils unique et l’imposer à tous. Malheureusement, cette approche est vouée à l’échec. N’oubliez pas qu’il s’agit de développeurs et d’administrateurs système. Jetez un œil dans le tiroir du haut de leur bureau : vous y trouverez sans doute de nombreux CD et clés USB contenant des logiciels non officiels qu’ils utilisent au quotidien. Ils sembleront peut-être partager votre avis sur la nécessité d’un outil unique, mais ils continueront très probablement à utiliser leurs outils à leur guise dès que vous aurez le dos tourné.
Les organisations tombent alors dans le piège de la logique : ayant donné des instructions à tous, elles les considèrent comme une évidence. Puis, un incident survient, et l’analyse post-mortem révèle les problèmes : des fonctionnalités cloisonnées, sans aucun contrôle centralisé.
Deuxièmement, il faut être pragmatique : il est désormais trop tard pour revenir en arrière et tenter de transformer cet ensemble chaotique d’outils utilisés individuellement en une solution plus adaptée aux besoins de l’entreprise.
De nombreux outils open source, grâce à l’utilisation croissante de plugins ou d’interfaces de programmation (API) ouvertes, peuvent recevoir des données d’autres outils open source avec un niveau de fidélité satisfaisant, voire élevé.
Lorsqu’un contrôle accru et un support complet sont nécessaires, un abonnement avec support à une distribution de logiciel open source – comme CloudBees, compatible avec Jenkins et ses composants supplémentaires – peut apporter le niveau de performance recherché par les organisations.
Les systèmes ouverts offrent une pérennité
Par ailleurs, des systèmes commerciaux permettent une grande ouverture et prennent en charge les outils existants. CA Automic, par exemple, propose une approche automatisée efficace pour rationaliser les processus DevOps tout en acceptant différents outils sous-jacents de manière ouverte.
La capacité de ces systèmes à permettre l’utilisation de différents outils sous-jacents est un point clé : il y a cinq ans, peu de gens parlaient de **[Chef et Puppet](https://searchitoperations.techtarget.com/tip/How-the-Puppet-architecture-manipulates-configurationsKubernetes n’a été lancé qu’il y a trois ans. À quoi ressemblera le marché dans cinq ans ? Si le système global mis en place est un système fermé, fortement lié à des outils prédéfinis, vous risquez d’être distancé. En revanche, s’il est ouvert et permet d’intégrer facilement de nouveaux outils, vous pourrez les adopter au fur et à mesure de leur apparition.
De nombreuses autres entreprises opèrent dans le domaine du DevOps. Par exemple, HashiCorp propose plusieurs outils, dont Terraform et Vagrant, qui simplifient l’exploitation d’un environnement DevOps. Perforce, initialement spécialisé dans le contrôle de version, a étendu ses activités au-delà du simple contrôle de version et a lancé sa suite d’outils Helix, offrant un large éventail de fonctionnalités DevOps.
Dans le monde des logiciels de gestion de configuration de systèmes traditionnels en constante évolution, BMC propose la suite d’automatisation BladeLogic. Modernisée pour intégrer le cloud computing et les conteneurs, BladeLogic Server Automation – notamment lorsqu’elle est combinée à d’autres produits BMC, tels qu’Atrium Orchestrator, Control-M Automation et la suite TrueSight – peut fournir des fonctionnalités DevOps.
L’infrastructure composable de HPE comble le fossé entre matériel et logiciel, permettant de configurer facilement des plateformes logiques et d’y provisionner des logiciels physiques, virtualisés ou conteneurisés via OneView.
Bien entendu, des solutions DevOps dans le cloud existent également. IBM offre un large éventail de fonctionnalités via sa plateforme BlueMix. AWS, Google et Microsoft proposent des outils directement sur leurs plateformes, tandis que nombre des outils déjà mentionnés sont disponibles en libre-service sur leurs plateformes cloud.
Le DevOps devient un levier majeur pour répondre aux besoins de l’entreprise : le développement continu de nouvelles fonctionnalités, rapidement déployables à la demande. Précisons qu’il s’agit plutôt de « BusDevOps » : les besoins et les attentes doivent être dictés par l’entreprise, et non par les développeurs.
Pour tirer pleinement parti d’un tel environnement BusDevOps, un outillage performant est indispensable, et il est peu probable qu’il soit obtenu par des règles prescriptives. Adoptez une approche pragmatique : fournissez des systèmes de supervision capables de structurer le chaos existant et de permettre aux développeurs et aux administrateurs système de travailler comme ils l’entendent.
Source : https://www.computerweekly.com
