Posts | Louis Holleville

L'agilité distordue

Thu, 11 Jan 2024 14:55:00 +0000

La méthodologie Agile, à travers ses différents frameworks (XP, scrum, kanban …), est porteuse de nombreuses promesses.

Les individus et leurs interactions, de préférence aux processus et aux outils

Des solutions opérationnelles, de préférence à une documentation exhaustive

La collaboration avec les clients, de préférence aux négociations contractuelles

La réponse au changement, de préférence au respect d’un plan

La grande force de l’agilité réside dans la livraison incrémentale de fonctionnalité dont le retour client va permettre l’ajustement au fur et à mesure du développement. En passant ainsi d’un effet tunnel type waterfall à une livraison continue, le client co-construit la solution finale. Excellent moyen, donc, d’assurer une satisfaction d’un produit dont nous sommes partiellement lauréat de son achèvement.

La méthode Waterfall

Avant l’agilité, la méthode Waterfall était la plus répandue dans la gestion de projet. Méthode simple à comprendre, elle consiste à mettre une emphase sur la phase préparatoire afin que la réalisation qui s’ensuit n’ait qu’à suivre un chemin si balisé que l’exécution et le résultat ne dévient que peu du plan.

Waterfall workflow

Un exemple de conduite de projet waterfall pourrait être la construction d’une voiture comme suit: on prend le besoin du conducteur, on designe l’ensemble des plans pour la voiture de rêve du conducteur puis on envoie la voiture en production à l’usine. Une fois la voiture produite, on la teste pour s’assurer de son bon fonctionnement et on la livre au client. Enfin, on se chargera de maintenir la voiture durant toute sa durée de vie chez le client.

La méthode Waterfall présente aussi certaines contraintes:

la phase de préparation étant conséquente, l’accueil du changement en cours de route s’en voit restreint, sans incidence minime.
le risque de non-alignement des besoins. Le recueil du besoin n’étant effectué qu’en début de projet, son développement est en tunnel, coutant cher et d’autant plus si le résultat atteint manque le besoin.

Avec notre exemple de voiture, voici ce qui pourrait rater:

les plans réalisés ne reflètent pas une réalité technique réalisable en usine.

les cycles de tests montrent des défaillances techniques ou de design qui nécessite le renvoi dans des étapes précédentes.

le client voulait une citadine et pas un SUV.

L’alternative agile

L’agilité, au contraire, intègre le besoin client tout au long du développement du projet. La phase initiale d’expression du besoin est plus courte. Les livrables arrivent aussi plus rapidement, à peine fonctionels et gagnent en consistance au fur et à mesure des livraisons. L’intérêt réside dans la prise de retour des clients et de leur besoin afin d’ajuster au fur et à mesure. Cela permet ainsi d’optimiser toute la production en ne fournissant à chaque fois exactement que ce qui est attendu.

Le client souhaite une voiture. Le besoin est pris et synthétisé, les équipes commencent à réfléchir au design. Les premières ébauches sont présentées au client qui précise ses attentes. La carcasse est envoyé à l’assemblage et le client valide la structure. Le moteur est ajouté mais à l’inspection, le client souhaite un moteur plus modeste: le moteur est changé. A terme, le client obtient une voiture complétement assemblée et fonctionnelle.

Les limites

Cependant, cette promesse papier est soumise à la réalité du marché et du business. Si les livraisons sont devenues régulières, c’est aussi parce que le financement des projets s’est échelonné, sous réserve de preuve de satisfaction.

De nombreuses entreprises distribuent des budgets périodiques à leurs projets/département. Leur montant se base sur des résultats précédents, à venir ou attendus. Cela permet aussi de rectifier ces budgets et de ne pas avoir à immobiliser de grosses sommes d’argent (parfois) inutilement.

Et dès lors, cette condition de la satisfaction se transforme en quête de l’approbation. Et c’est ici que le glissement peut s’opérer. Nous sortons du rationnel, et de la proposition de mener le projet à terme dans le bon ordre, pour se concentrer sur le “waow”. Si le stakeholder voit des choses qui lui plaisent, il valide. Peu importe si cela ne fait aucun sens dans la production du projet, ou pire, peu importe si cela ralentit/perturbe son bon déroulement. Et comme le stakeholder est souvent impliqué, de près ou de loin, dans le budget du projet, il est vital qu’il propage un avis positif.

