IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Débats sur le développement - Le Best Of Discussion :

DevOps est-il un échec ? Un ingénieur logiciel de Pulumi pense que c'est le cas et propose de passer à SoftOps


Sujet :

Débats sur le développement - Le Best Of

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Dirigeant
    Inscrit en
    juin 2016
    Messages
    2 544
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Dirigeant
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2016
    Messages : 2 544
    Points : 55 672
    Points
    55 672
    Par défaut 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 ?

    Nom : article-DevSecOps.jpg
Affichages : 15803
Taille : 135,2 Ko

    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 ?

    Disposez-vous d’un déploiement de conteneurs pour votre entreprise ? Comment assurez-vous leurs sécurités ?

    Voir aussi

    Les cinq étapes de l'évolution DevOps identifiées par le state of devops 2018, présentées par Puppet et Splunk

    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

    Le « DevOps » et le développeur « FullStack » mettraient en danger le métier de développeur le constat inquiétant de Jeff Knupp
    Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

  2. #2
    Modérateur
    Avatar de gangsoleil
    Homme Profil pro
    Manager / Cyber Sécurité
    Inscrit en
    mai 2004
    Messages
    10 075
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Manager / Cyber Sécurité

    Informations forums :
    Inscription : mai 2004
    Messages : 10 075
    Points : 27 719
    Points
    27 719
    Par défaut
    Bonjour,

    Il est évident que si on intègre la sécurité dès le début, celle-ci est moins cher à mettre en œuvre, plus facile à intégrer, et souvent plus robuste.

    Après, ce qu'il faut mettre en balance dans cette étude, c'est que le problème de sécurité n'est pas lié aux conteneurs ou aux processus DevOps, mais à un manque de sécurité dans les procesus. Autrement dit, si n'importe quoi d'autre aurait été utilisé pour faire ce déploiement, les problèmes de sécurité auraient été là également.

    On commence de plus en plus à intégrer la sécurité dès le début des processus, mais on part de tellement bas qu'il reste énormément de chemin à parcourir.
    "La route est longue, mais le chemin est libre" -- https://framasoft.org/
    Les règles du forum

  3. #3
    Chroniqueur Actualités

    Homme Profil pro
    Dirigeant
    Inscrit en
    juin 2016
    Messages
    2 544
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Dirigeant
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2016
    Messages : 2 544
    Points : 55 672
    Points
    55 672
    Par défaut 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.

    Nom : DevOps-cest-quoi-definition.jpg
