Bon, ce titre n’est pas celui de la présentation d’Eric Sadin, qui nous a introduit à la “responsabilité des ingénieurs”, mais son envie de nous convaincre et de nous apporter des clefs de compréhension était tellement grande qu’il ne voulait plus quitter la scène même avec une intervention du speaker de l’équipe Devoxx… De quoi détendre la salle après une présentation qui nous a fait réfléchir.
Lors de sa présentation, il a mis les ingénieurs au centre des problématiques du monde d’aujourd’hui et en particulier (c’est de bon goût à Devoxx) les “développeurs d’algorithmes” qui régissent les mondes d’aujourd’hui et de demain. Il nous a également demandé de faire attention avec les données remontées par nos objets connectés qui pourraient être à l’avenir de vrais problèmes de société.
Il nous renvoie ainsi à notre responsabilité, à notre devoir à l’égard de la société et nous rappelle que nos décisions nous engagent au delà de nous même.
Je ne saurais vous décrire ici l’ensemble des éléments et des explications donnés, mais je vous recommande de voir cette présentation dès qu’elle sortira sur Internet.
Une présentation très drôle de Laurent Victorino, qui nous a montré des exemples d’IA plus ou moins réussies et qui nous ont amenés à la réflexion : pourquoi sont-elles plus ou moins réussies ?
Les joueurs ont besoin de pouvoir gagner pour pouvoir aimer un jeu. Ce principe est au coeur du développement des jeux, quoi de plus pénible qu’une intelligence qui pourrait nous détecter dès notre apparition et prendrait immédiatement la bonne décision en un temps infime. Pourquoi jouer si on ne peut pas gagner ? À l’inverse, si des bots étaient bloqués par une simple porte entrouverte (faut-il l’ouvrir ou la fermer ?) quel serait l’intérêt de les battre ?
Selon l’expression du speaker, son métier consiste à faire la meilleure IA au monde puis “à la coincer dans un parking sombre et la tabasser” avant le lancement du jeu. Rassurez-vous, aucune IA n’a été maltraitée durant cette conférence.
Pour conclure son propos, l’auteur nous a raconté une légende d’Internet que beaucoup auront déjà entendu : dans le jeu Quake 3, les bots avaient la capacité d’apprendre de leurs erreurs et d’améliorer leur capacité de survie. Un joueur qui n’avait pas touché à son serveur depuis des années est retourné dessus et a constaté que la paix était présente entre les bots. D’après lui, l’IA était suffisamment intelligente pour avoir conclu que la meilleure façon de survivre c’est de ne pas se battre. Un très beau message d’espoir pour conclure cette présentation !
Une excellente présentation d'Alain Bensoussan, avocat à la Cour d’appel de Paris, qui a tenté de démontrer via des cas d’usage comment la responsabilité des “codeurs” pouvait être actée.
Il a en particulier rappelé le cas des logiciels truqueurs dans les tests écologiques des moteurs diesel, exemple édifiant pour bien faire comprendre un point : il ne s’agit pas de science-fiction mais bien d’une vérité et des pratiques qui existent aujourd’hui et où nous, codeurs, sommes au centre des événements.
Sous la forme d’un plaidoyer troublant, il nous a ensuite mis au coeur d’un procès sur le choix prétendument fait par une voiture autonome de tuer une personne, l’innocent, pour en sauver quatre, les coupables, et à poser les questions suivantes : qui a fait ce choix ? Qui est responsable ? Si à la première question la réponse est évidente : le codeur de l’algorithme, la deuxième suscitera forcément la polémique.
En conclusion, il propose d’établir une “charte du code de demain”, définissant un droit à l’humanité dans nos futurs algorithmes.
Cette présentation, faite par Laurent Bloch, avait pour centre une critique marquée contre le manque d’ambition de nos dirigeants français et plus largement sur l’ensemble du “vieux continent” envers l’ère qu’il a appelée “cyberindustrielle”.
Au cours d’un bref historique des révolutions industrielles, il a introduit trois étapes marquantes :
Ces trois révolutions ont chacune bouleversé l’histoire et la société sur les sujets juridiques, politiques et bien sûr économiques. Par exemple, avant la première révolution industrielle, la Chine et l’Inde avaient réciproquement 30% et 20% des richesses, et après celle-ci, ces deux pays étaient les plus pauvres au monde.
Pour éviter ce phénomène, toujours selon le speaker, nous devons adapter notre éducation, notre économie mais également nos institutions. Il nous faut également investir dans la recherche, dans les infrastructures, dans la formation de nos ingénieurs, être présents dans les organismes de normalisation,...
Pour conclure sa présentation, il nous a indiqué que la France semble avoir toutes les cartes en mains pour réussir cette révolution et qu’il nous faut juste convaincre nos politiciens de ne pas oublier le virage…
Pour finir cette Keynote, Piotr Mirowski nous a présenté un théâtre d’improvisation entre son robot ALEX et lui-même. Il a ainsi récupéré des lieux et des sujets dans le public, et a commencé à improviser une situation où son robot lui répondait (ou pas) dans un sens logique (ou pas). Malgré les difficultés techniques, il a pu nous convaincre de la situation grâce à un certain talent d’acteur.
Ensuite, il nous a expliqué les étapes de l’apprentissage et les futures évolutions de son robot. Dans son parcours d’évolution l’IA a suivi les étapes d’apprentissage de son créateur afin de surmonter la capacité à improviser.
En conclusion, je pense que ce spectacle sera de plus en plus intéressant dans les mois et années qui suivent… à suivre donc !
Pour cette université, Thomas Auffredou, Yannick Lorenzati et Jean-Louis Rigau ont choisi de comparer les 3 orchestrateurs de conteneurs que sont Docker Swarm, Mesos/Marathon ainsi que Kubernetes et leur comportement durant le cycle de vie d’une application.
Après un rappel de ce qu’est un conteneur ainsi qu’un microservice, a été abordé le besoin nécessitant l’utilisation d’un orchestrateur de conteneurs. En effet, il est nécessaire de gérer le cycle de vie des conteneurs par rapport aux ressources de l’hôte et sans une forte dépendance à une équipe d’OPS, dont ce n’est pas le rôle premier.
À partir de cela, la bataille entre orchestrateurs de conteneurs peut commencer. Le socle commun sera de construire et de déployer la même application avec les différentes options proposées.
La conclusion qui s’impose est la suivante : avec des principes de fonctionnement différents, les 3 orchestrateurs réussissent aussi bien à la tâche qui a été donnée, que ce soit dans le déploiement, la mise à disposition des services hors de l’hôte, la gestion persistante de données, ainsi que la résilience qui reste le point le plus important. Seul le couple Mesos/Marathon présente un bémol : la scalabilité n’est pas prévue par défaut.
Lors de ce Tools in Action, Etienne Peiniau d’Ekino et Frédéric Boulet, de Today I learned, nous présentent les différentes forces de Lambda : le découplage du code applicatif requis, une scalabilité simple, l’absence de besoin d’infrastructure, la disponibilité de nombreuses métriques ainsi qu’une facturation avantageuse. De plus, de nombreux services AWS peuvent être utilisés en tant que source. C’est alors que la complexité apparaît : si on utilise CloudFormation pour le déploiement de nos services, les templates sont rapidement longs et difficiles à gérer.
De ce constat est né Serverless, un framework en Node.js qui permet simplement de créer et déployer nos applications. En effet, les descriptions sont en Yaml avec une abstraction qui facilite la modification de ces mêmes descriptions. Le framework est extensible que ce soit par l’ajout de plugins mais aussi par l’inclusion de ressources CloudFormation aux templates. Cerise sur le gâteau, Serverless supporte non seulement AWS mais aussi Azure et Openwhisk.
Brian Fox de Sonatype nous présente ici les raisons pour lesquelles la sécurité est un élément prépondérant de la chaîne DevOps. En effet, de plus en plus d’éléments opensource sont utilisés lors du développement de projets et ceci pour une raison toute simple : un gain important en productivité. Toutefois, un aspect fondamental est souvent oublié : la mise à jour des composants opensource. Et ce sans prendre en compte l’aspect faillible de toute brique logicielle. De ce fait, le moindre point de vulnérabilité peut avoir des impacts désastreux pour une société.
La clé pour éviter ce genre de soucis est de choisir des composants de qualité, d’inventorier précisément l’utilisation de ces composants et de monitorer les failles de sécurité qui peuvent apparaître en fournissant des plans d’actions afin que la chaîne DevOps soit toujours opérationnelle.
Olivier Routier d’EDF nous présente ensuite un cas rencontré chez EDF. Une faille majeure est arrivée sur Apache Struts, utilisé dans une application critique. L’équipe de sécurité ne savait pas que Struts était utilisé. Suite à une analyse sur un logiciel ancien, de nombreuses failles ont été découvertes. Il a dès lors fallu réagir rapidement afin de résoudre ce problème et définir des méthodes afin que ce danger ne se reproduise plus. De ce fait, des outils de vérification ont été mis en place à plusieurs niveaux de la chaîne DevOps : dès le poste du développeur avec des plugins Eclipse et au moment du build sur Jenkins.
Nicolas de Loof et Yoann Dubreuil de CloudBees nous aident à y voir plus clair parmi toutes les solutions de conteneurisation.
Pour cela, ils retracent l’histoire de l’informatique en partant de la carte perforée (une tâche à la fois : mono-utilisateur / mono-processeur) pour arriver aux systèmes Unix des années 70, où pour une question d’optimisation des ressources, nous aboutissons à des solutions multi-tâches / multi-utilisateurs.
Ces aspects multi-tâches / multi-utilisateurs ont par ailleurs introduit les premiers mécanismes d’isolation intégrés aux primitives systèmes : systèmes de permissions et ACL.
Finalement, un conteneur s’exécute sur un runtime de conteneur qui est un assemblage de primitives systèmes permettant de gérer :
On notera que SystemD est quelque part un runtime de conteneurs.
L’assemblage de toutes ces solutions pouvant être différent (périmètre / version), nous pouvons avoir différents runtime de conteneurs.
Historiquement, c’est OpenVZ qui se présente comme le premier runtime de conteneurs, repris par LXC, lui-même repris par Docker dans les premiers temps. En parallèle, Rocket (Rkt) est apparu.
Cette disparité de solutions a donné lieu à une initiative de standardisation : Open Container Initiative dont RunC constitue une première implémentation.
Pourquoi réécrire un runtime? Parce-qu’au-dessus du runtime de conteneurs, on trouve un orchestrateur de conteneurs qui peut fournir des fonctionnalités spécifiques. Par exemple, Mesos qui souhaite tirer profit des GPU.
Trois utilisations des conteneurs existent:
Dans le cadre de “Blue Ocean”, la nouvelle interface de Jenkins, Nicolas et Yoann se sont heurtés au problème du “nested container”, c’est à dire des conteneurs qui doivent lancer d’autres conteneurs en interne.
Leur retour est que la question de l’imbrication des control groups et namespaces, en particulier au niveau du systèmes de fichiers, n’est aujourd’hui pas pleinement résolue.
Ils ont notamment testé Zfs (licence non GPL) et Btrfs. Leur choix s’est porté sur Btrfs qui fonctionne plutôt bien tant qu’il ne s’agit pas prod...
Les alternatives pour faire du “nested container” sont :
Dans cette conférence, François Teychene, DevOps chez TabMo, revient sur son expérience avec la production à base de conteneurs. Son constat est assez simple, la tendance des conteneurs est portée par les Devs, d’abord sur leurs postes, puis ils sont intégrés dans les serveurs d’intégration continue et tout le monde est content. Vient enfin le moment du passage à la production où les choses se compliquent rapidement après les premières heures de joies d’avoir enfin des conteneurs en production.
La grande promesse du conteneur qui permet de créer les mêmes environnements du dev à la production est largement dévoyée.
Il cite quelques-unes de ses désillusions lors du passage à la production :
En bref, que l’on fasse du conteneur ou pas, les problématiques de production restent les mêmes. La principale différence étant qu’on doit les adresser avec de nouvelles solutions (orchestrateur, service discovery, plugin de stockage, plugin de réseau, plugin de monitoring, et sous-système de log). Un slot qui a le mérite de rappeler la réalité de la production aux foules fanatiques des conteneurs. Nous noterons quelques impasses tout de même comme par exemple la gestion des dépôts d’images, le rythme de mises à jour du démon Docker et les éventuels soucis de sécurité. Le message que nous retiendrons est bien que les conteneurs sont des processus d’isolation de ressources, point final. Il permettent de densifier les infrastructures et nous obligent à sortir du paradigme de la gestion des serveurs comme des animaux de compagnie.
Edson Yanaga, directeur “developer experience” chez Red Hat nous a présenté les différentes stratégies de déploiement qui tendent vers le zero downtime.
Pourquoi le zero downtime ?
À ce stade, nous avons eu droit à une démonstration sur une infrastructure Kubernetes/OpenShift provisionnée dans une VM de 8 Go de RAM : Red Hat Container Dev Kit.
Les stratégies zero downtime démontrées au sein de Kubernetes seul :
Pour aller plus loin, parlons A/B testing, qui implique des métriques métiers pour prendre une décision de garder A ou B
Pour finir, Edson a abordé le feature toggling en présentant FF4J, un framework de gestion de features pour Java.
Charlotte Cavalier et Christophe Pont nous expliquent de quelle façon ils ont résolu les problèmes et désillusions que peuvent rencontrer des prestataires lors de leur arrivée dans une grande société où le fonctionnement est “politique” et tend vers un immobilisme assez important.
Cette solution est un combat de longue haleine afin de pouvoir organiser des BBL (Brown Bag Lunch), c’est à dire des présentations sur le temps de la pause déjeuner. Combat de longue haleine car il faut réussir à convaincre la hiérarchie afin de pouvoir réaliser cela, sans compter le fait de convaincre les employés de participer à ce genre d’activité. Mais après avoir réussi à réaliser cela, le succès est tellement important que tout le monde en redemande et que cela s’est étendu à la tenue de formations en interne, d’agile games, le tout de plus en plus régulièrement.
Si vous êtes triste dans votre mission, vous savez ce qu’il vous reste à faire.
Ce compte rendu illustre quelques conférences que nous avons suivies lors de l’édition 2017 de Devoxx France. Toutefois, ce n’est qu’une maigre partie de l’ensemble des présentations qui ont été dispensées durant ces 3 jours de conférences. Nous ne pouvons que vous conseiller d’aller sur la chaîne Youtube de Devoxx France où l’ensemble des conférences seront disponibles très prochainement.
Nous nous retrouverons prochainement pour différents articles sur Breizhcamp, dotScale et le Paris Container Day.