Les acronOps se sont infiltrés dans notre quotidien depuis quelques années. Vous en connaissez sûrement. Il y en a même parmi vous !
Qui sont-ils ? Que veulent-ils ? À quoi servent-ils ? Peut-on les apprivoiser ?
Commençons par découvrir ce qui se cache derrière ce mot.
acronOp nom masculin
: mot valise faisant la contraction du mot "acronyme" avec le terme "ops".
Tout débute avec un Ops. Comprenez un opérateur, autrement dit : gestionnaire de production ; membre du support technique. Son rôle est simple, il déploie les applications, les maintient en condition opérationnelle, surveille que tout se passe bien, résout les incidents, assure la communication aux clients et à la direction. On parle des équipes qui coûtent de l’argent à l'organisation, surtout s'il y a des astreintes ou du 24/7, mais ne produisent pas de valeur.
De l’autre côté, il y le Dev. Comprenez un développeur, autrement : création d’application, traducteur des besoins clients, fournisseur de fonctionnalités. À travers leurs lignes de code, les équipes de développement produisent de la valeur.
Le problème est que l’Ops n'apprécie pas le changement, alors que le Dev en crée régulièrement. Ces derniers doivent collaborer. Bien souvent, ils ne comprennent pas.
Le Dev se demande fréquemment : pourquoi ne livre-t-on pas plus vite ? Quand pourrais-je commencer à travailler sur l'environnement de dev ? Mon code fonctionne sur mon environnement, pourquoi il ne fonctionne pas en prod ?
Et l’Ops de rétorquer : pourquoi est-ce en panne ? Vous avez encore introduit un bug. Votre plateforme n’est pas ISO prod, c’est normal que ça ne fonctionne pas de la même manière !
Face à ce qui semble être une impasse de communication, s'ensuivit une longue réflexion puis un jour, LA solution !
DevOps
On a mis un Dev et un Ops dans une centrifugeuse, on a mélangé très fort. Tadam ! Le premier acronOp est né : le DevOps. On peut dire qu'il s'agit du Guizmo des acronOps.
Plus concrètement, Patrick Debois, Gene Kim et John Willis ont donné naissance à ce terme en 2007, pour tenter d’apporter une réponse aux silos caricaturés plus haut. Leur but, pousser la coopération au sein de l’organisation. Notamment au niveau des équipes IT.
Dans l’industrie, différentes philosophies ont émergé tel le taylorisme, le toyotisme, l’approche rugby ou le lean. En s’inspirant de ces dernières, ils ont imaginé une organisation dans laquelle les équipes IT réussiraient à travailler ensemble, en réduisant les points de friction.
DevOps : les 3 voies
La philosophie DevOps repose sur 3 principes :
- Vision globale du flux / système
- Amplifier les boucles de retour d’information
- Culture de l’expérimentation et de l’apprentissage
Vision globale du flux / système
Source : IT Revolution
Le premier principe se focalise sur la performance de l’ensemble du système. Un système peut être une organisation entière, une division, une équipe, un individu. Le focus est placé sur le flux de création de valeur qui est réalisé par l’IT. Cela démarre par l’identification des prérequis, passant par le développement, le déploiement et termine quand la valeur est livrée au client sous forme de service.
Les résultats de ce principe sont de :
- atteindre une compréhension profonde du système
- ne jamais livrer un problème à l'étape suivante
- ne jamais autoriser une optimisation qui crée une dégradation globale
- toujours chercher à améliorer le flux
DevOps encourage l'automatisation mais ce n'est pas une fin en soi. Le premier pilier a pour but principal l’identification des processus et des points de blocage ou d’engorgement. Automatiser ce qui est possible vient après.
Amplifier les boucles de retour d’information
Source : IT Revolution
Le second principe repose sur la création de boucles de retour d’information de la gauche vers la droite. Il est courant d’entendre l’expression "shift left" pour exprimer le fait d’anticiper certains éléments dans la chaîne de production qui est représentée par un déroulé de gauche à droite. Ici, il est question de raccourcir et amplifier les communications permettant d’apporter continuellement des correctifs.
Le résultat de ce principe est de comprendre et de répondre à tous les clients, internes et externes.
Culture de l’expérimentation et de l’apprentissage
Source : IT Revolution
Le troisième principe veut créer une culture qui encourage l’expérimentation continue et la compréhension de l’intérêt de la répétition et de la pratique pour atteindre la maîtrise. L’expérimentation continue pousse à prendre des risques et apprendre des échecs. Quand la répétition et la pratique sont les fondements pour la maîtrise.
Ces deux éléments permettent de progresser et de réduire les risques quand ils sont rencontrés. Leur allouer du temps régulier est essentiel pour la réussite de cette voie.
Dev(x)Ops
Comme évoqué plus haut, DevOps est le Guizmo des acronOps. Il a suffi de l’asperger un peu pour le voir se multiplier. Parmi les plus courants, nous avons :
- DevSecOps : une organisation DevOps qui intègre un focus sur la sécurité
- DevGreenOps : une organisation DevOps qui intègre un focus sur la sobriété numérique
- DevTestOps : une organisation DevOps qui intègre un focus sur le test Etc.
(x)Ops
Cette multiplication n’a pas suffi à assouvir le besoin d’envahissement des acronOps, tels des Pokémons, d’autres sont apparus au fil du temps. Certains sont des évolutions, d’autres des nouveautés.
La plupart présentent une déclinaison des pratiques issues de la culture DevOps apportés à un élément spécifique de la chaîne de production.
Bien souvent leur nom est explicite et permet de comprendre le sujet principal. Alors que la partie Ops résume la gestion des opérations autour du sujet préfixé. Ces acronOps se présentent comme inspirés par la culture DevOps, ou comme réponse à une organisation non prise en compte par cette dernière. La plupart découlent d’une mécompréhension ou d’un besoin d’apporter une terminologie pour (re)lancer une mode. Les Dev(x)Ops étaient clairs sur le fait d’apporter une accentuation de la culture sur un axe particulier. Les (x)Ops se montrent un peu plus flous et sont même présentés en opposition à leur parent.
NoOps
Celui-là est à la fois le vilain canard de la bande et mon préféré. Présenté par Forrester Research, son but est de supprimer l'Ops. À peine quatre ans après la publication de la culture DevOps, il est temps d’aller au bout de l’idée, l’Ops devient une histoire du passé.
Si les Dev ne veulent pas s'asseoir avec les Ops pour déployer plus efficacement, pourquoi les embêter avec une culture de collaboration. Allons au bout de l’idée : les Ops sont un frein, retirons-les. Comment ? Grâce aux automates, les systèmes de résilience, les clouds et leurs infrastructure-as-a-service ou platform-as-a-service.
Bien que très alléchante pour certains, cette vision ne s’est jamais réalisée. Il faut tout de même reconnaître qu’il y a des pistes de réflexions à creuser derrière cette idée. Comment rendre la vie des utilisateurs la plus simple possible ?
L’auteur, Mike Gualtieri est avant-gardiste. À l’époque, l’IA n’est pas un phénomène de mode omniprésent. ChatGPT, Copilot, Gemini, Claude et Le Chat sont très loin de leur couffin. Depuis leur apparition, certains remettent cette théorie au goût du jour : l’IA finira par remplacer l’Ops et pas seulement lui. Le terme AIOps est venu remplacer le NoOps, en y apportant quelques variations.
L’avenir nous dira ce qu’il en est.
NetOps / NetOps 2.0 / DevNetOps
Un acronOp à trois noms pour désigner une évolution dans la gestion des réseaux. Le but du NetOps est d’apporter les pratiques encouragées par le DevOps à l’administration réseau.
Les réseaux sont des composants d’infrastructures moins dynamiques que les applications. En dehors des structures d’hébergement Internet ou des clouds, les besoins en modification et automatisation sont assez faibles.
La démocratisation des clouds privés et publics a apporté un besoin de flexibilité et de réactivité. Les équipes ont dû s’adapter en s’inspirant notamment des outils et pratiques incitées par le DevOps.
La particularité du NetOps est qu’il est désigné sous trois termes qui recoupent la même idée. La désignation NetOps 2.0 est dérivée du Web 2.0. Tandis que le terme DevNetOps est un Dev(x)Ops qui indique que la gestion du réseau est intégrée dans la logique DevOps.
SecOps
De la même manière que le NetOps, la naissance du SecOps est une application de la culture au domaine de la sécurité. Il n’est pas rare de voir la sécurité évoquée en fin de chaîne de production. On y pense une fois l’application déployée. Ce qui n’est pas sans causer des problèmes, en termes de communication et de technique. Aujourd’hui, la sécurité est très médiatisée. La plupart des acteurs du numérique ont une sensibilité à ce sujet. Ce qui n’était pas le cas il y a quelques années. Le SecOps est donc une réponse à ce besoin de démocratiser et sensibiliser l’ensemble des acteurs à la sécurité.
Par ailleurs, son autre rôle est d’apporter aux équipes en place, une méthode de travail leur permettant de limiter les points de friction. Notamment en intervenant plus tôt.
À l’image du NetOps, le SecOps est un acronOp que l’on retrouve sous la dénomination DevSecOps pour indiquer que la sécurité est intégrée dans la logique DevOps.
NetSecOps
Le NetSecOps peut être considéré comme un mariage du NetOps avec SecOps. Il témoigne d’une volonté de collaboration étroite entre la gestion de réseau et la sécurité.
ChatOps
Le ChatOps est différent des autres acronOps, ici point de méthodologie, nous sommes face à un outil. Jesse Newland, de GitHub, a donné naissance à cet acronOp en 2013. L’idée est de fluidifier les échanges entre les équipes en passant par un chat bot. Les commandes lancées dans le chatbot permettent de lancer des scripts, des actions, des vérifications, etc. L’usage n’est pas réservé aux acteurs techniques. Il suffit de créer des commandes qui répondent aux différents besoins.
L’intégration de commandes dans un canal de communication est inspirée des pratiques d’automatisation que l’on trouve dans les clients IRC. Il s’agit d’une application de la culture DevOps. Aujourd’hui, il est courant de voir des outils de ChatOps, notamment dans Slack, Discord, GitHub et GitLab.
DataOps / MLOps / AIOps
La fratrie suivante est presque indissociable. Pourtant, chacun a sa spécificité. Nés à un an d’intervalle, le DataOps, le MLOps et l’AIOps traitent des pratiques DevOps autour des données.
Le DataOps est la pierre angulaire de ses frères. Il commença par apporter des pratiques au milieu de l’analyse de données pour évoluer vers une approche spécifique à la gestion des données.
Grâce à cela, le MLOps a pu se concentrer sur la gestion des modèles d’apprentissage automatique. Il apporte des pratiques DevOps pour la gestion des modèles, de leur déploiement et de leur maintenance. Dans ce domaine, la gestion de la donnée est primordiale. C’est pourquoi le DataOps est souvent un point de départ pour les équipes qui veulent se lancer dans le MLOps.
Le cadet de la fratrie, l’AIOps s’appuie sur les données issues de l’observabilité, analysées via les modèles de Machine Learning, pour apporter des réponses, voire des actions pour la résolution de problèmes de production. Il est l’écho du NoOps mentionné plus haut.
Sans DataOps et MLOps, point d’AIOps. Il est, à date, peu probable que son avènement découle sur le NoOps. Par contre, il s’avère être un compagnon de plus en plus utile.
Source : unravel
GitOps
Voilà un autre acronOp particulier : le GitOps. Théorisé par Weaveworks, il est une proposition de flux de travail autour de l'IAC (Infrastructure As Code). L’infrastructure est déclarée dans des fichiers. Ces fichiers sont versionnés dans un dépôt Git. L’infrastructure est déployée à partir de ces fichiers. Les changements sont gérés via des pull-requests. Les déploiements sont automatisés avec un déclencheur humain ou automatique selon le niveau de maturité des contrôles. Le schéma ci-dessous illustre ce flux.
Source : Rafay
Bien entendu, la culture DevOps a influencé la création de GitOps, qui est aujourd’hui très répandu, pour ne pas dire omniprésent, dans les écosystèmes clouds.
FinOps / GreenOps
Que dire des siamois FinOps et GreenOps. Ils partagent leur Genèse, bien que nés en décalage : l’usage des ressources des infrastructures incitées par la flexibilité que le DevOps veut apporter doit être maîtrisé. Tous deux regardent ces ressources. L’un, tel Picsou, ne jure que par le sou. L’autre, tel Captain Planet, se focalise sur l’empreinte environnementale. Pourtant, leurs actions apportent souvent les mêmes conséquences, via les mêmes méthodes. Seule la grille de lecture change.
Il faut reconnaître que leur naissance était nécessaire pour calmer l’euphorie encouragée par les clouds publics.
Leurs amis
Depuis 2020, aucun nouvel acronOp. Du moins aucun qui n’ait pris le focus. Peut-être que la pandémie a eu raison de leur créativité. Ou sont-ils suffisants pour apporter les variations que l’on souhaite pour exprimer la culture DevOps ?
Pour autant, ils sont toujours présents et ne sont pas seuls. Deux amis les accompagnent : SRE et Platform Engineering.
Site Reliability Engineering
Terme inventé chez Google, derrière cet acronyme se cache un rôle, un état d’esprit et une somme de pratiques. Site Reliability Engineering, l’ingénierie de la fiabilité des sites en français, est une discipline considérant l’ensemble de la chaîne de production pour garantir la fiabilité des services. Historiquement, ces acteurs sont nommés ingénieurs de production.
Les éléments fondateurs de cette ingénierie sont très similaires, voire identiques à ceux du DevOps, à la différence que le SRE veut répondre aux problèmes de fiabilité de la production. Là où le DevOps veut fluidifier la chaîne de création de la valeur.
Centré sur l’expérience de ces clients, le SRE cherche à répondre au mieux à ses besoins. Pour cela, il s’appuie sur différents indicateurs, qu’il partage avec l’ensemble des équipes.
Très rapidement le SRE a vu la synergie avec la culture DevOps, c’est pourquoi il l’encourage et l’applique.
Platform Engineering
Ce n’est pas le dernier de la bande et pourtant, cet ami des acronOps est le dernier à occuper l’espace médiatique. Le Platform Engineering est une démarche qui vise à construire et maintenir une plateforme self-service pour les équipes de développement.
Cette plateforme fournit des outils et des services (comme l'infrastructure, les pipelines CI/CD, la supervision, etc.) qui automatisent et simplifient les tâches opérationnelles, permettant aux développeurs de se concentrer sur leur code plutôt que sur la gestion de l'infrastructure. L'objectif est de fournir une expérience utilisateur fluide et efficace, réduisant les frictions et accélérant le cycle de développement.
La création d'une plateforme de ce type nécessite une collaboration étroite entre les équipes de développement et les équipes d'opérations. Il s'agit de définir les besoins des développeurs, de concevoir une architecture robuste et évolutive, d'implémenter les outils nécessaires, et de maintenir la plateforme en état de fonctionnement optimal. Le Platform Engineering met l'accent sur l'automatisation, l'observabilité et la sécurité, afin de garantir la fiabilité et la performance des services fournis.
En résumé, il s'agit d'une approche qui favorise l'autonomie des développeurs, leur permettant de déployer et de gérer leurs applications plus rapidement et plus facilement, en utilisant une plateforme fiable et sécurisée.
Il n’est pas rare de voir çà et là des articles indiquant que le Platform Engineering remplace DevOps. Il n’en est rien. Nous sommes plutôt face à un complément. Le Platform Engineering est une réponse à une organisation qui veut aller plus loin dans la collaboration et l’automatisation.
Conclusion
Les acronOps sont nés pour apporter une réponse aux problèmes de fluidité dans la chaîne de production. Initialement ciblées entre les Dev et les Ops dans les entreprises tech, elles ont vite élargi le cadre de cette nouvelle culture à l’ensemble de l’organigramme.
Chaque nouvel acronOp apporte une déclinaison de la culture DevOps. Ils partagent tous leur vision sur la collaboration, la fluidification des échanges entre les équipes et les étapes de la chaîne de production. Toujours dans un but d'améliorer la qualité et la vélocité.
La plupart portent sur l’organisation des équipes. Quelques-uns représentent des pratiques spécifiques, comme GitOps et ChatOps. Il est intéressant de voir les différentes compréhensions de ce qu’ils véhiculent. Le site DevOps topologies présente les implémentations que l’on trouve couramment.
Si vous en croisez un, n’ayez pas peur. C’est un ami qui vous veut du bien. Essayez de le comprendre et de l'apprivoiser.
Retenez surtout qu’aucun ne s’oppose aux autres. Chaque variation veut apporter un focus sur une partie de l’organisation. Complémentaires, ils peuvent être introduits dans l’entreprise en même temps. Comme le mentionne Kadia Himeur :
Le DevOps est avant tout et surtout une histoire de collaboration, de process et de culture.
Quant à leurs amis, ce sont des compléments essentiels pour une organisation qui veut aller plus loin dans la collaboration et l’automatisation.
Platform Engineering supports SRE. Good SREs implement DevOps. cf. The New Stack & Google
📝 Cet article fait partie du "Advent of Tech 2024 Onepoint", une série d'articles tech publiés par Onepoint pour patienter jusqu'à Noël.
Voir tous les articles du Advent of Tech 2024 d'ici Noël.
Top comments (0)