Interview d'Antonio Goncalves à l'occasion de Voxxed Microservices

D’où vient l’idée de Voxxed Days Microservices ?

C’est un long cheminement. Il y a fort longtemps, j’ai fait ma thèse sur CORBA et j’ai alors découvert les problématiques des systèmes distribués. À la même époque, je m’acharnais sur HTML 2.0, sans grand succès. J’ai ensuite travaillé pour BEA Systems où je mettais en place des architectures J2EE distribuées avec des clusters d’EJBs remote (RMI/IIOP), du fail over, de l’affinité de session, de la redondance… J’ai adoré ces années chez BEA. C’est aussi l’époque de Swing, et j’avoue avoir été aussi brillant en Swing qu’en HTML. Puis arriva l’ère des « Microservices ». Tous mes clients voulaient migrer leurs architectures, découper leurs monoliths, aller sur le cloud, centraliser leurs logs et configurations, etc. Des challenges passionnants. En parallèle, je m'efforçais de faire de l’Angular.

Bref. J’ai regardé en arrière et, clairement, ce qui m’a toujours plu dans ma carrière ce sont les systèmes distribués, et non les interfaces utilisateur. Fort de mon expérience du Paris JUG, je me suis dit : « et si je créais un meetup mensuel sur les microservices ? » Mais le panorama des meetups techniques à Paris a beaucoup évolué entre le moment où j’ai créé le Paris JUG et aujourd’hui. À l’époque il n’y avait aucun meetup technique. Aujourd’hui, il y en a plusieurs chaque soir. J’ai donc renoncé à créer un meetup mensuel, étant persuadé qu’il serait noyé dans la masse des meetups, pour me consacrer à une conférence annuelle et en anglais : Voxxed Days Microservices.

Cette conférence appartient à la famille des Voxxed Days, c’est ça ?

Oui. Je ne voulais pas me lancer en solitaire, en créant une conférence issue de nulle part. Je suis attaché aux communautés et je voulais continuer à les faire prospérer. J’ai donc contacté Stephan Janssen et Mark Hazell, qui gèrent les Voxxed Days et leur ai exposé l’idée. Ils ont adoré. Les Voxxed Days sont enracinés dans les communautés. Ce sont souvent d'anciens JUGs qui montent une conférence d’une ou deux journées. Cela faisait donc sens d’avoir un Voxxed Days dédié aux microservices.

Quelles sont les particularités de Voxxed Days Microservices ?

La particularité de cette conférence, c’est qu’elle est dédiée aux microservices, et uniquement aux microservices. Lorsqu’on parle « tests », on parle de tester des microservices. Lorsqu’on parle « déploiement », on parle de déployer des microservices. Durant deux jours (29-30 octobre 2018), dans deux salles en parallèle, vous entendrez donc parler uniquement de microservices. Les keynotes d’ouvertures et la keynote de fermeture seront aussi très techniques et porteront sur les microservices d’aujourd’hui et demain.

En parallèle des conférences, il y aura un hall d’exposition avec des sponsors. Là encore, tous nos sponsors ont des histoires à raconter sur les microservices. Il y a quelques SSII qui viennent nous parler de leurs retours d'expériences, des éditeurs qui nous présentent leurs frameworks microservices, ou des utilisateurs finaux qui ont mis en place les microservices avec succès.

Et au centre de ce hall, les participants auront accès à une zone « SOS Microservices ». Vous avez un problème ? Des questions ? Des doutes ? Entrez dans cette zone et échangez avec d’autres participants, ou des sponsors, qui ont résolu des problèmes similaires et peuvent vous aider.

La conférence a aussi vocation à élargir le scope des participants, elle est donc 100 % en anglais pour permettre d'accueillir des participants venant d’autres pays.

Quel en sera le contenu ?

