barmic 🦦 a écrit 5799 commentaires

faut dire, une croissance infinie dans un monde fini, ça pose quelques problèmes de logique

Pas du tout, la croissance c'est l'augmentation de la valeur d'une entreprise ou du pib d'un pays. Il peut très bien faire x1000/s jusqu'à la fin des temps. C'est une valeur monétaire on fait bien ce que l'on veut de la monnaie.

Ça ne veut pas dire qu'il n'y a rien à redire. Au contraire, comment est-ce que le calcul de cette croissance ou passer à autre chose pour prendre en compte des informations qui nous paraissent important. Et de même avec le PIB.

Mais non en soit l'argument croissance infinie dans un monde fini ne tient pas et il est plus de l'ordre de la phrase toute faite qui est ressorti sans comprendre que d d'une vérité. On parle d'un outil économique c'est l'augmentation d'une valeur en terme monétaire, ça n'a pas de limite physique : on crée de la monnaie en continue et on l'échange c'est ça qui crée de la croissance.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Mon commentaire était ironique. Là où tu parle de cacher l'outil et de le garder entre "sachants", moi je parle d'en partager l'usage et la connaissance.

C'est pas un point de détail ou une question de sens des mots, mais de vision du travail et de la collaboration. Je pense qu'étiqueter les gens comme sachants ou incompétents est une grosse erreur, une simplification à outrance et une manière de s'imposer ou se dédouaner problématique.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Bref, pour une efficacité maximale, dans le contexte des grands SI actuels, il vaut mieux qu'il reste "confidentiel" au sein d'une communauté de sachants en capacité de l'exploiter au mieux de ses capacités. Une médiatisation importante auprès des malfaisants de service conduirait cet outil tout droit au pourrissage en règle.

Tu veux dire qu'il fait prévoir une formation et un suivi pour ceux qui utilisent cet outil ? Tu as sans doute raison.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Les IM produisent aussi des suites de messages du même émetteur, c'est aussi de la maladie mentale ? J'ai pu aussi voir ce genre de comportement dans des bug tracker sans que ce soit de la relance.

Tu dis que ça n'est pas anodin, je suis d'accord, mais il manque quelque chose entre "le fonctionnement des outils de communication n'est pas anodin" et "les threads twitter relèvent de maladie mentale", tu ne crois pas ?

Le constat c’est que les “threads“ sont privilégiés […]

Non les 2 sont pratiqués.

[…] et on peut supposer honnêtement que le gain de rester sur Twitter malgré le fait que le support d’écriture ne soit pas adapté serait vécu comme supérieur à l’usage d’un support d’écriture plus adapté, dans la balance il y a forcément d’autres mécanismes qui font préférer le support inadapté.

Tu n'écris pas pour la beauté du texte, mais pour les personnes qui vont lire.

Tu pose ta vision avec ton prisme comme étant une vérité. Les threads ne sont pas une suite de réponse à soit même tel un délirant monologue, mais un tout comme tu construit tes textes en paragraphes. C'est un découpage de ton texte. L'IM, les sms, etc ne rendent pas fous. En tout cas pas plus que de voir chacune de ses prises de paroles notées comme ici par exemple.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je t'ai connu nettement plus pondéré. Chaque médium a ses usages et twitter les siens. Ils ne te conviennent pas ok. De là à parler de maladie mentale même si c'est pour la pratique et non pour les auteurs. Juger moins, comprendre plus ;)

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Oui oui tout a fait comme aujourd'hui si tu n'accepte pas les cookies certains sites te jettent. Je dis pas que ça n'est pas un problème en tant que drm, mais que ça ne change pas grand chose par rapport aux cookies.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je vous pas comment ton navigateur serait obligé de l'implémenter et de manière non débraillable. Comme la géo-localisation ou la webcam actuellement.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

J'ai compris la moitié de ce que tu raconte, mais pour les 2 trucs que j'ai compris :

• l'hébergement rest qu'une partie du cloud. Le sens de la phrase que tu cite c'est "tu confond fabriquer des moteurs et fabriquer des voitures". Tu as besoin de l'un pour faire l'autre mais tu peux difficilement vendre l'un comme étant l'autre
• le fais que des offres existaient avant l'utilisation tu terme n'invalide pas l'existence du mot. Énormément de mot c'est même l'une des façons classiques d'inventer des mots

