L'open bar à smoothies

Dites, j’espère que c’ets que moi, mais la box de rédaction, celle dans laquel j’écrit ce message, fait monter mon cpu à 90% et ma ram aussi… je sais pas mais y’a un truc dans l’interface client de ZdS, ou au moins un truc qui passe mal avec mon PC.

PS: C’est une de mes extenssions ou un morceau de ma conf de firefox, mais lequel ? Ce qui est certain c’estq ue ce n’ets pas ceux qui sont en navigation privée.
PPS: C’est l’extenssion Trace(son github) qui est fautive, le fait de changer certains paramètres vu par le javascript à un impact sur la boite d’édition, je me demande si, en concéquence certaines résolution et configurations ne peuvent pas êtres prises en charge par le site.

Pas de soucis pour moi venant de l’éditeur, mais sur Firefox tu peux check "about:performance" pour te dire les extensions/tabs qui consomment

Nan mais j’ai trouvé, en virant Trace, j’ai plus aucuns problèmes de ram ou de cpu. Ce qui est étrange c’ets que cette box cherche à avoir des infos bloqués par Trace, des infos qui sont quand pas utiles pour une box d’édition…

Ouais, ça ça fait partie des choses que j’ai toujours du mal à saisir. A priori on a des gestionnaires de paquets qui permettraient d’avoir les bibliothèques en commun et même de faire coexister plusieurs versions, avec une bonne gestion des dépendances.

Un environnement virtuel pourrait se résumer à une liste de versions ou à des liens symboliques, mais il faut croire que les gens préfèrent avoir des copies à tous les niveaux.

@Taurre:

À ce sujet, il y a truc que je n’ai jamais saisis c’est pourquoi cet engouement maintenant alors que c’était faisable depuis très longtemps ? Je veux dire, objectivement, quand tu creuses, un container docker c’est grosso modo un chroot

Oui au runtime, techniquement, un container n’est rien de plus qu’un processus complètement isolé avec un chroot. Mais tu oublies :

• Le format des images, qui est maintenant standardisé, qui n’est rien de plus qu’une archive TAR avec deux trois JSON dedans
• La possibilité de créer ces images à partir d’une syntaxe bête comme la lune : le Dockerfile, qui n’est rien de plus qu’un script bash un peu épuré
• Le fait que ces images soient des couches les unes par-dessus les autres, ce qui permet une mise en cache relativement efficace, qui n’est rien de plus que… ah non, y’a pas de moyen simple de faire ça avec des outils qui existent depuis des lustres, ou bien avec git, mais là ça commence à devenir sale,
• Le fait que tout cela vienne avec un système de distribution et de registries, qui ne sont rien de plus que des disques durs partagés avec une base de données,

Réduire l’apport des conteneurs à leur seul aspect technique, c’est passer complètement à côté du sujet. Le fait est que les conteneurs (et les registries) apportent :

• Une façon de concevoir son application comme une collection de services isolés,
• Constructibles relativement efficacement,
• Exécutables sur n’importe quel environnement,
• Qui sont de ce fait absolument identiques pour les développeurs, la CI, les opérationnels et la prod,
• Qui sont faciles à partager en tant que tels, et donc à réutiliser pour assembler d’autres systèmes (je pense aux images standard NGINX, Redis, etc.).

Certes, on pourrait faire ça avec des outils qui existent depuis très longtemps, j’ai d’ailleurs bossé dans une boîte où les gens s’amusaient avec LXC, qui existaient déjà depuis un bail avant Docker, mais côté pratique et maintenabilité, il y a un gouffre entre les scripts faits maison avec <3 pour créer des conteneurs LXC, et un service open source, bien standardisé et amplement documenté.

Tu peux développer ce point ? Parce que de mon point de vue c’est justement le contraire. Je ne trouve rien de plus inintelligible et d’inmaintenable qu’une chiée de containers docker qui sont censés communiquer entre eux.

Je t’invite, dans ce cas, à apprendre à te servir d’un orchestrateur comme Kubernetes pour configurer un système composé de multiples services. Parce que ça aussi, en théorie, tu peux le faire avec des scripts fait maison et ça ne va pas non plus casser 3 pattes à un canard du point de vue de l’innovation technique, mais c’est justement le rôle de l’orchestrateur de s’occuper de gérer cette complexité de façon automatique, et c’est précisément les propriétés des conteneurs citées plus haut qui rendent son travail possible.

