Chiron (11/11) : conclusion

[Laurent Caillette]

Nous arrivons au terme de cette série d'articles sur Chiron. Avec sa publication sur "GitHub"

https://github.com/OTCdLink/Chiron-framework

, on pourrait dire que l'histoire ne fait que commencer. Mais avec tout les développements qui ont précédé il y a déjà moyen de tirer quelques conclusions.

=== Fallait-il en arriver là ?

La règle numéro un c'est que jamais au grand jamais il ne faut écrire son propre conteneur d'application.

Mais comme c'est de l'informatique il y a une règle numéro un bis qui nous dit que des fois il faut jeter la règle numéro un.

L'exemple des moteurs de jeux vidéo est parlant. Il y en a des dizaines, de très haute qualité, multiplateformes, testés à mort, certains accompagnés d'un outillage fantastique. Et pourtant des équipes continuent de développer leurs propres moteurs avec succès, parce que l'existant ne satisfait pas certains besoins. 

Acheter ou construire, comment choisir ? C'est simple, on commence par écrire quelque chose qui marchouille avec un socle technique existant, et on regarde où ça coince. 

Avant Chiron il y avait Shoemaker, qui reposait sur CometD et Jetty. Les mauvaises performances de CometD liées au format de sérialisation idiot ainsi que l'absence de support de proxy HTTP par le client WebSocket de Jetty ont déclenché la migration technique vers Netty. C'est ainsi que Chiron a remplacé Shoemaker. La migration a coûté une blinde mais je n'aurais jamais été capable de concevoir Chiron du premier coup. Le passage par Shoemaker (donc Jetty et CometD) a limité le ticket d'entrée pour bâtir une application basée sur le sourçage d'événements, qui secoue déjà beaucoup d'habitudes. Et un projet ne peut pas absorber toutes les difficultés d'un coup.

Évidemment se pose la question de la rentabilité d'une telle approche. Il y aura toujours un petit malin pour torcher un prototype à base de React et `Node.js` en deux jours et on se sent fatigué rien qu'à l'idée de lui expliquer ce qu'il n'a pas compris et ne veut pas comprendre sous peine de perdre son petit plaisir d'auto-valorisation. Car ce qui coûte cher, ce sont les astuces -- fonctionnelles ou techniques -- pour rendre l'application testable //et// déployable //et// utilisable //et// capable de monter en charge. Il n'y a pas de solution magique, tout coûte cher, et tout ce qu'on peut espérer ce sont des solutions qui n'ajoutent pas de complexité là où il n'y a pas lieu. La difficulté c'est de percevoir cette complexité ; comme le montre bien l'exemple des SGBDR, ceux qui maîtrisent un outil ont toujours tendance à le légitimer et à sous-estimer sa complexité réelle.

Ça sera plus clair si on distingue deux choses : Chiron comme proposition architecturale, et la stratégie qui consiste à développer ses propres composants de bas niveau. 

Grâce l'architecture décrite, et notamment l'utilisation des contrats Upend et Downend, on a des tests d'intégration qui s'exécutent comme des tests unitaires, les plus rapides ne prenant qu'une vingtaine de millisecondes. Et grâce au serveur mono-processus on limite la complexité de l'infrastructure, en gardant la main sur des serveurs dédiés. Et comme tout est typé statiquement tu fais un "Find References" dans IntelliJ IDEA et tu vois exactement qui fait quoi. Plein de trucs dont beaucoup de projets peuvent rêver.

Faute d'un projet équivalent à Chiron, il n'y avait pas d'autre choix que de construire son propre socle technique de bas niveau. Et avec une telle approche où on maîtrise à peu près tout ce qui se passe au-dessus de la connexion réseau, pas moyen de se retrouver coincé. C'est bien illustré par ce qui a été fait pour l'authentification. C'était plus compliqué avec la pile Jetty-CometD qui nécessitait pas mal de contournements. 

