01 Jul 2020, 06:19

Pourquoi AWS, Azure et GCP dominent-ils le cloud public ?

Cloud

Un web décentralisé, entre trois entreprises…

Les clouds US cités sont de bons produits, il serait malhonnête de dire le contraire et je travaille régulièrement avec. Mais l’hégémonie de ces clouds publics me pose un problème, une très grande partie du web repose sur 3 acteurs qui sont de plus des GAFAM. Les chiffres sont assez éloquents : AWS 41,5 %, Azure 29,4 % et GCP 3 % de parts de marché (selon l’infographie de visualcapitalist).

Parts de marché

Le web qui se voulait un exemple de décentralisation de l’information se centralise de plus sur des entreprises qui détiennent déjà beaucoup d’espace numérique. De plus, ils sont tous des géants américains, il n’y a aucune souveraineté au niveau des autres pays en particulier pour l’Europe et la France. Je ne parlerai pas du marché asiatique que je ne connais pas assez.

La souveraineté n’est pas le seul problème, ces plateformes ont la main sur la majorité du web et vont donc pouvoir à terme contrôler l’information au niveau mondial. On en a des exemples précis aujourd’hui, notamment de la part de Micorosft qui par l’intermédiaire de Github aide les autorités espagnoles à enrailler l’organisation des manifestants Source.

Mais il n’y a vraiment pas d’alternative locale à cela ? Oui, il y en a aujourd’hui, par exemple : OVH, Clever Cloud, Outscale, Scaleway ! Alors nous allons parler du sujet qui fâche, pourquoi ne sont-elles pas aussi populaires ?

Cloud francais

Un peu d’historique

Revenons quelques années en arrière tout d’abord. Les grands acteurs du web grossissent à toute allure avec l’explosion d’internet, cela leur demande de revoir leurs organisations et leurs stack techniques. Ils vont littéralement repenser l’informatique en interne, c’est ainsi que certaines bases du DevOps, l’utilisation massive d’API et surtout le cloud (tel qu’on le connaît) vont émerger, il découvre avant tout le monde l’informatique de demain.

On va s’intéresser à l’une de ses grandes entreprises, que vous connaissez forcément, car on y trouve de tout de A à Z (d’où le logo) sur leurs sites ; Amazon. Leurs sites connaissent des pics de charge conséquent et leurs équipes ont un gros besoin de flexibilité sur l’infrastructure, ils vont donc investir massivement dans un système de cloud privé ultramoderne. Ce système va se montrer très efficace et là Amazon va avoir une idée qui va les propulser au sommet des acteurs numériques : “Vendre le fruit de leurs travaux sur une plateforme de cloud publique”. Cette plateforme qui sera nommée Amazon Web Service pose les grandes lignes du cloud public moderne. Amazon va proposer de plus en plus de services entièrement managés par leurs soins, payable à la minute totalement contrôlable par API ! Une révolution dans le secteur où beaucoup vendaient surtout du serveur dédié.

L’expérience qu’ils ont acquise en interne pour héberger Amazon va leur donner une grande longueur d’avance sur beaucoup de gros hébergeurs classiques, qui vont rapidement se retrouver dépassés sur ses sujets et le gros changement de paradigme du cloud public. Microsoft et Google vont emboiter le pas à AWS en utilisant eux aussi leurs expériences historiques. Cela à permis à ses trois acteurs de se placer en position de leader sur le marché du cloud publique.

Il fut compliqué pour les autres acteurs de s’aligner et de proposer des services d’une qualité aussi rapidement sans se ruiner en Recherche et développement. Et même si cela fut possible les autres acteurs ont continué d’investir massivement. Pour vous donner un ordre d’idée de la machine de guerre qu’est la Recherche et développement d’une entreprise comme Amazon, un fait simple : en 2018 Amazon a dépensé 22,6 milliards de dollars en recherche et développement (plus grosse dépense de Recherche et développement au monde), très peu, voir aucun acteur en dehors des GAFAMs ne peut investir de telles sommes.

Recherche et développement

On se retrouve donc avec des acteurs qui ont littéralement des années d’avance. Ce qui nous fait rentrer dans une boucle, leurs avances font venir des clients, donc leur font rentrer de l’argent pour améliorer toujours plus leurs services et attirer de nouveaux clients.

Le virage du PaaS