C’est sûr que si on se contente de conteneurs (que beaucoup de gens utilisent mal, par ailleurs), sans passer au niveau d’abstraction supérieur, on voit mal l’intérêt, et encore moins quand on sait que docker est truffé de bugs critiques que ses pendants standardisés (et méconnus) corrigent par design. Par contre, dès lors que ton système est géré par un orchestrateur dont le fonctionnement par défaut te permet d’automatiquement redistribuer les diverses instances de tes services quand une machine tombe subitement en panne ou devient inaccessible, ou encore de roll out une mise à jour (c’est-à-dire démarrer la nouvelle version, attendre qu’elle donne un signe de bonne santé, envoyer progressivement du traffic dessus, puis, quand la prod est stable, commencer à stopper et supprimer les anciens conteneurs, tout ça en une seule commande), ou la faire passer à l’échelle (j’ai besoin de trois instances de plus de ce service, composé de ce serveur, de son moniteur et de son cache redis, et n’oublie pas de mettre à jour la conf du load balancer) en une bête commande, tu peux te permettre de faire en trois minutes et plusieurs fois par jour, ce qui était hier un événement hebdomadaire mobilisant une équipe entière pendant une durée de plusieurs heures à plusieurs jours.

Et ça, c’est sans mentionner la version locale du même orchestrateur, qui tourne dans une VM sur le laptop des développeurs, pour leur permettre de reproduire sur leur machine la même configuration qui tourne potentiellement sur un parc de plusieurs dizaines ou centaines de serveurs en prod. Tout cela demande de raisonner sur des abstractions, dont l’unité élémentaire n’est même plus le conteneur, mais qui ne peuvent simplement pas exister si ton code n’est pas conteneurisé.

Je ne voudrais pas paraître rabat-joie, mais ça s’appelle un exécutable statique. C’est vraiment pas nouveau et certainement pas propre au Go.

Là encore, tu passes totalement à côté de l’aspect pratique : à quel point c’est facile (attention, je dis bien facile, pas faisable) d’écrire un site web qui embarque ses templates, ses fichiers de migration, et même sa documentation auto-générée pour la servir via le endpoint /doc, dans un exécutable statique en C ?

Tu sembles complètement oublier qu’il y a un monde de différence rendre quelque chose techniquement possible, et le rendre faisable avec facilité par le premier venu. Pourtant, c’est le second qui permet que les gens n’aient plus à s’en soucier et se libère du temps pour faire autre chose de plus utile que ce qui est techniquement possible. Comme par exemple s’assurer qu’ils rendent un vrai service qui répond aux besoins bien réels et humains de leur utilisateurs.

C’est voulu de faire l’impasse sur le C, ici ?

Oui, et je fais même l’impasse sur C dans tout mon post, notamment parce qu’il est question d’avenir, et que je tiens pour acquis, à notre époque, que les performances ne devraient pas venir au détriment de la safety. Il faut bien moins de travail pour qu’un programme Rust ait (ou surpasse) les performances de son homologue C, que de travail pour qu’un programme C ait les mêmes garanties de ne pas segfaulter que son homologue Rust (ou même Go, ou Java, ou même Python… Parce qu’on n’a pas eu besoin d’attendre Rust pour avoir des langages qui permettent d’écrire des programmes dans lesquels on dispose de cette garantie absolument extraordinaire que la mémoire sera libérée une fois et une seule). Entre les deux, en 2020, je considère qu’un ingénieur emploiera bien mieux son temps à optimiser un programme qui est automatiquement robuste, qu’à robustifier un programme qui est automatiquement rapide : la différence, c’est que le premier est tout à fait qualifié pour tourner en production dès le premier jour.

Édit :

Je ne sais pas quoi répondre si ce n’est que je trouve cette analyse très juste et fort pragmatique. Merci bien, cela répond pour partie à mon interrogation.

@nohar : tout d’abord, merci d’avoir pris le temps de me répondre de manière aussi complète.

Mmm… Ici, mis à part le point 2 (le chroot est facile à créer avec une commande comme debootstrap, mais plus fastidieux à configurer parce qu’il doit l’être avec un script bash ou un autre outil d’automatisation), un chroot dans un tar.gz rempli les mêmes critères (si on exclu Windows pour l’aspect « exécutable sur n’importe quel environnement », point sur lequel nous sommes d’accord, je pense). Je ne dis pas nécessairement que c’est mieux, juste que cela fonctionne également, depuis longtemps et qu’étrangement à mes yeux cette solution (l’emploie d’applications dans des conteneurs) semble tout d’un coup être « LA solution ».

Ce qui m’inquiète et me déplaît surtout avec ces solutions, c’est justement l’abstraction qu’ils fournissent. Gagner en simplicité d’utilisation au détriment du contrôle (comprendre : je sais ce qui tourne, quand et comment) est une chose que je ne peux concevoir. Les deux doivent rester pour moi correlés. Or, les solutions à bases de conteneurs ont justement pour but de fonctionner comme des boîtes noires : « tu l’instanties, ça marche et surtout tu n’y touches pas ». Typiquement ce que je déteste.

Après, c’est un point de vue personnel, qui ne contredit en rien ton argumentation.

