Chiron (5/11) : architecture et déploiement

[Laurent Caillette]

Nous avons vu précédemment que le sourçage d'événements attaque de front des problèmes tels que l'auditabilité ou la montée de version. Évidemment, le sourçage d'événements suppose que les messages décrivant la succession de changements d'état du système puissent être centralisés. Quand c'est le cas, on peut résumer la persistance à un bout de code qui balance les messages dans un fichier séquentiel et c'est tout. Ça veut dire que l'histoire d'un SGBDR qui vit sa vie dans un processus à part ou un serveur physique distinct, c'est du passé.

Et on peut faire subir le même sort au serveur HTTP ! Quel besoin de se traîner un Apache ou un NGINX alors qu'il y a des bibliothèques Java (comme Netty) qui font la même chose très bien ? Bon au lieu d'écrire de la configuration magique, on pisse du vrai code Java testable unitairement, donc on vire le webmestre qui a dit un jour qu'il était saoul que le code Java c'était pas du vrai Web. 

Dès lors à quoi ressemble le déploiement ? À une copie par SCP d'une archive contenant des exécutables Java. 

Les prérequis c'est un peu de configuration système pour créer //un// utilisateur avec les bons droits, copier le bon JRE, branlouiller les règles du pare-feu, déclarer la partoche DRBD, mais ça reste d'une légèreté insoutenable pour qui aurait voulu faire de l'administration système son métier. 

Avec un seul service qui tourne dans un seul processus tout devient horriblement simple : pas d'ordre d'arrêt-démarrage à respecter, moins de problèmes de droits, pas de conflits de version qui explosent uniquement en production, pas de corrélation de journaux d'exécution puisqu'on n'en a qu'un seul à la fois. 

Une telle approche n'est pas le monopole de Chiron. Par exemple Firebird est un SGBDR embarquable dans du code natif. Dans le monde Java, Jetty et HSQLDB sont embarquables en tant que bibliothèques. Et si l'on a besoin de faire évoluer le schéma, le mieux ça reste de le faire du côté du code applicatif qui doit accéder à ce schéma, parce que ça incite à effectuer plus de tests du côté des développeurs.

Je la refais : après quelques décennies où les vendeurs de solutions "orientées composants" ont essayé de nous convaincre que livrer des applications par petit bouts c'était bien, il faut se rendre à l'évidence : l'approche monolithique ça évite plein de problèmes. Démonstration : ce qui faisait (ou aurait du faire) l'objet de tests d'intégration se retrouve dans les tests unitaires, raccourcissant considérablement le cycle de correction.

=== Microservices et REST

Tiens puisqu'on parle de déploiement c'est le moment d'ouvrir une parenthèse à propos des Microservices et de REST.

Les "Microservices"

https://fr.wikipedia.org/wiki/Microservices

proposent de distribuer les sous-fonction d'une application serveur, généralement sous forme de services REST. REST est l'acronyme de "Representational State Transfer", qui signifie "transfert de données représentant les changements d'état". Comme personne n'a lu la "définition de REST"

https://fr.wikipedia.org/wiki/Representational_state_transfer

tout le monde croit que c'est une convention pour des appels de procédures distantes avec du HTTP. Mais non, REST c'est un style architectural non-lié à HTTP, basé sur la modélisation d'entités modifiables indépendemment. L'idée c'est que la notion de session ne passe pas l'échelle, donc REST interdit la notion de session. Par conséquent REST interdit les transactions, tout comme l'actualisation impromptue.

Le style architectural promu par Chiron, c'est une application monolithique, mono-serveur, pour faciliter les mises à jour impromptues qui bien sûr s'appuient sur des sessions. En se situant aux antipodes de REST, Chiron essaye de répondre à des besoins non-couverts par REST, mais avec le même effort de clarté conceptuelle.

Bon, si quelqu'un trouve son bonheur en utilisant Chiron pour écrire des Microservices, alors ça me fait super-plaisir aussi. Là le propos c'est juste de questionner la pertinence des Microservices : après avoir fumé les SGBDR, `Java EE`, les serveurs HTTP dédiés, pas de raison de s'arrêter là. 

Les Microservices c'est bien pour entasser plein de trucs dont on ne veut pas trop savoir s'ils fonctionnent ou non. Preuve : qui a déjà testé toutes les combinaisons possibles de pannes ? 

Donc oui une architecture monolithique encourage à virer le consultant Docker. Mais comme il sympa on le garde pour réorganiser l'usine de dev.

Après il y a plein de cas où les Microservices et le REST c'est vraiment bien. Pour un site de commerce en ligne, si le service de recommandation est en panne on n'affiche pas de recommandation et c'est tout. Et le REST fournit un bon outil de contractualisation, qui nivelle au passage les différences entre langages de programmation. 

Allez soyons fous, imaginons une architecture où Chiron sert de couche de communication entre serveurs qui s'envoient des mises à jour impromptues. On bénéficie alors des facilités de contractualisation, dont nous verrons les détails très bientôt. En renonçant aux limitations de REST, on renonce également à tous ses avantages, et on s'écarte de la définition des Microservices. Mais avec une formule qui sonne bien comme "RESTless Microservices" ("Microservices fébriles") y'a de quoi lancer une mode, non ?

=== Les DevOps à la rescousse

L'approche REST-Microservices ça peut être bien, mais en ce moment ces mots bénéficient d'un engouement pas toujours très raisonné. Bon d'accord Docker a levé plein de millions //et alors// ? Si on se calme un peu on s'aperçoit qu'il y a plein de sous à faire avec des applications en ligne où jamais plus de 1000 utilisateurs ne se connectent simultanément, et de façon plus aisée que dans des domaines hyper-concurrentiels imprégnés d'hystérie spéculative.

S'il faut absolument raccrocher Chiron à un mot à la mode, ça sera celui de DevOps. L'approche DevOps (développement-opérations) est une façon politiquement acceptable de signifier la mort des administrateurs système dont le travail est automatisable par des développeurs. Un des rôles des administrateurs système, c'était d'amortir le choc entre le développeur qui programme son truc dans son coin, et la réalité où ça doit fonctionner. C'est ce qui entraîne la prolifération d'outils pour virtualiser, rediriger, remplir des cache, les vidanger, etc. En gros c'est une façon techniquement ridicule de déplacer certaines dépenses du poste budgétaire "développement" (associé à l'idée de coût) au poste budgétaire "exploitation" (associé à l'idée de revenu). Sans parler des tests d'intégration faits à la main, pour lester le poste budgétaire "assurance qualité" (associé à la bonne conscience).

Bien sûr on peut faire du DevOps en automatisant bêtement tout un tas d'opérations compliquées, mais le meilleur levier se trouve en amont grâce à des simplifications de l'architecture. À cet égard, on gagne donc à déployer une application mono-processus dans un environnement système de complexité réduite, et Chiron aide à s'orienter vers ce type de solution. Chiron est l'ami du DevOps car le DevOps est l'étendard de ceux qui ont intérêt à virer les machins excessivement compliqués.

=== Java côté client

Chiron fournit un client de connexion en `Java 8` et rien en JavaScript. Oui on est en 2018 et c'est une drôle façon de se faire aimer. Il y a une petite lueur d'espoir du côté d'Android en passe de supporter `Java 8` mais il faudrait que Netty fonctionne correctement dessus. Chiron se limite donc à l'écriture d'applications déployées sur des ordinateurs de bureau, espèce garantie en voie de disparition depuis la fin du précédent millénaire.

Sauf que j'en vois toujours plein en service. Sont-ils juste en sursis, le temps qu'on pense à fabriquer des vêtements dont les poches accepteraient des tablettes avec double écran de `21 pouces` ? Peut-être aussi que le seul crime des ordinateurs de bureau c'est de ne plus générer des explosions de croissance de niveau mondial. Et ça, c'est surtout un problème pour des mecs voulant faire `900 %` de culbute d'ici 3 ans pour une mise initiale de 10 milliards d'euros. Même si ces mecs sont très véhéments ils ne représentent qu'une petite fraction des logiciels qu'on utilise tous les jours.

La cruelle vérité c'est que JavaScript est un langage ridicule avec de faibles capacités de parallélisation. Les machines virtuelles offrent des performances médiocres et les applications Web continuent de pâtir des incompatibilités -- notamment graphiques -- entre les navigateurs.

Par contre `Java 8` fournit un système de typage digne de ce nom, il supporte nativement les données immuables, et fournit tout ce qu'on peut espérer en programmation concurrente. Les performances de la JVM écrasent celles de toutes les machines virtuelles JavaScript. En bricolant un peu on arrive à faire des choses très propres en Swing, et carrément belles avec JavaFX. 

Une autre cruelle vérité c'est que l'apparente facilité de déploiement des applications Web n'est qu'un transfert de coût vers l'assurance-qualité qui doit tester tous les navigateurs officiellement supportés. Si on embarque une JVM dans un installeur signé, Java se charge de la compatibilité avec de très bons résultats. Bien sûr ça laisse en suspens le problème de la sécurité. Faut-il confiner l'exécution dans une machine virtuelle ? Activer le ``SecurityManager`` de la JVM ? Le déploiement de code natif est un sujet complexe qui fera sûrement l'objet d'un autre article mais pour l'instant on peut retenir que Chiron pousse également à s'affranchir du navigateur Web. 

Donc là on dégage l'armada de dévelopeurs-intégrateurs JavaScript-CSS-HTML-JQuery-Angular-JQuery-React-et-j'en-oublie et on installe un terrain de basket à la place des bureaux laissés vides.

Il y a quelque chose qui est possible avec du pur Java et pas avec un client Web, c'est démarrer un serveur HTTP local (et accessible en local seulement) qui va recevoir des commandes émises des applications tierces. Ça permet d'automatiser le client comme avec du bon vieil AppleScript, mais dans n'importe quel langage pouvant cracher une requête HTTP -- oui même Excel peut faire ça-_. L'avantage c'est que le client devient un frontal rejetant les commandes erronnées ou trop fréquentes, qui pourraient surcharcher le serveur central. Pour faire la même chose avec une application Web, il faudrait dédier un serveur au rôle de frontal, et autoriser plus d'une session par utilisateur. Il faudrait aussi que l'utilisateur s'authentifie deux fois (un vrai plaisir avec de l'authentification à deux facteurs), ou qu'il copie un jeton d'accès pour chaque application connectée au frontal. Sans parler de l'incapacité d'Excel à se remettre des erreurs qui sont la norme avec une connexion réseau.

Tout cela étant dit, le non-support du JavaScript pour le client risque de dissuader beaucoup de gens. Une évolution possible de Chiron ça serait la migration vers "Kotlin"

http://kotlinlang.org

, qui supporte la transpilation vers JavaScript. Mais il faudrait réécrire pas mal de trucs pour utiliser les WebSockets côté navigateur.

=== Mais comment ça se code ?

Allez, on va dire que j'ai convaincu tout le monde. La question suivante c'est : comment ça se code ? Réponse dans le prochain épisode. 

[Dominique Jocal]

Allez laurent, du baume au cœur pour toi: ventes pc de nouveau à la hausse!

http://www.cnetfrance.fr/news/pc-pour-la-premiere-fois-depuis-six-ans-le-marche-repart-a-la-hausse-39862658.htm

J'ai bien ri sur tes attaques tronçonneuse sur à peu près toutes les technos pratiquées ou révées (souvent à tort) du moment.. sacré style l'écrivain!

Ton amour pour js devrait te faire lorgner du côté de web assembly... ce court-circuit post-gwt sous stéroïdes a déjà un compilateur pour... C! Alors java... on devrait avoir plusieurs compils..

Non, Chiron n'est pas perdu pour le navigateur!

A te lire.

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "techos".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse techos+unsubscribe@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse tec...@googlegroups.com.
Visitez ce groupe à l'adresse https://groups.google.com/group/techos.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

[Henri Tremblay]

Quelques petits commentaires en pagaille:

• HSQLDB c'est mort. On utilise H2
  
• Ça fait assez longtemps qu'on a plus trop besoin de faire servir des resources statiques en front ou un machin de même. Java fait ça très bien. Et si tu veux améliorer ta latence, tu prends un CDN.
• Par contre NGINX va encore server de load balancer. Mais là tu dirais qu'on est mieux avec HAProxy et tu auras raison. Et là, tu diras que sur un Cloud, il y a toujours un load balancer qui traine (genre ELB pour AWS) et tu auras encore raison. Donc bref, NGINX et Apache, ça sert plus à rien en effet
• J'ai une nouvelle passion pour Gluon qui permet de faire du JavaFX sur Android, IOS et desktop. Je n'ai pas encore assez tester mais je me base sur des gens très biens qui l'ont fait
• Typescript rend le Javascript plus digeste. Mais bon, j'aime autant éviter aussi
• Au niveau migration DB, j'utilise liquibase. Donc je n'ai plus le célèbre script de migration SQL. En gros, quand je livre un serveur, il regarde si la base de données est à jour et lance la migration au besoin. C'est donc fait par le serveur Java
• Pas mal d'études et de gens biens on fait un constat sur les microservices. En gros, le mieux c'est de commencer monolithique et de ne pas penser à ça. Parce que tu vas perdre plein de temps et que c'est le bordel. Quand tu commences un peu plus à comprendre ce que tu es en train de faire, tu commences à découper à la Netflix. Pas avant.

[Laurent Caillette]

Salut Dominique, salut Henri, 

Gluon a l'air chouette en effet. JavaFX est typiquement le produit sous-coté parce qu'il résoud trop de problèmes pour que beaucoup d'éditeurs puissent faire du beurre avec. On dirait du LibGDX avec un plus haut niveau de finition.

Après je ne suis pas sûr que Netty fonctionne bien sur Android.

Ce qui est marrant avec le Web Assembly, c'est que les mecs te l'emballent comme un truc nouveau. Est-ce que la sécurité autour sera meilleure que celle de la JVM et du Java Plugin ? J'aimerais bien que la question soit posée plus souvent. 

À bientôt pour l'épisode 6 !