Comme le dit le fameux adage: le cloud c’est juste l’ordinateur de quelqu’un d’autre. Ce n’est pas nouveau et ça existait depuis pas mal d’années, mais là où les géants on sût disrupter comme disent les jeunes startupeurs, c’est sur le service. À l’époque ou Amazon développe son cloud, la grande majorité des concurrents propose surtout des offres d’infrastructure, c’est-à-dire de la machine virtuelle et du réseau (IaaS), or a cette époque va se démocratiser la notion de service managé PaaS qui va changer profondément le marché.

Plutôt que louer des serveurs qu’il faut gérer au niveau système maintenir et sécuriser notamment, le PaaS va vous proposer directement des Middlewares prêts à l’emploi et gérés par l’hébergeur. Cela peut paraitre très basique, mais ça été un réel changement de paradigme, réduisant la charge de maintenance et en rendant plus accessible à tous beaucoup d’infrastructure. Cela vient d’une approche très business : vous gérez ce sur quoi vous apportez de la valeur ajoutée le reste vous le sous-traitez.

Ce virage a été assez brusque, notamment grâce à des budgets d’innovation démentielle comme je le disais précédemment. Les acteurs alternatifs se sont un peu retrouvés perdus sur ce point et ont tardé à réagir, ce qui avait laissé par mal d’avance sur le marché aux Google, Microsoft et Amazon.

Verrouiller le marché

Donc là vous vous dites ils ont de l’avance c’est tout, mais vous vous doutez bien que ce n’est pas aussi simple. Quand vous êtes leader du marché, votre objectif est bien sûr de le rester, pour ça il faut établir une position de domination sur le long terme. Pour cela il y a des armes destructrices que ces entreprises ont utilisées en masse.

  • Le réseau de partenaires

La plus efficace, les partenariats, rendez-vous dans la majorité des écoles aujourd’hui, elles sont partenaires d’AWS, Azure ou encore GCP, ce qui permet aux étudiants de découvrir ses technologies le plus souvent gratuitement. Mais alors, ces entreprises que je décrivais plutôt comme de méchantes sociétés capitalistes prêtes à tout pour écraser son prochain, sont-elles devenues de belles entreprises bienveillantes œuvrant pour le bien de l’humanité ? La réponse est bien sûr non, le but est là de conditionner les étudiants, si dans leurs formations vous leur apprenez uniquement certaines technologies ils iront naturellement vers ses choix qu’ils connaissent et qui sont rassurant pour eux une fois en entreprise.

Prenons un exemple, une étudiante qui s’appelle Éloise, elle étudie dans une école d’informatique dans le but d’obtenir un master en architecture des systèmes d’information. Dans ses cours, elle a les grandes technologies classiques qui sont utilisées aujourd’hui, mais aussi les nouvelles comme le cloud. Pour le module cloud elle va utiliser Azure, ce qui est parfait vu que son cursus a déjà signé de nombreux partenariats avec Microsoft pour les cours de système. Elle va apprendre Azure et se concentrer dessus pour son examen, elle n’aura pas le temps de s’attarder sur une autre technologie. Elle réussit son examen haut la main, Microsoft l’invite à passer une certification gratuitement, elle la passe et la réussi là encore sans problème. Éloise décroche son master quelques mois plus tard, elle est comme tous les étudiants informatiques débauchés par de nombreuses entreprises, en majorité des ESN. Elle finit par accepter l’une d’entre elle qui lui propose un bon salaire au vu de sa certification et lui propose de passer les niveaux supérieurs. Entre temps elle se rend chez un client qui lui demande conseil dans la mise en place du cloud publique, il n’a pas le temps de traiter le sujet c’est pour cela qu’il fait appel à l’ESN. Éloise qui est dans ça première mission va chercher à ne pas être perdu et donc choisir Azure qu’elle maitrise. De certification en certification de client en client elle deviendra une experte Azure, sans jamais avoir eu le temps ni les moyens d’élargir le champ des choix.

Cette petite histoire est en réalité proche de la réalité et assez courante, et ne blâmons pas Éloise, la grande majorité des personnes dans cette situation se serait rassurée en choisissant un terrain connu. Vous me direz, ben c’est la faute de l’école elle ne doit pas faire ça ! Mais pour avoir travaillé en école, la réalité est bien moins simple. Elles n’ont souvent pas le choix, les technologies évoluent TRÈS rapidement et très souvent il est impossible d’avoir des experts sur les nouvelles technologies ni des cours complets et récents sans dépenser des sommes astronomiques. Alors quand Microsoft se présente devant la porte et propose un pack qui donne des crédits Azure à tous les étudiants et surtout des cours adaptés aux technologies modernes avec des experts le tout gratuitement, les écoles foncent. Cela n’est pas nouveau j’ai connu les cours de Microsoft serveur sponsorisé très largement, les cours d’Oracle et j’en passe. La majorité des étudiants n’auront jamais le recul, ou le temps de tester et d’apprendre des technologies autres d’eux-mêmes.

Big Data is Watching you

Ce principe de partenaire est utilisé à la quasi identique sur les entreprises elles-mêmes qui ont tout un système de certification. Tout en apportant un effet boule de neige, si vous chercher de la main d’oeuvre en prestation ou interne, vous aurez une grande majorité d’expert cloud AWS, Azure ou Google.

  • Le lobbying

Et là arrive l’arme ultime : le lobbying, le grand classique dans lequel je vais parler de pas mal de petites actions qui misent bout à bout ont un impact sur le classement. Le plus frappant est le coup classique pour attirer les nouveaux clients sont les offres d’essais. Demain vous montez un startup pour disrupter un domaine ? Vous pouvez êtes sûr que rapidement vous allez avoir de belles offres de Google, Azure et AWS sans parler de leurs offres d’essai. Vous allez me dire que cela leur coûte cher, mais c’est très lucratif, les clouds sont assez fermés un changement demande de revoir beaucoup de choses, donc une fois l’offre promotionnelle terminée les utilisateurs y reste. D’ailleurs si vous regardez du côté des fameux incubateurs de startup par exemple Station F, ils sont très présents afin d’influencer au maximum ces nouvelles pousses.

Le lobbying ne s’arrête pas aux dernières entreprises de la startup nation, mais s’attaque bien sûr aux bonnes veilles DSI bien velue ! Vous êtes DSI vous n’avez pas suivi le virage du cloud, mais bon il faut que votre entreprise y passe c’est une question d’image vis-à-vis de la direction et des clients. Vous devez faire un choix, vous n’avez pas le temps de demander à l’extérieur, vous faites quoi ? Ben vous choisissez quelque chose que personne ne vous reprochera ! Jamais des dirigeants ne vont reprocher à une personne un choix d’un mastodonde qui a fait ses preuves. Si le projet de migration échoue avec AWS, la faute sera remise sur le temps la gestion ou tout autres élément aléatoire. Par contre, si le même responsable avait fait un choix moins commun comme OVH dès lors que le projet aurait loupé la faute aurait été mise sur ce choix. Le responsable choisit donc le choix politique : Azure, GCP, AWS

  • Le service

Il faut bien reconnaître les fournisseurs américains ont aussi compris un élément simple, le client est roi. Vous avez fait une erreur et vous avez laissé un cluster de tests allumé dans le vide une semaine ? Le service client d’Amazon vous proposera surement une solution pour le rembourser, ce coût pour eux et en réalité faible, car vous serez satisfait de leurs services, donc pas prêt de partir.

Leurs services très souvent ne sont pas que techniques, quand une grande entreprise fait un appel d’offres il y a des contraintes de conformités et beaucoup d’autres choses. Les acteurs américains ont une démarche très rodée, ils vont fournir tous les documents rapidement et en n’hésitant pas à s’adapter au besoin. Sans compter qu’ils n’hésitent pas à certifier TOUS les services possibles sur leurs clouds aux grands classiques comme les normes ISO ou encore HDS. Pour les grands comptes, c’est un aspect ultra important qui explique que beaucoup de contrats de santé notamment arrivent chez les Google, Amazon, Microsoft plutôt que chez les acteurs français malgré le Cloud Act. Des acteurs alternatifs font certifier les services, mais pour beaucoup cela ne représente que 2 à 3 services de leurs cloud ce qui est souvent insuffisant.

  • Le coût de la migration

C’est un point qui à mon sens est souvent trop cité, mais il est réel. Passer d’un cloud à l’autre aura souvent un très gros coût, entre la réécriture du code, le coût des transferts de données c’est très lourd. Après je pense que quelque soit le cloud, passer de l’un à l’autre aura toujours un coup il n’y a pas de standard assez complet pour fournir un cloud commun, Open Stack est un début, mais ne fournit qu’une petite partie des services managés d’un cloud public en 2020.

Ces techniques ne sont clairement pas nouvelles et ont été éprouvées dans de nombreux autres domaines. J’aurais aussi pu aborder l’effet de mode, mais je pense que celui-ci est venu bien après et il est fortement lié aux points déjà cités. J’en ai surement oublié, et je vous invite à me dire ce que vous en pensez j’ai donné ma vision de consultant technique.

Conclusion

Une lumière au fond du tunnel ?