Les postes de ceux qui distribuent les budgets sont aussi éjectables l’un que l’autre. La crédibilité et la longévité reposent donc à miser sur les bons chevaux.

Et l’agilité s’en retrouve ainsi tordue. La porte est grande ouverte pour que le chef du projet se rapproche du PO avec une nouvelle idée qui va impressionner les stakeholders. La vision même du projet s’en trouverait compromises ? Peu importe, maintenant que le chef de projet sait que l’agilité accueille “volontier” le changement. Et difficile ensuite pour le PO de revenir à la charge avec des arguments rationnels car il faut rappeler d’une deuxième realité, le chef de projet a, très souvent, l’ascendant hiérarchique dessus.

Qui n’a jamais entendu au daily son PO annoncer une “NOUVELLE REGLE !” ?

Tous les milieux ne fonctionnent pas comme cela et les cas où la gouvernance joue cavalier seul ne sont pas généralité. Mais plus il y a de la place pour la politique en entreprise, plus l’agilité devient une arme dans cette guerre de pouvoir.

Découvrez le GitOps !

Tue, 28 Mar 2023 22:50:00 +0000

Le GitOps est une approche de la gestion opérationnelle qui utilise Git comme source de vérité pour l’infrastructure et les applications qui y sont déployées. Cette méthode repose sur l’idée de versionner des fichiers de configuration et les définitions d’infrastructure dans un référentiel Git, qui sert de source unique de vérité pour tous les composants du système.

Ainsi, avec le GitOps, toutes les modifications apportées à l’infrastructure ou aux applications sont effectuées via des modifications du référentiel Git, que ce soit manuellement ou au travers de processus automatisés. Par exemple, lorsqu’un développeur effectue une modification de code et la pousse sur le référentiel Git, l’outil de déploiement GitOps détecte cette modification, construit l’application et la déploie automatiquement sur l’infrastructure appropriée. L’état de l’infrastructure est mis à jour, tenant en compte ce dernier ajout.

Les avantages de GitOps sont multiples et convergent, dans la mouvances DevOps, à rationnaliser les processus tout en les rendant plus accessible, plus ouverts:

Source unique de vérité: le GitOps se basant sur le versionnement des ressources, il consistue l’unique référence de l’état de l’infrastructure. Non seulement on réduit le facteur humain dans la connaissance de cette infrastructure, mais en plus on en simplifie la gestion et on en assure la cohérence!
Intégration continue: le gitops se marrie parfaitement avec l’automatisation. On peut ainsi tirer toute la puissance de l’approche DevOps en prolongeant le déploiement continu applicatif avec le déploiement continu d’infrastructure. On augmente la SLA, on effectue des MEP précises, fiables et répétables!
Tracabilité: le code étant versionné, on exploite également toute les capacités à tracer les changements, à maitrise qui peut publier; un gros atout pour la sécurité. Enfin, tel d’authentiques dévelopeurs, on mets à disposition la capacité à revert des changements dans le code et donc l’infrastructure !
Collaboration: un des gros enjeux de l’infrastructure est de sortir de cette fatalité que l’infrastructure est inaccessible au commun des mortels. Désormais, l’infrastructure est décrite sur YAML (ou autre) de manière (presque) lisible pour l’humain et surtout, centralisée. Il faudra peut-être s’équiper d’un dictionnaire infra->français dans un premier temps mais rien que ce changement est un pas de géant!

En termes plus techniques, il existe quelques outils qui permettent d’orchestrer clés-en-main du GitOps dans un contexte applicatif Kubernetes. Les deux outils pertinents selon moi sont:

FluxCD: un outil open-source qui se déploie en mode serveur sur le cluster cible directement et qui permet de définir des workflows personnalisés. Cet outil est destiné pour être manipulé en CLI mais est très léger.
ArgoCD: également open-source, l’outil est très complet et un peu plus conséquent à deployer (Helm est votre ami). Il est orienté GUI et permet une gestion fine des utilisateurs permettant à ces derniers d’avoir eux aussi la main sur la gestion d’environnement. J’ai personnellement une préférence pour ce dernier, je vous laisserai chercher pourquoi.

Il existe également d’autres outils, ou d’autre méthodes de gérer du GitOps. Certains impliquent une gestion un peu rock&roll de gitlabCI, GitHub Action et cie . D’autres, comme JenkinsX (Jenkins dans le nom) ne m’attirent pas forcément pour l’instant.