Oui, alors là il me semble que l’exemple que tu donnes est un peu biaisé. Si je ne dis pas de bêtises, tu fais référence au module Go permettant de construire un serveur HTTP. Sauf qu’il me semble que c’est une solution qui propose une alternative à l’utilisation de serveurs HTTP existants comme Apache, NGINX ou httpd en plus de l’application web en elle-même.

Or, à défaut d’une telle bibliothèque en C, c’est plutôt un serveur HTTP et du CGI que tu utiliseras (genre de l’OpenBSD, avec httpd et slowcgi). Donc, non, ce n’est pas possible en l’état de « faire la même chose qu’en Go », mais ça l’est d’employer un exécutable statique généré avec un autre langage que Go (ce qui était le propos de mon message).

Le fait que cela le rend « faisable par le premier venu » ne signifie pas que c’est une bonne solution, ni que c’est la seule qui la rende faisable facilement, ni que c’est la seule manière de répondre aux attentes des utilisateurs.

Mon point de vue est plutôt qu’à notre époque, c’est le temps de développement et d’apprentissage qui ne devrait pas être sacrifié, pour quelles que raisons que ce soit. En vrai, j’ai bien plus l’impression qu’un langage est adopté par l’industrie pour le temps de développement et d’apprentissage qu’il fait « gagner » bien plus que pour une quelconque autre raison. Je ne dis pas que ces langages n’apporte rien de plus, juste que le critère dominant est le temps et rien d’autre.

J’estime pour ma part qu’un développeur emploiera bien mieux son temps à réfléchir à ce qu’il conçoit, à le tester et à le déboguer qu’à essayer de le pousser en prod le plus rapidement possible.

Pour ce qui est du C, on peut l’aimer ou ne pas l’aimer pour des tas de raisons et notamment pour ses deux qualités et défauts principaux : son minimalisme et son « laxisme » (je pourrais dire « libéralisme » pour utiliser un adjectif plus positif, mais ce ne sont que les deux faces d’une même pièce), toujours est-il que ce sont justement ces deux aspects qui font qu’il est toujours utilisé en 2020 et qu’il n’a pas pû être remplacé par un autre langage.

Je ne dis pas nécessairement que c’est mieux, juste que cela fonctionne également, depuis longtemps et qu’étrangement à mes yeux cette solution (l’emploie d’applications dans des conteneurs) semble tout d’un coup être « LA solution ».

Parce que l’ingénierie informatique ne fonctionne pas tellement différemment de la recherche : à un instant donné, tu auras le plus gros de la communauté qui sera en train de travailler collectivement sur une idée, pour la développer, et voir où elle nous mène. Si l’idée permet d’aller plus loin que l’existant, alors elle se fait massivement adopter, ce qui permet à plus de monde de contribuer, etc.

Ce ne sont pas les conteneurs seuls qui sont considérés comme "la" solution, mais l’usage de conteneurs isolés et d’orchestrateurs pour architecturer des applications sous forme de micro-services, pour créer des systèmes qui sont résistants aux défaillances de l’infrastructure. Infrastructure que l’on choisit d’ailleurs de plus en plus souvent de migrer vers un cloud, plutôt que d’acheter soi-même ses machines, ne serait-ce que parce que cela revient au final moins cher, et est peut-être bien une solution pour limiter l’impact de la crise écologique qui nous arrive sur le coin de la figure dans les années à venir.

Ce qui m’inquiète et me déplaît surtout avec ces solutions, c’est justement l’abstraction qu’ils fournissent. Gagner en simplicité d’utilisation au détriment du contrôle (comprendre : je sais ce qui tourne, quand et comment) est une chose que je ne peux concevoir. Les deux doivent rester pour moi correlés. Or, les solutions à bases de conteneurs ont justement pour but de fonctionner comme des boîtes noires : « tu l’instanties, ça marche et surtout tu n’y touches pas ». Typiquement ce que je déteste.

Cela ressemble grandement à un préjugé.

Une abstraction ne sert pas, fondamentalement, à rendre les choses compréhensibles pour des singes, et ne te dispense pas d’avoir une certaine compréhension de ce qui se trouve en-dessous. C’est simplement qu’à un moment, si tu veux être capable de faire tenir la totalité de l’architecture d’un système comme Netflix ou Tinder dans ta tête et de raisonner, tu n’as pas d’autre choix que de t’abstraire des menus détails, quitte à zoomer au besoin sur un composant particulier, et t’intéresser de près à ce qui se passe en-dessous.

L’abstraction sert à rendre intelligible ce qui nous dépasse en complexité, de manière à pouvoir raisonner, mais ce n’est absolument pas (du moins de mon point de vue), un prétexte pour ignorer ce qui se passe en-dessous.

Mon point de vue est plutôt qu’à notre époque, c’est le temps de développement et d’apprentissage qui ne devrait pas être sacrifié, pour quelles que raisons que ce soit. En vrai, j’ai bien plus l’impression qu’un langage est adopté par l’industrie pour le temps de développement et d’apprentissage qu’il fait « gagner » bien plus que pour une quelconque autre raison. Je ne dis pas que ces langages n’apporte rien de plus, juste que le critère dominant est le temps et rien d’autre.

Parce que le temps que tu n’as pas besoin de passer à apprendre à gérer ta mémoire à la main peut être réinvesti dans l’apprentissage du design ou de l’architecture système.

Parce que minimiser le temps entre la conception d’une idée et le moment où on peut observer un utilisateur qui se sert de notre programme et avoir des métriques sur ses performances, permet de diminuer la charge cognitive des développeurs (limiter notamment les interruptions au bout de 3 mois), et leur permettre d’améliorer la qualité, la quantité et la régularité de leur travail.

Ce qui m’amène à :

J’estime pour ma part qu’un développeur emploiera bien mieux son temps à réfléchir à ce qu’il conçoit, à le tester et à le déboguer qu’à essayer de le pousser en prod le plus rapidement possible.

Utiliser un langage à haut niveau d’abstraction ne dispense absolument pas de réfléchir, simplement je trouve que forcer les gens à passer du temps à gérer manuellement ce qu’une machine peut faire 10 fois plus efficacement qu’eux en une fraction de seconde, relève du masochisme et de l’aliénation gratuite.

Le progrès n’est pas là pour remplacer les développeurs par des chimpanzés : il est là pour leur permettre de concevoir des solutions beaucoup plus complète et complexes qu’avant, et pour beaucoup moins cher : le temps gagné, c’est du temps réinvesti.

Réduire l’apport des conteneurs à leur seul aspect technique, c’est passer complètement à côté du sujet. Le fait est que les conteneurs (et les registries) apportent :

• Une façon de concevoir son application comme une collection de services isolés,
• Constructibles relativement efficacement,
• Exécutables sur n’importe quel environnement,
• Qui sont de ce fait absolument identiques pour les développeurs, la CI, les opérationnels et la prod,
• Qui sont faciles à partager en tant que tels, et donc à réutiliser pour assembler d’autres systèmes (je pense aux images standard NGINX, Redis, etc.).

Mmm… Ici, mis à part le point 2 (le chroot est facile à créer avec une commande comme debootstrap, mais plus fastidieux à configurer parce qu’il doit l’être avec un script bash ou un autre outil d’automatisation), un chroot dans un tar.gz rempli les mêmes critères (si on exclu Windows pour l’aspect « exécutable sur n’importe quel environnement », point sur lequel nous sommes d’accord, je pense). Je ne dis pas nécessairement que c’est mieux, juste que cela fonctionne également, depuis longtemps et qu’étrangement à mes yeux cette solution (l’emploie d’applications dans des conteneurs) semble tout d’un coup être « LA solution ».

Les conteneurs à base de cgroups c’est bien plus puissant qu’un chroot. Il faut voir ça comme une forme de virtualisation légère, car si le noyau est commun et partagé entre ces groupes, ils agissent de manière complètement isolée à tout point de vue. Et de manière plus simple à mettre en oeuvre qu’un chroot qui répond aux mêmes exigences, notamment en terme de simplicités.

Et tu peux aller bien plus loin. Par exemple, je travaille sur des plateformes embarquées et on a déjà eu des cas où on devait apporter des garanties que seuls les cgroups pouvaient fournir. Tu peux limiter la mémoire de chaque groupe de processus pour éviter qu’ils bouffent toute la RAM pour x ou y raison, de même pour les CPU ou accès disques. C’est d’une souplesse remarquable, tu ne peux pas le faire avec chroot. Ou du moins de manière non tordue.

Ce qui m’inquiète et me déplaît surtout avec ces solutions, c’est justement l’abstraction qu’ils fournissent. Gagner en simplicité d’utilisation au détriment du contrôle (comprendre : je sais ce qui tourne, quand et comment) est une chose que je ne peux concevoir. Les deux doivent rester pour moi correlés. Or, les solutions à bases de conteneurs ont justement pour but de fonctionner comme des boîtes noires : « tu l’instanties, ça marche et surtout tu n’y touches pas ». Typiquement ce que je déteste.

Je ne trouve pas que Docker cache tout. Au contraire même, si tu as le Dockerfile, tu sais comment il a été généré et ce qu’il y a dedans. Et comme une image Docker est simple (tu ne fais pas tourner tous tes processus dans le même), tu améliores justement le contrôle sur ce qui se passe. Tu limites les effets de bord, tu peux contrôler finement les entrées et sorties du conteneur et ainsi éviter des comportements non souhaités ou une exposition non utile.

Tu as tous les outils pour comprendre ce que tourne dedans et déboguer ce qui se passe. Honnêtement je ne vois pas la perte de contrôle dedans.