Je pense qu’il y a beaucoup à apprendre de la parts des géants du web et pas uniquement sur la technique. Aujourd’hui on peut dire qu’on a des alternatives viables comme celle déjà citée : Alibaba cloud, OVH, Clever Cloud, Outscale, Scaleway ! Ils n’ont effectivement pas autant de service managé qu’AWS, mais ils commencent à avoir le minimum de services nécessaires à la plupart des projets à l’heure actuelle : Du Kubernetes managé, du stockage objet, des machines virtuelles, des bases de données managées des équilibreurs de charge efficaces et surtout des outils et APIs fonctionnels (ils ont des providers Terraform adaptés). Un peu de chemin est encore à faire, la gestion des comptes IAM, les réseaux virtuels privés et le FaaS sont encore trop souvent aux abonnés absents, même si je félicite Scaleway pour ses développements récents sur ses sujets.

Alors pourquoi on met tant de temps à rattraper ce retard ? Ces acteurs ont dû se dépasser pour rattraper la recherche et développement et les investissements des grands acteurs Américain et surtout se remettre en question, cela a pris du temps, mais le développement des outils OpenSource comme Kubernetes ou encore OpenStack a permis de mutualiser les efforts et d’avoir des solutions efficaces.

Maintenant que la technique est là il faut passer à l’offensive commerciale qui a déjà commencé, OVH est très présent à Station F, Scaleway a mis en place de belles offres d’essais. En continuant sur cette voie, il se pourrait bien que le marché du cloud public change enfin de visage pour devenir plus varié.

Il faut aussi soutenir l’éducation, nouer des réseaux de partenaires solides ! Et faire certifier les services pour pouvoir attaquer les grand-comptes, on reparlera des certifications et de tout ça dans un prochain article.

Mais pour que ces nouveaux acteurs se démocratisent il faut une chose, que nous les personnes de la technique arrêtions de répéter des patterns, tester ces nouvelles alternatives et les proposer pour pousser vers un web différent est plus diversifié !

11 Jun 2020, 14:59

Découvrir Podman par la pratique

Podman

Après plusieurs années d’utilisation de Docker, notamment sur mon infrastructure personnelle, j’ai eu envie de tester un autre outil pour gérer mes conteneurs. Parmi les alternatives qui existent une m’avait donné envie d’en savoir plus : “Podman” particulièrement après en avoir entendu parler au FOSDEM 2020.

Une histoire de conteneur …

Il y a de grandes chances que vous connaissiez déjà Docker qui bousculé les habitudes de travail avec les conteneurs, mais cette technologie est bien plus vieille que Docker. Je ne vais pas vous faire un historique complet, mais il faut savoir que les conteneurs existaient déjà. On peut penser aux solutions antérieures à Docker comme OpenVZ ou Linux Container qui était d’ailleurs utilisé comme base par Docker dans ses jeunes années.

Alors qu’est-ce que Docker a apporté pour rencontrer un tel succès ? Un écosystème et une manière de faire nouvelle au moment de l’essor du DevOps. Le fait de décrire ces conteneurs dans un fichier (Dockerfile), de pouvoir stocker et partager des images (Docker hub), de réutiliser des layers. Tout cela a beaucoup changé la manière de travailler en grande partie grâce à cet écosystème qui permettait de répondre aux paradigmes apparus notamment en parallèle de la mouvance DevOps, comme le pet vs cattle par exemple.

Mais avec le temps la société qui gère Docker a subi quelques difficultés, notamment après le succès de Kubernetes face à Swarm, son orchestrateur maison. De plus, le moteur de Docker n’ayant jamais été passé sous licence libre, les libristes avaient donc tendance à le bouder quelque peu.

…Qui devient une histoire de Pod

En quelques années, vous l’avez surement vu Kubernetes est devenu un standard dans le monde de l’orchestration de conteneurs. Parmi tous les apports de Kubernetes, je vais m’attarder sur une qui a son importance dans l’histoire, le pod. Alors le pod est une notion qui désigne une unité dans Kubernetes représentant un ensemble de conteneurs qui sont liés. Ils ne pourront par exemple jamais être séparés sur deux machines différentes et interagir directement entre eux.

Cette notion est par essence très importante dans Kubernetes, mais n’est pas du tout présente dans Docker. C’est là qu’on entre dans une situation qu’ironiquement Docker voulait nous éviter : le développeur sur son ordinateur utilise du Docker voir docker-compose et sur les environnements on utilise du Kubernetes qui va plus reposer sur la notion de Pod. Même si la notion est relativement proche, je trouve dommage de perdre la fameuse homogénéité que Docker devait apporter.