La conférence couvrira le cycle de vie d’un projet orienté microservices. Il sera question d’architecture, mais aussi de design et de modélisation (ex. DDD). Qui dit modèle, dit également données. Lorsque chaque microservice a sa propre base de données, comment synchroniser ces données (ex. Capture Data Change, Event Sourcing) ? On couvrira, bien sûr, la partie REST (mais aussi gRPC, contrat…) ainsi que la partie messaging (avec Kafka assez présent cette année). Puis il y aura des conférences sur les parties très techniques des microservices (ex. Proxy, gateway, circuit breaker, load balancer…). Une fois tout ce beau back-end architecturé, modélisé et développé, il y a bien sûr pas mal de questionnements sur les interfaces utilisateur (ou comment agréger plusieurs interfaces graphiques en une seule). Ensuite, commencent à se poser les problématiques de sécurité (il y aura des conférences sur JWT, OAuth2, Open ID). Puisque nous sommes de bons développeurs, on n’oublie pas la partie test et monitoring bien sûr (Health check, agrégation de logs, traces distribuées…). Et puis, le happy end, le packaging des microservices (ex. Docker, Kubernetes) avant de partir sur le Cloud pour avoir une architecture scalable (ex. Istio, OpenShift). En parallèle de toutes ces conférences techniques, des sujets plus transverses seront aussi couverts comme l’impact des microservices dans l’organisation des équipes, ou bien des retours d'expérience. Car non, les microservices, ce n’est pas que bien. La mise en place est parfois douloureuse…

C’est quand et où ?

La conférence a lieu à Paris, à l’espace Charenton, le lundi 29 et mardi 30 octobre 2018. Pour celles et ceux qui veulent mettre les mains dans le cambouis, vous pouvez prolonger l'expérience et participer à une journée de workshop le mercredi 31. Et surtout, c’est une conférence annuelle, n’hésitez donc pas à suivre le compte twitter de la conférence @vxdmicroservice pour être tenu au courant de son actualité. Enfin, comme toutes les conférences Voxxed, tout le contenu sera filmé et disponible sur YouTube.

En partenariat avec Developpez.com, vous pouvez profiter de 20% de réduction grâce au code VXDMS18_DVP.

C’est quoi un microservice ?

La « définition officielle » donnée par James Lewis and Martin Fowler de Thoughtworks est un peu pompeuse et on s’y perd un peu. J’aime assez la définition de Sam Newman, ancien de Thoughtworks : « Microservices are small, autonomous services that work together ».

Le problème numéro un, c’est la fameuse « taille » d’un microservice. Trouver un contexte fonctionnel n’est pas chose facile. Vous avez des besoins utilisateur, vous les analysez, et là, vous pouvez soit vous retrouver avec un monolithe, soit avec quatre ou onze microservices. Pour nous aider à découper par contexte fonctionnel, il faut se replonger dans le fameux livre d’Eric Evans et bien comprendre le Domain-Driven Design (DDD). Une fois votre fonctionnel découpé en N microservices, vous vous retrouvez à dupliquer des données entre bases de données. Il faudra alors les synchroniser. La difficulté des microservices est avant tout une difficulté liée à votre métier. Ensuite, il y a bien sûr un peu de technique. « Services that work together », on imagine bien des appels synchrones REST entre services, mais aussi des appels asynchrones, des messages… et tout ça en JSON, XML ou plus récemment, en utilisant des protocoles binaires tels que gRPC. Et puis il y a le fameux « work » de « work together ». Pour que tout cela « fonctionne » sur un réseau et du matériel défaillant, il faudra mettre en place plusieurs patterns et briques techniques pour que l’architecture continue à fonctionner, même en mode dégradé.

SOA est-il l'ancêtre des Microservices ?

Oui, il y a une certaine genèse des microservices dans le SOA, et même avant dans le RPC. Plusieurs problématiques techniques ont déjà été résolues dans les architectures SOA : couplage lâche, protocole de communication, tolérance aux pannes, haute dispo, découpage fonctionnel plus fin, etc. Une des différences majeures, c’est qu’on a l’impression que les architectures SOA venaient avec des solutions toutes faites (ESB, WSDL, SOAP, etc.) alors que les microservices viennent surtout avec des design patterns, des manières de faire sans imposer de technologies. Et bien sûr, entre l’époque du SOA et plus récemment celle des microservices, il y a la containerisation qui est totalement nouvelle, le déploiement hybride qui rajoute de la complexité, tout ça orchestré par un mouvement DevOps qui n’existait pas à l’époque.

Donc pour toi, les microservices, c’est un phénomène de mode, ou bien c’est là pour rester ?

Je reprends ma casquette de développeur qui est passée par plusieurs buzzwords durant sa carrière. Si on remplace « Microservices » par « Systèmes distribués », ou SOA, on se rend compte que cela fait plus de trente ans qu’on fait des « Microservices ». Donc, ils étaient là avant (mais sous une autre forme, une autre dénomination), ils sont là aujourd’hui, et ils seront là demain (peut-être sous une autre appellation, comme, « serverless »).

Conseillerais-tu donc tes clients à migrer vers les microservices ?

Oui… Mais uniquement s’ils en ont besoin.

Il faut bien comprendre l’avantage des microservices (scalabilité d’une partie des services, résilience, déploiement, cycle de développement plus court…) et se poser les bonnes questions : « ai-je vraiment besoin de scalabilité par microservice ? », « ai-je vraiment besoin de déploiement hybride ? »…

Les architectures microservices sont bourrées d’avantages… et d’inconvénients. Si on effectue une migration coûteuse, qui rajoute du risque, des régressions, des remaniements d’équipe, du déploiement continu complexe… pour ne pas bénéficier pleinement des avantages, alors il ne vaut mieux pas migrer ! Si vous avez des doutes, rien ne vous empêche de commencer à migrer les briques les plus faciles, les moins risquées, et mesurer les avantages. Puis, fort de cette première expérience réussie, vous pourrez vous attaquer à des challenges plus ambitieux.

Spring Boot ou Microprofile ?

Spring Boot ! Spring Boot a une maturité, une communauté et un écosystème que le Microprofile n’a pas encore. Nous sommes à la croisée des chemins : il y a eu Java EE d’un côté, Jakarta EE de l’autre, le Microprofile au milieu… bref, il faudra attendre encore quelques releases du Microprofile pour avoir la même richesse que Spring Boot.

Penses-tu que les conteneurs (via Docker) ont accéléré la mise en place des architectures Microservices ?

Oui, clairement. Le moindre microservice que vous développez a une adhérence à un service de registry (ex. Consul), une base de données, une gateway ou un proxy. Soit vous passez votre temps à mocker tout ça pour faire passer vos tests d’intégration, soit vous utilisez la « containérisation » pour booter tous les services manquants. Une fois que vous êtes à l’aise avec tous ces conteneurs externes, vous vous apercevrez que vous pouvez aussi « containériser » vos propres services, vos propres briques techniques, et vous vous retrouverez alors dans le monde merveilleux des conteneurs pour le développement ou les tests d’intégration ou end-to-end. Pour la production, c’est une autre paire de manches. Mes clients n’ont pas encore tous franchi le pas.

Quelles sont les technologies que tu utilises pour développer des architectures Microservices ?

Je suis un gros fan de JHipster. Plus qu’un générateur de code, JHipster a une communauté de développeurs très importante qui injecte des bonnes pratiques dans le code, les services, les outils, les frameworks. Je suis tellement fan que je l’utilise chez presque tous mes clients pour bootstraper une architecture microservices. Ensuite, on s’éloigne du code JHipster, mais c’est un bon châssis de développement. Donc, je pars sur du Spring Boot, la suite Netflix, Keycloak, Metrics, ELK, Docker, Kubernetes, etc. Et je dois dire être devenu un gros fan de PostgreSQL. PostgreSQL allie le bon vieux modèle relationnel à la possibilité de gérer des documents JSon ou de faire du full-text search. Bref, j’ai redécouvert les joies du monde SQL grâce à PostgreSQL…

Dans la liste des Speakers attendus, beaucoup viennent de la communauté Java, peut-on dire que Java est la plateforme idéale pour faire du Microservices ?

Venant du monde Java, ayant des clients Java, déambulant dans les communautés Java… forcément je vais dire oui… Mais pas tout le temps.

