Le 14 juin 2019 a eu lieu la 3ème édition du Devfest Lille, l’occasion pour plusieurs collaborateurs d’Elosi de s’y rendre.

Pour certain d’entre nous cela fut la première fois que nous nous y rendions (shame on us :-) ), pour d’autres aucune édition n’a été manquée.

Le Devfest kesako ?

Le Devfest est « LE festival des développeurs organisé par des développeurs », un évènement organisé par le GDG (Google Developers Group) local dans un lieu adapté pour cela puisqu’il s’agit du Kinépolis situé à Lomme.

Nous allons donc vous parler de conférences auxquelles nous avons assisté.

Si par nos écrits, une de ces conférences vous intéresse, vous pourrez la retrouver sur youtube lorsqu’elle sera publiée :

https://www.youtube.com/user/francegdg/videos

- “Euh une conf sur les micro-services ce n’est pas has been?”
- Et bien non car en fait cette conférence n’était pas tournée autour du thème “Les microservices c’est trop génial, il faut détruire tous les monoliths et celui qui dit le contraire est nul et doit être maudit sur plusieurs générations”

Cette conf était un retour d’expérience sur la transformation d’un monolithe en micro services.

Ce qu’il faut retenir et comprendre, c’est que les microservices ce n’est pas si facile, que ça coûte de l’argent (plus cher qu’un monolithe), que le découpage micro doit être réalisé de façon fonctionnelle et non technique, j’ai d’ailleurs adoré cette  illustration pour permettre de bien comprendre :

Un client techniquement c’est la même chose mais fonctionnellement ça ne l’est pas.
En effet un client dans le contexte de la vente n’est pas le même que dans le contexte du support => Les microservices ce n’est
pas une guerre de technos. Certains en se lançant dans la mise en place de microservices se sont lancés dans une guerre de technos.

Il s’agit d’une erreur car l’utilisation de trop de techno devient vraiment chaotique en terme de maintenance.

Cours de cuisine

L’un des gros défaut lorsque l’on transforme un monolithe est de prendre un gros bout de ce monolithe ce qui est une erreur.

Nous avons du coup appris au cours de ce talk que pour faire des raviolis, il ne fallait pas d’abord faire des lasagnes, en prendre une part et la transformer en raviolis.

L’application des principes du DDD (Domain Driven Design) ont été évoquée lors du talk afin d’expliquer que les erreurs d’un microservice ne doivent pas être masquées et surtout doivent avoir été pensées lors de la conception.

Quelques rappels ont été fait comme le fait de ne jamais partager les même tables entre microservices.

Deux points ont été évoqués et  doivent être couverts dès le début de la réalisation des microservices :
- Le monitoring : Car il faut pouvoir répondre rapidement à son client si un incident arrive.
- L’automatisation des déploiement car cela peut vite être problématique.

Et les migroservices dans tout ça qu’est ce que c’est ????

En voici les règles principales :

Un très bon talk concernant l’utilisation d’outil, la productivité pour la production, le management et le debug sous Kubernetes.

La présentation des outils kubectx, K9S, Tubekit, Kubectl, Kube-Score, Kubesec, Helm Unittest, Helm diff, Kubetail, Kubefwd, Telepresence et Squash (rien que ça), nous a permis de nous rendre compte qu’un outillage complet existait pour être plus efficace lorsque l’on utilise Kubernetes.

Mention spéciale pour Squash permettant de débugger en local son microservice lorsque celui-ci s’exécute dans Kubernetes.

Talk de retour de déjeuner, un peu flippant en fait.

En effet, Tiffany qui est data scientist nous présente comment une IA peut être trompée mais surtout nous a fait beaucoup réfléchir sur le fait que l’IA peut être très dangereuse car elle devient si perfectionnée que l’on n’arrive plus à faire la différence entre fake et réalité. Par ce biais, elle nous présente les algorithmes GAN (Generative adversarial network) et par quels moyens ceux-ci permettent également d’améliorer les prédictions.

Si vous avez assisté à l’Apérops organisé par Elosi concernant l’IA, vous saviez déjà que l’IA pouvait générer des photos de personnes n’existant pas, maintenant l’IA peut faire parler des images.

Je vous invite à regarder cette vidéo c’est tout simplement impressionnant.Et pour le titre de la conférence have a look :
https://www.youtube.com/watch?v=uAXtO5dMqEI

Un excellent retour d’expérience de la part de Maxime Pawlak concernant sa reconversion en tant que Data Scientist.

Durant son talk, Maxime fait référence à différentes choses l’ayant aidées à atteindre ses objectifs, accompagnés de conseil.

Brut de fonderie voici quelque conseils, ouvrages, cours et outils l’ayant aidés lors de son long voyage d’apprentissage.

Supports

• The analytics edge

• Coursera Machine Learning => cours mathématique

• Siraj rival : TENSORFLOW in 5 minutes

• Learn data science in 3 months => gratuit 10h d’effort /semaine et un slack permettant de trouver un parrain

• Cours CS231 de l’université de Stanford

• Toward data science

• Chaîne YouTube tensorflow

• Deep Learning with Python : livre passionnant

Tools

• Pandas : biblio Python

• Jupyter : éditeur

• Scikit learn : bibliothèque ML très puissante

Réalisations

• Assister à des meetup

• Kaggle : plateforme de concours de ML et forte communauté

• Ecrire ! Tenir un blog !

Conseils

• Toujours commencer par une solution simple

• Beaucoup d’infos à connaître, pas besoin de tout maîtriser

• Prendre des raccourcis si des notions sont déjà connues

• Définir des objectifs atteignable

• Toujours se lancer des projets pour appliquer et gagner en expérience

• Avant de se mettre dans le deep Learning il faut prendre en main les concepts du ML classique
  

Aujourd’hui, Java ne permet pas d’optimiser la mémoire d’une application. Si nous pouvons influer sur la Heap (en définissant le paramètre -Xmx), elle ne représente pas la totalité de la mémoire allouée. Elle est une partie intégrante du RSS (Resident Set Size, rien à voir avec vos fils d’actus préférés!) qui se compose donc de la Heap size, du MetaSpace et du OffHeap size. Le RSS pouvant donc être très volumineux, la containerisation Java en subit les conséquences immédiates quand le sujet de l’optimisation de la consommation mémoire arrive sur la table.

En plus de proposer un temps de démarrage du serveur proche de 0 secondes et un HotReloading à en faire pâlir les développeurs Front-End, Quarkus permet donc de réduire la taille du RSS dans son ensemble (et non pas uniquement de la Heap Size, qu’on connaît tous) afin de faciliter la containerisation et la scalabilité.

On y retrouve donc une gestion de la mémoire beaucoup plus intéressante pour l’aspect containerisation, un temps de démarrage serveur proche de l'instantané pour garantir de la performance sur le Cloud.

Les promesses sont intéressantes, et c’est avec notre plus grande attention que la suite de la  conférence s’est déroulée. Après, la théorie, nous sommes entré dans du concret avec des exemples d’utilisation de Quarkus, depuis un projet “From Scratch”.

Armé de votre IDE Favoris, d’un JDK (de la version 8 à 11), d’Apache Maven (dans sa version 3.5.3 minimum), vous êtes prêt à démarrer ce projet flambant neuf avec Quarkus.

Grâce à Maven, il va être possible de Bootstrapper le projet, avec par exemple :

mvn io.quarkus:quarkus-maven-plugin:0.18.0:create -DprojectGroupId=com.elosi -DprojectArtifactId=demo-quarkus -DclassName=”com.elosi.tutoriel.HelloWorldResource” -Dpath=”/hello”

Il est trop tôt pour se prononcer sur Quarkus. Le projet reste récent (mais prometteur). Aujourd’hui, il peut-être une alternative solide lorsque vos solutions nécessitent des enjeux mémoire bien spécifiques (à identifier assez rapidement néanmoins!). Mais une chose est sûre, avec les apports de nouveaux frameworks comme Quarkus (ou encore Micronaut, un concurrent), la façon de travailler va changer, et de nouveaux standards risquent de débarquer sous peu!

