1 pièce(s) jointe(s)
DevOps est-il un échec ? Un ingénieur logiciel de Pulumi pense que c'est le cas et propose de passer à SoftOps
Les conteneurs du DevOps présentent-ils des risques pour la sécurité de vos données ?
Oui, selon une étude
À l’heure où la méthode de travail DevOps semble gagner toutes les entreprises technologiques, de nombreux professionnels ont commencé à s’inquiéter sur la sécurité des conteneurs souvent préférés pour leur flexibilité et leur agilité. L’un des éléments clés dans la mise en œuvre du DevOps est la technologie des conteneurs. Les conteneurs sont de plus en plus mis en œuvre par les entreprises. Le DevOps est un mouvement en ingénierie informatique et une pratique technique visant à l'unification du développement logiciel (dev) et de l'administration des infrastructures informatiques (ops), notamment, l’administration système.
Apparu courant de 2010, le mouvement DevOps se caractérise principalement par la promotion de l’automation et du suivi (monitoring) de toutes les étapes de la création d'un logiciel, depuis le développement, l'intégration, les tests, la livraison jusqu'au déploiement, l'exploitation et la maintenance des infrastructures. Les principes DevOps soutiennent des cycles de développement plus courts, une augmentation de la fréquence des déploiements et des livraisons continues pour une meilleure atteinte des objectifs économiques de l'entreprise. La virtualisation à base de conteneurs est une méthode de virtualisation dans laquelle la couche de virtualisation s'exécute au sein même du système d’exploitation.
Dans cette approche, le noyau du système d'exploitation hôte exécute directement plusieurs machines virtuelles invitées et autonomes sans passer par une couche logicielle supplémentaire. Ces machines invitées s'appellent des conteneurs. Les conteneurs permettent donc de s'affranchir des hyperviseurs et de la gestion qui découle de l'exécution sur chaque machine virtuelle d'un système d’exploitation invité. Cette approche permet d'améliorer les performances, puisqu'un seul et unique système d'exploitation (l'hôte) se charge des appels matériels. Elle permet également d'héberger sur un serveur beaucoup plus d'instances virtualisées que la virtualisation traditionnelle.
Cette technologie est depuis quelques années très utilisée par de grandes firmes telles que Google, BlaBlacar, etc. L’un des plus connus de ces conteneurs est Docker (il s'agit d'un conteneur Linux). Cette façon de faire est très répandue aujourd’hui dans le monde technologique. Mais la technologie des conteneurs garantit-elle une sécurité optimale pour les ressources des entreprises ?
Une récente étude de Tripwire, une agence de cybersécurité, révèle que 60 % des entreprises ont subi un incident lié à la sécurité des conteneurs en 2018. Les résultats de l’étude publiés le 7 janvier dernier indiquent que les entreprises qui ont adopté le DevOps feront certainement face à des défis importants et des risques liés à la sécurité de leurs conteneurs. Pour Tripwire, si ces entreprises veulent minimiser les risques et leur exposition aux menaces numériques, elles devront penser à des solutions immédiates pour sécuriser leurs conteneurs.
Tripwire a procédé à l’interrogation d’environ 311 professionnels de la sécurité informatique qui gèrent des environnements avec des conteneurs dans beaucoup d’entreprises et les réponses étaient pour la plupart inquiétantes. D’abord, 60 % ont confirmé avoir subi quelques problèmes concernant la sécurisation et le déploiement de leurs conteneurs. L’étude de Tripwire fait ressortir que pour la majorité des entreprises dont il est question, plus le nombre de conteneurs en production augmente, plus les risques de sécurité augmentent.
« 86 % des organisations interrogées avaient des conteneurs en production au moment de l'étude. Plus il y avait de conteneurs dans la production, plus il était probable qu'ils subissent un incident lié à la sécurité des conteneurs. Parmi les entreprises comptant plus de 100 conteneurs en production, 75% avaient subi un incident lié à la sécurité. Il n’est donc pas étonnant que 94% des répondants se disent préoccupés par la sécurité des conteneurs. Soixante et onze pour cent des personnes allaient jusqu'à prédire que le nombre d'incidents liés à la sécurité des conteneurs augmenterait au cours de la prochaine cette année », indique Tripwire.
Selon Tripwire, si de tels risques planent sur les installations de ces entreprises, cela peut être la conséquence directe de leur manque d’expérience ou leur immaturité dans la mise en œuvre du DevOps. L’étude rapporte à ce sujet que beaucoup d’entreprises dans le lot traînent encore des lacunes dans leurs stratégies actuelles pour sécuriser leurs conteneurs. Par exemple, lit-on dans le rapport, à peine 12 % des répondants au sondage ont déclaré pouvoir détecter un conteneur compromis en quelques minutes. Quarante-cinq pour cent des participants au sondage ont déclaré que cela prendrait des heures, alors que certains estimaient que cela prendrait encore plus longtemps. Dans le même temps, près de la moitié (47 %) des professionnels de la sécurité informatique ont déclaré que leurs entreprises fabriquaient des conteneurs vulnérables, tandis que presque le même nombre (46 %) ont déclaré ne pas savoir avec certitude si c'était le cas.
Bon nombre de ces entreprises limitent pour ce fait leurs déploiements de DevOps pour parer certains risques de sécurité, indiquent les résultats de l’étude. Elles veulent toutes pouvoir acquérir de nouveaux environnements offrant bien plus de sécurité. « Avec la croissance et l'adoption de conteneurs, les entreprises sentent la pression pour accélérer leur déploiement. Pour faire face à la demande, les équipes acceptent les risques en ne sécurisant pas les conteneurs. Sur la base de cette étude, nous pouvons constater que le résultat est que la majorité des organisations sont confrontées à des incidents de sécurité des conteneurs », a expliqué Tim Erlin, vice-président chargé de la gestion des produits et de la stratégie chez Tripwire.
Source : Tripwire
Et vous ?
:fleche: Disposez-vous d’un déploiement de conteneurs pour votre entreprise ? Comment assurez-vous leurs sécurités ?
Voir aussi
:fleche: Les cinq étapes de l'évolution DevOps identifiées par le state of devops 2018, présentées par Puppet et Splunk
:fleche: Azure DevOps : Microsoft annonce le successeur de Visual Studio Team Services et un service d'intégration et déploiement continus intégrés à GitHub
:fleche: Le « DevOps » et le développeur « FullStack » mettraient en danger le métier de développeur le constat inquiétant de Jeff Knupp
1 pièce(s) jointe(s)
DevOps est-il un échec ? Un ingénieur logiciel de Pulumi pense que c'est le cas et propose de passer à SoftOps
DevOps est-il un échec ? Un ingénieur logiciel de Pulumi pense que c'est le cas et propose de passer à une nouvelle approche appelée SoftOps
pour résoudre les problèmes que DevOps n'a pu résoudre
Lee Briggs, ingénieur logiciel chez Pulumi, une société d'infrastructure en tant que code (infrastructure-as-code - IaC), a récemment publié un avis personnel selon lequel l'approche DevOps est un échec. L'approche DevOps vise à supprimer les frictions entre les développeurs et les opérations dans toutes les étapes de la création d'un logiciel, depuis le développement, l'intégration, les tests, la livraison jusqu'au déploiement, l'exploitation et la maintenance des infrastructures. Mais Briggs pense que DevOps n'a pas réussi cette mission et ajoute que la plupart des outils commercialisés sous le nom de "DevOps tooling" sont axés sur les opérations.
DevOps est un ensemble de pratiques qui met l’accent sur la collaboration et la communication entre les développeurs de logiciels et les professionnels des opérations informatiques, en automatisant le processus de livraison de logiciels et les changements d’infrastructure. L'objectif est de créer une culture et un environnement dans lesquels la conception, les tests et la diffusion de logiciels peuvent être réalisés rapidement, fréquemment et efficacement. Selon ses partisans, DevOps n’est pas seulement une méthodologie, c’est une véritable philosophie de travail. Cependant, d'autres pensent que DevOps n'a pas su tenir ses promesses.
Lee Briggs est de ceux qui pensent que DevOps a échoué. « En fin de compte, mon évaluation de DevOps en 2022 est la suivante : DevOps, ce sont des gens du côté des opérations qui essaient de convaincre les développeurs de faire les choses à leur manière. La quasi-totalité de l'outillage commercialisé sous le nom de "DevOps tooling" est axée sur les opérations. Si vous parcourez /r/devops, vous verrez des messages successifs de personnes parlant d'opérations et d'outils opérationnels. Si vous regardez la description de poste d'un ingénieur DevOps, elle ressemble beaucoup au rôle d'un administrateur système de 2013 », déclare Briggs.
Selon lui, si DevOps était censé changer la culture générale, il ne peut pas être considéré comme un mouvement réussi. L'ingénieur va plus loin en comparant DevOps à une course de dupes et appelle à un changement. « Les personnes du côté des opérations diront volontiers "Eh bien, nous essayons !", mais ce qu'ils veulent dire par là, c'est qu'ils essaient d'être un joueur de flûte pour les considérations opérationnelles. Ce n'est pas une voie à double sens. Il est bon de rappeler qu'en tant que personne chargée des opérations, nous sommes généralement en minorité d'au moins 5/1 dans toute organisation d'ingénierie donnée », a-t-il déclaré.
« Essayer de convaincre le moindre développeur de faire les choses "à la manière des opérations" et "d'utiliser les outils des opérations" est en fin de compte une course de dupes. Nous avons besoin d'un changement. En fin de compte, je pense qu'il est trop tard pour sauver le terme "DevOps". Si les gens vous vendent du DevOps, il est probablement trop tard. Ce que j'aimerais voir voir se produire à partir de maintenant, c'est un changement fondamental dans la façon dont les gens de DevOps pensent dans leur rôle quotidien », a-t-il ajouté. Briggs poursuit en disant que les opérations en arrivent parfois à oublier leur rôle principal.
« Il est parfois difficile de s'en souvenir, mais, en tant que personnes axées sur les opérations, notre rôle est de permettre et d'aider les développeurs à mettre les fonctionnalités dans les mains des clients (ou tout autre objectif commercial qu'ils pourraient avoir). La création d'un chemin de moindre résistance est une partie essentielle de la création et du maintien de la vitesse des développeurs qui livrent des produits et des fonctionnalités, et le fait que les développeurs apprennent et maintiennent toutes les pratiques d'exploitation n'est tout simplement pas réalisable », rappelle-t-il.
Eu égard à tout ce qui précède, Briggs propose de changer d'approche et de passer à ce qu'il appelle : SoftOps (Operations for Software Developers). « SoftOps est l'idée que nous allons construire des pratiques opérationnelles centrées sur l'amélioration de la vie des développeurs. Nous n'allons pas leur dire ce qu'ils doivent faire, nous allons leur demander ce qu'ils veulent faire, d'un point de vue opérationnel, puis nous allons leur faciliter la tâche autant que possible », a-t-il déclaré. Selon lui, l'époque où on lisait des pages de manuel de 48 pages et où l'on disait à son chef de projet que l'on ne respectait pas les délais des sprints est révolue.
Briggs explique que SoftOps est l'idée que vous allez mettre les développeurs en premier, en tant que client principal. Pour lui, l'élaboration de pratiques opérationnelles qui s'adressent à un monde de développeurs devrait (en théorie) amener les développeurs à la table des négociations afin de travailler en collaboration. « Peut-être que si nous nous concentrons uniquement sur cet objectif, nous finirons par résoudre les problèmes que DevOps a essayé de résoudre depuis 2009 », a-t-il déclaré. Briggs n'est pas allé plus loin dans les explications sur la nouvelle méthodologie qu'il met en avant, mais les avis sur sa proposition sont mitigés.
En outre, certains mettent en avant une autre approche appelée NoOps, et qui est présentée comme une amélioration du DevOps. NoOps est une évolution de la méthode DevOps visant à éliminer la nécessité d'une équipe d'exploitation distincte en automatisant entièrement l'infrastructure informatique. Dans cette approche, toutes les tâches d'approvisionnement, de maintenance et autres sont automatisées à un niveau tel qu'aucune intervention manuelle n'est nécessaire. NoOps et DevOps sont similaires dans un sens, car ils reposent tous deux sur l'automatisation pour rationaliser le développement et le déploiement de logiciels.
Cependant, DevOps vise à créer un environnement plus collaboratif tout en utilisant l'automatisation pour simplifier le processus de développement. D'autre part, NoOps vise à éliminer toute préoccupation opérationnelle du processus de développement. Dans un environnement entièrement automatisé, les développeurs peuvent utiliser directement ces outils et processus, même sans connaître leurs mécanismes sous-jacents. Par ailleurs, une autre proposition est l'ITOps. Dans ce cas, toute tâche informatique peut relever de l'ITOps, quel que soit le domaine d'activité. ITOps peut s'appliquer à pratiquement tous les domaines.
ITOps (ou TecOps) est l'abréviation de IT Operations. Dans sa forme la plus fondamentale, l'ITOps est le processus de fourniture et de maintenance de tous les services, applications, technologies et infrastructures nécessaires au fonctionnement d'un produit ou d'un service basé sur les technologies de l'information. Par conséquent, ITOps considère le développement de logiciels et la gestion de l'infrastructure informatique comme une entité unifiée faisant partie du même processus. La principale différence d'ITOps est la façon dont il gère la livraison et la maintenance.
Les ITOps sont davantage axées sur la stabilité et la fiabilité à long terme, avec un soutien limité aux flux de travail agiles et rapides. En général, l'agilité et la rapidité ne sont pas du tout les préoccupations principales des ITOps. Ainsi, les ITOps sembleront inflexibles avec des flux de travail rigides. Cette approche est également orientée vers la gestion de l'infrastructure physique avec des produits logiciels hautement testés et basés sur des versions, où la fiabilité et la stabilité sont des facteurs clés. Selon les critiques, ce manque de souplesse est également le principal inconvénient des ITOps.
Cependant, les analystes estiment qu'il peut constituer un excellent choix pour les développements de logiciels monolithiques et à évolution lente, comme dans le secteur des services financiers. En revanche, ils ajoutent que l'approche ITOps devient obsolète dans les développements logiciels qui évoluent rapidement. Et comme les développements logiciels modernes entrent dans cette catégorie, ITOps n'est pas un candidat approprié pour de tels environnements.
Source : Billet de blogue
Et vous ?
:fleche: Quel est votre avis sur le sujet ?
:fleche: Que pensez-vous de l'avis de Lee Briggs sur l'approche DevOps ?
:fleche: Selon vous, la méthodologie DevOps est-elle une réussite ou un échec ? Pourquoi ?
:fleche: Que pensez-vous de l'approche SoftOps proposée par Briggs ? En quoi est-elle meilleure que DevOps ?
:fleche: Que pensez-vous des autres alternatives au DevOps, telles que l'approche ITOps ou NoOps ?
Voir aussi
:fleche: Les conteneurs du DevOps présentent-ils des risques pour la sécurité de vos données ? Oui, selon une étude
:fleche: Plus de 60 % des équipes DevOps sacrifient la sécurité des conteneurs au profit de la vitesse, selon un rapport de NeuVector
:fleche: France : le poste administrateur système DevOps officiellement créé, et classé au niveau 6 du cadre national des certifications professionnelles