Donc je ne dis pas que tout projet doit réinventer son propre conteneur d'application, je dis que //des fois// il faut ne pas avoir peur de le faire. Dans une telle optique le choix de Netty peut s'avérer déterminant car Netty fournit des possibilités de très bas niveau, tout en orientant vers les bons choix sur des sujets très casse-gueule comme la gestion de la mémoire ou la concurrence d'accès. Celui qui repartirait de la ``java.net.Socket`` se condamnerait à réinventer plus ou moins Netty, pour peu qu'il en ait la capacité.

Après plusieurs années de développement, je prétends que l'approche concrétisée par Chiron a porté ses fruits. Je n'ai toujours pas vu de solution équivalente disponible sur le marché.

=== Utilisabilité sur d'autres projets

Concernant l'utilisabilité de Chiron sur d'autres projets ainsi que les garanties de ceci ou cela, tout se résume au bouton "Fork" sur GitHub. Disponible 24 heures sur 24 et 7 jours sur 7 ! J'accepte de répondre aux questions de celui qui m'offre un coup à boire en bas de chez moi, sous réserve qu'il signe un accord de non-divulgation s'il veut voir à quoi ressemble le code applicatif utilisant Chiron. Certains abonnés de Techos l'ont d'ailleurs déjà fait.

=== Trucs qui manquent

Chiron est relativement jeune et il lui manque :

- Une application-exemple un peu plus touffue.

- Le support du contrat réactif côté Netty.

- De la génération de bytecode pour les objets ``Command``.

- Une documentation utilisateur (à commencer par la traduction des billets précédents en anglais).

- Le Downend en Kotlin pour générer du JavaScript (pas vraiment une priorité).

- De la tolérance de panne avec Raft (très compliqué, très cher, ne pas y compter avant longtemps).

=== Visions d'avenir

L'important, c'est de retenir comment Chiron encourage à simplifier certains sujets, en comparaison du paradigme SGBDR :

- Actualisation impromptue ("push").

- Structuration du code applicatif.

- Concurrence d'accès.

- Persistance (en réutilisant le code de sérialisation pour le réseau).

- Montée de version du schéma des données persistées.

- Utilisation d'un langage unique de haut niveau fortement typé.

- Piste d'audit de bas niveau.

- Sauvegarde à long terme.

- Déploiement comme application mono-processus.

- Testabilité accrue grâce à l'approche monolithique.

L'approche résolument mono-machine de Chiron limite son emploi à certains volumes de données. Cette contrainte ne s'applique qu'aux données chaudes ; l'accès aux données froides accepte des simplifications liées au fait qu'elles ne sont plus modifiables. 

Tout porte à croire que des pratiques comme le sourçage d'événements ("Event Sourcing"

http://martinfowler.com/eaaDev/EventSourcing.html

) ou la ségrégation commande-requête (CQRS, "Command Query Responsibility Segregation"

https://martinfowler.com/bliki/CQRS.html

) vont s'imposer tranquillement dans les années à venir. Des éditeurs avec une grosse force de frappe commerciale comme Oracle n'en feront pas l'article parce qu'ils ne veulent pas voir les clients s'éloigner de leur vache à lait relationnelle, et ils ont perdu la capacité de sortir des produits intéressants qui pourraient remplir ce segment de marché, malgré la pression exercée par la démarche DevOps.

À un moment les auteurs de socle technique voudront aller au-delà du clone de Ruby on Rails, tout en exploitant les possibilités offertes par les lambdas de `Java 8`, le typage fort et la programmation réactive. Des idiomes de programmation fonctionnelle émergeront naturellement, ouvrant encore d'autres possibilités comme une piste d'audit de bas niveau capable d'alimenter un débogueur. On a "vu"

https://groups.google.com/d/topic/techos/m9ezgGijfrQ/discussion

que c'est comme ça que fonctionne le débogueur d'Elm, qui attend juste d'être copié. Certes, Chiron ne fournit pas ce niveau de fonctionnalité, mais l'application développée avec Chiron défriche bien le terrain du sourçage d'événements qui est un bon point de départ pour plein de trucs intéressants.

Bien sûr on prend à rêver d'un futur radieux pour Chiron, mais indépendemment des efforts dont il bénéficiera, on peut dès maintenant y trouver une grille d'évaluation pour des conteneurs d'application à venir.