Les fondamentaux du DevOps

Dans un monde submergé par le software et les « applis », l’informatique (et pas que) doit se transformer, s’adapter pour délivrer « vite et mieux », elle doit coller aux attentes des clients (internes et/ou externes) et en plus elle doit amener des bénéfices financiers !

Pour tenter d’approcher ces objectifs au plus près, il faut changer le cycle de vie des applications et surtout radicalement modifier la façon de les amener aux clients.

Bonne nouvelle ! Des démarches existent pour répondre à ces défis sur la partie organisationnelle / culturelle :

Schématiquement :

• Lean Management (élimination des gaspillages, qualité, chaîne de valeur…)
• Agile (Itérations, l’humain au centre, équipes autonomes…)
• ITIL (standardisation, contrôle et organisation, stratégie…)

Source: Extrait de la présentation de Nigel Thurlow © Toyota Connected

Ces trois « piliers » de méthodologie apportent tous des aspects complémentaires pour obtenir une culture permettant de répondre aux objectifs Business.

La place du DevOps

Le DevOps vient compléter ce trio par de la technique et des outils, en prenant en compte la valeur des méthodologies associées

Source : slideshare.net

C’est à la rencontre de ces 4 aspects que l’on produit le plus de valeur pour l’entreprise.

Le DevOps est donc un moyen, une méthodologie pour maîtriser toute la chaîne de valeur, du métier vers la production. C’est également un environnement technique, des outils et des façons de travailler qui sont spécifiques.

Le système doit fonctionner en fonction de la vue du client final, mais ce n’est pas suffisant !

Il nous faudrait une formule magique pour que nous ayons en plus :

• De la rapidité (Time To Market)
• De la qualité (Code / Delivery / production) sur toutes les étapes de construction et de livraison de l’application
• Une amélioration de l’expérience client

Comment le mettre en œuvre ?

Il faut dans un premier temps casser les barrières :

Techniques :

Les « Devs » recherchent plus de réactivité : il faut aller vite, ajouter de nouvelles fonctionnalités, déployer rapidement sur de nouveaux environnements pour tester… C’est la nature même du code : malléable, adaptable.

A l’inverse, la production a besoin de stabilité et de standardisation.

Stabilité, car il est souvent difficile d’anticiper quels impacts aura telle modification de code, d’architecture ou d’infrastructure.

Standardisation enfin, car la production veut s’assurer que certaines règles soient uniformément respectées pour assurer la qualité de service de l’infrastructure.

Reste que ces deux groupes, « devs » et « ops » ont pourtant bien un objectif commun : faire fonctionner le système vu du client final

source : https://www.semanticscholar.org/

Organisationnelles :

Pour maîtriser la chaîne de valeur dans son ensemble, il faut une vision globale qui peut être amenée par des équipes pluridisciplinaires (Dev/Ops et même métier) : une culture de la collaboration

Ceci passe également par une transformation de l’organisation pour passer en mode produit (feature teams / pizza teams …)

Et la technique ?

Ce sont justement les outils techniques et les méthodes utilisés par l’équipe DevOps qui permettent d’apporter une réponse.

Si on devait résumer en quelques mots clés :

• Automatisation
• Continuous Everything
• Feedback permanent (et donc également indicateurs temps réels, tests omniprésents…) technique et utilisateurs
• Collaboration

Le cycle DevOps est caractérisé par cette fameuse boucle qui représente les diverses étapes de construction et de mise à disposition d’une application, d’un software :

Techniquement, chaque étape nécessite un savoir-faire et des outils différents, complémentaires.

Le « secret » de la démarche technique est d’être effective sur tout le parcours, avec le moins d’intervention humaine possible ce qui permet d’avoir un résultat fiable, automatisé et prévisible, accompagné d’un fonctionnement itératif court permettant une réactivité et une qualité supérieure (il est plus efficace de gérer une petite implémentation.)

Il faut donc, par exemple, développer et tester sur des systèmes similaires à ceux de la production, développer et déployer avec des processus réutilisables (Infra As Code, gestion des configurations, Continuous Integration and Delivery/Deployment (CI/CD)), surveiller et valider la qualité opérationnelle.

Source : CNCF Cloud Native Interactive Landscape

Même si l’automatisation est en place, ces étapes doivent se dérouler de manière continue, ce qui implique un temps d’attente le plus court possible et des process imbriqués les uns aux autres.

Source : pluralsight

Outils :

Les outils utilisés pour mettre en œuvre ces différentes phases sont très nombreux ! Pour preuve un échantillon de ce « paysage » ( https://landscape.cncf.io/ )

Source : CNCF Cloud Native Interactive Landscape

Voici une autre illustration d’un exemple d’environnement DevOps, l’important étant d’avoir une continuité et donc une compatibilité (via plugin ou autres) entre les outils pour pouvoir opérer en continu.

Métiers

Cette organisation et ces outils amènent une approche globale. Pour autant, quoiqu’en disent de nombreux CV ?, le reflet de cette approche ne peut être que multidisciplinaire pour avoir une expertise élevée et constante sur l’ensemble de la chaîne.

Un ingénieur DevOps n’existe donc pas ?

Il existe mais sur une portion du cycle de vie : naturellement un « ops historique » maîtrisera (et préférera) les outils d’infra as code, de déploiement et de monitoring alors qu’un « dev historique » aura une expertise plus poussée sur le build du Code et ses test. Cependant, les parois deviennent poreuses et la collaboration amènera forcément de la montée en compétence sur les sujets non maîtrisés.

J’en profite pour placer ici que la démarche DevOps est très alignée avec une organisation de l’entreprise en mode produit, ce qui amène au sein de l’équipe, par ex, un Product Owner et un Scrum master (Brièvement : le Product Owner recueille et priorise les besoins clients , le Scrum Master aide à appliquer la méthodologie et anime les rituels d’équipe)

Au niveau de l’hébergement et de l’infrastructure, il ressort quelques éléments importants :

• Le container est roi, le COE est l’empereur :

Le container est le chemin le plus proche vers l’application. Il permet l’isolation de chaque composant de celle-ci (microservices). Il permet donc d’exécuter, par exemple, différentes versions du même produit (dépendances différentes) au sein du même host physique. La solution phare est Docker qui s’intègre parfaitement à la plupart des pipelines de développement.

Source : aws

Qui dit Container dit COE (container orchestration engine) et donc Kubernetes (ou encore Apache Mesos ; Docker Swarm ; Nomad et autres…).

Source : CNCF Cloud Native Interactive Landscape

Ces plateformes permettent d’obtenir une infrastructure au service de l’application : scalabilité pour répondre à la demande, sondes de vie pour relancer les composants défaillants, gestion des secrets (tokens, passwords, certificates…), immutabilité, mises à jour applicatives simplifiées…

• Les composants de l’infrastructure sont autant d’interfaces pour l’automatisation du cycle de vie des applications :

Les différentes ressources de l’infrastructure doivent pouvoir être consommées à la demande par les développeurs et donc par l’orchestrateur.

Il devient donc de plus en plus crucial, dans une approche DevOps, de posséder des composants d’infrastructure compatibles avec ces plateformes.

Par ex côté stockage : CSI (Container Storage Interface)

https://kubernetes-csi.github.io/docs/drivers.html

Ou encore côté réseau CNI (Container Network Interface)

Source : CNCF Cloud Native Interactive Landscape

• La donnée reste au centre de certaines problématiques :

Dans cet environnement nouveau/adapté, il faut savoir gérer la donnée et sa protection !

Certes, dans ce monde « Cloud Native », les applications devraient se protéger seules mais il est important de prendre en considération la donnée :

• Plan de secours – plan de continuité de service (réplications, copies de données…)
• Backup (solution compatible Namespaces Kubernetes par ex.) et archivage
• Protection ransomware (snapshots par ex.)

Et d’autres impératifs liés à la donnée…

Les solutions d’infrastructure doivent donc rester capables d’adresser ces besoins. (Même si ces infrastructures sont hébergées dans le Cloud public, il est nécessaire de connaitre et d’appliquer les bonnes pratiques de protection de la donnée et de sa bonne répartition)

• Le Cloud public :

Le choix de l’hébergement peut donc être un facteur de simplicité pour répondre à ces besoins, toutes les infras on-premise n’ont pas la possibilité d’être élastiques, d’avoir un environnement optimal pour la mise en place de ces environnements.

Même si certains Clouds privés pourraient répondre à ces besoins, il est parfois naturel de se tourner vers des infrastructures managées, dans le Cloud Public, pour bénéficier de tous les avantages qu’apporte l’orchestration de containers (infrastructure et outillage).

Les offres des hébergeurs Clouds Publics proposent toutes un environnement managé possédant, pour chaque phase de la boucle DevOps les outils correspondants. (Azure pipeline ; AWS code pipeline ; GCP cloud Build pour le CI/CD par ex.). Il est également possible d’interfacer d’autres produits DevOps avec ces outils.

DevOps et la sécurité : le DevSecOps

L’apparition de cette nouvelle méthodologie DOIT être accompagnée d’une démarche sécurité durant toutes les phases du cycle, du développement à la mise en production.

Bien entendu, sa mise en œuvre implique une automatisation systématique pour suivre la célérité des étapes et ses itérations courtes.

Succinctement :

• Plan : Insérer les exigences de sécurité dans le backlog et/ou dans les critères d’acceptance
• Code : analyser le code source pour détecter des vulnérabilités connues (SAST : Static Application Security Testing)
• Build : Analyser les vulnérabilités connues sur les composants / frameworks (SCA : Software Composition Analysis)
• Test : Framework de tests spécifiques de sécurité
• Release : SCA et/ou CSA : Container Security Analysis, pour les environnements containerisés
• Deploy : Identifier les défauts de configuration, attaques pré-définies (DAST : Dynamic Application Security Testing)
• Operate / Monitor : Auditer la sécurité en continu, mettre en place des agents de sécurité, tester son application. (DAST, RASP : Runtime Application Self-Protection)

Il serait très difficile d’avoir un expert sécurité dans chaque équipe, elle doit cependant être en relation étroite avec celles-ci, par exemple en ayant un « Security Ambassador » par Squad.

De par nature, la méthodologie DevOps est automatisée, journalisée et standardisée, ce qui est un atout pour la sécurité :

A titre d’information, le point de vue de la CSA (Cloud Security Alliance)

Est-ce rentable ?

Il est souvent mis en avant que l’approche DevOps possède un réel intérêt économique :

• Optimisation du temps : En automatisant les déploiements et le développement, on laisse l’opportunité aux équipes de tester différentes versions ou fonctionnalités, d’innover, de passer moins de temps à corriger les erreurs éventuelles.
• Retour sur investissement accéléré : En déployant les logiciels plus rapidement et en misant sur des processus fiables et automatisés. Le « Time to Market » est réduit, l’investissement est lissé sur la livraison de nouvelles fonctionnalités.
• Amélioration de l’expérience client : Grâce au feedback permanent associé à la démarche, et aux itérations courtes, le produit s’adapte rapidement aux attentes du client.

Source : medium.com

• Augmentation de la fiabilité, disponibilité du service : Les itérations courtes permettent de n’ajouter que de petites modifications à la fois sur les applications, d’où une fiabilité augmentée et un temps de réparation amélioré.

Ces différents facteurs combinés doivent apporter un ROI assez significatif (bien sûr dans le meilleur des mondes !)

Avant de partir …

Ceci est juste une ébauche de compréhension de ce grand monde qu’est le DevOps et j’ai forcément oublié quelques éléments, mais il en ressort de toute façon une nouvelle approche de la construction d’une application jusqu’à sa mise en production, autant techniquement qu’au niveau humain et organisationnel.

Le DevOps n’est pas une philosophie en tant que tel, comme on peut l’entendre. Le DevOps utilise et s’inscrit dans des démarches plus globales comme l’Agile ou le Lean Management.

C’est un ensemble constitué d’outils techniques, de best practices, de communication et de compétences associées, qui fait que la mise à disposition de software répond aux besoins actuels (rapidité, qualité, amélioration expérience utilisateur, ROI…)

Et vous, comment définissez-vous le DevOps ??