En conclusion, le GitOps est un outil puissant pour la gestion de la configuration et le déploiement continu des applications, qui offre une source unique de vérité, une automatisation continue, une visibilité et une traçabilité complètes, une collaboration efficace et une sécurité renforcée. Le GitOps est une tendance en forte croissance et à raison: simplicité, accélération des déploiements tout en réduisant les erreurs humaines.

Une note sur le multicloud

Sat, 10 Dec 2022 14:55:00 +0000

Il y a quelques jours, j’ai pu assister à une conférence dont le sujet traitait du multi-cloud¹. Le contenu même de la présentation ne s’est finalement révélé n’être qu’un tableau pros/cons bancal sur le multi-cloud. Finalement, la partie la plus intéressante aura été la séance de question-réponse. Comme j’ai été très sceptique sur les réponses de l’intervenant ou même sur sa posture un peu trop enthousiaste pour le multi-cloud, je souhaitais faire quelques retours sur cette thématique et donner ma position.

Le multi-cloud n’est pas aujourd’hui quelque chose de souhaitable.

Et je vais commencer par rappeler, tels mentionnés par l’intervenant, les bénéfices du multi-cloud :

la capacité à faire jouer la concurrence sur les services négociés. Et c’est tout. Et même sur cet unique avantage, nous pouvons en rediscuter, car dans un contexte où juste trouver un ingénieur infrastructure est un parcours du combattant, souhaitons nous vraiment dilapider cette précieuse bande passante sur un multi-cloud ?

La seule raison qui peut mener à une situation de multi-cloud acceptable serait le legacy, comme par exemple l’acquisition et fusion. Autrement, n’y allez pas volontairement, car devoir travailler sur le plus petit dénominateur en commun de différents clouds nous ferait faire un retour en arrière de 10 ans. L’avenir du cloud est dans le managé, est dans le vendor-locking. C’est assez choquant à dire, mais comprenons que les ressources des DSI sont limitées. A tel point qu’investir l’équivalent d’un salaire dans un outil qui économiserait des mois-hommes est le genre de levier qui permet, en définitive, de gérer efficacement son budget. Ne soyons pas frileux de nous engager profondément avec un fournisseur, quels qu’il soit, car toute la puissance de leur solution prend vraiment sens quand on se donne la peine de les utiliser pleinement. Et ce n’est pas achevable ici pour le multi-cloud. Très peu d’entreprises sont capable de revendiquer un lift&shift indolore, bien au contraire. Cela me désole d’autant plus que des cabinets tels que celui du présentateur font conseil sur ce type d’infrastructure chronophage, et c’est bien dans leur intérêt.

La seule chose achevable par le multi-cloud est de réinventer la roue à vos frais.

On parle ici de l’utilisation de 2 fournisseurs cloud ou plus pour la gestion d’infrastruction, d’opérationel. Il n’est pas question de parc hybride ici. ↩︎

A propos de la complexité d'utilisation des ressources AWS

Thu, 08 Sep 2022 17:55:00 +0000

Le Cloud est un outil merveilleux, la flexibilité qu’il nous donne est d’une plus-value incomparable aux infrastructures d’il n’y a pas si longtemps. Plus besoin d’être dans le prédictif, dans l’anticipation du besoin, plus besoin d’expert CISCO introuvables et hors de prix. Pourquoi s’encombrer d’autant de savoir et de couches de savoir quand d’autres peuvent le faire bien mieux, de manière mutualisée et abordable ? Récemment, j’ai eu l’occasion de travailler sur les aspects réseaux de notre infrastructure à WeMaintain et de redécouvrir l’énorme palette d’outil proposé par AWS pour résoudre le moindre de nos besoins. Mais l’expérience n’a pas été aussi ergonomique qu’à ce que j’aurai pu m’y attendre. L’aurait-elle due?

La dynamique des acteurs cloud ces dernières années a été de rendre de plus en plus de services accessibles, à moindre coût. Ainsi, beaucoup d’infra y ont vu naissance et beaucoup d’existante y ont migré. Parralèlement, l’accès à ses services s’est simplifié, rendant l’attrait plus fort et l’expérience utilisateur plus engageante, selon moi. Dans cette dynamique, en 2022, je me suis attelé à vouloir créer un réseau virtuel privé (VPC) dans AmazonWebService (AWS) afin de tester la possibilité de créer une zone isolée d’internet, dont l’accès n’est possible que depuis un bastion et dont le but est d’opérer uniquement des services internes à notre SI. Dans un monde idéal, ce VPC n’était connecté à internet que pour les besoins de mises à jour de ses composants.

