NoOps et hyper-automatisation : la suite logique du DevOps ? 

NoOps : en route vers l’hyper-automatisation 

L’objectif initial du DevOps est la réduction des éléments générateurs de friction, aussi bien humains que techniques. Humainement, cela se traduit par une collaboration étroite du développement et de l’opérationnel et techniquement par une automatisation à outrance des étapes nécessitant de faible ou moyennes compétences. 

Cette collaboration n’est pas non plus sans impact dans la carrière des deux protagonistes. En effet, dans ce modèle, une évolution intellectuelle et technique est nécessaire afin que chaque partie puisse assimiler une partie des compétences de l’autre.  

Ces profils avec ces 2 casquettes nécessitent une certaine maturité et sont de plus en plus recherché sur un marché IT déjà tendu en termes de ressources et la numérisation de notre société en forte croissance ne fera qu’aggraver cette situation. 

Aujourd’hui, les grandes DSI ont atteint une certaine forme de maturité qui leur ont permis d’ajouter d’autres éléments différenciants à la chaîne DevOps : 

• Continuous Development : développer à la livraison de la dernière itération. 
• Continous Testing : tester en permanence que l’on développe. 
• Sécurité : qui s’intègre sdans tout l’aspect d’automatisation. 

Toutes ces évolutions permettent de converger vers une forme d’hyper-automatisation. 

Le NoOps en réponse à la pénurie de ressources sur le marché 

NoOps : transformation du métier de l’Ops 

Il faut tout d’abord casser le réflexe instinctif que l’on a vis-à-vis du NoOps, car cela ne signifie pas ne plus avoir d’Ops.

Le NoOps se définit par le fait de réduire au strict nécessaire l’intervention des opérationnelles vis à vis du métier et de la MOA. Le métier d’Ops se transforme en les sortant de leur intervention manuelle dans les déploiements classiques d’infrastructures. L’opérationnel devient un fournisseur de service sous forme de marketplace. 

Le rôle de l’Ops dans une logique NoOps consistera à remplacer ses activités manuelles par une automatisation complète du processus qui visera à déployer l’infrastructure, que ce soit vers un client final ou vers les équipes de développeurs par le biais d’un portail unique et centralisé. Le NoOps vise l’hyper-automatisation à travers l’Infrastructure as Code. 

Le NoOps naît de la volonté de dupliquer la méthodologie appliquée aux applications, aux infrastructures. Effectivement, dans un modèle DevOps, les entreprises ont tendance à descendre les problématiques techniques jusqu’aux dev alors qu’elles doivent rester côté Ops. Côté Ops en revanche, on doit être en capacité de produire des services dans un catalogue de services où le dev sélectionne ses services et les consomme sans se soucier ou être contraint aux exigences techniques même de ce service.  

Donc le modèle NoOps qui est en quelque sorte une suite logique, voire une résultante du DevOps, s’inscrit dans la continuité des enjeux qu’on a indiqué d’un point de vue ressources et gestion technique.  

NoOps : un changement de paradigme 

Cependant, le NoOps implique un changement de culture dans les équipes Ops. Il faut repenser les méthodes, les choix de solutions pour s’orienter vers un modèle microservices. Dès l’architecture, il faut penser ses briques d’infrastructure avec l’idée que ces briques puissent être automatisées. 

Il y aura toujours dans les équipes des exploitants N1 ou N2 en charge du maintien en condition opérationnelle. Ce serait un mythe d’affirmer qu’ils disparaîtraient totalement, mais aujourd’hui on attendra surtout des Ops qu’ils développent des compétences de développement (réalisation de scripts pour produire les environnements à la demande…) afin que le dev, ou le métier, puisse commander des environnements avec un provisionning rapide. 

NoOps et Infrastructure as Code (IaC) 

L’Infrastructure as Code 

Beaucoup d’outils permettent aux entreprises de converger vers le NoOps. Le plus connu concerne l’Infrastructure as Code (Terraform, Ansible, Puppet…) Comme dans toute chaîne DevOps, on va utiliser du Git pour suivre le code qui déploie notre infrastructure et pour avoir un suivi de version et de réversibilité. 

Dans le NoOps, on utilise les mêmes outils que pour le DevOps mais avec une finalité différente. Avant, Ansible ou Terraform étaient utilisés pour créer un environnement sur un projet. Avec la logique de NoOps, tous les scripts auront été variabilisés afin que l’utilisateur puisse automatiser totalement le provisioning des environnements. 

Ainsi, tous les éléments pouvant être irritants sur un projet côté infrastructure (renouvellement d’un certificat, ouverture d’une route, le cryptage de fichier ou le chiffrage pour être plus précis) seront générés, autogénérés ou autorégénérés si nécessaire. 

Sur des environnements cloud, où le NoOps sera plus facile à atteindre, beaucoup d’outils permettent d’atteindre l’hyper automatisation côté infrastructure : Azure Function, AWS Lambda, BizTalk… qui sont des outils type Function as a Service (FaaS). 

Le FaaS (Function as a Service)  

