Quelle est la différence entre DevOps et Automation?


42

Je vois que chaque fois que quelqu'un utilise DevOps, il s'agit principalement d'automatiser des tâches telles que le déploiement, etc.

Mais où finit l'automatisation et où commence DevOps?


Bonjour, @punkpanther, si telle ou telle réponse a résolu votre question, merci de l' accepter en cliquant sur la case à cocher. Cela indique à la communauté plus large que vous avez trouvé une solution et donne une certaine réputation à la fois au répondeur et à vous-même. Il n'y a aucune obligation de le faire. Si vous pensez que votre question n'a pas reçu de réponse, n'hésitez pas à communiquer avec les auteurs dans les commentaires.
Richard Slater

Peut-être que la meilleure question serait de savoir où finit DevOps et où commence l'automatisation? Tout ce qui est fait avec DevOps ne concerne pas l'automatisation; une grande partie, oui, mais pas tous ... On pourrait dire que DevOps est tout sauf l'automatisation - c'est le système administrateur, les normes d'architecture commune, les normes de publication communes (disons GitHub) d'un domaine technologique particulier ... Où est-ce que l'automatisation dans ce domaine commence est une bonne question en soi, je pense ...
JohnDoea

Réponses:


45

Une grande partie de DevOps permet de publier très souvent. Cela vient avec une construction automatisée, des tests automatisés, etc. Vous pouvez dire que pour atteindre ses objectifs, DevOps doit utiliser l'automatisation pour être efficace.

Voici comment DevOps et l’automatisation sont liés. DevOps n'est pas simplement une automatisation, il y a plus que ça. À l'inverse, l'automatisation n'est pas exclusivement utilisée par les "personnes DevOps". Avant l’installation de DevOps, beaucoup d’automatisations étaient en cours dans le domaine informatique.

DevOps en relation avec l'automatisation

Ne considérez pas que le diagramme ci-dessus représente tout ce qui est DevOps, ou tout cela, c'est de l'automatisation. C'est pour aider le lecteur à comprendre comment les deux concepts sont liés.


1
Exactement ce que j'avais dit à ce sujet :)
Tensibai

Pourquoi le "workflow de tickets" n'est-il pas dans DevOps?
Nakilon

15

L'automatisation est un attribut clé de DevOps, mais ce n'est pas tout. La question est un peu comme "Quelle est la différence entre la boxe temporelle et Scrum?".

Vous entendrez DevOps appeler une "culture", un "mouvement", une "méthodologie" et toutes sortes de choses qui ne l'encadreront pas assez bien pour que vous puissiez la comprendre, même si ces descriptions sont exactes. En résumé, DevOps concerne la confluence des méthodologies Agile, de l’automatisation et de la virtualisation qui permet une nouvelle boucle de rétroaction dans la gestion / le contrôle / le pilotage d’un projet logiciel.

Avec l'automatisation agressive, les choses qui prenaient beaucoup de temps et étaient sujettes à des erreurs humaines se produisent maintenant rapidement et sans incident. En conséquence, nous avons tendance à les faire plus souvent. Un premier exemple de ceci est un «déploiement en production». Nous avions l'habitude de sauvegarder de grandes quantités de travail et de les déployer en dehors des heures de travail au cas où «quelque chose n'allait pas». Mais maintenant, nous pouvons déployer des changements plusieurs fois par jour, de manière à réduire considérablement les chances de «tomber sur un problème» et à réduire considérablement l'impact de ce qui se passe mal.

Une fois que ce processus reproductible est en place, nous commençons à le voir comme un «pipeline». Les exigences entrent, le code déployé en production sort. Nous automatisons tout le long de ce pipeline - tests, documentation, fusions, déploiements, et plus de tests, etc. ... Parce que les gens se concentrent sur l'automatisation, ils ne voient pas la «mentalité de pipeline» qui l'a piloté. C'est la méthodologie de gestion - l'attention portée au pipeline - qui fait de DevOps plus que de l'automatisation.

Une fois que cette automatisation est en place, les boucles de rétroaction entrent en jeu. Nous commençons à mesurer des éléments tels que la durée du cycle afin de déterminer les éléments que nous avions précédemment essayés de deviner avec des estimations. Les éléments de l'architecture qui rendent difficile l'automatisation / la distribution continue ont tendance à être remplacés par d'autres modèles architecturaux facilitant l'automatisation / la distribution continue (plusieurs excellents exemples sont présentés dans le livre "Bases de données évolutives". Les "déploiements verts / bleus" en sont un autre exemple. )

Remarquez que j'ai pu fournir cette description sans parler de Jenkins, de Check, de Puppet, d'Ansible, de Vagrant, d'AWS ou de tout autre outil le prenant en charge. C’est ce que nous entendons par mots à la mode, tels que «méthodologie». En fin de compte, n'importe quel ensemble d'outils peut être remplacé ... Ce qui nous reste, ce sont les principes de gestion de base rendus possibles par l'automatisation et l'accent mis sur le pipeline.