Et c’est là qu’apparaît : PODMAN !

Podman logo

Podman est une alternative à la ligne de commande Docker supportée par RedHat, qui va vous permettre déjà de gérer des conteneurs sans avoir de démon, et sans les droits root sur la machine, mais surtout gérer des Pods nativement ! Vous avez bien compris, on apporte la notion de pod démocratisé par Kubernetes en “local”. Podman ne s’arrête pas là en matière de synergie, il va permettre d’exporter et d’importer directement des définitions yml Kubernetes !

Ok, du coup là vous devez vous dire que c’est génial, mais que vous avez appris Docker et qu’il faut tout réapprendre. Et là Podman a encore la réponse pour vous, la syntaxe des commandes est très proche de Docker à tel point qu’ils conseillent même de faire un alias docker=podman.

Familiarisons-nous avec Podman

Quoi de mieux pour découvrir une technologie que de la manipuler ?

  • Installation de Podman

Le plus simple est de suivre la documentation officielle. Sur Debian, il suffit d’ajouter le dépôt et de l’installer avec APT :

Pour Debian 10

echo 'deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_10/Release.key | sudo apt-key add -

sudo apt-get update -qq
sudo apt-get -qq -y install podman
  • Les actions basiques (Docker-like)

Les actions basiques ressemblent en général à l’option près à la commande Docker. Même les images et dépôts Docker sont compatibles !

Démarrer un conteneur

root@tmp /root  » podman run hello-world
Trying to pull docker.io/library/hello-world...
Getting image source signatures
Copying blob 0e03bdcc26d7 done  
Copying config bf756fb1ae done  
Writing manifest to image destination
Storing signatures

Hello from Docker!
This message shows that your installation appears to be working correctly.

[...]

Vous remarquez d’ailleurs que par défaut, Podman va chercher les images directement sur le Docker hub.

Lister les conteneurs

root@tmp /root  » podman ps -a
CONTAINER ID  IMAGE                                 COMMAND  CREATED             STATUS                         PORTS  NAMES
4ec0e83cb175  docker.io/library/hello-world:latest  /hello   About a minute ago  Exited (0) About a minute ago         agitated_vaughan

On peut voir notre conteneur “Hello World” que vous pouvez supprimer avec podman rm $CONTAINER_ID

Petit tutoriel pour découvrir les pods !

Vous vous demandez surement où sont les fameux Pod, car bon pour l’instant cala ressemble plus à un équivalent de Docker.

Pour vous parler des pods on va partir sur un objectif simple :

  • Monter un Wordpress en container
  • Il sera contenu dans un pod
  • Le pod contiendra 2 container : Wordpress front et MySQL la base de données

On créé tout d’abord le pod qui va contenir nos containers, en lui demandant d’exposer le port 80 à l’extérieur. Cela nous permettra d’accèder à notre Wordpress.

podman pod create --name wordpress -p 80

Votre pod est donc créé, vous pouvez l’observer :

podman pod ls
POD ID         NAME        STATUS    CREATED         # OF CONTAINERS   INFRA ID
4ee4f1e626e7   wordpress   Created   2 minutes ago   1                 caf216f50735

Si on exectute d’ailleur un ps, on voit que Podman créer en même temps que le pod un conteneur pour le gérer comme sur Kubernetes (l’image est d’ailleurs originaire de Kubernetes)

podman ps -a
CONTAINER ID  IMAGE                 COMMAND  CREATED             STATUS   PORTS               NAMES
caf216f50735  k8s.gcr.io/pause:3.2           About a minute ago  Created  0.0.0.0:80->80/tcp  4ee4f1e626e7-infra

On peut ensuite créer nos 2 conteneurs en les attachant au pod créé précédemment

  • MySQL

    podman run -d --pod wordpress -e MYSQL_ROOT_PASSWORD=VOTRE_MOT_DE_PASSE mysql:5.7
    
  • Wordpress

    podman run -d --pod wordpress -e WORDPRESS_DB_HOST=127.0.0.1 -e WORDPRESS_DB_USER=root -e WORDPRESS_DB_PASSWORD=VOTRE_MOT_DE_PASSE -e WORDPRESS_DB_NAME=localhost -e WORDPRESS_TABLE_PREFIX=wp_ wordpress:latest
    

Vous remarquerez que pour interroger la base MySQL Wordpress se base sur le localhost, en effet ils sont dans le même Pod vous pouvez donc communiquer directement sur cette interface.

Vous pouvez maintenant utiliser votre instance Wordpress sur le port 80 :)

