NoOps arrive ??
NoOps arrive ??

NoOps arrive ??

Le monde a besoin d’effet de mode, la Tech ne fait pas exception loin s’en faut.

“The real goal of DevOps was faster, cheaper, better quality. With NoOps, instead of bringing developers and operators together to reduce friction is driving automation so that developers can focus even more on the code,” Corless adds.

Pour avoir entendu ici et ailleurs ce terme ‘NoOps’ j’ai voulu en savoir un peu plus. Je tente dans ces quelques lignes de décortiquer ce que le “concept” NoOps peut bien vouloir dire et d’y projeter notre quotidien, et pourquoi pas notre futur ...

Quelle définition peut-on lire sur la toile au concept NoOps ?

Littéralement : Absence de personnel d’exploitation. L’objet est donc de mettre en place process et outils pour que l’automatisation soit telle qu’il n’y ait plus besoin de personne pour intervenir sur une Infrastructure. Un lieu où il n’est même plus utile de combiner Développements et Opérations pour que les choses se fassent. La mort du DevOps assassiné par le NoOps ? Le NoOps poursuit donc un but ultime : faire en sorte que tout soit “déployable” par design, sans effort de personne. Cela semble pourtant simple à appréhender : à chaque commit du développeur sur son repo, tout est déployé, le concept de CI/CD poussé à son paroxysme; Applications et infrastructures main dans la main dans un ballet automatisé et sûre.

L’accélérateur de cette approche semblerait moins philosophique que technologique, l’automatisation et les outils afférents n’ayant jamais été aussi performants que de nos jours.

NoOps est-il alors une réalité ou même une possibilité ?

Mettons de côté un instant les applications construites pour être serverless (un post complet sur ce sujet devra être écrit tant il y a à dire). Considérons une architecture* composée d’un cluster K8S managé (GKE ou EKS) quelques computes pour des briques applicatives existantes (je n’ai pas écrit Legacy, opposé à la vision extrémiste d’un monde où les applications seraient legacy à peine passées leur premier anniversaire …). Et enfin dans notre architecture quelques services managés bien utiles, citons une base de données (CloudSQL ou RDS) et un service de gestion de messages (Memorystore ou ElastiCache).

*Je choisi à dessein une infrastructure construite sur GCP ou AWS, on ne va pas se refaire, SKALE-5 est née et grandie avec cette finalité...

A partir de cette architecture somme toute assez standard et commune pour tenter ici l’exercice d’une approche NoOps :

  • IaC à 100%, c’est jouable, clairement une cible à viser et à atteindre. À partir du moment magique où tout est en place, on projette les futures évolutions (car il y en aura*) dans les mains uniques des Dev. Ils devront prendre du temps pour acquérir un minimum de compétences et pour réaliser ces actions. Très rapidement la promesse du NoOps comme modèle économique frugale et d’une vélocité garantie sera vraisemblablement remis en cause …
  • *La nature des changements est longue comme la liste de Prévert : faire face aux fluctuations du trafic (tout n’est pas autoscalling), ajouter des composants imposés par les Dev. eux-mêmes, intégrer les nouveautés du Cloud Provider, gérer des contraintes sécuritaires et autres up-dates, OS pour ne citer qu’eux, etc…

  • Déploiement applicatif en continue engageant le minimum d’efforts et sans intervention. Dit autrement automatisé. Dit encore autrement une vraie et belle CI/CD. C’est un voeu parfois bien pieux. Tous ceux qui se seront frottés au sujet auront de cuisants souvenirs d’une stack technique un peu ancienne ou une conception d’architecture logicielle bien stateful freinant de tout son poids les initiatives pour rendre dociles ces fameuses mises à jour applicatives. Rien n’est simple ici et il faudra faire preuve de beaucoup de créativité, et de pugnacité dans certains cas, pour arriver à un résultat qui ne nous affranchira pas complètement d’une petite conf. à la main …

  • Autant de scripts d’automatisation, autant de maintenances à faire. Autant de librairies et d’outils autant de dettes progressives. Autant de pipeline définies, autant de compétences à garder et à documenter. Le poids de l’automatisation n’est pas neutre, et si on considère qu’il s’agit bien de code, ce n’est pas celui qui produit des features aux utilisateurs, objectif premier des équipes de Dev... Il faudra donc bien quelqu’un pour s’occuper de toute cette machinerie. On ne se libère pas des Ops, on fait “shifter” leur job vers d’autres tâches. Appelons cela si vous le voulez bien des travaux DevOps …

  • Une dernière touche à la mise en place du NoOps : l’IA. Vous aurez l’occasion de croiser quelques slides et arguments vantant l’IA comme la clé du NoOps. Auto-découverte des composants, analyse des transactions ou encore autorésolution nous promettent bien des merveilles heuristiques qu’il faudra appréhender quand elles seront un peu plus matures … « l’Autonomous Cloud Enablement », peut-être même un Buzzword à surveiller ?