Il y a des milliards de lignes de code Java qui traînent dans les SI. Ce sont ces lignes d’aujourd’hui qu’on va refactorer, analyser, optimiser, découper… pour obtenir les microservices de demain. Java permet une modélisation métier, vient du monde du distribué (RMI, c’est dans les premières versions de Java), a une maturité à toute épreuve, une JVM hyper optimisée… Mais il est vrai que le temps de démarrage de la JVM peut être un souci dans le monde du microservices et du cloud. C’est pour cela qu’on voit apparaître des briques, peut-être un peu plus techniques, écrites en Go par exemple. Le temps de démarrage et l'empreinte mémoire étant réduits, cela permet des cas d’utilisation auquel Java ne peut pas (encore) répondre (on verra comment se porte GraalVM dans quelque temps).

Pour le développement des IHM, il est encore difficile de faire la composition d'interface développée avec des bibliothèques différentes, penses-tu qu'il s'agit du prochain défi ?

C’est clairement mon défi personnel.

Le monde du back-end distribué a plus de trente ans. Donc, coté back, on sait (à peu près) faire. Aujourd’hui, on se retrouve avec des microservices un peu partout, développés par des équipes différentes, dans des pays différents, et on a souvent besoin de fournir une interface graphique intégrée, unifiée et multiplateforme. Lorsqu’une équipe développe son IHM en JSF, l’autre en JSP, l’autre en Angular et l’autre en React… pas facile d’intégrer tout ça dans un look and feel cohérent. Oui, il y a les web components qui arrivent et qui vont certainement résoudre pas mal de problèmes. Mais aujourd’hui, il faut souvent agréger des IHM existantes et c’est un réel challenge.

Devoxx France, c’est terminé ?

Oh que non ! Je continue à coorganiser Devoxx France avec mes acolytes Nicolas Martignole et Zouheir Cadi. Voxxed Days Microservices est une initiative personnelle, que j’ai placée en octobre, à six mois de Devoxx France pour ne pas se marcher dessus. Vous continuerez donc à me voir déambuler dans les couloirs du Palais des Congrès avec mon polo rouge.

Que penses-tu de la communauté Developpez.com ? Comment peut/doit-elle se positionner vis-à-vis de l’essor des microservices ?

Il faut y aller à fond. Je verrais bien une section 100 % Microservices, avec des interviews, des articles, du code, des tutos… uniquement orientés Microservices. La communauté DVP a toujours su s’adapter aux nouvelles tendances, aux nouvelles technos… Voici un nouveau challenge de plus pour DVP !…

Pour finir, un petit mot pour encourager les lecteurs à assister à la conférence ?

Je dirai que Voxxed Days Microservices, c’est tout ce que vous avez toujours voulu savoir sur les Microservices sans jamais oser le demander.

Vous avez des doutes sur l’organisation de vos équipes, sur la mise en place de pratiques DevOps ? Venez écouter les conférences. Vous n’avez pas tout compris du Domain-Driven Design ? Venez faire un workshop. Vous hésitez entre REST, gRPC ou GraphQL ? Venez discuter avec les meilleurs speakers sur le sujet. Votre réseau n’est pas fiable (comme aucun réseau d’ailleurs), vous devez mettre en place des patterns de résilience et vous ne savez pas par où commencer ? Venez échanger avec les sponsors. Vous ne savez pas comment synchroniser vos bases de données ? Venez dans la zone « SOS Microservices » et vous aurez une réponse.

Et j’ai mieux pour vous. Vous avez réponse à toutes les questions concernant les Microservices ? Alors venez partager votre savoir-faire avec les autres participants.

En accord avec les organisateurs de la conférence, nous avons le plaisir de pouvoir offrir une place pour Voxxed Microservices Paris 2018 à l’un de nos lecteurs. Ce dernier sera choisi au hasard parmi les personnes ayant laissé un commentaire (pertinent) à cet article avant le 10 octobre.

Toute l'équipe de Developpez.com se joint à moi pour remercier Antonio et son équipe d'avoir participé à cette interview. Nous leur souhaitons que cette nouvelle aventure soit couronnée de succès.

Et comme d'habitude, merci aux équipes de Developpez.com qui ont participé à cet article, et en particulier f-leb.

Voxxed Microservices : https://voxxeddays.com/microservices/