Les compteurs Linky permettent à distance, à l'état, de réduire voire couper la puissance électrique délivrée dans nos foyers.

Et ces compteurs permettent de le faire foyer par foyer puisque l'identifiant d'un Linky c'est le PRM du foyer, et ça, c'est une simple ligne en base... Je précise cela en sachant que je suis passée par Enedis dans ma carrière.

Je cite Charles SANNAT qui tape une fulgurance à mon avis :

C’est toujours ainsi que se matérialisent les effondrements.
Par des rationnements.
Par des pénuries.
Et ce qui est terrible, par une réduction des libertés.
Charles SANNAT

Notre pays est en train de s'effondrer, façon URSS. C'est le mot que je cherchais sans mettre le doigt dessus :

• Les médicaments sont déremboursés => Rationnement
• Les déserts médicaux s'installent => Pénurie
• Certains cours essentiels ne sont plus enseignés => Rationnement
• Les routes gratuites se raréfient => Rationnement + Pénurie
• Les taux montent, impossible d'obtenir un crédit => Rationnement + Pénurie
• Etc.

Alors certes, c'est une façon de percevoir les problèmes, mais sous ce prisme de l'effondrement, les vautours du capital sont en train de faire leur dernier grand festin, puis partiront se nourrir ailleurs.

Ferez-vous partie des proies dévorés ? Sinon comment vous protegerez-vous ?

Il y a une idée qui me travaille depuis quelques temps et il faut que je l'écrive pour m'en débarrasser.

Les médias nous disent qu'il ne faut pas aider les plus pauvres car cela encourage l'assistanat. Nous pouvons même lire et entendre dans le monde occidental des milliardaires ou des journalistes nous expliquer que rien n'est gratuit, car au bout de course, il y a toujours quelqu'un qui a travaillé ; et c'est vrai.

J'écoutais dernièrement Warren Buffet parler de l'idée d'une sécurité sociale aux USA et le milliardaire s'appuyait sur cet argument pour expliquer que cela ferait du prolétariat des assistés voire des vampires qui suceraient la richesse produite par les travailleurs.

Et c'est ici que mon esprit s'est emballé...

Taxer la richesse produite par les travailleurs pour son bénéfice personnel, c'est la définition même d'un actionnaire. Fondamentalement, si on veut être en accord avec l'idée qu'il ne faut pas taxer la richesse des travailleurs pour une sécurité sociale car on est de droite néo-libérale, alors il faut être en accord avec l'idée qu'il faut interdire l’actionnariat qui fait la même chose.

Mais l'inverse est vrai aussi, si on accepte de taxer la richesse pour une sécurité sociale, alors on accepte l'idée même de taxer la richesse et donc l'actionnariat ne devrait pas être un problème pour la gauche socialo-communiste.

En fait, les deux camps s'accordent pour taxer la richesse produite par les travailleurs, mais chaque camp ne veut l'attribuer qu'à ce qui l'intéresse. Je trouve que c'est quand même moralement supérieur de vouloir taxer les travailleurs pour leur fournir une sécurité sociale complète et efficace car ils récupèrent ainsi le fruit de leur travail, ou éventuellement voient leurs semblables en profiter lorsqu'ils ne sont pas malades.

Après je ne suis plus contre les dividendes tant qu'ils sont majorés en valeur et en temps ; mais je suis pour qu'on interdise les plus-values sur le marché secondaire. Le marché primaire reste utile à l'économie, le secondaire et les produits-dérivés ne sont qu'un casino qui assassine les populations à petit-feu.

Je vais rentrer directement dans le vif du sujet en prenant argument par argument et en répondant à chaque fois. Puis j'apporterai les miens à la fin.

1) Les bus applicatifs permettraient de coder en évènementiel.

Oui mais ça ne veut pas dire que c'est la seule technologie permettant de le faire. Vous en connaissez sûrement une autre : les requêtes AJAX sur HTTP. Vous savez ce truc à la base de tous les internets "modernes" sorti en 1996.

Par essence une requête AJAX est asynchrone et c'est lorsque le serveur notifie le client qu'il a traité sa demande (ce qui est la définition même d'un évènement) qu'une fonction de call-back est invoquée.

2) Passer par un bus applicatif réduirait le couplage entre les services.