Je suis par contre surpris que tu connaissent des gens qui faisaient déjà la même chose que du cloud tout en réclamant une définition de celui-ci :p

Ah et je sais pas ce qu'est un rant.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Personnellement, je trouve triste d'être OK avec ça.

C'est pas une question d'être ok ou pas. Avant de reprocher ça a mongo, ça pourrait être reproché à un paquet de logiciels même non commerciaux. Mais aussi à Intel, AMD, Nvidia et n'importe quel fabriquant de carte mère. Tu utilise du x86 ? C'est triste d'être ok avec ça.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Plein de monde qui clairement n'était pas habitué aux manifestations, ça respirait un amateurisme rafraichissant et authentique.

Après la manif' pour tous, puis les gilets jaunes, les manif de police et maintenant les anti-pass, il va falloir gratter pour trouver des français qui ne sont pas manifestants. Si présenter des manifestations comme non-habituées a un jour était un argument (je trouve que ça parle plus des corps intermédiaires que du fond des mouvements), je ne suis pas sûr qu'il ai encore même une once de rafraîchissement vu que ça fait des années qu'on a des mouvements non-habitués.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Dans les bugs encore récent et drôle, tu as des requêtes "upsert" pour mettre à jour ou insérer. Ces requêtes peuvent te dire des trucs du genre "error: _id already exists"…

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ça a continué avec des tonnes de bugs tous plus hallucinants les un que les autres. Si tu as des soirées de libre, remonte le bug tracker jusqu'à la version 3 et tu y trouveras les trucs les plus hallucinants que j'ai pu voir dans ma carrière¹.

Tu parle d'une version d'il y a 6 ans. C'est très vieux. Même pour pg, si tu prends une version d'il y a 6 ans, tu aura de gros gap (par exemple avoir des déploiement un peu plus sympa que du primaire/secondaire ou dans tout ce qui est partitionnement). Je ne parle même pas de redis qui était très balbutiant il y a 6 ans.

Critiquer aujourd'hui un logiciel si vieux, dans un domaine qui évolue autant (postgresql ne supporte pas de versions aussi vielles). C'est à minima non pertinent.

Ensuite le marketing, je comprends et en même temps je ne comprends pas pourquoi débrancher son cerveau. Sur un sujet dont c'est ton domaine s'appuyer sur les discours marketing, plus que sur l'architecture ça ne me parait pas être une bonne idée et c'est pas comme si mongo inc étaient les seuls à parler de mongo. De la même manière qu'il faut pas trop accorder d'importance au market de datastax (la boite derrière cassandra) ou d'elastic pour elasticsearch. Ils sont éventuellement intéressant pour savoir quel marché intéresse la boite, mais ça ne vas pas plus loin.

Si tu veux te marrer regarde redis et hazelcast :

• https://redisson.org/feature-comparison-redis-vs-hazelcast.html
• https://redislabs.com/blog/benchmarking-redis-enterprise-5-2-0-vs-hazelcast-3-9/
• https://hazelcast.com/compare-with-redis/
• https://hazelcast.com/resources/hazelcast-vs-redis/

C'est peut être désolant, mais il y a un marché et donc des gens qui se battent.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

C'est moi où tu reproche à une base de données NoSQL de ne pas être ACID ?

Là, tu es carrément de mauvaise fois, MongoDB est très polyvalent, PostgreSQL l'est encore plus, et les deux sont dans la même niche: des bases de données.

C'est pas parce que ça stocke de la donnée que c'est la même chose. Envoyer un recommandé et un sms, c'est de "l'envoi de message" pourtant. C'est de la sémantique ce que tu tente de faire, mais quand tu sort d'ACID tu quitte le monde de la base de données tel que tu semble le comprendre, c'est comme si tu te mettais à stocker à la main sur disque ou via ftp. Si on ignore ça, on a le genre de surprises que tu décrit.