De plus, je suis méfiant avec cette volontée de tout contrôlée, partout, tout le temps. Je n’ai pas le temps, ni les connaissances et encore moins l’envie de tout auditer. Si Firefox crache, oui je peux étudier moi même les raison et peut être corriger le problème. Mais faute de temps et de connaissances du logiciel en lui même, je ne le ferais jamais. Je rapporterais un bogue en espérant une correction.

Et c’est le cas pour la plupart des logiciels que j’emploie. À part ceux que je connais bien le code et sa techno (et ils ne sont pas nombreux).

L’abstraction permet de gagner du temps et de l’efficacité. Oui c’est forcément en contre partie d’un système un peu plus complexe. Le code du noyau est plus complexe car il a des couches d’abstractions pour tout. L’architecture du processeur, le boutisme, qui masque les différences entre les périphériques d’une même famille pour leur pilote, etc. Ce n’est pas gratuit, ni en performances, ni en lisibilité et simplicité du code. Mais le gain est énorme, tu peux l’exécuter sur des machines radicalement différentes en ayant un espace utilisateur qui exploite la même interface pour y communiquer. Cela évite qu’on code des noyaux différents pour remplir le même besoin en étant plus brut en terme d’architecture du code.

Et c’est le cas pour le système en entier, nous avont des bibliothèques de partout pour uniformiser et cacher des spécificités et je ne pense pas que ce soit regrettable de s’en servir.

Docker apporte des garanties appréciable pour un exploitant et permet de cloisonner les métiers. Est-ce que celui qui doit gérer l’infrastructure Docker doit connaître les systèmes dans les moindres détails ? En admettant que c’est réaliste (ce qui ne l’est pas).

Tu peux donc avoir quelqu’un dont le métier c’est de gérer les instances et la répartition des images Docker, un dont le métier sera plutôt de créer ou choisirs les conteneurs pour répondre au besoin métier, etc. Pour de grandes structures, cela fait vraiment sens.

Mon point de vue est plutôt qu’à notre époque, c’est le temps de développement et d’apprentissage qui ne devrait pas être sacrifié, pour quelles que raisons que ce soit. En vrai, j’ai bien plus l’impression qu’un langage est adopté par l’industrie pour le temps de développement et d’apprentissage qu’il fait « gagner » bien plus que pour une quelconque autre raison. Je ne dis pas que ces langages n’apporte rien de plus, juste que le critère dominant est le temps et rien d’autre.

Le temps, c’est ce qu’il coûte cher aussi, c’est un point à ne pas oublier dans l’équation.

J’estime pour ma part qu’un développeur emploiera bien mieux son temps à réfléchir à ce qu’il conçoit, à le tester et à le déboguer qu’à essayer de le pousser en prod le plus rapidement possible.

Je dirais que les deux peuvent aller ensemble.

Je veux dire, Python ou Rust apportent des garanties que le C n’apportera jamais nativement. Du coup, il y a des classes de bogues qui deviennent improbables voire inexistant. Tu peux focaliser ton attention, ton temps et tes compétences sur d’autres sujets.

Et du coup tu peux délivrer plus vite ton produit, en ayant moins peur que cela explose en vol. Cela peut arriver, mais tu as réduit automatiquement ta surface d’attaque.

Le problème réel sans doute des langages haut niveau c’est que certains oublient certaines bases nécessaires. Cela est criant dans l’enseignement. Genre comme Java gère la mémoire, pas besoin de comprendre comment ça se passe. C’est faux, tu fais une boucle qui alloue de nouveaux objets en quantité alors qu’à l’itération suivante tu n’en a pas besoin, tu peux avoir des surprises de consommation. Ce n’est pas magique et de nombreuses formations l’oublient.

Mais malgré tout, Java permet de moins se préoccuper de la mémoire que le C et d’éliminer nombre de bogues habituels qu’un développeur C rencontre souvent. Le C implique une rigueur assez inhumaine pour un projet d’envergure.

Donc si ton projet est plutôt haut niveau. Genre tu ne codes pas pour un microcontrôlleur ou un pilote de périphérique où l’aspect minismaliste et le contrôle fin de ce qui se passe est fondamental. Le faire en C est risqué et sans doute problématique.

Il faut savoir choisir sa techno dans le bon contexte.

Pour ce qui est du C, on peut l’aimer ou ne pas l’aimer pour des tas de raisons et notamment pour ses deux qualités et défauts principaux : son minimalisme et son « laxisme » (je pourrais dire « libéralisme » pour utiliser un adjectif plus positif, mais ce ne sont que les deux faces d’une même pièce), toujours est-il que ce sont justement ces deux aspects qui font qu’il est toujours utilisé en 2020 et qu’il n’a pas pû être remplacé par un autre langage.

Le C reste de moins en moins courant pour le haut niveau, il faut le reconnaître. Pour faire de l’assembleur générique il ne le sera probablement pas ou alors par quelque chose de assez similaire en fin de compte.