En général on me sort cet argument face à RESTful ce à quoi je réponds : le degré de couplage est le même.

Effectivement en RESTful ce qui compte c'est le chemin utilisé et un fichier JSON qui contient les données. Il ne s'agit pas là d'invoquer une méthode via RMI, ni d'employer la même technologie côté client et côté serveur, il s'agit d'envoyer un fichier texte contenant les bonnes informations sur une URL. Wouah mais quel couplage ! #Unbelievable

Nous sommes déjà au degré utile et essentiel de découplage. Commencer à vouloir s'abstraire de l'URL est un non-sens d'autant qu'elle se retrouvera quand même dans les messages des bus comme Kafka mais sous une autre forme : le type du message.

Je m'explique : pour qu'un message soit dépilé par le bon service, il faut qu'il soit typé (ie. je contiens tel contenu et j'incarne telle demande), or le typage d'une demande en RESTful c'est ni plus ni moins que l'URL. Avec les bus applicatifs comme Kafka, nous représentons ce typage sous la forme d'une entrée de type clef-valeur dans un header mais cela revient à la même chose que de contacter une URL. C'est juste moins facile à relire car les protocoles sont binaires et non textuels (cf. KafkaMessage) donc ça paraît "plus découplé" mais ça ne l'est ni plus ni moins.

3) Les bus applicatifs permettraient de gérer des queues de messages.

En réalité cet argument n'en est pas un. Nous avons ajouté de la puissance de calcul dans le bus dont le rôle sera d'encaisser les pics de charge ; or pourquoi ne pas affecter cette puissance de calcul (en générale inhumaine lorsque nous parlons d'un cluster Kafka) directement dans les µ-services ? (ndr. qui sont eux aussi un anti-pattern d'architecture)

Dit autrement, nous préférons affecter de la puissance de calcul à des unités de stockage de messages, rajoutant ainsi des latences et augmentant les coûts d'infrastructure plutôt qu'aux unités de traitement qui fournissent elles des calculs utiles.

Je suis favorable aux queues lorsqu'elles sont à l'intérieur d'une application, car elles aident à mettre en place des algorithmes de calculs mutli-threads et parallèles pour ainsi tirer parti de 100% des hardwares mutli-cpus / multi-cores.

Au niveau inter-applicatif c'est une très mauvaise idée car cela fait reposer nos SI sur l'élément le moins fiable du monde : le réseau.

4) Les bus applicatifs seraient plus sécurisés en forçant une rupture protocolaire.

L'argument du changement de protocole dépend de comment fonctionne le bus et de son implémentation. Par exemple les bus qui travaillent en SOAP sur HTTP fonctionnent sur HTTP... Comme nos requêtes REST en somme... #ChangementDeProtocoleSur20

Ensuite, la sécurité ce n'est pas qu'une simple histoire de protocole, c'est toute l'architecture qui doit être pensée pour être résistante aux attaques. Cet argument laisse accroire que la sécurité est une chose facile et que nous aurions magiquement augmenté le niveau juste par la présence d'un sacro-saint bus, ce qui est faux.

Enfin, en quoi un changement de protocole sécurise quoi que ce soit ? Si j'envoie un message via un bus, quoi qu'il arrive ce dernier sera traduit dans un format interprétable par l'application, si je peux effectuer une injection parce que l'application tolère les injections, je pourrai quand même attaquer le système.

Souvent, on me rétorque à cet argument que le bus peut faire des contrôles anti-injections par exemple, mais ce sont les mêmes personnes qui me disent de l'autre côté qu'un bon bus reste au niveau du réseau et qu'il doit être neutre au niveau application : décide-toi camarade.

Pour moi ce qui transporte un message ou une requête ne doit transporter que le message ou la requête et ne rien faire d'autre. Quand j'envoie ou que je reçois une lettre par la poste je ne veux pas que la poste ouvre ma lettre et en modifie le contenu "pour me protéger". #Censure Pour mes applications c'est pareil, je décide seule de ce qui est une attaque et de ce qui est une demande, pas le bus, donc pas de sécurité à son niveau. #SegragationOfConcerns

5) Le monitoring réseau est plus facile avec un bus.

Le bus est un endroit centralisé par lequel tout transite, donc enregistrer qui s'adresse à qui semble plus simple que faire la même chose dans un réseau maillé à la sauce internet où n'importe qui peut contacter n'importe qui d'autre.

Alors cela est vrai lorsque les bus ne sont faits que d'une seule instance... Or si une seule et unique machine peut encaisser toute la charge de vos messages, déjà je vous pose la question de l'intérêt d'avoir mis en place un bus pour un SI aussi peu complexe avec une volumétrie aussi faible mais admettons...

En général les bus applicatifs sont de très gros clusters avec des systèmes de réplication inter-instances... Les gens qui me parlent de monitoring vont me dire que "grâce au bus je sais qui envoie des messages au cluster de mon bus et qui reçoit des messages du cluster de mon bus". Ok... Mais que se passe-t-il à l'intérieur du cluster ? Quel trajet le message a-t-il effectué dans cette #BoiteNoire ?

En y regardant de plus prêt nous nous rendons compte qu'il existe une case à l'intérieur de laquelle nous n'analysons plus rien et nous décrétons que cette case n'est pas à superviser puisque c'est le bus lui-même ; ce qui revient à superviser un routeur.

Or ne regarder que ce qui est extérieur au bus se rapporte à monitorer la périphérie du SI, c'est-à-dire nos services et c'est déjà chose possible avec des logs produits par les services eux-mêmes + ELK pour un coût et une complexité d'infrastructure dix fois moindre.

Je sais que Kafka est plus intelligente et permet de se monitorer elle-même, mais cela ne répond pas à la question du nombre d'instances supplémentaires à gérer du fait de sa seule présence, ni même de l'expertise que cela requiert ou encore de la manière dont Kafka va contraindre la façon de coder les services.

6) Les bus me permettraient de changer un service sans impacter les autres.

L'idée sous-jacente est de dire que comme tout le monde parle au bus alors les services ne se connaissent pas entre-eux. Il devient donc possible de changer un service sans devoir patcher les autres.

En réalité ce coût de transformation est déporté non pas pendant la mise à jour du service mais au moment de la migration du bus A vers un autre bus B.

Sauf que l'économie de ces petits coûts traités au fil de l'eau se métamorphosera en supra-giga-facture lors de la big-bang transformation qui consistera à sortir totalement le SI du bus A. C'est évident, puisque tout le monde parlant au bus, aussitôt que l'on changera de bus, il faudra mettre à jour tout le monde avec la complexité et le risque que ce genre de "migration" impose. Vous le sentez l'anti-pattern du point de vue du CTO ou d'une DSI ?

Je préfère disposer d'une communication ad-hoc entre plusieurs services REST s'appuyant sur des Swagger faisant office de contrat d'interfaçage. Ainsi tant que tout le monde parle le bon JSON, ça marche point.

Pas de protocole particulier, pas de lib "kafka-client" à tirer dans mon application, pas de dépendances vers des tiers, juste des fichiers textes ayant une structure (CSV, JSON, XML, YAML, etc) et que j'envoie ou reçois sur le réseau ; avec des mises à jours petites, fréquentes et réalisées en continue pour faire virer notre paquebot de SI sereinement.

Je peux en plus choisir un format adapté qu'il soit plat (properties) ou arborescent (JSON) là ou Kafka m'impose du plat en clef-valeur. Cette contrainte rend juste votre vie difficile pour représenter une hiérarchie d'objets, heureusement ça n'arrive que tout le temps...

Il faut bien comprendre que lorsqu'un Swagger change pour ajouter un nouvel attribut par exemple, il faut alors changer tous les clients. Mais c'est également le cas avec des bus comme Kafka ! En effet, si un message nécessite une valeur supplémentaire, il faut que tous les clients émettant ce message intègrent cette nouvelle valeur. Mais alors où se trouve le découplage des bus par rapport à REST ? Où se trouvent el famoso "mise à jour sans impact" ? Réponse : nulle part, c'est un mythe.

Nous voici arrivés à la partie contre-arguments (qui va être courte car j'en ai marre d'écrire) :

Les bus sont des SPOF (Single Point Of Failure) mais pourquoi ?