[PostgreSQL] convient très bien aussi pour faire du clé-valeur (bien que j'ai un faible pour Redis pour ce besoin)

Tu vois t'es encore entrain de comparer des choux et des patates. L'un ne stock rien sur disque et est là pour faire de la latence faible a un modèle de stalabilité… particulier. Là où l'autre écrira toujours tout sur disque fourni largement plus de garanties etc. Bon perso je trouve que redis est le roi du goodenought, mais c'est une autre histoire.

Postgre est une excellente base de données et ça se voit car son moteur est très flexible et tiens la dragée haute à des moteurs pensés directement pour cette flexibilité (je parle de rocksdb ou cockroachdb qui sont des moteurs qu'on utilise pas directement normalement) alors que pg existe depuis 25 ans. AWS s'en sert par exemple pour produire leur solution compatible mongodb (mais ils n'utilisent pas le support jsonb libre, ils ont leur propre truc à eux). Mais il ne faut pas croire pour autant que tout est gratuit son event/notify est anémique face à de vraies solution (pareil pour redis).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

On stocke quelques Tio dedans sans problème particulier, on a plusieurs collections à plus de 20 millions de documents et qu'on met à jour à probablement plus de 2k/s sans problème particulier. Mongo n'aime vraiment pas avoir de gros documents ça le ralenti pas mal.

Je ne comprends pas trop les gens qui disent "j'étais avec X, oulala les galères, je suis passé sur Y (Y ayant rien à voir avec X), depuis ma femme est revenu !". mongo et postgre sont 2 outils très différents. Pour moi c'est vraiment comme dire "pour ma vis, j'utilisais une clef allen c'était une galère depuis que je me suis acheté une clef torx ma vie a changé, je la serre et la déserre avec plaisir". Ma machine à laver n'est pas meilleure que mon vélo.

Tous ces outils sont très bons. Ils ne sont juste pas fait pour les même usages. Souvent on est peu contraint et moins on est contraint moins la techno sous-jacente n'a d'importance. Quand on parle de grosse contraintes, il faut se rappeler que ce sont des techno utilisé pour d'énormes infra être petit à coté n'est pas une insulte (et je suis un tout petit à coté). Nous on utilise mysql/mongo/cassandra/infinispan selon le besoin et je n'irais pas dire que l'un dépasse les autres chacun vient avec ses avantages (ce que tout le monde a en tête) et ses inconvénients (qu'on a facilement tendance à oublier), mais si on ne prend pas en compte ses inconvénients ça pose des problèmes (et faut avoir du recul y compris sur ce qui est présenté par le vendeur de ses trucs).

Par exemple si mongo parle d'avoir des transaction par exemple, il faut pas se dire que c'est parti on refait comme en SQL. Tous ses outils et pg le premier tentent d’agrandir autant que possible leur surface d'utilisation, mais sauf cas particulier ça devrait rester à la marge (voir être ignoré) parce que ça remet en cause l'architecture de base du truc ce qui lui donnait un intérêt.

En plus avec PostgreSQL tu peux explicitement créer les indexes comme bon te semble, et profiter de toutes ses autres fonctionnalités.

Je ne te suis pas, de quoi parle-tu ? Mongo peut très bien avoir des indexes par contre postgre ne peux pas faire n'importe quoi avec du jsonb. Si par "toutes les autres fonctionnalités" tu entends "sauf ma majeure partie des fonctions relationnelles" ça en enlève un paquet et ça réduit fortement l'intérêt d'un moteur de base de données relationnelle à cela on ajoute un requêtage limité, de même pour les vues du coup. Clairement c'est pas fait pour la même chose.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Prêcher les "bonnes" pratiques sans donner d'exemples clairs n'est déjà pas très utile.

C'est pour ça que j'ai voulu prendre en un exemple, je voulais installer PHP et montrer ce que ça pourrait être, mais je n'ai pas eu le temps ce matin et je vais finalement m'abstenir.

J'aurais largement préféré qu'on me fasse des retours sur les problèmes rencontrés sur des architectures que je n'ai pas pu tester ou sur les paramètres particuliers d'Apache à surveiller, plutôt qu'entamer un débat sur "Faut-il coder avec moins de 3 indentations ?"

Très bien.

Niveau lisibilité, c'était autre chose… certains devs imprimaient les codes et dessinaient des accolades pour trouver les portions de code concernées.

La lisibilité c'est pas une question de testostérone. Tu n'es pas ton code et les remarques que j'ai pu faire sur ton code ne préjugé rien sur toi. Elles ne t'intéressent pas, très bien.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je me permet moi aussi de me taper l'incruste :)

Les fonctions permettent de gérer le niveau d'abstraction et de cloisonner un programme.

Si je prend l'un des plus haut niveau de profondeur du script :

// search for the pid with this inode in /proc/<pid>/fd  (need to be root)
$pid = "";
$process_name = "";
$process_cmdline = "";
if ($h1 = @opendir("/proc")) {
    $found = false;
    while (false !== ($file1 = readdir($h1))) {
        if (! $found) {
            if (is_numeric($file1)) {
                if ($h2 = @opendir("/proc/$file1/fd")) {
                    while (false !== ($file2 = readdir($h2))) {
                        if (! $found) {
                            if (is_link("/proc/$file1/fd/$file2")) {
                                $file3 = readlink("/proc/$file1/fd/$file2");
                                if (strpos($file3, "socket:[$inode]") !== false) {
                                    display("[..] Found inode for port $port in $file3 in /proc/$file1/fd");
                                    $status = file_get_contents("/proc/$file1/status");
                                    $status_ppid = "";
                                    $status_pid = "";
                                    $status_lines = explode("\n", $status);
                                    foreach ($status_lines as $line) {
                                        if (substr($line, 0, 4) == "Pid:") {
                                            $status_pid = trim(substr($line, 4));
                                        }
                                        if (substr($line, 0, 5) == "PPid:") {
                                            $status_ppid = trim(substr($line, 5));
                                        }
                                        if (substr($line, 0, 5) == "Name:") {
                                            $process_name = trim(substr($line, 5));
                                        }
                                    }
                                    if ($status_ppid == 1) {
                                        $pid = $status_pid;
                                    } else {
                                        $pid = $status_ppid;
                                    }
                                    $process_cmdline = readlink("/proc/$file1/exe");
                                    $found = true;
                                }
                            }
                        }
                    }
                    closedir($h2);
                }
            }
        }
    }
    closedir($h1);
}
if ($pid == "") {
    display("[!!] Fatal error : unable to find the main apache process pid in /proc for inode $inode");
    exit();
} else {
    display("[OK] Apache main process '$process_name' found : $process_cmdline (pid $pid)");
}

On a un savant mélange de manipulation de chaîne de caractères, de parcourt d'une arborescence et d'affichage. On a aussi des variables qui se balades à tous les niveaux.

Des fonctions permettent de s'abstraire de tambouille peut utile au fonctionnement globale (savoir comment on gère le format d'un fichier est indépendant de comment on va chercher ce fichier) (bon on est sur un cas pathologique où les conditions sont dans des if alors qu'ils pourraient être dans les while).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je ne pense pas[…]

Ton commentaire précédent ne parlait que d'infrastructure.

TLDR : Le seul retard réel existant en Europe est un retard d'investissement, et la volonté politique actuelle est une ennemie, pas une potentielle alliée.

Le fait d'avoir peu d'utilisateurs, ralenti la maturation des offres, réduit leur possibilité d'investissement, etc, etc. C'est même pas moi qui le dit c'est Octave Klaba¹ (patron d'OVH) et Quentin Adam² (patron de clevercloud). Ils n'affirment pas être au niveau des concurrents américains, ils disent qu'ils sont sur la voie qu'ils y travaillent et la seule façon de les aider c'est de les utiliser (pour ça, si c'est juste pour acheter des machines ils savent très bien en vendre).

Mais on est tout à fait d'accord pour le reste.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Tu confond cloud et hébergement et infrastructure. Une offre de cloud ce n'est pas une offre d'hébergement. Les gens ne vont pas chez AWS pour l'offre EC2 qui n'est pas géniale mais parce qu'ils ont besoin de différentes bases de données sans avoir envi d'avoir des compétences en interne pour installer/maintenir en condition opérationnel/monitorer/mettre à jour diverses bases de données, avoir accès à des ressources à la demande comme des GPU pour quelques jours ou quelques jours par mois, des outils de traitements automatique de langages naturels efficace, de faire du push mobile sans s'embêter avec google(qui en est à sa troisième API actuellement)/apple/huawei/…, etc etc. Ça coute peut être chère, mais moins qu'avoir les compétences en interne (il faut une bonne politique de recrutement, de formation, il faut plus de gens - parce qu'on gars qui sait tout faire ne pourra pas tout faire en même temps -, gérer la capitalisation des connaissances sur tout ses aspects,…) et c'est moins casse gueule. Il peut être intéressant de voir tout ce qui a était publié autour de netflix qui a démarré chez AWS pour se lancer rapidement, puis a tout mis en interne pour réduire les coûts avant de repartir chez Amazon quand ils ont vraiment grossi et qu'ils ont décidé de ce qui relevé de leur métier et ce qui n'en relevait pas.

Tant qu'on ne comprends pas la différence entre Azure et Gandi, on ne pourra pas tenter de concurrencer les gens d'aller voir le premier plutôt que le second.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Plus que la presse spécialisée qui recrache les discours commerciaux ? L'important ce qui t'es utile c'est :

• la performance mesurée
• la chauffe/consommation si tu monte ta machine

Détailler des bouts de spécifications ne fait que flatter l'égo du client un peu intéressé (moteur 16 soupapes, injection getho-blaster,…).

L'important c'est qu'au lieu de se transformer en zombie (« moi je suis team intel #pentiumM »), il faut s'arrêter, se demander ce qu'on va faire et trouver des benchmarks correspondants. Il y en a pleins.

S'attacher à des mesures de densité de transistors, finesse de gravure ou autre c'est intéressant pour des gens du domaine, qui s'intéressent à l'évolution technique pas à l'utilisateur final.

Tu ne compare pas les logiciels en fonction du nombre de ligne de code et tu ne crée pas une mesure de ligne de code "équivalent C" pour palier en fait que le nombre de ligne de code en C, python et haskell ne peut pas être comparé.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

C'est possible, mais il faut faire attention à savoir quels sont les biais que l'on inclue dans l'analyse parce que tous les paramètres ne sont pas indépendants les uns des autres. De plus ils permettent de donner une indication pas une vision globale.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

On en a déjà parlé ici, qui pointe vers ce lien. C'est loin d'être parfait mais ils y travaillent et c'est qui se fait de mieux que je sache (y pris hors mobile d'ailleurs).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je suis d'accord que c'est très confus. D'une part tu ne dis pas clairement l'objectif et d'autres part tu enchaîne les étapes sans les expliquer.

Tu ne décrit pas duplicity et ce qu'il t'apporte. Tu l'utilise avec ssh, mais c'est loin d'être la seule façon de faire et tu l'a choisi à la place de tar hors c'est ce qu'il utilise en interne.

La partie génération de clef, tu ne dis pas à quoi servent chaque clef. Tu commence en expliquant que tu t'es tromper en voulant tout faire d'un coup, mais tu dis ensuite autant faire tout d'un coup et tu décrit comment tout faire d'un coup.

En soit on comprend ce que tu dis et fais quand on connaît déjà tout ça. Donc je vois pas trop l'objectif du journal :

• tu c'est pour parler à des connaisseurs inutile d'entrer dans les détails
• si c'est pour aider quelqu'un qui ne connaît pas, séparer gestion des mots de passe et sauvegarde et décrire ce qu'on fait (et pourquoi) avant de le faire le semble nécessaire

En tout cas c'est super si tu es satisfait de la solution que tu as mis en place et tes content que traîner dans le coin t'ai aidé. C'est génial de vouloir partager continue !

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ça tombe bien ce qui est dis c'est que ce qui est sous-traité n'est pas la partie traitement de données. Toutes les boîtes de développement logiciel n'utilisent pas exclusivement du logiciel à eux.

Toute la partie "suivi de leurs assurés" ne semble pas être géré de la même façon.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Mais je suis plutôt partisan des approches 'lean' où on évite des usines à gaz pour 2-3 fonctionnalités qui nous intéressent.

J'évite de penser de cette façon. Les mots clefs n'ont pas toujours du sens en soit. Est-ce que c'est lean d'avoir de la complexité un peu partout plutôt que de regrouper tout ce sujet à un seul endroit ? Ça dépend de pleins de choses.

Il est parfois plus rapide de coder une fonctionnalité que d'apprendre à utiliser (et maintenir, et déployer, etc) des outils complexes. Je ne suis pas non plus partisan de l'approche inverse que consiste à tout coder tout seul.

C'est aussi pas simple de faire un passage de l'un à l'autre. Mais pour l'exemple le fait de regrouper tout cette problématique au même endroit permet d'avoir un comportement homogène partout.

one-to-one

Voir le module elixir Registry.

Est-ce que c'est à l'émetteur de se soucier de la liste de ses destinataires ? C'est un choix. 'fin c'est un choix jusqu'à ce que tu ai un grand nombre de destinataires ou que la liste des destinataires soit très mouvant.

que tu ne peux pas retirer le destinataire

Grâce au mécanisme de supervision des processus, le module Registry ci-dessus gère parfaitement la connexion/reconnexion d'un client. Est-ce cela dont tu parles ?

Tu garde un couplage entre l'emmeteur et le destinataire. Le plantage/mise à jour du destinataire impose un travail en plus à l'émetteur.

Oui, sauf que mettre en œuvre une stratégie à base de timeouts, de retries, voire de files d'attentes différentiées se fait en quelques dizaines de lignes de code, à comparer à la configuration d'un outil comme RabbitMQ (+ configuration du code client).

Je me doute, mais elle a donc de potentiels bugs, doit donc être pensée complètement en amont (tu as bien moins de flexibilité lors de ton run). La configuration d'un client rabbitmq c'est quelques lignes (et vraiment on parle en ligne et pas en dizaines de lignes) quelque soit le langage. La configuration d'un rabbitmq c'est fait une bonne fois pour toute.

que tu ne peut pas lisser ta charge en empilant des messages dans une fille ou si tu le fait c'est plus fragile parce que la file est géré par le destinataire et pas commune à plusieurs instances du destinataire

Voir GenStage

Si j'ai bien compris c'est l'émetteur qui doit gérer la disponibilité ou non du destinataire.

GenStage gère très bien le back pressure.

C'est très cool, ça n'est pas naturel avec AMQP (ça l'est déjà bien plus avec kafka).

Mais la back pressure ce n'est pas forcément le lissage de charge. Tu peux avoir du code qui reçoit des requêtes à un débit qui est acceptable pour toi, mais qui doit transmettre à quelqu'un d'autres qui a plus de mal. Si c'est intermittent le fait de laisser un brocker stocker les messages pour les donner tranquillement au destinataire c'est pertinent. Si tu veux être élastique de scale les destinataires en fonction de ce que tu empile, tu dois faire la remonté d'alerte ou de monitoring à la main pour ensuite avoir une autre partie qui gère tes déploiement. Avec des brocker ça peut se faire avec un peu de conf et se faire sur tout ou partie du système sans modification du code.

Je n'ai rien contre RabbitMQ (écrit en erlang en plus :D ) mais j'ai vu plusieurs cas où son utilisation n'était pas justifiée et créait un overhead énorme, pas seulement en terme de latence mais surtout en terme d'intégration et de maintenance.

Moi je n'ai pas d'action chez eux. Je répond juste à ton message qui ne voyais pas d'intérêt. Tu te retrouve à tout faire à la main (avec une certaine simplicité mais l'ajout de différentes bibliothèques) et tu n'es plus agnostique. Et surtout tu fais un choix de où tu place les responsabilités (avec ce que ça implique dans un sens comme dans l'autre). Sans aller dans l'idée qu'il faut que tout soit toujours agnostique, je me fais de petits outils amqp qui ne sont pas avec le même langage que le reste et j'en suis bien content.

Après je ne te parle pas des workflows surprenant comme router du trafic environnement pour des tests/expérimentations/bench qui te permettent de récupérer du contenu d'un environnement pour le jouer localement ou sur un autre environnement sans avoir à ajouter du code dédié à ton expérimentation.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je sais pas pourquoi tu viens me chercher sur kubernetes, mais kerbernetes n'a pas besoin d'un stagiaire pour redémarrer quand ça plante (et on l'a pas attendu pour inventer les watchdogs).

Après je ne sais pas si :

• laisser un stagiaire seul face à une prod est quelque chose de raisonnable surtout si redémarrer est la seule chose qu'il sait faire
• juger une techno à ce qu'un stagiaire présumé bête sait en faire est quelque chose de pertinent
• maintenir des travaux manuels facilement automatisables pour laisser du travail à des gens présumé ne rien comprendre est une bonne idée

Après chacun gère sa prod comme il l'entends.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll