Curieux d’en savoir apprendre sur le NoOps ? Vous avez raison, c’est une des prochaines révolutions techniques annoncées.
Laissez les développeurs exprimer tous leurs talents en les libérant des restrictions imposées par l’exploitation est considéré comme le Graal pour n’importe quel éditeur d’application.
C’est la promesse d’applications plus fluide, plus rapides, plus agiles… Un prérequis indispensable à n’importe quelle société pour surmonter le tsunami de transformation numérique.
Et pour rappel, à cause de l’augmentation de l’adoption des technologies, personne n’est à l’abris de ce tsunami de transformation digitale.
Ce Graal est matérialisé depuis quelques années par le terme NoOps (littéralement Plus d’opérations).
L’objectif est une automatisation complète du déploiement, de la surveillance et de l’administration des applications, ainsi que de l’infrastructure sur laquelle elles s’exécutent.
En d’autres termes, l’objectif du NoOps sera d’automatiser entièrement le déploiement d’applications et d’infrastructures sans intervention humaine.
Dans la suite de cet article vous comprendrez :
- Comment est né le NoOps ?
- Comment le différentier du DevOps ?
- Comment faire vos premiers pas dans ce nouveau monde ?
Pourquoi le NoOps ?
Pour bien comprendre le NoOps il faut se replonger dans le passé et les différentes évolutions en termes d’exigences des Systèmes d’information.
Step 1, le modèle en cascade ou Waterfall
Le modèle en cascade est une méthode héritée de l’industrie ou de la construction. Industries, dans lesquels une conception préalable est nécessaire étant donné les fortes contraintes matérielles et des coûts élevés afférents aux changements de la conception en cours de réalisation.
Ce modèle a été et reste utilisé dans de nombreuses organisations sous forme de cycles en V (modèle identique à la cascade mais avec un renforcement des étapes de validation).
Dans ce modèle nous intégrons en avance des infrastructures technologiques solides, pérennes… qui permettront de répondre aux besoins du projet pendant longtemps.
Ce modèle à l’avantage d’être très strict et « solide » mais il a le fort désavantage d’être très rigide et souvent long à déployer.
Step 2, le modèle agile
Ces modèles en cascade ont engendrés des coûts opérationnels importants pour les DSI (maintenance d’infrastructure, maintenance des environnements…).
De plus ces modèles ne sont plus adaptés à des organisations en recherche constante d’agilité.
Nous constatons donc la naissance des modèles agiles avec :
- Une meilleure collaboration entre les équipes
- Une plus forte autonomie des équipes
- Une équipe de développement plus proche des opérationnels
Je vous conseille de lire l’article ci-dessous si vous voulez en savoir plus sur la méthode agile.
Step 3, Le serverless
Pour servir ce modèle agile, les géants de la Tech ont créés le serverless.
L’architecture serverless est un modèle dans lequel le fournisseur de services cloud (AWS, Google cloud, Ms Azure) est responsable de l’exécution d’un morceau de code en allouant de manière dynamique les ressources.
Et le top du top est que ce fournisseur de service ne vous facturera que ce que vous utilisez.
Ce modèle serverless n’est pas sans impacts sur les équipes informatiques. Car elles doivent repenser l’ensemble de leurs programmes sous forme de micro services.
Fini donc les gros monolithes difficiles à faire bouger et bonjour les applications (voir des fonctions) dédiées à des fonctionnalités.
Step 4, DevOps mais pas encore NoOps
Cette organisation agile ne peut fonctionner que dans la mesure ou tout devient agile. Y compris la gestion d’infrastructures.
Et les besoins sont nombreux pour être réellement agile. Il faut faire évoluer son organisation IT pour être capable de réaliser plusieurs étapes clés.
Intégration Continue, Continuous Integration
L’objectif de l’intégration continue sera d’augmenter la fréquence de regroupement des codes des développeurs en toute sécurité.
Chaque modification importante d’une équipe de développement déclenche la création d’un build afin de détecter au plus tôt les anomalies dans le cycle de développement à l’aide de tests unitaires et fonctionnels automatisés.
Les anomalies sont détectées plus facilement et rapidement car il y a de fortes chances qu’un problème se trouve dans le dernier lot de code fusionné.
Les retours en arrière (rollback) sont plus simples car les modifications isolées peuvent être annulées dans le référentiel de code.
Livraison Continue, Continuous Delivery
La livraison continue est la suite logique de l’intégration continue et permet de publier en production plus rapidement les nouveautés applicatives.
Ce processus permet de créer, tester et déployer plus rapidement des logiciels en privilégiant des mises à jour incrémentielles au lieu de refontes complètes.
C’est un gain de temps significatif à l’équipe de développement qui n’a plus besoin de préparer la publication du code en amont.
Le code est mis à jour en continu pas l’équipe grâce à la publication incrémentielle dans un environnement de test (pour garantir la cohérence fonctionnelle).
Grace à cela non seulement les tests sont automatisés mais le processus de publication sera également capable de déployer, seul, une nouvelle version de l’application.
Après la validation des tests (sur un environnement dédié et identique à la production) les sources de trafic des environnements pourront être inversées afin de mettre à jour l’application.
En cas de bug sur le nouvel environnement, un retour en arrière sera simple il suffira de ré-inverser les environnements.
Déploiement Continu, Continuous Deployment
Le déploiement continu est la version améliorée de la livraison continue.
Le code est automatiquement testé, validé et mis en production avec « simplement » un monitoring des problèmes susceptibles de nécessiter un retour arrière.
La seule chose qui pourra empêcher le déploiement en production d’une version applicative sera l’échec d’un test automatisé.
Avec ces concepts, il est maintenant possible de livrer fréquemment de nouvelles fonctionnalités en diminuant au maximum le nombre d’incidents.
L’objectif étant que la mise en production devienne un non-évènement.
Enfin, Le NoOps
Dans le concept de NoOps l’infrastructure doit également être déployée automatiquement sans intervention humaine.
L’ensemble des concepts développés ci-dessus doivent pouvoir aussi s’appliqués aux infrastructures.
L’Infrastructure as Code va permettre l’automatisation de la gestion, l’approvisionnement et la mise à l’échelle de l’Infrastructure informatique grâce à du code.
Ceci repose sur des outils qui permettent une abstraction de haut niveau des ressources d’infrastructure grâce à des syntaxes déclaratives des états souhaités.
Si vous voulez en savoir plus sur le sujet, je vous conseille de vous renseigner sur l’outil Terraform.
Finalement le NoOps est, à l’image du développement applicatif, une automatisation des processus de gestion de l’infrastructure.
En conclusion, pour le NoOps
Ce sont les exigences en termes de qualité, cohérence et agilité qui amènent progressivement les organisations vers un concept NoOps.
Le DevOps n’est pas mort, il est simplement entrain de muter vers des environnements plus agiles, plus automatisés et plus « dev ».
Ceci pour permettre aux infrastructures des applications d’être plus proche de la réalité des métiers et des développeurs d’applications.
Comme vous avez pu le constater ci-dessus, le NoOps ne sera pas accessible à tous.
Il nécessitera de nouveaux processus opérationnels et une adaptation forte de l’ensemble de l’organisation.