De Podman à Kubernetes

Je vous ai parlé d’une autre fonctionnalité qui me semble bien intéressante, l’export et l’import de yml on va la tester avec notre Wordpress.

Pour exporter un pod directement dans un fichier yml il suffit de faire :

podman generate kube -f /tmp/wordpress.yml wordpress

Vous pouvez aussi faire le cheminement inverse, à partir de fichier généré par Podman ou un fichier de Kubernetes.

podman play kube /tmp/wordpress.yml

D’ailleurs, si vous tentez de recréer notre exemple vous allez surement avoir une erreur 500 sur le Wordpress évoquant un timeout sur la base de données. Une petite explication s’impose, de base la définitions des pods dans les fichiers yml ne permets pas d’avoir la notion de dépendance entre les conteneurs, donc le Wordpress démarre avant la base de données donc il ne peut pas s’y connecter. En redémarrant le conteneur Wordpress vous allez observer un retour du service.

Une fois que vous avez terminé les tests, vous pouvez stopper le pod et le supprimer :

podman pod stop wordpress
podman pod rm wordpress

Ce n’est bien sûr qu’une exploration de la surface de Podman, je vous invite à pousser l’utilisation si ça vous intéresse et consulter la documentation officielle.

Que penser de Podman face à Docker

Alors que penser de Podman, je pense que c’est une alternative très avantageuse à Docker pour plusieurs raisons, même si certaines choses sont encore perfectibles.

Dans les quelques défauts, il y a problème de dépendance qui est liée au format de description utilisé par Kubernetes. On peut le contourner au besoin avec de petits “hack” dans les conteneurs ou en passant par le projet podman-compose ce qui reste un peu dommage, car on perd le côté natif. Un dernier point qui est mériterait aussi de s’améliorer c’est la documentation, qui est moins complète/agréable que Docker je trouve.

Pour les utilisateurs de Windows, je sais qu’il y en a, Podman n’est pas compatible nativement avec Windows. Néanmoins, WSLv2 permet visiblement de l’utiliser ce qui est plutôt une bonne nouvelle.

Le fait d’avoir des commandes très proches de Docker est une bonne chose, même si parfois à l’utiliser j’ai l’impression qu’on a forcé un peu pour rester sur une apparence Docker.

Ne pas avoir de démon et ne pas nécessiter les droits root sont des avantages assez séduisants. Mais je pense que le vrai avantage est bien la synergie avec Kubernetes. Celui-ci étant devenu aujourd’hui qu’on le veuille ou non un standard. Même si elle ne va pas vous générer un fichier prêt pour la production en une commande, elle pourra accompagner les développeurs à tester des programmes sur Kubernetes facilement. De mon point de vue le fait que la solution soit open source et soutenu par RedHat est aussi un signe encourageant.

Personnellement, je n’utilise plus Docker quand c’est possible, je trouve que Podman plus agréable surtout la notion de Pod. J’espère que Podman va gagner en efficacité, notamment avec la prometteuse version 2 qui arrive ! Néanmoins, Docker est bien installé sur le marché et je ne pense pas que Podman va le détrôner en tout cas pas tout de suite, surtout vu la communauté de Docker. Dans tous les cas je vous invite à suivre de près l’actualité de Podman !

PS : Si vous souhaitez utiliser directement Podman pour héberger des services, je ne peux que vous conseiller l’excellent combo Ansible / Podman / systemd que vous pouvez découvrir sur cette publication de RedHat : https://redhatnordicssa.github.io/ansible-podman-containers-1. Je l’utilise pour mes services personnel, c’est stable et efficace.

14 May 2020, 12:18

La documentation technique, le récit d'un échec

La documentation technique est un débat qui déchaîne les passions dans les différentes équipes, quelles que soient leurs spécialités depuis des décennies. Quand elle doit être écrite, on la dépriorise et quand elle est manquante dans un projet, elle retarde toutes les équipes. Je vais donc me pencher sur les problèmes de la documentation technique que j’ai pu observer durant mes expériences.

Illu. Introduction

Mille et une raisons de ne pas faire de documentation

On ne va pas se mentir faire de la documentation n’est pas la partie la plus marrante de nos métiers, mais elle fait partie intégrante de celui-ci. Je pense même que pour être un bon “tech”, il ne faut pas juste savoir “pisser du code”, il faut savoir documenter et comprendre les besoins métiers entre autres. Néanmoins dans beaucoup de cas on l’omet, ou l’esquive pour de multiples raisons. Je ne pense pas qu’il y ai de bonnes raisons d’éviter la documentation, je vais donc passer en revue des excuses que j’entends trop et voir pourquoi elle ne se justifie pas.