Au niveau du réseau
Comme tout passe par le bus, alors si le bus tombe tout tombe. C'est la raison pour laquelle Kafka a émergé ; puisque si un nœud Kafka tombe, alors il en existe d'autres pour assurer le travail et l'engouement pour Kafka est à mon sens le témoin du fait que les bus mono-instances étaient encore plus des anti-patterns. Mais quid des difficultés d'administration de Kafka ?

Je rappelle qu'un service doit déclarer les adresses de tous les nœuds Kafka pour se connecter au cluster (au cas où le seul nœud déclaré aurait lâché). Je dois donc paramétrer mon application pour qu'elle ait une connaissance de l'infrastructure alors que celle-ci devrait être agnostique de cette infrastructure. Nous revenons en arrière de 20 ans (promis je ferai un poste expliquant en quoi Docker fait la même chose vis-à-vis du build lié à la sécurité).

Le nombre d'instances à administrer augmentent mais pas seulement... Le type d'instances aussi !
Et oui il faut administrer les instances du bus en plus des instances applicatives mais en plus il faut disposer d'admin-sys ayant des compétences sur les applications ET sur le bus !

Alors du point de vue du cabinet de conseil c'est merveilleux puisque je peux fourrer encore plus de prestas ! #Money Mais du point de vue du CTO ou de la DSI, c'est mon porte-feuille qui se fait mettre à mal.

Et là je ne parle pas que de compétences, arguons que chaque instance tourne sur du hardware en dernier recours et que ce hardware a un coût. Plus d'instances => Plus de hardware ou du hardware plus gros et donc plus cher ! C'est le second effet kiss-cool au porte-monnaie.

Mais il y en a un troisième !! Il faut que je recrute des développeurs qui maîtrisent le bus. Vous savez les développeurs Kafka par exemple... Sauf que compétences en plus => tarifs plus élevés. Et cela engendre des difficultés de recrutement d'une part et une sensibilité accrue au turner-over d'autre part surtout quand l'expert Kafka nous quitte...

Les schémas du SI intégrant un bus masquent l'horreur de la réalité.
Avant les bus applicatifs, les architectes fournissaient des schémas avec plein de boites et encore plus de flèches le tout partant dans tous les sens. C'était alors triviale de constater l'ampleur du grand merdier et donc de réclamer une simplification du SI aux architectes dont le travail était manifestement défaillant.

Avec un bus, nous nous retrouvons avec les boites applicatives en périphérie de ces schémas et une plus grosse au centre : celle du bus lui-même. Là le schéma est propre, harmonisé, au moyen une belle structure en étoile où chaque composant ne s'adresse qu'au bus... #PowerPointSur20

Soyons clairs, c'est le même bordel à l'intérieur de la grosse boi-boite qui représente le bus que ça ne l'était avant sans la présence du bus. Sauf que ce souk devient invisible quand on ne se rend pas sur le terrain, en observant les flux et le code... Mais ce que le CTO ne voit pas ne lui pose pas de problème n'est-ce pas ?

Illustration du problème AVANT

Illustration du problème APRES

Comment identifier l'endroit où la complexité est la plus dense ? Comment y affecter des personnes et mesurer sans effort l'ampleur des difficultés qu'elles vont affronter si tous ces schémas avec ces flèches dans tous les sens ont été effacés du regard ? Comment justifier les coûts budgétaires aussi élevés à chaque mise à jour alors que notre SI paraît si simple, si joli, si sophistiqué avec sa structure en étoile dans de beaux Power-Point animés ?

Si certains architectes aiment autant les bus, je pense que c'est parce qu'ils peuvent montrer à quel point ils brillent, leurs schémas devenant clairs, limpides, dignes des experts qu'ils sont au vu de leurs tarifs. Et toute la difficulté retombera alors sur le dos des développeurs, vous savez ces "tocards" payés à pas cher et importés de l'étranger... De parfaits coupables pour des experts influents et bien-pensants face à la certitude que les devs soient des incompétents.

Je résumerais ma position sur un principe : KISS (Keep It Simple, Stupid !). Cela vaut pour du code, cela vaut aussi pour le SI.