Initial needs schema

La réalité de l’exécution a été légèrement différente et c’est la que nous rentrons dans le vif du sujet. Quand bien même l’accès à ces services s’est simplifié, leur usage est resté à peu près le même. CICD, sous-réseau, gateway mais si tout les mots-clés n’y sont pas, l’ensemble des notions restent le même. Il y a même désormais une couche supplémentaire: celle du provider cloud. En ajoutant leur interfacage sur ces concepts réseaux, ils ont développé leurs propres modules qui répondent à leurs propres règles et recommandations. Ainsi, un expert réseau se doit désormais d’être aussi un expert réseau cloud. La complexité monte quand d’Azure à AWS les noms, les règles changent également. Et nous voilà avec une toute nouvelle profession. Non pas que cela soit gênant, car elle couvre bien plus de besoin avec moins de compétente, mais qu’on aurait pu s’attendre à ce qu’elle n’existe pas du tout.

En effet, j’ai été fortement étonné quand j’ai eu, moi-même, à mettre en application des architectures réseaux basées sur des besoins basiques. Créer un VPC isolé d’internet ne me semble pas si spécifique. Créer un VPC dont l’accès depuis l’extérieur est impossible ne me le semble pas non plus. Et pourtant, c’est à moi de faire les recherches, de me documenter pour accomplir cela selon le standard du provider cloud en question.

Ne serait-on donc pas encore à l’apogée du cloud et du no-infrastructure ? Car si une dynamique est claire, c’est bien celle de rendre le cloud si accessible que le seul métier qui y soit associé soit “expert clic-clic AWS/Azure/etc”, si cela devait encore être un métier et pas juste une formation.

Toujours est-il que mon métier d’ingénieur m’a permis de m’en tirer en une après-midi. Peut-on aller plus loin?

Le schéma final de l’infrastructure de mon projet ressemble finalement à cela et je l’imagine être le standard, selon mes recherches.

Final VPC schema

Il aurait même pu être encore plus parfait si je ne m’étais pas rendu compte que des acteurs tels GitHub¹ ne gérait pas encore l’IPv6 et si je n’avais pas eu à intégrer une couche IPv4 en dépit, j’aurai eu un egress IPv6 only, ce qui est vachement sexy.

Dans un futur proche ?

Shame ↩︎

ArgoCD en production chez WeMaintain !

Sun, 28 Aug 2022 16:00:00 +0000

Pourquoi ne pas gérer son SI tel un produit métier ? Consommateurs, clients, fournisseurs, MVP, stakeholders, planification; plus j’y réfléchis et plus j’y vois de notions communes.

Tout ce qui nous manquait serait donc le lien entre la théorie et la pratique ?

Plus tellement désormais: Infrastructure as Code, Network as Code, DevOps et maintenant #gitops, tous ces concepts prennent forme au travers de solutions telles Terraform, Istio, Ansible, Argo et tant d’autres. Mis bout-à-bout, l’évolution d’un SI est désormais complètement possible au travers du code, comme un projet dans son ensemble, et peut lui-même être sujet à de l’automatisation de son déploiement (InfraOps donc? :p). L’infrastructure devient réactive. Les technologies cloud nous permettent désormais une grande flexibilité, nous ne sommes plus dans l’anticipation à quelques années mais dans la réaction à quelques minutes. L’infra devient apparente, malléable et peut désormais suivre de prêt les besoins métiers. Ses processus d’exploitation sont automatisables et rationalisables, en maximisant la répétabilité et réduisant le facteur humain, le rêve. CI over GitOps, canary et blue-green permettent même désormais un workflow de livraison automatisé, de la plus petite intégration à la mise en prod. Et le plus important, d’autres personnes ont désormais cette possibilité de consulter ce “nouveau” code, d’y contribuer, de le questionner et d’y apporter une vision fraîche, naïve, vitale.

Ayant posé la première brique GitOps à WeMaintain la semaine dernière, je me réjouis déjà de constater la confiance grandissante dans nos process et suis impatient de pouvoir aller encore plus loin. Et, je dois dire, c’est un réel plaisir de travailler dans un milieu qui vise aussi loin et s’en donne les moyens.