Je ne sais pas quoi répondre si ce n’est que je trouve cette analyse très juste et fort pragmatique. Merci bien, cela répond pour partie à mon interrogation.

J’ai parlé de l’utilisation « discutable » qui est souvent faite des containers, et qui les a rendus aussi massivement populaires, mais il faut noter que cela n’enlève rien au fait qu’ils sont une brique utile dans le cas de besoins d’infrastructures importants, pour l’orchestration par exemple.

Un problème auxquels les containers s’attaquent, c’est le morcellement de l’écosystème Linux. Si tu écris du code avec une syntaxe pour Python 3.7 mais que la distribution de ton voisin est en 3.6, ça va casser.

Les containers apportent une réponse (peu économe en ressources) à ce problème. Au sein d’un groupe restreint de personnes, une solution possible est de chercher une voie de standardisation comme, « tout le monde sous Ubuntu LTS ». C’est ce qu’on a essayé de faire au sein de mon entreprise et, même si j’étais sous Arch auparavant, je ne la trouve personnellement pas déraisonnable.

Mais si on parle d’un projet open-source avec des centaines de contributeurs, la donne change. Faire un guide bien expliqué et qui gère suffisamment de cas est la solution qui était employée par les projets qui fonctionnent bien, jusqu’ici, et elle l’est toujours. Les containers permettent juste une seconde voie qui dirige vers un peu plus d’adoption, car dans les faits la friction à installer le logiciel est réduite et sur la grande quantité de gens qui entendent parler d’un projet, seule une petite partie ira jusqu’à l’utiliser ou à déployer ce qui en résulte, réduire la complexité perçue à l’entrée permet donc potentiellement d’augmenter cette petite partie, surtout si c’est une application complète.

Les containers sont juste un outil technique qu’il faut utiliser à bon escient. Dans l’idée, l’environnement d’exécution d’une application web écrite dans un langage non-compilé en natif sur l’infrastructure d’un grand compte est une succession d’abstractions :

• Langage machine
• Assembleur
• Langage compilé
• Interpréteur/exécuteur de bytecode
• Unité de code interprété (client)
• Classe/module
• Type abstrait hérité du framework
• Application
• Container
• Système hôte virtualisé
• Ochestrateur
• Cluster de servers
• Datacenter au milieu des champs
• Emprise foncière

Si tu parles à un microcontrôleur, il te faudra les deux ou trois premières. Si tu fais un petit projet d’études pour débuter dans un langage, il t’en faudra les six ou sept premières selon sa typologie. Si tu es Google et qu’on te demande, trois cent fois par seconde, la meilleure façon de relier Vladivostok à Barcelone par la route mais de préférence en évitant les ferries, ou que tu es une banque qui va devoir faire traverser le pays à une transaction à chaque fois que quelqu’un achète du pain avec sa carte, tu auras quelques bonnes raisons de tout vouloir.

De plus en plus d’entreprises importantes, comme Discord ou les entreprises de jeu en ligne, ont également des besoins d’infrastructure importants (et qui va en croissant) et elles se font écouter. C’est pour cela que les développeurs reproduisent les schémas qu’elles choisissent d’employer.

Bonne journée,

Je ne vois pas en quoi il faudrait utiliser avec parcimonie les conteneurs. C’est un peu ce qui fait qu’un smartphone et son ecosysteme, ca marche bien mieux qu’un PC: justement parce que tout est dans des conteneurs.

L’exemple n’est pas anecdotique, c’est bien une des sources d’inspiration des certains geants de la tech pour justifier de shifter 100% vers du cloud natif et donc l’utilisation massive de container.

A lire certains messages, j’ai l’impression que certains minimisent l’avancee conceptuelle des containers tant sur l’ecosysteme numerique tout entier, que, par la force des choses, la maniere de developper des applications.

D’ailleurs, je vais faire une prediction. La prochaine evolution sera une CRI semblable a une VM, ce qui permettra d’avoir un acces au hardware via diverses techniques d’isolation (IOMMU/PCI Passthrough) de sorte que la stack classique hardware <-> OS [ containers ] sera totalement remplace par du hardware a la demande, scalable au plus bas niveau. Rendez-vous dans 5 ans. Ou peut-etre avant

(au passage, docker c’est juste une surcouche LXC)

Je vais pas rentrer dans ce débat, mais là si tu veux mon avis c’est vraiment pas la bonne piste, non, déjà rien que parce qu’une salle serveur en soi est un désastre écologique.

C’est possible, oui.

Ce n’est pas le sentiment que j’ai quand je vois par exemple comment on vend les conteneurs et le DevOps, justement. Avec ce système, c’est le développeur qui devient administrateur sur son conteneur et le pousse sur un serveur. On a davantage scinder les rôles entre développeurs et administrateurs système, le premier n’est plus conscient de ce qui se passe en dehors de son ou ses conteneurs, le second n’a plus à connaître les besoins des développeurs en dehors de l’infrastructure de gestion des conteneurs.