En fait nous avons tous la capacité de voyager dans le passé ! En effet, le vous du futur est en train de vous observer à travers ses souvenirs qui sont donc vos propres souvenirs ; de la même façon le vous d'à présent s'observe étant enfant à travers vos souvenirs actuels.

Voilà :-)

Je repensais à ce que j'avais pu lire sur le Styx, de je ne sais plus quel shaarliste, à savoir que les interviews de Thinkerview étaient horribles, que le journaliste n'avait de cesse de couper son invité, qu'il l'empêchait de construire sa pensée et que cela rendait la chose détestable à suivre.

Et en y réfléchissant ce matin, je me dis que non en fait. Tout simplement parce que je pense que les autres interviews - celles réalisées par les autres journalistes des grands médias - sont globalement fabriquées sur le même mode, la différence résidant dans le montage. En effet, Thinkerview nous montre l'interview sans coupure ni montage, sans la possibilité d'afficher un temps mort, de couper les questions ou les réponses, d'ajouter de fondu au noir pour ralentir le rythme et procurer aux spectateurs l'impression que les choses se sont passées dans le calme et la sérénté.

Bref, mieux vaut une interview sans montage, même si le journaliste coupe la parole, plutôt qu'une interview montée avec laquelle on ne peut pas savoir comment les choses se sont réellement passées, typiquement pourquoi l'invité s'énerve sans raison ou tape des accélérations.

Aux alentours de 2016, 58 personnes détenaient autant de richesses que la moitié des individus les plus pauvres. Aujourd'hui, ces milliardaires ne sont plus que 26 parvenant à réaliser le même "exploit".

Je dois apporter quelques précisions à cette information :

1. En 2019, nous sommes 7,6 milliards à peupler notre planète tandis qu'en 2016 nous étions 7,3 milliards (soit 300 millions d'individus en moins).

Ce qui fait que non seulement ces 26 personnes les plus riches sont devenues encore plus riches, mais leur richesse a crue de manière plutôt quadratique et non linéaire ! (ndr. c'est-à-dire encore plus vite d'années en années)

2. Une définition du capitalisme donnée par Franck Le Page ici dit que Le capitalisme est le droit d'accumulation illimité.

Dans un monde fini, aux ressources naturelles limitées et restreintes, afin de garantir à chacun un minimum pour vivre et un minimum de dignité, alors il faut deux choses :

• Mettre en place un maximum au droit d'accumulation illimité que prône le capitalisme ; et de facto on fait du socialisme.
• Contrôler le nombre de naissances qui ne peut croître lui aussi de manière illimitée.

Dit autrement, il ne peut exister de valeurs qui tendent vers un infini, qu'il s'agisse du nombre d'êtres humains ou de l'argent accumulable par certains, dans un monde aux ressources naturelles finies.

3. La richesse accumulée par ces 26 milliardaires inclue tout.

C'est difficile de s'en rendre compte, mais lorsque l'on parle de richesses, on ne parle pas seulement d'argent ou d'actions d'entreprises. On parle de richesses au sens LAAAAARGE du terme. Je m'explique, ces 26 milliardaires détiennent autant :

• D'argent
• D'actions
• D'entreprises
• D’œuvres d'Art (peintures, sculptures, etc)
• De propriétés intellectuelles (livres, musiques, films, etc)
• De propriétés industrielles (brevets, ADN via les OGM, médicaments, formules chimiques, produits de consommation, machines et outils, etc)
• De propriétés immobilières (maisons, villas, grattes-ciels, châteaux, musées, etc)
• De terres (champs, terrains, îles, montagnes, plages)
• D'eau potable et non potable (rivières, mers, morceaux d'océans)
• D'énergie (nourriture, mais aussi pétrole, uranium, etc)
• De métaux précieux (or, argent, nickel, cuivre, etc)
• De champs d'exploitation (mines, forêts, champs agricoles)
• Et tellement d'autres...

que les 3,8 milliards d'humains les plus pauvres !

À la lecture de ces mots, vous devriez vous poser ces questions :