Le FaaS, ou « Function as a Service », est un modèle de service cloud qui permet aux développeurs de déployer et d’exécuter des fonctions (des morceaux de code) sans se préoccuper de la gestion de l’infrastructure, ce qui est optimal pour des tâches spécifiques déclenchées par des événements. Les fournisseurs de services cloud gèrent l’infrastructure, et les développeurs peuvent simplement charger leur code qui sera exécuté dans des conteneurs stateless qui sont déclenchés par des événements spécifiques (comme des requêtes HTTP). C’est une approche qui offre une grande flexibilité et est souvent utilisée pour créer des applications orientées microservices. 

Quelles différences entre le FaaS, le PaaS et le SaaS ?  

Le PaaS fournit aux développeurs une plateforme complète pour le développement et le déploiement d’applications, sans la complexité de la gestion de l’infrastructure sous-jacente. Le SaaS, quant à lui, propose des logiciels applicatifs accessibles via internet, gérés entièrement par le fournisseur de services, offrant une solution prête à l’emploi pour les utilisateurs finaux sans besoin d’installation ni de maintenance. Le FaaS se situe entre les deux. L’utilisateur déploie son application mais n’a pas à se soucier de la scalabilité, du monitoring, de l’obsolescence, de la sécurité… 

Bonnes pratiques et méthodologie pour une démarche NoOps 

Il y en a une multitude de bonnes pratiques et de méthodologies différentes qu’il faut savoir adapter à l’environnement de chaque entreprise.  

Nous vous proposons une liste de conseils proposés par nos Architectes DevOps pour aboutir à de l’hyper-automatisation via un modèle NoOps :  

• Tout d’abord, il est déconseillé de pousser les systèmes legacy vers un modèle DevOps ou NoOps. Cela fera perdre de l’énergie aux équipes et apportera une multitude de problèmes accidentogènes (bugs, incidents…) Il est préférable d’allouer une petite équipe au maintien du legacy le temps de mener la transformation DevOps ou NoOps. 

• Pour parvenir à faire émerger un modèle NoOps, il faut capitaliser sur les quick wins. Pour cela, on identifie les éléments les plus utiles côté infrastructure (par exemple, le renouvellement des certificats) pour déployer des efforts sur des cas d’usage qui apporteront des gains rapides dans une logique des 80/20. 

• Il faut s’appuyer sur le FaaS dans votre infrastructure en s’attachant aux éléments qui peuvent rapidement être problématiques dans un projet, surtout au début (dashboard à mettre en place, sécurité…) Vous pouvez vous appuyer sur des outils proposés par le clouder, des outils qui le font de manière automatique ou même développer votre propre solution. 

• Il faut également penser l’infrastructure avec peu d’interactions. Il ne faut pas perdre de vue que les dev ne sont pas des techniciens, et les contraintes ne doivent pas toute redescendre sur eux. Il est important de garder en tête l’objectif qui consiste à créer de la valeur à travers un catalogue de services à destination du dev. 

• L’endroit où concentrer l’effort est important. Il faut s’attarder en priorité sur les tâches de l’Ops qui sont à la fois consommatrices de temps et facilement automatisables, avant de se lancer dans l’automatisation de tâches trop complexes.  

• Dans beaucoup d’entreprise, il y a une multitude de langages qui existe pour faire la même chose. Il faut une forme de “police” afin de réduire le nombre de technologies, surtout quand on est en capacité de faire les mêmes choses avec une seule et même technologie. La réduction du nombre de technologies permettra d’atténuer le nombre de compétences nécessaires, un vrai avantage sur un marché de l’emploi en tension.  

• Centraliser l’ensemble des services dans une interface unique sous forme Retail / Market place avec une transparence sur le coût et les délais. 

• Enfin, il ne faut pas oublier qu’une technologie qui est “tendance” aujourd’hui peut ne plus l’être demain. Beaucoup peuvent se retrouver avec des composants techniques gérable par des ressources qui ne se trouvent plus sur le marché. 

Le NoOps dans la continuité du DevOps  

L’hyper-automatisation, possible avec l’aboutissement du modèle NoOps, permet aux entreprises de s’affranchir des contraintes techniques et se focaliser sur le business. Le dev est consacré à 100% au business et non à des tâches complexes (ex : ouverture de route). Vous pouvez donc consacrer votre temps et votre budget au développement, et non à l’infrastructure. Enfin, il est possible à terme de réduire le nombre de compétences nécessaires avant la mise en production sur un domaine particulier.  

Dans les écrits autour du NoOps, on peut retrouver une forme d’opposition entre le DevOps et le NoOps. De notre conviction, ce n’est pas la trajectoire à suivre. Pour Synapsys, le NoOps est une continuité du DevOps, et non un remplacement. Le NoOps permet de converger à de l’hyper-automatisation.  

Alors que le DevOps se concentre sur l’aspect collaboratif de la méthodologie agile, le NoOps quant à lui répond surtout à la problématique de ressources, de compétences et d’hyper-automatisation.

Pour aller plus loin

Article – DataOps, le DevOps pour la data ?