À quoi servent les analogies DevOps?

Certains présentateurs utilisent des analogies pour clarifier une certaine technologie, par exemple Pizza as a Service 2.0 qui explique les différences entre les différentes piles as-a-Service (aaS).

Les avantages de cette analogie avec Pizza est qu'elle se compose de plusieurs analogies, c'est-à-dire runtime aka pizza et fait maison aka legacy.

Quand on google "DevOps analogy", différentes images sont montrées, mais aucune d'entre elles n'est très accrocheuse.

Définition de «récupération»

1. Afficher l'image dans une présentation
2. Parlez-en 30 secondes
3. Pendant l'ascenseur, de plus en plus de gens comprennent DevOps et c'est parfaitement clair pour eux.

DevOps est l'industrialisation de l'informatique

Surtout pour les développeurs mais bien informés des autres avec le mème "fille de catastrophe": "Fonctionne sur ma machine .. Problème d'Ops maintenant!" Cela illustre que le manque de responsabilité peut mettre en danger l'ensemble de l'entreprise, et la valeur des logiciels fonctionnant uniquement dans un environnement spécifique n'est pas absolue.

Aussi, la matrice de l'enfer . L'ajout de Docker peut sembler être une colonne de plus, mais les conteneurs deviendront à long terme la technologie et l'architecture standard. Ainsi, vous pouvez également exécuter des conteneurs Docker avec Kubernetes ou Apache Mesos.

L'analogie DevOps la plus importante à laquelle je peux penser est l' analogie Pet vs. Cattle sur les infrastructures jetables. Cependant, je dirais que cela concerne moins la récupération associée à l'image, et plus la facilité de compréhension et de relation.

Un autre que j'aime est celui-ci de ce site Web https://devrant.com/search?term=devops

comme je l'ai entendu plusieurs fois et ça me frustre parce que c'est un comportement en silo et anti devops. Je veux essentiellement l'imposer, lorsque vous le changez, vous devez le libérer ou lorsque vous le cassez, vous le corrigez. En pratique, ce n'est pas aussi simple qu'un état d'esprit doit être changé.

Une autre analogie a été trouvée ici https://devrant.com/search?term=devops

Je pense que cela est également applicable car il y a encore des développeurs qui continuent de jeter des choses par-dessus le mur.

Je dois admettre que je ressens cela et que cela m'encourage à apprendre la programmation. J'apprends maintenant Java et je veux obtenir des certificats. J'étudie actuellement pour Java Oracle Associate.

Sur la base d'une suggestion dans l'un des commentaires à l'une des réponses de @PeterMuryshkin, j'ai lu plus sur Industry4.0 et je pense que cela pourrait être une analogie DevOps.

Une autre analogie DevOps pourrait être l'industrie 4.0:

L'industrie 4.0 est un nom pour la tendance actuelle de l'automatisation et de l'échange de données dans les technologies de fabrication. Il comprend les systèmes cyber-physiques, l'Internet des objets, le cloud computing et l'informatique cognitive. L'industrie 4.0 est communément appelée la quatrième révolution industrielle.

Pour introduire l'industrie 1.0, le processus fonctionnel, c'est-à-dire comment produire du coton manuellement, doit être clair afin d'automatiser cela, 2.0 automatisé davantage et 3.0 également. De nos jours, DevOps consiste également à automatiser de plus en plus, mais pour ce faire, le processus doit également être clair. Étant donné que 4.0 concerne le passage au cloud, par exemple AWS, GCP, AWS, CI / CD et les systèmes d'auto-réparation, cela pourrait également être une analogie.

DevOps pourrait également être comparé à une escouade de commandos, composée d'un petit nombre de spécialistes. Je dois toujours penser au premier niveau de Commandos 1 derrière les lignes ennemies. Il y avait trois personnages:

• Marin
• chauffeur
• béret vert

Chacun d'eux possède des qualités uniques: plongée, natation, aviron (marine), plongeur (mitrailleuse, conduite), béret vert (escalade, port de barils).

Tous ont réussi à éliminer les ennemis alias l'automatisation dans DevOps. Que les opérations puissent être comparées à la marine, le conducteur du béret vert n'a pas d'importance. Le fonctionnement, le développement et l'assurance qualité ont tous leurs spécialités. La combinaison de ces éléments est essentielle pour publier plus souvent des logiciels.

Si par exemple l'un des commandos est décédé dans le jeu, le jeu était terminé. Tous devaient travailler ensemble pour accomplir une mission. Je me souviens que chacun des commandos était isolé au début du niveau 1 et devait éliminer lui-même ses ennemis, mais ils dépendaient également les uns des autres.

Le marin devait amener le conducteur et le béret vert sur l'autre île car il était le seul à pouvoir ramer le coffre. Une fois sur l'île, le béret vert était nécessaire car il était le seul à pouvoir déplacer les barils explosifs nécessaires pour faire sauter la station de radio.

Quand ils travaillaient ensemble, il y avait plus de chances qu'ils puissent survivre car trois tirs étaient nécessaires pour éliminer un ennemi. S'ils tirent ensemble, l'ennemi est immédiatement éliminé.