• Est-ce que je trouve normal qu'un enfant meurt de faim parce qu'il a eu la mauvaise idée de naître dans une famille pauvre ?
• Est-ce qu'il est de mon intérêt personnel à favoriser fiscalement et socialement les milliardaires ? (Même question vis-à-vis des intérêts de ma descendance.)
• Ai-je encore une chance réelle et tangible de devenir milliardaire qui m'inciterait à les défendre plutôt que de me défendre moi ?
• En favorisant les intérêts des milliardaires, tout en sachant que je ne le suis pas, est-ce que j'augmente mes chances de devenir milliardaire à mon tour ou est-ce que je ne ferais que creuser l'écart entre eux et moi, rendant ainsi plus difficile ma capacité à "les rattraper" ?
• Dans quelle classe sociale me situé-je ? (ndr. non il n'y a pas de faute de grammaire ni de typo ici, c'est du français)
• Est-ce que je trouve normal de permettre à des milliardaires d'acheter littéralement tout ce qui existe ? En ce sens, pourquoi ne pas vendre de l'oxygène ? Et du droit au sommeil ?

Sûrement certains se diront que j'exagère dans mon interprétation et sans doute ont-ils un peu raison. Mais à ceux-ci je vous le demande, que comprenez-vous lorsque vous lisez droit d'accumulation **ILLIMITÉ** ?

Moi je comprends qu'en droit français, actuellement en 2019, tout ce qui n'est pas explicitement interdit est autorisé. Cela sous-entends que l'on peut accumuler DE TOUT de manière ILLIMITÉE.

Et cette chose porte un nom : de la pure folie.

Merci à Timo pour le lien.

Je me disais quelque chose en me couchant tout à l'heure... Est-ce que la domination imposée à l'Afrique est de la faute des européens, ou des africains ? Je vais faire un parallèle : la France fût la seconde puissance mondiale (en prenant en compte les aspects économique, militaire, scientifique, philosophie, géo-politique, etc) mais n'est que l'ombre d'elle-même et sur un déclin sans précédent.

Cela est principalement du au fait que la population ait délaissé le contrôle du pouvoir politique à une mafia trop heureuse de se gaver de l'argent dont le pays regorgeait (et regorge encore) ? Peut-être connaissez vous l'adage : une nation de mouton engendre toujours un gouvernement de loups.

Mais là n'est pas la question. La question est : faut-il en vouloir aux mafieux en col-blancs de se servir goulûment là ou toute une nation les laisse faire, où est-ce la responsabilité de l'ensemble des citoyens qui (pour en citer quelques unes) :

• Préfère ne pas savoir parce que ça fout le bourdon
• Préfère se vider la tête parce qu'après une journée de boulot, enfin voilà tu comprends...
• Préfère ne pas réfléchir parce que ça fait du bien de se poser par fois
• Préfère ne pas aller manifester parce que ce n'est pas leur problème cette grève (et puis il va pleuvoir en plus)
• Préfère ne pas voter parce que ça ne sert
• Préfère ne pas apprendre l'économie parce que c'est compliqué
• Préfère ne pas étudier l'histoire géo-politique parce que cela ne les intéresse pas
• Préfère ne pas changer parce que j'ai le droit d'avoir mes habitudes quand même
• Préfère ne pas partager parce que c'est à moi pas à toi ?

Je pense que vous m'avez comprise... Ce qui est arrivée aux africains est aussi de leur responsabilité, ils se sont désolidarisés, ne se sont pas organisés et on ensuite contribué au saccage de leurs nations et la beauté de l'Histoire est qu'il est en train d'arriver la même chose à la France ; alors certes sous une autre forme, moins rapide et moins visible que la traite négrière ou la déstabilisation politique par actions militaires, mais tout aussi morbide : aller nourrir vos enfants sans argent dans une société intégralement capitaliste.

Cela prendra encore quelques années pour ne pas dire décennies, mais la France sera tôt ou tard, à défaut de l'émergence d'une cohésion citoyenne et nationale, une nouvelle Afrique, prise de haut et de force par la même mafia séculaire qui gangrena toutes nos sociétés civiles.

Une réflexion / remarque lue sur imgur qui est d'une puissance et d'une intelligence phénoménale ! Pourquoi lorsque l’aîné d'une famille de trois prend une décision, en réalité, il en prend trois !

Olivier Beruyer : toujours aussi pragmatique et factuel dans ses réflexions et explications. Un merveilleux point de vue merveilleusement expliqué.

Je suis une grande fan !