Affichages : 98488
Taille : 88,7 Ko

    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 ?

    Quel est votre avis sur le sujet ?
    Que pensez-vous de l'avis de Lee Briggs sur l'approche DevOps ?
    Selon vous, la méthodologie DevOps est-elle une réussite ou un échec ? Pourquoi ?
    Que pensez-vous de l'approche SoftOps proposée par Briggs ? En quoi est-elle meilleure que DevOps ?
    Que pensez-vous des autres alternatives au DevOps, telles que l'approche ITOps ou NoOps ?

    Voir aussi

    Les conteneurs du DevOps présentent-ils des risques pour la sécurité de vos données ? Oui, selon une étude

    Plus de 60 % des équipes DevOps sacrifient la sécurité des conteneurs au profit de la vitesse, selon un rapport de NeuVector

    France : le poste administrateur système DevOps officiellement créé, et classé au niveau 6 du cadre national des certifications professionnelles
    Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

  4. #4
    Membre éprouvé
    Homme Profil pro
    retraité
    Inscrit en
    septembre 2014
    Messages
    475
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : retraité

    Informations forums :
    Inscription : septembre 2014
    Messages : 475
    Points : 1 171
    Points
    1 171
    Par défaut
    Mais de quoi parle l'auteur quand il écrit "If you browse /r/devops"...En fait, et je l'avais deviné c'est https://www.reddit.com/r/devops/ ... mais bon sang quelle manière d'écrire chez ces américains !
    Sinon ce qu'il considère comme un échec peut-il être à l'origine de ceci https://emploi.developpez.com/actu/3...-cette-raison/ ?

  5. #5
    Membre extrêmement actif
    Profil pro
    Inscrit en
    juin 2010
    Messages
    782
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2010
    Messages : 782
    Points : 962
    Points
    962
    Par défaut
    Citation Envoyé par TotoParis Voir le message
    Mais de quoi parle l'auteur quand il écrit "If you browse /r/devops"...En fait, et je l'avais deviné c'est https://www.reddit.com/r/devops/ ... mais bon sang quelle manière d'écrire chez ces américains !
    Sinon ce qu'il considère comme un échec peut-il être à l'origine de ceci https://emploi.developpez.com/actu/3...-cette-raison/ ?
    Tout le monde sait que /r est reddit sauf les boomers

  6. #6
    Membre confirmé
    Inscrit en
    mai 2003
    Messages
    223
    Détails du profil
    Informations personnelles :
    Âge : 42

    Informations forums :
    Inscription : mai 2003
    Messages : 223
    Points : 575
    Points
    575
    Par défaut
    le job d un ingénieur moderne est d automatiser des tâches, cad de faire travailler des machines plutôt que des humains.
    Avec DevOps, il s agit donc de supprimer les équipes opérationnelles et de demander aux développeurs de les remplacer par des outils automatisés. Sauf que ces outils sont souvent frustrants à utiliser pour les développeurs car comme dit l auteur, les outils sont d abord penser pour la partie opérationnelle et sont pas aussi mature que les IDE pour la partie développement des scripts.
    Prenez par ex les pipelines CI/CD sur Gitlab ou AzureDevOps: ce sont les outils de base pour déployer automatiquement les composants logiciels écrits par les équipes de développeurs. Mais on demande à ces mêmes développeurs d'écrire aussi les scripts de ces pipelines, qui peuvent vite devenir très complexe dans un environnement entreprise: une ligne de code d un script yaml est autrement plus "coûteuse" (en terme de temps) qu'un bloc de code en java, JS ou autre car on ne peut pas débugger notre code si facilement.
    (bais cognitif du moment: cela fait des semaines que je me prends la tête sur les "rules" dans des pipelines imbriquées sur Gitlab)

  7. #7
    Membre extrêmement actif
    Homme Profil pro
    Inscrit en
    janvier 2014
    Messages
    1 336
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : janvier 2014
    Messages : 1 336
    Points : 5 077
    Points
    5 077
    Par défaut
    C'est Devops qui est un échec, ou alors les baltringues qui sont censés faire appliquer cette méthode ?

    T'es nul en programmation ? T'es nul en informatique ? T'es nul en management de projet ? Hop devient "Devops" après quelques semaines de formation merdique dans une école privée pourrie avec des profs nuls voir absents, ou alors lis un "tuto" sur Youtube, et devient grassement payé à ne rien foudre en travaillant seulement en vrai 1 h par jour pour pondre des rapports à la con qui servent à rien

    La théorie sur ce que ça devrait être :




    Le résultat sur le terrain en pratique dans les faits :




    « L’humour est une forme d'esprit railleuse qui s'attache à souligner le caractère comique, ridicule, absurde ou insolite de certains aspects de la réalité »

  8. #8
    Modérateur
    Avatar de grunk
    Homme Profil pro
    Lead dév - Architecte
    Inscrit en
    août 2003
    Messages
    6 608
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Lead dév - Architecte
    Secteur : Industrie

    Informations forums :
    Inscription : août 2003
    Messages : 6 608
    Points : 19 693
    Points
    19 693
    Par défaut
    Citation Envoyé par Eric80 Voir le message
    le job d un ingénieur moderne est d automatiser des tâches, cad de faire travailler des machines plutôt que des humains.
    Avec DevOps, il s agit donc de supprimer les équipes opérationnelles et de demander aux développeurs de les remplacer par des outils automatisés. Sauf que ces outils sont souvent frustrants à utiliser pour les développeurs car comme dit l auteur, les outils sont d abord penser pour la partie opérationnelle et sont pas aussi mature que les IDE pour la partie développement des scripts.
    Prenez par ex les pipelines CI/CD sur Gitlab ou AzureDevOps: ce sont les outils de base pour déployer automatiquement les composants logiciels écrits par les équipes de développeurs. Mais on demande à ces mêmes développeurs d'écrire aussi les scripts de ces pipelines, qui peuvent vite devenir très complexe dans un environnement entreprise: une ligne de code d un script yaml est autrement plus "coûteuse" (en terme de temps) qu'un bloc de code en java, JS ou autre car on ne peut pas débugger notre code si facilement.
    (bais cognitif du moment: cela fait des semaines que je me prends la tête sur les "rules" dans des pipelines imbriquées sur Gitlab)
    Rien ne t'empêche d'écrire un yaml ultra minimal qui va ensuite aller exécuter des scripts écrits dans le langage que tu veux.

    Le but de devops c'est pas de supprimer les équipes opérationnelles , mais de supprimer la friction entre les dev et les ops. L'ops ca reste un vrai métier pour lequel les dév on rarement de l'intérêt et quand c'est le cas il leur manque souvent de la connaissance pour faire les choses bien (exemple).
    Par contre écrire un script pour mettre en oeuvre ce qu'à préparer les ops ca on sait faire , souvent plus efficacement que les ops.
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  9. #9
    Expert confirmé
    Homme Profil pro
    Développeur .NET
    Inscrit en
    novembre 2009
    Messages
    1 801
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : novembre 2009
    Messages : 1 801
    Points : 4 870
    Points
    4 870
    Par défaut
    Citation Envoyé par grunk Voir le message
    Par contre écrire un script pour mettre en oeuvre ce qu'à préparer les ops ca on sait faire , souvent plus efficacement que les ops.
    Avec cette phrase tu résumes le phénomène. Les "ops" ne sont que les "sys admin" de la décennie précédente.
    Et comme dans la décennie précédente, tu as les gars dans les petites boites qui font tout (dev/exploitation/support/qualité) et au plus tu vas dans de grosse boite au plus les activités sont dissociées. Cette mouvance "devops" est initiée par des gars de grosse structure qui voulait ressentir le coté touche à tout de la petite boite.
    Mais le réel c'est que passer le fun d'apprendre des trucs avec des tutos, ça reste bien plus efficace d'avoir des "spécialistes".

    Moralité: si vous voulez faire du vrai devops il faut aller dans une petite structure.

  10. #10
    Membre chevronné
    Homme Profil pro
    Développeur
    Inscrit en
    août 2003
    Messages
    763
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : août 2003
    Messages : 763
    Points : 2 082
    Points
    2 082
    Par défaut
    Citation Envoyé par grunk Voir le message
    Le but de devops c'est pas de supprimer les équipes opérationnelles , mais de supprimer la friction entre les dev et les ops. L'ops ca reste un vrai métier pour lequel les dév on rarement de l'intérêt et quand c'est le cas il leur manque souvent de la connaissance pour faire les choses bien (exemple).
    C'est en effet ce qui arrive quand on embauche des développeurs sur du DevOps.
    En tant que développeur, quand je vois la stack technique sur la partie dev (souvent back-end avec la connaissance du front ) et qu'en plus ça demande des compétences CI/CD et Cloud dans les offres d'emploi, ce n'est pas étonnant que la production soit mal configurée. Certe, on a des connaissances et des compétences sur la partie DevOps mais on deviendra rarement un expert DevOps si on n'est pas à plein temps dessus.
    Personnellement, je me contente au quotidien de :
    - 1-2 langages de programmation avec 1-2 framework par langage
    - docker pour la conteneurisation et effectuer des tests
    - un serveur Linux et Ansible pour le déploiement de la solution en production
    - nginx pour configurer le serveur web

    La partie CI/CD je passerais du temps si je dois mettre ça en place

  11. #11
    Membre extrêmement actif
    Profil pro
    Inscrit en
    juin 2010
    Messages
    782
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2010
    Messages : 782
    Points : 962
    Points
    962
    Par défaut
    Citation Envoyé par grunk Voir le message
    Rien ne t'empêche d'écrire un yaml ultra minimal qui va ensuite aller exécuter des scripts écrits dans le langage que tu veux.

    Le but de devops c'est pas de supprimer les équipes opérationnelles , mais de supprimer la friction entre les dev et les ops. L'ops ca reste un vrai métier pour lequel les dév on rarement de l'intérêt et quand c'est le cas il leur manque souvent de la connaissance pour faire les choses bien (exemple).
    Par contre écrire un script pour mettre en oeuvre ce qu'à préparer les ops ca on sait faire , souvent plus efficacement que les ops.
    Perso mes Yaml ne font que lancer des scripts powershell et ce pour Windows, Linux et Macos grace à Powershell core https://github.com/powershell/powershell .

  12. #12
    Membre chevronné Avatar de Astraya
    Homme Profil pro
    Consommateur de café
    Inscrit en
    mai 2007
    Messages
    1 029
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France

    Informations professionnelles :
    Activité : Consommateur de café
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mai 2007
    Messages : 1 029
    Points : 2 152
    Points
    2 152
    Par défaut
    Citation Envoyé par redcurve Voir le message
    Perso mes Yaml ne font que lancer des scripts powershell et ce pour Windows, Linux et Macos grace à Powershell core https://github.com/powershell/powershell .
    Je suis heureux de pas être le seul pour ma part c'est un exécutable. Net Core que je peux aussi tester sur ma machine
    Homer J. Simpson


  13. #13
    Membre extrêmement actif
    Profil pro
    Inscrit en
    juin 2010
    Messages
    782
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2010
    Messages : 782
    Points : 962
    Points
    962
    Par défaut
    Citation Envoyé par Astraya Voir le message
    Je suis heureux de pas être le seul pour ma part c'est un exécutable. Net Core que je peux aussi tester sur ma machine
    Franchemen je n'ai pas touché Bash depuis 3 ans et je dois dire que ça ne me manque pas

  14. #14
    Membre chevronné
    Profil pro
    Inscrit en
    juin 2009
    Messages
    655
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2009
    Messages : 655
    Points : 2 132
    Points
    2 132
    Par défaut
    Mon point de vue sur DEVOPS c'était surtout de "professionnaliser" ce qui tourne autour du dev sans être du dev pur. En effet, le focus étant souvent mis sur le dev pur que le reste, le reste est mal maîtrisé au sens gestion, mal budgété, et en plus mal maîtrisé techniquement par les développeur, résultant plus souvent dans des résultats relativement "amateur".

    Car le fait est que la plupart des développeurs peuvent écrire quelques script d'auto déploiement qui marcherons a peu près. Mais pour avoir un truc nickel, surtout dans le cas d'un client lourd par exemple, il y a une marche qui distingue bien un truc plus "amateur" qu'un truc "pro" fait par les gens plus du système généralement.

    Dans les exemples :
    • Mis à jour automatiques des applications, mais aussi upgrade des composant de serveur/bdd.
    • Regénération des certificats SSL nécessaires pour avoir une plateforme validation qu'on teste en HTTPS.
    • Gestion des comptes utilisateurs, de l'AD, des trucs SSO (kerberos, SAML, CAS, ,...),...
    • Pipelines CI (bon j'ai pas chez moi ça )
    • ...


    Quand on voit ça, j'ai aucun doute qu'une bonne partie peuvent ce dire "bon je vais galérer mais ça va globalement passer", ben oui, sauf que régulièrement y'a quand même un truc qui pète et le temps de trouvé tu prend deux jours.

  15. #15
    Membre expérimenté

    Homme Profil pro
    Consultant informatique
    Inscrit en
    avril 2015
    Messages
    350
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vendée (Pays de la Loire)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : avril 2015
    Messages : 350
    Points : 1 700
    Points
    1 700
    Par défaut
    Problèmes de riches. "De mon temps", même dans des structures importantes, un développeur était responsable de son produit de a..z. Accessoirement, c'étaient les développeurs internes qui développaient l'environnement d'exploitation et l'environnement de développement, afin d'offrir une gestion de sources et de versions homogènes, une gestion multi-plateformes des mises en production, etc.
    Ça, c'était dès 1990. Ensuite, on a voulu des spécialistes, car un spécialiste, c'est spécialisé et le "chef de projet consultant" aura toujours beau jeu de le renvoyer à sa spécialité lorsque lui-même sera menacé d'avoir démontré son inutilité.
    La situation a commencé à sérieusement se dégrader lorsque les méthodes dites agiles sont apparues. L'aspect sectaire et messianique des séances était frappant, leur inefficacité aussi. Mais comme on avait payé très cher le super consultant venu mettre tout ça en place, il n'était pas question de revenir en arrière. Alors on a engagé, car c'est bien connu : Quand un projet prend du retard, doublez les effectifs, ça ira mieux (je plaisante).
    Bref. J'ai l'impression qu'aujourd'hui beaucoup de gens dépensent une énergie folle à faire une informatique qui ne soit plus de l'informatique mais de la gestion administrative, tout en s'affublant de titres inflationnistes.
    Mais dans le fond, si vous voulez livrer quelque chose qui facilite la vie de votre client, un compilateur (multi-plateformes), un SGBDR, de bonnes librairies, du temps, un peu de talent valent beaucoup mieux qu'une équipe de fashionistas déversant leur glose récemment apprise en prenant l'air d'avoir inventé la poudre qui pète deux fois.

  16. #16
    Membre chevronné
    Homme Profil pro
    Développeur
    Inscrit en
    août 2003
    Messages
    763
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : août 2003
    Messages : 763
    Points : 2 082
    Points
    2 082
    Par défaut
    Citation Envoyé par TJ1985 Voir le message
    Problèmes de riches. "De mon temps", même dans des structures importantes, un développeur était responsable de son produit de a..z. Accessoirement, c'étaient les développeurs internes qui développaient l'environnement d'exploitation et l'environnement de développement, afin d'offrir une gestion de sources et de versions homogènes, une gestion multi-plateformes des mises en production, etc.
    Ça, c'était dès 1990. Ensuite, on a voulu des spécialistes, car un spécialiste, c'est spécialisé et le "chef de projet consultant" aura toujours beau jeu de le renvoyer à sa spécialité lorsque lui-même sera menacé d'avoir démontré son inutilité.
    La situation a commencé à sérieusement se dégrader lorsque les méthodes dites agiles sont apparues. L'aspect sectaire et messianique des séances était frappant, leur inefficacité aussi. Mais comme on avait payé très cher le super consultant venu mettre tout ça en place, il n'était pas question de revenir en arrière. Alors on a engagé, car c'est bien connu : Quand un projet prend du retard, doublez les effectifs, ça ira mieux (je plaisante).
    Bref. J'ai l'impression qu'aujourd'hui beaucoup de gens dépensent une énergie folle à faire une informatique qui ne soit plus de l'informatique mais de la gestion administrative, tout en s'affublant de titres inflationnistes.
    Mais dans le fond, si vous voulez livrer quelque chose qui facilite la vie de votre client, un compilateur (multi-plateformes), un SGBDR, de bonnes librairies, du temps, un peu de talent valent beaucoup mieux qu'une équipe de fashionistas déversant leur glose récemment apprise en prenant l'air d'avoir inventé la poudre qui pète deux fois.
    Dans les années 90 il n'y avait pas autant d'outils qu'aujourd'hui et d'environnements cloud. De plus on voit ce que ça donne le code legacy :
    - souvent peu de documentation
    - les personnes qui les ont développés sont parties
    - chacun programmait à sa façon
    - parfois obliger de coder des fonctionnalités qui sont devenues standards dans les autres langages/frameworks
    - peu de tests

    Quand les outils de gestions de version sont arrivés cela a apporté un confort et de nouvelles règles.
    Je trouve que ça s'est complexifié quand les solutions cloud sont arrivée : avant on installait un serveur de A à Z mais maintenant on doit apprendre un nouvel environnement à chaque fois que l'on change d’hébergeur cloud.
    Avant on avait des petits scripts pour la compilation et le déploiement (ou ce dernier point était fait manuellement) mais maintenant on a intégrer des outils d'analyse de code, des automatisation de tests, des règles pour les pull requests donc de nouveaux outils à connaître.
    Enfin, on a des délais courts pour le développement donc il est plus facile de déléguer à des spécialistes plutôt que de passer plusieurs jours pour automatiser le déploiement ou autre.

Discussions similaires

  1. Réponses: 3
    Dernier message: 17/06/2018, 01h09
  2. Réponses: 70
    Dernier message: 22/06/2017, 15h21
  3. Virtualisation : des risques pour la sécurité selon Intel Exec
    Par Annaelle32 dans le forum Virtualisation
    Réponses: 0
    Dernier message: 19/07/2009, 06h04
  4. Virtualisation : des risques pour la sécurité selon Intel Exec
    Par Annaelle32 dans le forum Actualités
    Réponses: 0
    Dernier message: 19/07/2009, 06h04

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo