Journal Sorties de Micronaut 1.3.0 et Micronaut Data 1.0

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
18
6
fév.
2020

Bonjour,

Micronaut est un cadriciel (framework) sous licence Apache v2 basé sur la JVM permettant de créer des micro‑services. Son auteur n’est autre que Graeme Rocher, le créateur de Grails et Gorm.

Ses principales caractéristiques sont :

  • il est polyglotte, prenant en charge à la fois Java, Kotlin et Groovy ;
  • il n’utilise pas l’introspection durant l’exécution mais à la compilation, ce qui le rend particulièrement léger et rapide à l’exécution ;
  • il utilise GraalVM pour compiler les applications en exécutables natifs ;
  • on peut aisément avoir une approche modulaire pour le développement (dite « DevOps », pour les intimes) dans le sens où il utilise Gradle comme outil de gestion de construction et peut aisément avoir une exécution distribuée (le même contrôleur sur plusieurs serveurs).

Les nouveautés de cette version sont principalement une amélioration des performances et des mises à jour de modules.

Les développeurs se concentrent sur la version 2.0, qui devrait inclure :

  • la gestion « reactive » de Micronaut Data pour SQL, Neo4j et MongoDB ;
  • HTTP/2 ;
  • l’amélioration pour les applications « serverless » ;
  • de meilleures performances ;
  • de nouveaux greffons Gradle.

Voilà, il y a bien d’autres choses à dire, mais nous n’en sommes qu’au stade de la démonstration de faisabilité (PoC) pour remplacer certaines application Grails ; aussi, je ne peux pas en dire tellement plus.

En revanche, le code est particulièrement bien fait et, selon moi, il fait office de référence pour l’édition de classes Java à la compilation (ASM et Annotation Processors, voir dans le projet micronaut‑core, le module inject)

→ L’annonce (en anglais).

  • # Markdown

    Posté par  (site web personnel) . Évalué à 3.

    j'ai merdé mon markdown, et j'ai un peu précipité un peu l'envoi.. oui, je suis trop émotif quand j'écris un journal.

    • pourtant le sait faire des listes à puces…
    • la preuve par 2

    • [^] # Re: Markdown

      Posté par  . Évalué à 5.

      C’est corrigé. :-) J’ai également effectué quelques corrections : orthographe, orthotypographie et francisation.

      • [^] # Re: Markdown

        Posté par  . Évalué à 4.

        On passe en dépêche ? ça le mérite.

        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: Markdown

        Posté par  (site web personnel) . Évalué à 3.

        Merci pour ces corrections.

        Je ferais un autre journal, bien rédigé, pour expliquer comment fonctionne l'AOP à la compilation dans Micronaut, il n'y a pas beaucoup de ressources sur ce sujet.

        Avec le support des DSL, on peut vraiment faire des miracles avec ce cadriciel (ça mérite un autre journal, avec des exemples de code).

        • [^] # Re: Markdown

          Posté par  . Évalué à 2.

          ça mérite plutôt une dépêche qui reprendrait le tout.

          "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

          • [^] # Re: Markdown

            Posté par  . Évalué à 1.

            Ouaille note…

          • [^] # Re: Markdown

            Posté par  (site web personnel) . Évalué à 5.

            3615MaVie, Je ne peux vraiment pas le faire en ce moment, pour une histoire de Gitlab qui a craché, et de backup qui n'est pas restaurable (merci ARM, merci Gitlab, merci Scaleway, ça c'est dit …).

            Pour nous c'est critique, je pense que ça va m'occuper le WE. Je passe sur Gitea pour le moment, après je le fais, promis (et j'arrête de fumer aussi).

            • [^] # Re: Markdown

              Posté par  . Évalué à 3.

              Hein ? J'étais justement en train de comparer les forges pour une équipe de 4 personnes et je me demandais si j'allais chez Gitlab, Github, Bitbucket, ou autre hébergé (Gitlab, Gitea, Gogs, …)
              Comme tu mentionnes Scaleway, je suppose que vs hébergiez votre Gitlab. C'est lui qui vs a fait défaut ? Ou c'est Scaleway ? Sinon qu'est-ce qui fait que vous avez choisi Gitea ?
              (Rien à voir avec le sujet du journal… pardon pour le bruit)

              • [^] # Re: Markdown

                Posté par  (site web personnel) . Évalué à 2. Dernière modification le 07 février 2020 à 07:19.

                Gitea nous convient pour le moment. Je l'ai choisi car il est très simple à configurer et simple à déployer, et nous n'avons pas beaucoup de test d'intégration qui justifierai autre chose (pour le moment).

                Gitlab embarque son propre Postgres … Il y a un fichier de configuration de 2300 lignes, contre 5 lignes pour Gitea.

                on a minutieusement enchaîné les petites erreurs pour péter mon WE :
                - Nous avons installé le paquet Gitlab de Debian sur une Debian Stretch sur ARM à l’origine. C'était un bon choix car ce package utilisait la version Debian de Postgres et était disponible sur ARM.
                - Le serveur n'était pas très stable, aussi je n'aime pas l'ancienne interface de Gitlab, j'arrive jamais à retrouver ce que je cherche, et je trouve ça lent. Alors, je décide de migrer sur Gitea…
                - Pour la migration, il fallait disposer de la version 4 de l'API de Gitlab. Donc on décide de mettre à jour notre Gitlab.

                Et là, c'est le drame …
                - d'abord je le backup du serveur
                - La mise à jour du paquet ne fonctionnant pas, je mets à jour la distribution. Tout ce passe nickel, sauf que Gitlab n'est toujours pas installable…
                - Je remets encore à jour le serveur (vers SID), idem
                - Je cherche à installer la version officielle, mais pas d'image pour l'architecture ARM.

                En installant la version officiel sur un serveur x86-64, je constate la complexité délirante de ce produit : il faut 5 minutes au serveur pour "générer sa configuration"… Jamais je n'aurais installé Gitlab si j'avais assisté à ça. Ce n'est pas moi qui ai installé le serveur, et je comprends bien que les packageur officiel de Debian ont du se tirer une balle en essayant de packager cette bouse.

                N'arrivant pas à importer la backup Postgres dans la version embedded de Postgres, je décide de remettre le backup. Et là, problème :
                pour installer le backup, il faut créer une instance ARM (identique à celle d'où provient le backup), cool, sauf que Scaleway n'a plus d'instance ARM depuis un baille, et comme c'est installé dans la partition Root, je ne peux rien en faire.

                Donc ce We, je vais me coltiner le modèle de Gitlab, l'API de Gitea, et faire l'importation de ce que je peux (utilisateur, clés, repos, organisation, tickets). Je fais ça en Groovy pour l'info. C'est pas compliqué, mais très chiant.

                Au final, j'aime bien Debian et ARM. Il faut juste faire très attention lors du choix d'un logiciel, surtout aussi fondamental qu'une forge qui doit être pérenne, à la complexité de celui-ci.

                Clairement Gitlab est trop complexe à intégrer. Puis j'aime vraiment pas avoir Postgres10.2 installé, alors que Debian propose déjà 3 versions de Postgres..

                • [^] # Re: Markdown

                  Posté par  . Évalué à 1.

                  J'ai le même genre d'expérience avec gitlab et scaleway arm. J'ai abandonné gitlab en auto hébergé suite à une auto destruction que je n'ai toujours pas compris et une restauration impossible.

                  Le plus frustrant, c'est le "backup" scaleway de la machine qu'on ne peut plus lancer, ou alors dans une machine à 4 fois le prix, parce que dans mon cas j'avais plusieurs disque sur un dédié arm.

                  Maintenant, scaleway propose une conversion des images vers d'autres architectures, c'est un peu mieux. La dernière fois que j'ai eu un soucis, j'ai fini par réussir à relancer ma backup sur une archi différente, puis convertir l'image générée vers ma machine d'origine… Mais ça a été 2 jours de galère.

                  Sinon, scaleway propose toujours des instances arm, mais en VM.

  • # Différences entre Micronaut et Quarkus

    Posté par  . Évalué à 5.

    Quarkus est l’autre framework au top de la hype pour plus ou moins faire la même chose que Micronaut.
    Quelles sont les principales différences et quelles conditions vont faire pencher pour l’un ou l’autre ?

    • [^] # Re: Différences entre Micronaut et Quarkus

      Posté par  (site web personnel) . Évalué à 3.

      Je connais pas bien Quarkus, il semble y avoir peu de différences. Les 2 jouissent d'un développement très actif, et ont plein de dépendances communes.

      à l’avantage de Micronaut, je dirais:
      - support Groovy, Gorm, Kotlin (pour moi c'est important)
      - plus de fonctionnalités intégrées (Micronaut Data par exemple, il y a Panache pour QuarkUs, mais peut-on utiliser les Validator pour autre chose qu'Hibernate ??)
      - doc qui montre le code dans les langages supporté, et que je trouve très bien faite. Moins bordélique que celle de QuarkUS
      - il parle moins de Kubernate, mais plus d'ASM.
      - L'auteur

      à l'avantage de Quarkus :
      - peut-être plus minimaliste
      - plus orienté performance

      Il faut que je regarde comment fonctionne l'injection de dépendance pour vraiment les différencier.

      • [^] # Re: Différences entre Micronaut et Quarkus

        Posté par  . Évalué à 2.

        En cherchant un peu j’ai trouvé cette vidéo, sans la regarder toutefois. Elle doit potentiellement apporter quelques indications.

        https://www.youtube.com/watch?v=hnEXOqcNXPs

      • [^] # Re: Différences entre Micronaut et Quarkus

        Posté par  (site web personnel) . Évalué à 1.

        (Full disclosure : je travaille sur Quarkus)

        • plus de fonctionnalités intégrées

        Pas convaincu. Nous avons énormément d'extensions.

        il parle moins de Kubernate, mais plus d'ASM

        En quoi c'est un argument sur le framework lui-même ? Pour info, Quarkus utilise énormément la génération de code via Gizmo (une bibliothèque au dessus d'ASM).

        L'auteur

        Euh, sérieusement ?

        De notre côté, on a décidé d'éviter les comparaisons alors je ne vais pas m'embarquer là-dedans. Je vous invite à faire l'expérience des deux et à découvrir le live coding avec Quarkus qui à mon avis change énormément de choses sur le confort de développement :).

        Dans tous les cas, on est assez content de participer à mettre un coup de pied dans la fourmilière Java :).

        PS : aucune fourmi n'a été blessée.

        • [^] # Re: Différences entre Micronaut et Quarkus

          Posté par  (site web personnel) . Évalué à 3.

          Tu t'embarques dans les comparaisons puisque tu parles de live coding :)

          On utilise JRebel avec Grails. Il y a d'autres solutions comme utiliser Spring DevTools (qui fonctionne pour les applications SpringBoot), mais dans notre cas, l'application est assez volumineuse et le rechargement des classes se fait en plusieurs longues secondes. Ce n'est pas optimal, mais on survit.

          C'est donc la grosse différence entre les framework (je ne connais pas trop le pour et le contre des 2 approches) :

          • Quarkus modifie le bytecode directement lors du build, il utilise un plugin gradle ou maven pour pouvoir le faire, ce plugin sait comment recharger les classes modifiées ;
          • Micronaut enrichi le bytecode pendant l'analyse des sources. Il n'utilise pas de plugin Gradle / Maven et ne connait pas les classes à recharger.

          ça rend Quarkus intéressant pour le coup, ne serait-ce que pour voir comment ça fonctionne.

          • [^] # Re: Différences entre Micronaut et Quarkus

            Posté par  . Évalué à 1.

            Micronaut enrichi le bytecode pendant l'analyse des sources. Il n'utilise pas de plugin Gradle / Maven et ne connait pas les classes à recharger.

            De ne comprends pas cette phrase. Lors de l'analyse des sources il n'y a pas de bytecode à modifier 🤔

            Pour jrebel, c'est un outil non libre et payant (et je cris pas donné), ça limite pas mal son utilisation.

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

            • [^] # Re: Différences entre Micronaut et Quarkus

              Posté par  (site web personnel) . Évalué à 2.

              Micronaut ajoute le byte code en utilisant l'infrastructure que propose Gradle sans plugin via les "annotationProcessor". On peut faire du build incremental, agréger ces annotationProcessor pour reconstruire rapidement.. Mais gradle ne sait pas recharger le contexte, il sait juste Builder et redémarrer le tout en cas de changement.

              L'impacte est limité pour Micronaute, car le temps de redémarrage est de quelques courtes secondes.

              Je ne connais pas la complexité de développement d'un plugin Gradle qui pourrait faire le rechargement de contexte pour Micronaut.

              Concernant JRebel, on peut s'en passer pour les applications Grails (qui est bien plus lourd que Micronaut). On utilise finalement Spring DevTools, et on optimise.

        • [^] # Re: Différences entre Micronaut et Quarkus

          Posté par  . Évalué à 3.

          De notre côté, on a décidé d'éviter les comparaisons

          Ce qui est bien dommage car il y a pléthore de solutions :

          • spring boot
          • micronaute
          • quarkus
          • vertx (utilisable via quarkus fais avec quels changements ? Je sais que Julien Viet et Clément Escofier sonteenthousiastes pour quarkus donc j'imagine qu'il y a surtout des gains)
          • ratpak
          • lagom
          • helidon
          • ktor
          • grail

          Et j'en oublie voir ne connaît pas certains. Il faut bien faire un choix et dire qu'il n'y a qu'à tester c'est rigolo, mais en fait non. Ils seront tous très rapides si on joue leur getting started parce que 3 classes java c'est léger quoiqu'il arrive.

          Après je connais quarkus via Emmanuel Bernard et Clément, j'ai des billes pour en comprendre la philosophie, le fonctionnement et donc savoir à quoi m'attendre. Mais pour moi l'argument "on a une boucle de feedback rapide", c'est presque comme dire qu'on peut coder un webservice dans un twitt. Ma prod s'en fout, si c'est pour ne pas tenir les perf dont j'ai besoin, être compliqué à monitorer ou ne pas être perdre tous les avantages dès que j'utilise quelque chose d'un peu exotique, ça m'embête un peu plus.

          Sans entrer dans des guerres de bench inutiles, il y a des différences objectives entre tous ces projets et c'est bien d'en parler, sinon c'est que les dev se sont juste dit "et si on écrivait un énième framework comme c'est la mode ? On est meilleur que les autres donc on va faire mieux !".

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

          • [^] # Re: Différences entre Micronaut et Quarkus

            Posté par  (site web personnel) . Évalué à 6. Dernière modification le 08 février 2020 à 18:35.

            En fait, le truc, c'est que si tu t'embarques dans les guéguerres de chapelle, c'est sans fin. On a décidé de ne pas baser notre communication sur les comparaisons et de laisser les gens les faire eux-mêmes avec leurs propres contraintes.

            Pour répondre à tes points d'interrogation :

            • la boucle de feedback rapide, c'est très important pour le développement. Oui, ta prod ne va pas y attacher d'importance mais le confort de développement est quand même extrêmement amélioré, ce qui permet de développer plus vite, de corriger les problèmes plus vite… Au final, je pense que ça participe à améliorer la qualité, notamment parce que tu passes du temps sur l'important (par exemple traquer un bug remonté par la prod plutôt que d'attendre que ton application redémarre). Et c'est un tout parce que sans temps de démarrage rapide, on a du mal à scaler instantanément ou à faire du serverless.
            • les performances de Quarkus sont bonnes. On a beaucoup de très bons retours de production à la fois sur les temps de démarrage, la consommation mémoire et les performances au run en général. Et on continue à améliorer tout cela en continu.
            • pour le monitoring, on a MicroProfile Metrics et Health.
            • Vert.x est au coeur de Quarkus. Par défaut, RESTEasy, notre implémentation REST, se repose sur Vert.x pour le bas niveau.

            Bref, je pense qu'on propose une alternative très intéressante. Peut-être pas pour tous les besoins mais chacun pourra juger en fonction de ses contraintes.

            Ca fait un moment que j'hésite à écrire une dépêche sur Quarkus ici mais je ne savais pas trop si on avait encore des lecteurs Java ici depuis le départ (regretté) de Pierre Tramo. Je peux m'y coller un de ces quatre si suffisamment de gens sont intéressés.

  • # « natively cloud native »

    Posté par  . Évalué à -1. Dernière modification le 06 février 2020 à 15:36.

    Aurait-on franchi un nouveau niveau de marketing ?

    En dehors de ce troll et sans même faire de Java, je suis un peu jaloux de ces annotations, surtout quand je regarde mon code en Go.

  • # Spring is coming

    Posté par  (site web personnel) . Évalué à 6.

    Bonjour,

    Je suis un jdécideur pressé, pourquoi j'échangerais mon baril de Spring pour un baril de Micronaut?

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.