Vous pouvez retrouver les slides ici :

https://t.co/uRCm7GQOdE

Permettant de découvrir la puissance et la simplicité d’utilisation de cet outil Google

Comment la GCP m'a permis de sauver ma prod chez Mamie de

Sylvain Nieuwlandt

Google met le paquet dans sa Cloud plateforme pour un coût moins élevé qu’un hébergement sur ses propres serveurs.

Certe beaucoup de Cloud provider permettent de mettre beaucoup d’outil en services managés mais peu propose de débugger en mode pas à pas son code en live depuis la console de management et d’activer l’auto-scalabilité de ses outils via une appli mobile.

Talk super intéressant et animé sur ce que produisent les data scientists et comment leur travaux sont exploitables & industrialisables dans la vie d’un projet informatique.

Au final, ils livrent des scripts pythons (ou autre) indéchiffrables avec des tas de CSV et des tas de formules mathématiques avec une documentation très brève sur comment le faire tourner et comment ça marche.

Mais du coup… Le data scientist a été payé, il a produit quelque chose, sa mission est terminée… Il est tout à fait logique que le chef de projet force la main pour que ça part en production.

Mais comment aller en production rapidement avec de tels inputs ?!

Au programme de ce talk :

• Jupyter : l’outil préféré des data scientists

• Comment importer / refactorer le projet Jupyter et le faire tourner avec des VSCode

• Industrialisation & mise en place de pratiques devops sur des projets ML avec Azure Pipelines

Conférence de fin de journée détente et philosophique présentée par un passionné de l’IOT qui nous permet de nous questionner sur ce domaine et ces implémentations.

Après une présentation de l’IOT dans le cadre du questionnement, ce talk nous présente divers d’axes de réflexion autour de l’IOT : est-on dépendant de l’IOT ? Est-ce une bonne chose ? Tout doit il forcément passer par là ? Quels sont les limites ? Et l’éthique dans tout ça ?

Un très bon talk qui nous interroge sur le monde des framework frontend actuel, les choix que nous faisons et leurs répercussions.

Aujourd’hui, commencer un développement front, c’est trop souvent choisir entre les 3 grands frameworks actuels (Angular, React et Vue) et s’enfermer dans leur l'écosystème en y adaptant notre code. On en oublie les problèmes de bases, les fondamentaux, et le plus souvent cela nous pousse à écrire du code qui mélange les couches (UI, accès au DOM, accès aux données, router, state manager...) et qui résiste mal au temps.

Pour choisir le bon écosystème, il faut déjà identifier les besoins utilisateurs (rapidité, accessibilité, ..) et besoins de développement. Il est par exemple important qu’un utilisateur d'un site e-commerce ait un 1er chargement rapide et qu’un webmail ait une navigation rapide au-delà du 1er chargement. Les équipes de développement ont besoin de travailler avec des outils leur permettant de développer rapidement tout en produisant du code propre et réutilisable.

Lors qu'on développe les différentes couches d'une application, il est facile en tant que développeur de rester dans solutions fournis par l'écosystème du framework.

Or il peut exister d'autres solutions plus performantes et qui répondent de manière plus pertinente aux problématiques rencontrées.

Il est important de concevoir l'application en couche et de choisir la solution la plus adaptée (ou de garder une solution actuelle pertinente dans le cas d'une refonte).

Ces choix permettent aussi aux développeurs de garantir l'isolation des couches et ainsi d'avoir une application plus facilement évolutive. Inutile par exemple que le routeur soit présent dans l'UI. Ce couplage sera un frein à de futurs évolution.

Il est donc important de bien identifier les besoins des utilisateurs et des développeurs avant de choisir les solutions proposées par les framework et de ne pas s’enfermer dans dans leur écosystème par confort quitte à remplacer certaines parties par des librairies différentes. Cela permet de réaliser une application évolutive qui n’imposera pas une refonte complète une fois que l'écosystème sera devenu obsolète.