Si le code est clair, il n’y a pas besoin de documentation.

Surement une des explications les plus courantes, en réalité elle traduit un problème plus profond. Le but de la documentation technique n’est pas d’expliquer les lignes de code mais le contexte de l’implémentation et d’en donner une vue globale pour gagner du temps et de l’efficacité.

Vous savez développer, la personne qui reprendra le code le sait aussi. Par contre ce qu’elle ne sait pas c’est le contexte dans lequel cela a été réalisé et pourquoi. Car on le sait tous, parfois on fait des choix étranges qui sont nécessaires à cause du contexte. Par exemple, pourquoi redévelopper une fonction pour faire une action, pourquoi implémenter un programme de cette façon. Il peut y avoir des raions, techniques ou politiques, mais ces raisons ne se verront pas dans le code au premier coup d’oeil.

Le code nécessite parfois de la documentation sous forme de commentaires. Nous avons tous nos petites habitudes et nos petits hacks qui peuvent complexifier la lecture du code, c’est pourquoi pour être plus efficient il est toujours préférable d’écrire une petite ligne pour l’expliquer. Il ne faut cependant pas faire d’excès de zèle et sur-commenter, avoir plus de lignes de commentaires que de code est souvent symbolique d’un problème. Prenons un exemple parlant que je vois encore souvent, les lignes de commentaires de ce type :

# Permet de récupérer l'id
function get_id():
	return this.id

Le commentaire n’apporte rien mise à part augmenter le nombre de lignes.

La documentation est donc nécessaire, quelle que soit la qualité du code

On va réduire le nombre de jours / hommes sur la documentation.

Une autre phrase que vous avez dû entendre souvent ! Car oui, beaucoup de projets informatiques finissent par avoir du retard, comme dans beaucoup d’autres domaines. Pour réduire les retards, les gestionnaires de projets ont une technique assez classique, supprimer ou réduire le temps donné aux tâches non prioritaires. Retenez par “non prioritaire”, toutes tâches n’apportant pas directement un rendement. Autant dire que cela contient souvent : l’optimisation, le refactoring et la documentation. Alors oui, ça fait économiser quelques jours hommes dans l’immédiat, mais sur le long terme cette approche n’est pas rentable. L’application va avoir un cycle de vie qui va à de nombreuses reprises avoir besoin d’être modifié, mise à jour. À chaque fois qu’une personne devra travailler dessus, elle va devoir prendre du temps pour comprendre le code et le contexte avant de pouvoir travailler. Il est rare que sur le cycle complet de vie du produit cela soit rentable.

À cela s’ajoute encore un autre point, il ne faut pas réinventer la roue, donc réutiliser le code le plus souvent possible. Si vous souhaitez que votre code soit réutilisé, un des premiers critères sera la présence de documentation et l’organisation de celui-ci. Exemple: si vous faites de l’Infra As code avec Terraform, cela va vous prendre plus de temps de séparer les éléments en modules indépendant, mais vous ou d’autres pourront les réutiliser pour divers projets.

La documentation n’est pas une tâche optionnelle à faire quand on a le temps, elle fait partie du projet et apporte de la valeur

Illu. Documentation

On a tout automatisé, il n’y aura pas besoin de documentation.

Aujourd’hui avec l’agilité et l’approche DevOps il est de plus en plus courant d’avoir des projets très matures sur l’automatisation comme l’utilisation du déploiement continue, d’infrastructure cloud automatisée et j’en passe. Avec tout ça, on est parfois tenté de se dire qu’il n’est pas nécessaire de faire de la documentation.

Automatiser les choses ne veut pas dire perdre la maîtrise, je pense qu’il est important de comprendre les tâches faites par notre industrialisation et de savoir les faire sans. Cela permet de corriger les bugs et optimiser vos solutions, sans cela en cas de problème vous serez bloqués. Petite anecdote, j’ai déjà entendu un administrateur à qui l’équipe sécurité à demandé de mettre à jour OpenSSL en urgence, Il n’a pas compris où OpenSSL se trouvait ni comment le mettre à jour car en réalité, il récupère qu’une image Docker sur le DockerHub. Je pense que cela montre bien pourquoi il est important d’avoir conscience de la partie invisible de l’iceberg.

Savoir ce que l’automatisation fait cela fait partie de la documentation. Six mois après la mise en production, il y a peu de chance de se rappeler les spécificités du système. La documentation vous remettra dans les rails facilement, surtout sur les infrastructures actuelles qui sont de plus en plus complexes.