1
Je suis désolé, mais cela ressemble plus à un manifeste agile qu’à une culture devops. La méthodologie du cycle agile / itératif / court même si elle est souvent utilisée n'est pas obligatoire pour une organisation devops. Vous pouvez avoir des équipes de devops sur un projet de cascade et automatiser la livraison en silo, ce qui, à mon avis, répond en partie à la question.
Tensibai

2
@Tensibai Je ne suis pas tout à fait d'accord. Vous n'automatisez pas un processus qui ne s'exécute pas souvent. DevOps sans Agile revient à automatiser la construction d'une supercar de plusieurs millions de dollars.
Dave Swersky

Cette réponse est incroyablement prolixe et il est difficile de résumer les différences, ou les avantages / inconvénients liés au PO Q.
Evgeny

@Dave vous manquez le point, je devais avoir un doute, ce que je veux dire, c'est qu'une culture devops consiste à rompre les équipes de silos, l'automatisation ou les cycles courts ne sont pas liés même si, d'habitude, je n'ai pas vu ce point important dans votre réponse.
Tensibai

13

DevOps est vraiment un changement culturel - il est prévu de supprimer les barrières traditionnelles entre les opérations et le développement (et vraiment aussi avec le contrôle qualité et le reste de l'entreprise!). L'idée est que, plutôt que d'avoir des «silos» départementaux, vous pouvez travailler directement avec les autres équipes pour faire avancer les choses plus rapidement et plus efficacement.

Il s’agit de supprimer les contraintes et de rationaliser les processus. L'automatisation est un facteur important car la répétabilité des processus permet de supprimer les contraintes. Par exemple, si une personne des opérations doit exécuter manuellement un processus de libération pour obtenir du code dans un environnement, il peut y avoir plusieurs problèmes qui peuvent gêner - le fait est qu'il doit y avoir quelqu'un dans les opérations libre pour effectuer le déploiement, et deuxièmement, le processus de publication suscite moins de confiance, car le travail manuel est sujet aux erreurs.


4

DevOps inclut l'automatisation, mais ce n'est qu'une partie de celle-ci. DevOps est un changement culturel qui consiste à décomposer les cloisonnements entre les différentes parties de l’organisation afin de fournir un flux de valeur complet. Fournir une culture où le commerce, le développement, l'assurance qualité, l'infrastructure, la sécurité, les opérations, etc. travaillent ensemble pour offrir une valeur ajoutée à l'utilisateur final. DevOps n'est pas un outil, vous ne pouvez pas l'acheter, vous devez changer de culture.

L'automatisation est un élément clé de DevOps en ce sens qu'elle permet une livraison rapide et de qualité. L’automatisation du processus de déploiement est l’un des domaines sur lesquels de nombreuses personnes se concentrent tout d’abord, car c’est l’un des meilleurs moyens d’acquérir rapidement de la valeur et un retour sur investissement élevé en réduisant non seulement le temps nécessaire au déploiement, mais également en normalisant le processus et en supprimant les coûts. les erreurs.


1

J'aimerais ajouter mes 2 centimes:
1) Automatisation :
     Quelque chose vers lequel nous devons actuellement nous déplacer. Il est devenu plus indispensable que la méthode privilégiée soit l’automatisation des pièces, si ce n’est tout le processus. Cette approche donne aux utilisateurs (développeurs) la souplesse nécessaire pour utiliser une étape fixe et leur permettre de personnaliser en fonction des besoins.
     L'avantage de cette approche est que nous pouvons automatiser les pièces que nous voulons tout en permettant au développeur de lier le processus individuel. Plus les étapes d’automatisation sont détaillées, plus elles ont un meilleur contrôle.
     En outre, il existe de nombreux outils pour l'automatisation dans des espaces tels que l'automatisation robotique, l'automatisation des SOP (pour l'industrie du service), l'automatisation des rapports (comme Splunk), etc.
2) DevOps:
     Compte tenu de la qualité et de la rapidité de livraison attendues dans le monde actuel, il est nécessaire d'étendre l'automatisation du processus de livraison de logiciels. Pour permettre cela et apporter de la valeur au client le plus rapidement possible, DevOps s'appuie largement sur des outils d'automatisation.
     L’avantage de cette approche est qu’il est possible d’automatiser les étapes individuelles afin d’assurer la cohérence au sein de l’entreprise, tandis que l’orchestration globale peut être modifiée pour s’adapter au processus requis par le projet.
     Les outils d'automatisation individuels (en quelque sorte) tels que Chef pour le déploiement, Docker via Dockerfile, Maven pour la construction, etc. peuvent être liés entre eux, probablement via Jenkins, pour fournir la solution requise tout en réduisant le temps nécessaire à la mise en oeuvre ou à l'utilisation. .
J'espère que cela vous aidera à ajouter de la valeur au processus de réflexion que vous pourriez avoir déjà.