On peut y voir une avancée parce que les deux côtés ont « gagné du temps pour se concentrer sur autre chose ». Pour ma part, j’y vois une perte pour les deux : il n’y a plus (ou quasiment plus) d’échanges, chaque partie se retrouve cloisonnée dans sa spécialité et finalement perd globalement des connaissances dans la branche de l’autre (sans compter les relations humaines en moins).

En bref, si, l’administrateur système, là, il se rapproche du singe qui a « juste » à faire en sorte que les conteneurs tournent sans jamais savoir ce qui se trame en-dessous.

En effet, cela laisse toutefois sous-entendre que la gestion manuelle de la mémoire n’est pas un apprentissage intéressant, ce qui n’est pas mon avis.

Alors, de un c’est pas sympa de considérer les pratiques masochistes négativement. Tous les goûts étant dans la nature, ce n’est pas parce cela ne te plaît pas que c’est forcément mauvais. Ensuite, je n’ai pas dit qu’une personne utilisant un langage de plus haut niveau que le C le dispensais de réfléchir, juste qu’il serait à mon sens bien plus constructif de mettre l’accent sur l’apprentissage, la conception, les tests et le débogage que sur le temps de développement (oui, je sais, c’est contraire à la logique capitaliste) qui a tendance à être le seul argument, notamment pour le choix du langage.

Il va falloir que tu définisses « progrès » si tu veux que l’on s’entende la-dessus, plus précisément : le progrès comment ? édit : Le progrès pour quoi ? Le progrès pour qui ? Le progrès par qui ? Parce qu’en terme de « progrès », je ne trouve par exemple pas que les développeurs y ont gagnés ces dernières années, non, en tous les cas pas en connaissances générales.

Question technique ici : pour ce qui est de la RAM et du CPU, les limites que tu peux fixer par utilisateurs via /etc/limits.h (sous Debian et cie, je me rappel plus où est le fichier sous Red Hat et cie) n’étaient pas suffisantes ?

Tu limites effectivement les effets de bords sur le système hôte, en revanche tu perds en visibilité sur ce qu’il se passe (au sens : que fait l’application dans son evironnement, par exemple si elle merde). Si tu veux voir cela plus finement, tu dois entrer dans chaque conteneurs.

On est bien d’accord, mais là on parle d’un utilisateur lambda et de son navigateur. Si tu remplaces cela par un administrateur système qui doit s’assurer que sa machine est saine et a le comportement voulu, installer plusieurs sous-systèmes de fichiers configurés par on ne sait pas forcément qui ni comment, cela donne pas forcément envie de prime abord (oui, ok, c’est pareil si tu télécharges du code source, le compile et l’installe sans l’avoir audité auparavant, toutefois, tu le fais dans ton environnement).

Non, mais stop les gars, je n’ai pas dis : « à bas les abstractions, communiquons tous nativement avec nos disques pour gérer nos données ! ». On parle d'une abstraction particulière : les conteneurs. Évidemment que s’abstraire du matériel cela a du bon (pas dans de rares cas, mais bref), j’en utilise moi-même une chiée de couches d’abstraction rien que pour écrire ce message. Cela n’enlève rien au fait que l’utilité ou l’apport de certaines d’entre-elles reste discutable.

Là, on glisse vers un autre sujet qui est le cloisonement et la spécialisation des tâches. A minima, c’est une nécessité (une personne ne peut pas tout faire, ni tout connaître) toutefois c’est à mon sens utilisé de nos jours à l’excès. Trop cloisonner est à mes yeux nuisible sur le plan humain et au niveau de l’apprentissage en général.

Je vais éviter de glisser en politique et en économie, là on s’en sortira plus.

En effet.

Je profite de cet échange, au demerant fort intéressant, pour poser une question. On parle ici de technologie à la mode (que ce soit docker¹, Go, Rust ou Python). Ces technologies sont (ou vont être) demandées à l’embauche pour certains postes en informatique. Mais, en vrai, est-ce que l’informatique, ce n’est pas du code en COBOL ou FORTRAN77, sur une machines qui tourne sous AIX ou Solaris ? La mode, c’est bien jolie, mais si on regarde tous les trucs qui tournent, Python n’est-il pas un monstre de progressisme et de nouveauté ?

Bien sûr, j’exagère le trait, mais pour bosser sur AIX en ce moment, je me pose vraiment la question.

Par contre, il faut bien évidemment différencier ce qui existe et ce sur quoi on cherche des gens. Les postes s’ouvrent plus facilement sur des technologies à la mode et sur des secteurs grandissant que sur des vieux trucs qui périclitent où il suffit de remplacer une partie des départs à la retaite.

Mais … euh ! C’est pas DevOps tout ça. 😭