La documentation est nécessaire, quelle que soit votre maturité sur l’automatisation

Si je documente mon travail, on pourra me licencier.

Ça va peut-être en choquer certains, mais j’ai déjà entendu cette phrase plusieurs fois. D’ailleurs, c’est souvent ces mêmes personnes qui veulent limiter l’automatisation pour cette raison. Bref, je ne leur jette pas la pierre, je peux comprendre qu’on ai peur de perdre son emploi. Il ne faut cependant pas se leurrer.D’expérience le fait qu’il n’y ait pas de documentation n’empêchera jamais une entreprise de procéder à des licenciements. Je pense même que ça va souvent plus détériorer la qualité et l’ambiance de travail.

Bref, ne faites pas ça, je ne pense pas que ça jouera un jour en votre faveur bien au contraire.

La documentation n’empêchera pas de vous faire virer mais ne pas en faire peut entrainer le licenciement plus rapidement.

Documentation Memes

La documentation à l’heure de l’agilité et du DevOps

On a vu différentes raisons qui sont souvent invoquées pour ne pas faire de documentation mais nous n’avons pas abordé une particularité qui me tient à coeur: la documentation à l’heure de l’agilité et du DevOps. Quand on a accéléré le déploiement des applications et des infrastructures, on a gagné pas mal de temps, mais qu’en est-il de la documentation ? Concilier les deux est pourtant important et je ne pense pas que ce soit si compliqué.

Pour gérer celle-ci à l’heure du DevOps, j’aurai tendance à conseiller les choses suivantes :

  • La documentation doit faire partie du cycle de vie, donc être versionnée et tagée comme celui-ci. En général, je choisis de le stocker dans le dépôt git du code associé, ça évite de le perdre au passage.
  • Les modifications doivent être accompagnées des documentations associées, si elle est faite en continu c’est plus rapide. Chaque merge request doit-être accompagnée des modifications et ajouts de documentation associés.
  • Écrire la documentation doit-être un réflexe et être fait en même temps que le code comme si celle-ci en était une partie intégrante. Je déconseille de mettre juste une tâche de documentation en fin de projet, répartissez la dans les tâches techniques elle en fait pleinement partie.
  • Automatiser au maximum possible, quand vous documentez des modules Terraform ou des API REST il existe des outils permettant d’automatiser une bonne partie comme les versions, les entrées / sorties, etc.
  • Faites la vivre, souvent les gens ont tendance à ne plus lire et directement demander sur les chats. On a tous reçu des messages sur Slack ou autre pour nous poser des questions auxquelles les réponses étaient dans la documentation. Renvoyez ces personnes vers la documentation gentiment en leur demandant de vous recontacter si ce n’est pas assez précis, si c’est le cas, faites-la évoluer ! Car demain vous serez peut-être en vacances sur une île paradisiaque et vous ne pourrez pas répondre.
  • Si vous êtes dans un contexte entièrement francophone et que vous ou l’équipe n’est pas toujours à l’aise avec l’anglais, il n’y a pas de honte, faite là en français ! L’important c’est que la documentation ne doit pas être une barrière ou une difficulté, mais une aide.
  • Tout le monde doit documenter ce qu’il fait, ce n’est pas à une personne d’assumer un point aussi central et important.

Voilà les quelques points qui me semblent importants pour avoir une méthodologie de documentation efficace dans un environnement DevOps. La liste demeure néanmoins personnelle et non exhaustive.

Pour finir : RTFM

La documentation est importante, elle fait gagner du temps à vous et aux futurs techniciens. Oui, avec du reverse engineering, vous pouvez vous en sortir, ça m’est arrivé de tomber sur des programmes obscurs que j’ai dû comprendre à coup de strace, nc ou encore tcpdump, mais c’est chronophage et pas efficace sur le long terme. N’ayez pas non plus peur de répondre “Read The Fucking Manual” à une personne, afin de lui donner le réflexe de lire la documentation pour qu’il gagne en autonomie.

Étant consultant, mon but n’est pas de rester ad vitam aeternam chez le client, mais de l’aider à prendre la main pour n’avoir avant mon départ, qu’à lui donner le manuel et les clés de son nouveau système. Pour que ce client et ces équipes puissent s’émanciper, la documentation est vitale.

Si vous ne le faites pas pour vous, faites-le pour la personne qui viendra après vous. Vous pouvez peut-être lui sauver des semaines d’un travail peu intéressant et long.