Cette année, Sedona a eu la chance de participer au VOXXED Microservices et d’en être un des sponsors.

 

Pour s’être nous même mis au Microservices il y a environ un an et demi, ils nous semblait naturel d’être impliqué dans cette conférence. Ce sera l’occasion pour nous de profiter de l’expérience et de l’expertise des speakers présent à cette conférence mais aussi de faire un retour de notre propre expérience lors de la conférence « Microservices : Highway to hell ».

La conférence s’est déroulée sur 3 jours à l’espace Charenton (Paris), les deux premiers jours étaient consacrés aux talks et le troisième jour aux Hands on labs.

Voici un résumé de quelques conférence auxquelles nous avons assisté lors des deux jours de talk et les liens vers les vidéos.

Lundi 29 Octobre

Hexagonal at Scale, with DDD and microservices ! [ ▸ ]

Comment définir le périmètre de nos micro-services ? Comment éviter de se retrouver avec un super « monolithe distribué » ? Et l’Architecture Hexagonale dans tout ça ? Autant de questions qui ne paraissent pas si compliquées au premier abord mais peuvent se révéler être pleines de pièges lorsque l’on s’y attarde un peu.
Cyrille Martaire nous donne des pistes pour mettre en place une architecture « Hexagonal at Scale » dont les composants seront nos micro-services définis à l’aide de la notion de Bounded Contexts apportée par le Domain-Driven Design.

Pour aller plus loin sur le DDD :
– Conférences Domain-Driven Desin Europe sur Youtube
– DDD Reference (Eric Evans) sur DomainLanguage
 – Le livre de référence : Domain-Driven Design par Eric Evans, sur Amazon

 

Stop reinventing the wheel with Istio [ ▸ ]

Le microservices impliquent clairement l’utilisation de container. Ces containers fournissent un environnement cohérent et reproductible pour l’exécution de ces derniers. D’ou l’utilisation d’un orchestrateur tel que Kubernetes qui nous aide à gérer et à faire évoluer nos clusters de containers à l’aide d’une API cohérente. C’est un premier pas vers une architecture de microservices faiblement couplés, seulement cela ne suffit pas, il nous reste à contrôler les flux entre composants, découvrir les nouveaux services, les mettre en relation, connaitre les dépendances, découvrir les problèmes, gérer les identités de services etc… Des solutions comme spring cloud nous permettent de le faire mais cela implique beaucoup de développement et de customisation. C’est là qu’arrive Istio, une plateforme qui va nous permettre de connecter, gérer et sécuriser nos microservices et qui s’intègre très bien avec Kubernetes (mais pas que, consul peut aussi fonctionner avec Istio). Ne réinventons pas la roue et appuyons nous sur un outil qui nous fournit les services, clef en main, pour pouvoir gérer, administrer et sécuriser nos environnement de microservices.

 

A Software Architect’s Approach towards SPA-Based Micro Apps [ ▸ ]

Et si les microservices inspiraient des pattern de développement front, c’est clairement ce que Manfred Steyer nous propose de voir ensemble.

Le point de départ de cette conférence est une application qui au départ est petite et controlée, puis plus le temps passe plus celle-ci devient énorme, difficilement compréhensible donc compliquée à reprendre. Du coup l’idée de structurer une grosse application en fragment se pose. A l’instar des microservices pourquoi ne pas avoir une approche sur un fort découpage voir découplage et donc sur la possibilité de laisser à des petites équipes la possibilité de gérer de petite partie spécifique qui une fois assemblée seront l’équivalent d’un gros monolith, avec l’avantage de part  la découpe que ce soit plus facile à comprendre donc plus facile à reprendre et à faire évoluer… Manfred introduit même l’idée de pouvoir mixer des technologies (Angular, React, Vue…) dans une grosse application composée de plusieurs petite application.

Manfred nous présentera donc les avantages et inconvénients sur :

• Le développement d’application monolith dans une entreprise, comment avoir une approche élégante sur l’utilisation des librairies dans différent projets afin d’avoir une uniformisation de celles-ci. Permettre à tout le monde d’être « up to date » sur les versions et pouvoir vérifier facilement qu’une montée de version n’impacte pas tel ou tel projet se basant dessus. Ainsi on peut plus facilement faire en sorte que les devs utilisent les dernières version de librairies, que tout le monde utilise les mêmes librairies et même développer ses propres librairies utilisées dans différent projet. Pour répondre à ces problématiques Manfred mettra en avant sa vision de mono repo, tous les projets vont partager un même répertoire « node_modules » et les différent projets pourront aussi s’appuyer sur les autres projets.

• Le développement de plusieurs petite applications se référençant les une les autres par de simple lien, chaque application est pointu sur un use case et donc mis bout à bout elles feront le même travail une grosse application monolith. Cependant un problème se pose sur la gestion d’un état entre ces différentes applications.

• Le développement d’une application qui pourra charger d’autres applications, une approche SPA qui embarque d’autres SPA. C’est une approche Web component, sauf que ces web component sont plus complexes. Une application pour en encapsuler d’autres, on peut voir cela comme un container qui embarque d’autres micro-container. (à noter que une Iframe peut répondre au besoin, cependant les Iframes sont déconseillée pour un extranet, par contre pour un intranet cela peut être une bonne approche dans certains cas)

• Et enfin comment réfléchir à quelle approche utiliser.

 

 

 

Mardi 30 Octobre

Thorntail – A Micro Implementation of Eclipse MicroProfile [ ▸ ]

Eclipse MicroProfile est une initiative qui vise à optimiser Enterprise Java pour l’architecture de Microservices. Basé sur un sous-ensemble d’API Java EE WebProfile, nous pouvons créer des applications MicroProfile comme des applications Java EE. Sauf que l’on embarque dans notre application le strict minimum.

L’objectif de MicroProfile est de définir des API standard pour la création de microservices et de fournir des applications portables sur plusieurs runtime de MicroProfile.

MicroProfile est une cible en évolution rapide et a beaucoup évolué depuis son annonce il y a deux ans. Seulement suivre régulièrement cette évolution rapide des spécifications et des implémentations correspondantes nécessite beaucoup d’énergie pour tous les fournisseurs. Il a donc été proposé de regrouper les parties communes de ces efforts d’implémentation dans une implémentation unique de MicroProfile, indépendante du fournisseur, dont le nom de projet est SmallRye.

Thorntail est le premier conteneur MicroProfile à utiliser l’implémentation SmallRye. Dans sa version actuelle, 2.2.1.Final, il implémente la version 1.4 de microprofile. Thorntail se nommait Wildfly swarm mais celui-ci a été renommé pour éviter tout confusion avec d’autres outils (par example Wildfly, ex JBOSS qui est un serveur d’application JEE)

Il s’en suivra une démo live de ce que l’on peut faire avec Thorntail, des outils nécessaire à la mise en place de microservices viennent avec (circuit breaker, health-check, configuration, sécurisation…). En complément voici la documentation sur les microprofile et Thorntail.

En conclusion, je dirait qu’on a enfin une alternative digne de ce nom à l’écosystème Spring, que je trouve personnellement plus léger et plus élégant. Cependant il ne faudrait pas que la sortie des implémentations des microprofile trainent trop car Spring reste une solution viable et qui évolue très rapidement pour s’adapter aux nouveaux besoins.

 

Microservices: Highway to hell [ ▸ ]

Ce talk (présenté par Sedona), était un retour d’expérience sur le développement d’une plateforme de réseau social implémentée en utilisant les microservices.

Sur des cas pratiques, une liste de 7 erreurs, faites pendant le projet, est dressée :

• Utilisation de trop de composants logiciels dès le démarrage du projet
• Déploiement d’une nouvelle version d’un microservice fonctionne out-of-the-box
• Penser local et non distribué
• Essayer de deviner comment un composant logiciel fonctionne (sans passer par la case documentation)
• Librairie partagée entre les différents microservices
• Une petite équipe qui travaille sur tous les microservices
• Confiance aveugle des API fournis par le fournisseur de la plateforme cloud

 

Secure microservices made easy with MicroProfile JWT [ ▸ ]

La présentation commencera par l’explication de ce qu’est un token JWT (RFC7519) et de comment cela peut être utilisé. Il peut bien sur être utilisé seul simplement, lors d’une authentification on soumet un JWT (chiffré ou pas, signé ou pas) qui est par la suite envoyé dans un header HTTP et lu par des ressources auxquelles on veut accéder. Ce token est auto-suffisant puisqu’il peut porter l’identité et les habilitations de la personne ou du service qui l’utilise, ainsi la ressource n’a qu’à lire ces informations contenu dans le token et valider ou non l’accès. Il peut aussi être utilisé comme token pour des protocoles connu comme Oauth 2 (habilitation) et OpenID connect (authentification). Je ne rentrerai pas plus dans le détail, voir jwt.io pour plus d’informations sur le token en lui même.

Par la suite sera présenté la brique qui implémente la spécification Eclipse MP-JWT 1.1, c’est une des briques d’une des implémentation des microprofile, Thorntail (anciennement Wildfly swarm).

Il nous sera présenté comment cela s’intègre dans l’écosystème JEE, avec en particulier CDI. A l’instar de ce que fait Spring Security avec ses fichiers de configuration et l’accessibilité aux informations de sécurité dans le context (récupérer sur le JWT, l’identité, les droits…), on pourra de même injecter, vérifier, sécurisé etc…

Voici un article assez complet en complément pour comprendre comment cela s’intègre.

 

REST API vs gRPC, which one should you use in breaking a monolith [ ▸ ]

Ce talk est un comparatif des avantages / inconvénients entre développer une REST API et l’utilisation de gRPC pour exposer des services.

Après une très courte introduction sur les REST API, notamment sur l’implémentation avec Spring Boot, le speaker introduit gRPC.

gRPC est une manière d’exposer des services  à l’instar de CORBA ou RMI pour Java. Introduit par Google en 2008, il est cross-plaform et cross-language.

gRPC utilise protobuf pour l’échange de messages client serveur. Concrètement, pour créer un service gRPC, il suffit de créer un fichier .proto qui décrit le service et le contenu des messages qui vont transiter. Grâce à ce fichier il est possible alors de générer un stub et un skeleton (respectivement pour la partie client et pour  la partie serveur)

S’en est suivi un live coding avec pour exemple ce projet trouvable sur Github: https://github.com/vladimir-dejanovic/grpc-bank-example

Les avantages à l’utilisation de gRPC par rapport à l’utilisation des API Rest, est la réduction de la bande passante lors de la communication client/serveur (protobuf est un protocole binaire), la rapidité d’instancier un client (par génération de stub) et de découvrir l’API.

 

Microservices Lessons Learned [ ▸ ]

Ce talk est un retour d’expérience sur la migration d’une application monolithe en microservices dans une startup.
La présentatrice était alors CTO pendant cette migration.

Elle a très fortement appuyée le fait que chaque journée est différente et de fait, il y aura toujours des imprévus (nouvelle techno apportant des restrictions techniques, changement organisationnel, etc…). Il faut aussi les prendre en compte et faire avec.

Dans leur organisation chaque microservice a une équipe dédiée avec un cycle de vie (et temps de développement) différent des autres. Cela a été bien anticipé.

Une des grosse erreur réalisée lors de leur migration a été d’essayer de migrer beaucoup de choses en une seule fois et en y ajoutant en plus des évolutions (fonctionnalités & interface).

Une problématique sur la partie authentification a été soulevée : faire un microservice d’authentification est un bon concept mais il faut absolument éviter l’effet « Distributed Monotlith ». Cet effet est un couplage trop fort entre le microservice d’authentification et les autres.
Solution : fournir un contrat commun entre le microservice d’authentification et tous les autres microservices.

Enfin, le dernier sujet concernant les différents moyens d’interactions direct entre les microservices et comment gérer le partage de données communes. La solution d’Apache Kakfa Streams a alors été présentée.

Lien vers le talk : https://www.youtube.com/watch?v=mYCdVjMMmck

 

Si vous voulez voir les autres conférences voici la chaine youtube du VOXXED

 

Let’ rock Microservices!!!