Edit: J'ai oublié d'ajouter que j'avais parlé du processus et des outils - 2 des 3 aspects de DevOps. Comme mentionné par les autres, le troisième et tout aussi important aspect est celui des personnes. Une des différences majeures entre l’automatisation et l’automatisation est que les utilisateurs sont plus enclins à absorber l’automatisation plus souvent qu’ils ne résisteraient à DevOps. Je pense que cela est dû à la nature même de DevOps, en ce sens que l'automatisation est généralement associée à la simplification des tâches, alors qu'ils ont le sentiment que DevOps change la manière dont ils sont à l'aise.


1

Le mouvement DevOps comprend quatre zones principales abrégées en CAMS :

  1. Culture
  2. Automatisation
  3. La mesure
  4. Partage

Voici le post de définition original de 2010.

Dans chaque domaine, certains outils, processus et pratiques sont généralement acceptés, bien que le sujet ne soit pas bien défini pour les meilleures pratiques, mais il existe dans la plupart des cas quelques bonnes pratiques à suivre.

L'automatisation est un sujet un peu plus vaste, mais dans le contexte de DevOps, il ne s'agit que d'un sous-ensemble de ce qui est couvert. Prenez note que nous menons avec culture, bien que de nombreux praticiens de DevOps débutant sur le terrain l'ignorent souvent à leurs risques et périls et passent directement à l'automatisation.


-2

Automation et DevOps ne sont pas liés. DevOps s'apparente davantage à une ingénierie combinée dans laquelle les développeurs d'un site ou d'un service sont tous les opérateurs de ce site ou de ce service. Pourquoi ce roman? D'après mon expérience, la première chose que l'équipe des opérations a faite quand quelque chose de plus excitant qu'un coup sec sur le réseau s'est produit a été d'appeler l'équipe de développement. Pourquoi ont-ils fait ça? Parce que tout ce que l’équipe d’Ops avait fait, c’était surveiller et garder une liste des numéros de téléphone des développeurs à appeler.

Remarquez que je n'ai rien dit sur l'automatisation.

L'automatisation consiste à répéter le succès. Si je fais les étapes a, b et c et que le traitement X fonctionne toujours, les étapes a, b et c sont de bons candidats à l’automatisation. Ensuite, je peux utiliser le temps qui était auparavant un processus manuel pour faire des choses qui me rapportent plus d’argent. L'automatisation est réussie quand c'est simple. Déployer de nouvelles versions, exécuter des tests d'intégration, serrer un écrou sur un boulon, sauvegarder des données, équilibrer crédits / débits, etc. sont d'excellents candidats pour l'automatisation, car les étapes sont répétées, que ce soit par une personne ou par un robot.

Remarque : la nouveauté est que les développeurs sont également les opérateurs. Il n'y a pas un autre groupe. La coopération dans mon cas était rare. S'il n'y avait rien dans le Guide de dépannage (aussi appelé TSG), vous avez la garantie d'un appel téléphonique. D'après mon expérience, Ops était le premier appel en cas de pelle rétrocaveuse. Les problèmes entre les services étaient hors de leur timonerie.


Mais quelque chose, la coopération était toujours là, non? La communication entre dev et op, est-ce quelque chose de nouveau? qu'est-ce que devops apporte de nouveau?
pinkpanther

La nouveauté est que les développeurs sont aussi les opérateurs. Il n'y a pas un autre groupe. La coopération dans mon cas était rare. S'il n'y avait rien dans le Guide de dépannage (aussi appelé TSG), vous avez la garantie d'un appel téléphonique. D'après mon expérience, Ops était le premier appel en cas de pelle rétrocaveuse. Les problèmes entre les services étaient hors de leur timonerie.
Aucun remboursement, aucun retour

3
L'automatisation et les DevOps sont "non liés"? Respectueusement, je ne pouvais pas être plus en désaccord. L'intégration continue, le déploiement continu, les tests automatisés, etc., font partie intégrante du composant technologique de DevOps. Sans automatisation, DevOps n'est que culture. La culture est importante, bien sûr, mais ce n'est qu'une jambe du tabouret DevOps à trois pieds (Culture, Process, Technology)
Dave Swersky -

@NoRefundsNoReturns Les développeurs sont des opérateurs. Dans le sens où il n'y a pas besoin d'une équipe de devop?
pinkpanther

N'hésitez pas à être en désaccord. Nous avions des tonnes d'automatisation lorsque nous formions une équipe de "développeurs" et une "équipe d'exploitation". C'est pourquoi je dis qu'ils ne sont pas liés. L'automatisation pourrait se soucier moins de votre structure organisationnelle. Si vos développeurs sont également les opérateurs, il est fort probable que l'automatisation se produise car la plupart des développeurs sont paresseux et auront tendance à automatiser les tâches répétitives. Votre réponse m'embrouille @pinkpanther
pas de remboursement,
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.