Nous avons partagé l’amnésie. Lorsque je parle à de jeunes développeurs de technologies passées, j’obtiens souvent des étoiles vides. Pour être juste, c’est en partie parce que je suis un peu “intense” ou “bizarre”, mais c’est en partie parce que. Hein? Ah bon? Avons-nous cela?
Exemple de transactions XA et 2PC (Two Phase Commit). Nous avons une jeune génération qui ignore complètement cette capacité et le fait que c’était “une chose”. L’exigence de gestion des transactions a-t-elle disparu d’une manière ou d’une autre ?
Les banques n’ont-elles plus besoin de cohérence ? Si vous n’êtes pas sur la « même page », cette technologie fonctionne en transférant le contexte transactionnel entre des serveurs distincts. Ainsi, un commit sur un serveur était un processus en plusieurs étapes qui garantissait à peu près tous les serveurs réussis ou annulés en un seul. C’était assez incroyable et fonctionnait raisonnablement bien (avec des mises en garde évidemment). Étonnamment, cela a fonctionné via l’invocation de méthode. Vous n’aviez rien à faire. Même lors de l’appel d’une méthode distante sur un serveur complètement différent. Cela “a juste fonctionné”.
Je parlais avec une startup basée sur Node dans le secteur bancaire il y a quelques années. Ils ont dit que les banques étaient très ouvertes à travailler avec Node. Depuis, j’ai compris qu’ils réécrivaient leurs trucs dans un environnement plus « mature ». Lorsque j’utilise des outils “plus récents” comme Node, je suis toujours étonné par les éléments de base qui manquent. Bien sûr, c’est plus simple et plus petit si vous n’y intégrez pas tout ce dont nous avons besoin. Il est facile de créer des choses simples lorsque vous jetez des fonctionnalités de base.
Le drame NoSQL des années 2010
En 1999, je créais ma société de conseil et un ami m’a demandé de rencontrer son patron. Je suis allé dans ce bureau où le “patron” a dit qu’il avait eu l’idée la plus incroyable à laquelle personne n’avait pensé. Ils ont un financement et seront lancés dans 6 mois pour un million d’utilisateurs dès le premier jour !
Moi : D’accord. Quelle est l’idée ?
Lui : Je te le dirai après ton inscription pour travailler pour nous.
Moi : Je signerai une NDA.
Lui : Non. L’idée est trop bonne. Ces NDA ne valent rien. Vous vous inscrivez et puis…
D’une manière ou d’une autre, j’ai pu résister à l’attrait de travailler pour cette entreprise. Environ un an plus tard, ils ne se sont évidemment pas lancés, mais ma société de conseil se portait bien. L’ami m’a rappelé. Cette fois, ils avaient besoin d’aide avec le produit, alors j’y suis allé avec mon chapeau de consultant et je les ai aidés.
Leur idée était une application de chat intégrée au site Web afin que les visiteurs du site puissent discuter entre eux. Un concurrent déjà lancé, et je consultais quelques autres entreprises avec la même idée. Ils ont pivoté pour se concentrer sur les chats liés au commerce électronique. Mais je m’égare…
Leur système fonctionnait terriblement. Lent comme de la mélasse avec un seul utilisateur. Apparemment, le PDG a insisté sur le fait qu’ils devaient prendre en charge 1 million d’utilisateurs le premier jour (comme il me l’a dit). Ils l’ont transmis à Oracle qui a déclaré qu’ils auraient besoin d’un cluster de trois serveurs pour prendre en charge ce volume. Ensuite, ils ont parlé à un fournisseur de bases de données orientées objet qui a promis de pouvoir gérer 1 million d’utilisateurs avec une seule machine. Ils se sont donc lancés dans la base de données orientée objet. Lorsque j’ai exprimé mon choc à ce sujet, ils ont affirmé que leurs données étaient très «orientées objet» car chaque utilisateur peut avoir plusieurs éléments… Ugh.
Ils ne comprenaient pas les limites des transactions, le code de stockage était mélangé avec tout car il n’y avait que du code, et c’était lent. Ce n’était pas fiable et impossible à comprendre. Vous ne vous souvenez peut-être pas de la période des bases de données orientées objet, mais c’était un précurseur de la mode NoSQL qui a saisi notre industrie dans les années 2010. Pendant ce temps en tant que consultant, j’ai pu revoir une rediffusion de cette histoire. Cette fois, la plupart des entreprises se sont lancées avec succès.
Mais ensuite, ils ont découvert que le fait d’avoir des données non structurées n’est pas la panacée. L’avantage qu’ils ont obtenu en termes de performances était minuscule par rapport à la simple utilisation d’une bonne mise en cache et d’un SQL bien réglé. L’histoire du déploiement était assez complexe et les outils auxiliaires n’atteindront probablement jamais ce que nous avons dans le monde de SQL.
Pour être clair : il existe des utilisations valides pour NoSQL. Mais les utilisations les plus courantes de ces bases de données ne sont pas très bonnes et découlent du RDD (Resume Driven Development). C’est un schéma que ceux d’entre nous qui ont fait le tour du pâté de maisons à plusieurs reprises voient encore et encore :
- L’ancienne technologie est un complexe maladroit
- Les gens inventent quelque chose de propre et simple
- Oubliez que l’ancienne technologie existe
- Les nouveautés sont trop simplistes et ne font pas beaucoup de choses de base
- Réinventer ces complexités
- Les nouveautés deviennent la complexité ancienne et maladroite qui doit être réinventée… Rincer/répéter
Sans serveur comme les nouveaux mainframes
J’ai fait beaucoup de travail sans serveur au cours du dernier mois et je pense que c’est un grand pas en arrière. C’est une répétition des problèmes que nous avions avec PaaS. C’est pratiquement un ordinateur central. À l’époque, nous avions l’habitude de payer pour que notre travail s’exécute sur un ordinateur central où nous partagions du temps. Cela ressemblait un peu plus à un environnement de virtualisation mais l’idée était similaire : nous ne sommes pas propriétaires de l’environnement. On peut dire que c’est également vrai pour le cloud SaaS, mais sans serveur, ce concept va assez loin.
Même l’expérience de débogage est terrible. Nous n’avons pas le contrôle de base de notre code ou de la logique d’application de base. J’ai du mal à comprendre pourquoi les gens l’utilisent pour plus que des tâches de base.
Il y a un excellent cas d’utilisation auquel je peux penser : les webhooks. Obtenir le code du ruban adhésif pour les webhooks est toujours pénible. Ils ne se déclenchent pas souvent et y faire face est une corvée. Utiliser une fonction sans serveur pour simplement ajouter des éléments à la base de données et faire le travail peut être assez simple. Puisqu’un rappel est difficile à déboguer de toute façon, la terrible expérience de débogage sans serveur n’est pas un énorme obstacle. Mais pour tous les autres cas d’utilisation, je suis absolument déconcerté.
Les gens passent tellement de temps à vérifier et à mesurer le débit, mais le simple fait d’utiliser un serveur légèrement plus grand et seuls les appels locaux donneront plus de débit que ce dont vous pourriez avoir besoin. Sans tous les liens avec les fournisseurs dans lesquels nous tombons. Hébergement avec Linode, Digital Ocean, etc. économiserait tellement d’argent. En ce qui concerne le délai de mise sur le marché, il serait beaucoup plus simple d’utiliser la mise en cache et des outils locaux rapides que tout ce que vous pouvez créer dans le cloud.
Les conteneurs sont un bon progrès et ils ont rendu cela tellement plus simple, mais nous avons laissé tomber et nous sommes allés à fond sur la complexité avec des choses comme Kubernetes. Ne vous méprenez pas. K8s est génial. Mais 98% d’entre nous n’en ont pas vraiment besoin et ne devraient pas l’utiliser. Si vous êtes une petite startup, Kubernetes est une perte de temps et d’énergie.
Retour à Java et à Rust
Java est un exemple où la partie amnésie est bonne. Nous avons eu de petites conversations, et c’était super. Lorsque Java est arrivé, c’était une solution inférieure avec une syntaxe étrange semblable à celle du C. L’aspect évolutif n’était pas clair. Java a jeté de nombreuses idées géniales à la fois en smalltalk et en C++. Il a adopté certaines idées controversées (exceptions vérifiées, primitives, etc.). Pourtant c’est réussi. Il a attrapé la part d’esprit; il a pu tirer parti de cela.
Cela a commencé comme un petit langage qui a jeté toutes les ordures et la sur-ingénierie que d’autres plates-formes ont ajoutées. Regardez-le maintenant. Plus personne ne le décrit comme “petit”. Les développeurs sont occupés à essayer de créer des langages plus petits et plus simples en se plaignant des défauts de Java. Le succès les ramènerait là où nous avons commencé. Une petite langue qui grandit trop. Java est actuellement là où il devrait être. C’est l’un des rares exemples d’une bonne réécriture.
La rouille semble également être l’une de ces rares exceptions. Il réinvente le C d’une manière qui contribue à quelque chose de complètement nouveau. Il est difficile de dire s’il survivra à long terme. Mais il faudra sans aucun doute acquérir beaucoup de complexité en cours de route.
Réinvention consciente
Qu’est-ce qui fait de la réinvention d’un langage ou d’un outil existant un succès sur le marché de masse et qu’est-ce qui laisse ces outils de côté ?
SQL est revenu d’entre les morts et est à nouveau chaud avec de nouvelles startups. On ne peut pas en dire autant du C++. Comment sont-ils différents?
Node et Python sont populaires malgré les éléments de base manquants que nous avons dans le monde JVM. Comment est-ce et vont-ils maintenir cette popularité? Vont-ils rajouter certaines de ces choses?
Jusqu’à notre adolescence, notre cerveau ajoute constamment des synapses. Pendant notre adolescence, nous les avons abattus. Une théorie est que c’est la source de tous les changements que nous traversons à l’adolescence. Nous devons déconnecter les choses qui ne fonctionnent plus pour nous. Sinon, nous apprendrons simplement ce que nos parents savaient. Nous ne pouvons pas nous améliorer en faisant nos propres erreurs. En essayant à nouveau quelque chose qui a échoué dans cette génération.
En conséquence, nous répétons les erreurs et commettons de nouvelles erreurs terribles. Nous faisons également des sauts et des découvertes incroyables. C’est là que l’innovation prend son envol. Il en est de même pour l’ingénierie. Comment différencions-nous : l’angoisse des adolescents d’une nouvelle direction brillante ?
Honnêtement, nous ne pouvons pas. En tant que personne âgée, beaucoup de ces choses m’ont semblé stupides quand je les ai vues pour la première fois. Nous avons déjà essayé ces choses et avons échoué. Pourquoi ressasser cette direction brisée? C’est là que réside l’innovation. Mais si nous regardons de plus près les tentatives réussies, nous pouvons voir ce qui a fonctionné pour eux.
Java n’a pas été conçu pour mettre fin à C++. Bien sûr, cela aurait pu être un fantasme. Mais Gosling l’a conçu pour la simplicité et la petite taille. Pour résoudre un créneau très étroit, concentrez-vous sur la sécurité, la taille et la mise en réseau.
Rust n’a pas été conçu pour mettre fin à C. Il a été conçu pour rendre des projets comme Firefox plus stables et performants.
Je pense que la réinvention, comme toute startup, fonctionne très bien lorsque nous nous limitons initialement à un cas d’utilisation très petit et étroit. En faisant cela et en gardant l’objectif initial, nous pouvons construire quelque chose de bien et ensuite faire le grand saut.
Également publié ici
CHARGEMENT EN COURS
. . . & commentaires Suite!