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 : 

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 :  

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.  

Slide12 1

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.