Alors si on a pu observer que la promesse NoOps a une réalité relative dans un contexte de Production existant, on peut s’interroger sur sa promesse dans un contexte FEUILLE BLANCHE, où tout est à écrire depuis zéro. Cette “start-up” bercée par la comptine “You build it, you run it” pourra se jeter à corps perdu dans cette quête. Prenons alors le temps de proposer quelques conseils :

  • Optez pour du serverless et/ou une application pleinement containers reposant sur Kubernetes. Et formez-vous …
  • Simplifiez à outrance votre stack technique. Et oubliez les toutes dernières nouveautés et autres empilages de techno …
  • Simplifiez à outrance vos étapes de mises en production pour construire un système de déploiement robuste. Et passez vraiment du temps à parfaitement l’automatiser …
  • Livrez en continue sur la Production. Et intégrez immédiatement vos tests fonctionnels et techniques dans vos déploiements automatisés …
  • Mettez en place des outils de monitoring. Et maintenez les triggers de supervision qui doivent voir les problèmes avant vos utilisateurs …
  • Build it, Run it. And don’t forget to be ready taking action at any time. Il faudra bien quelqu’un pour intervenir un soir ou un week-end …

Le concept NoOps est basée sur l’hypothèse que l’automatisation peut tout réaliser, éliminant par ce fait l’intervention de l’Homme. Tenter de construire une architecture sans aucun point de failure n’octroie aucune certitude sur sa parfaite résilience. Par ailleurs comme nous l’avons vu plus haut, les systèmes plus anciens cohabitent (et pour encore longtemps) avec des applications plus modernes et Cloud native. Ce faisant l’automatisation et les promesses d’IA ne seront pas effectives sur l’ensemble IT qui constitue le SI de nombreuses entreprises.

“the more complex a system is, the more likely it will need to have humans to [help maintain it],”

“human skills will always be needed for some monitoring, troubleshooting and repair taskssays” Charles Betz Forrester Research principal analyst

OUI ! l’automatisation est la clé de voute des nouvelles Productions modernes en suivant l’objectif d’une infrastructure “smart” avec peu d’efforts de maintenance et aussi automatisée que possible. Pour autant imaginer un monde NoOPS remplaçant celui du DevOps est une hypothèse que de très rares organisations arriveront à mettre en place.

De ce point de vue, qu’est-ce que NoOps ? un nouveau Buzzword trending du monde inventif du Cloud. Il faut reconnaitre que l’on se lasse vite et qu’un Buzzword en chasse vite un autre …

Je doute que NoOps soit un futur, j’ai tendance à croire que le DevOps a déjà en soit cette tendance naturelle à automatiser un maximum de choses. C’est sûre, l’automatisation aura un immense impact sur les populations IT, mais on ne s’affranchira pas de compétences pour gérer cette automatisation. Finalement ce que l’on fait déjà aujourd’hui en pratiquant “correctement” du DevOps …

Ken Corless, principal chez Deloitte Consulting LLP résume ainsi : NoOps as the “pinnacle of the DevOps mountain.” Je préfère de loin : Automation as the “pinnacle of the DevOps mountain.”

Mais à toute médaille son revers, l’automatisation apporte aussi son lot de problèmes et de paradoxes. Qu’adviendra-t-il quand le “pilote automatique” fera quelque chose qu’on ne comprend pas (ou que peu de personnes pourront comprendre …). D’ailleurs verra-t-on toujours et immédiatement quand quelque chose ne va pas ? L’automatisation est inévitable et souhaitable, mais comme n’importe quel outil il peut aussi profondément desservir.

“automation brings speed and potentially lower costs, but organizations also need stability, reliability and resiliency — characteristics that automation can both help and hinder depending on how it’s used and managed.” Charles Betz Forrester Research principal analyst.

NoOps est une jolie vue conceptuelle, elle pousse dans son sillage d’excellentes choses, mais elle restera surement inaccessible; À l’instar du Golf la carte parfaite d’un parcours en 18 coups n’existe pas …

Merci pour votre lecture. Si cet article vous a plu, merci de le partager sur vos réseaux 😉

Jean-Pierre Chamarande - Nov 21, 2019

image