Avoir une infra à base de containeur, ça vise pas du tout à cloisoner les métiers. L’idée c’est un rapprochement fort entre les équipes de développement et la technique. On shift-left les tâches Ops mais en contre parti, il faut qu’un Ops aie conscience des besoins et problématiques des Dev (un opérateur technique dédié au moins).

Si on repart dans une logique de cloisonnement, on perd l’intérêt.

J’ai de la famille qui bosse sur des systèmes bancaires en COBOL. Tout simplement parce que toute l’infrastructure a été codée comme ça à la base, et que le système est trop critique (et trop gros aussi) pour pouvoir tout retranscrire en un autre langage. Mais je crois pas qu’ils aiment beaucoup le COBOL pour autant.

Ah ? ^^"
Ce n’est pas le résultat final obtenu, pourtant ? Je veux dire, il fait quoi ton « Ops » dans une architecture fonctionnant à base de conteneurs (vraie question) ?

Bah c’est aussi une partie de l’informatique, en effet. ^^"
Dès que tu as des systèmes critiques auxquels il est impossible de toucher pour des raisons de coûts ou autres (comme l’a précisé @Phigger), ben ça bouge plus. Le secteur bancaire est sûrement le plus emblématique à ce niveau où tu arrives à des abominations comme écrire des applications en Java (ou autre) pour jouer les interfaces avec des vieux brols en COBOL.

L’Ops, il gère l’infrastructure pré-prod, installe la CI/CD et a une activité de conseil pour les dev teams. Dans un gros projet, il va devoir gérer les services entre eux (les conteneurs).

S’il a juste docker build && docker run à faire, alors il faut passer en no-Ops.

Histoire de ne pas comprendre de travers : tu veux donc dire que l’Ops installe le système avant qu’il ne soit en production (il prépare et configure le ou les serveurs, donc ?) et met en place l’infrastructure CI/CD (donc fait en sorte que le code poussé par les développeurs soit testé automatiquement et éventuellement poussé en production s’il y a du CD, j’ai bon ?). Si je me plante pas jusque-là, qui maintient le système et l’infrasctructure CI/CD par après, c’est toujours lui ou bien il n’intervient qu’avant la mise en production ?

Peux-tu développer ce point ?

Les conteneurs doivent communiquer entre eux, certains utilisent des volumes, y’a l’orchestrateur, etc. Tout ça, souvent, ce sont les Ops qui mettent en place, qui moniterent et qui réparent .

Mmm… Ok, dans ce cas il y a une question qui me vient : si le rôle des administrateurs système (donc la partie « Ops ») est avant tout d’installer et de maintenir l’infrastructure de gestion des conteneurs, en quoi y a-t-il un rapprochement entre les développeurs et les administrateurs système ? Que leurs objectifs convergent davantage je suis d’accord (y a plus cette contradiction entre maintenir un système stable et pousser les dernières fonctionnalités), mais où est le rapprochement « fort » par rapport à l’ancienne manière de fonctionner ?

Le rapprochement il est qu’à tout moment un Ops est disponible pour la dev team. Il a son mot à dire et joue un rôle de conseil. Il sait à quoi sert le service et comment il fonctionne.

Là où avant (maintenant ?) on passe par un ticket qui serra traité par les administrateurs système, pas forcément le même à chaque fois, donc pas forcéement conscience des enjeux ni même du sujet.

Bon, ça peut également être automatisé mais le monitoring de la préprod, c’est les opérateurs.

Le "rapprochement fort" peut également se trouver dans le fait que pour une toute petite équipe, typiquement une startup qui démarre, les responsabilités de dev et d’opérations incombent à la même personne, qui d’une façon générale doit savoir comment résoudre le problème efficacement, comment déployer sa solution, mais aussi comment la monitorer en production.

Au final, qu’il s’agisse d’une personne seule en tout début de projet (mon cas actuellement) ou d’une équipe, les deux responsabilités incombent à la même personne ou équipe. (Je vois d’ici venir le non-argument "dans ce cas on fait des gens bons à rien et mauvais en tout", auquel je ne perdrai pas mon temps à répondre).

Si on prend la peine de lever le pif de l’aspect purement technique, cela permet aussi d’augmenter considérablement le bus factor d’une équipe, puisque chacun peut réagir au pied levé même quand l’expert local est cloué au lit par la grippe.

En termes de relations humaines, je ne conçois pas que l’on puisse y voir une régression puisque cela implique une collaboration complète entre les gens, pour que chacun, malgré son expertise personnelle, reste opérationnel sur l’ensemble du logiciel, de sa conception initiale au monitoring, et c’est ça tout l’intérêt du mouvement DevOps : plus il y a de gens pour se soucier du même aspect, plus ils communiquent, plus ils réfléchissent collectivement, et la qualité de solution vers laquelle ils convergent s’en retrouve rehaussée.