Deuxième et dernier jour de ce Volcamp 2022 ! Un peu plus stressé et un peu moins de talks vus que la veille puisque je passais vers 14h.
Keynote
Par Ludovic Cinquin
Ludovic est le CEO d’OCTO. Il nous a présenté sa vision des 10 prochaines années de la tech. C’était très dense (j’ai pris 7 pages de notes…) et très intéressant. Il s’est posé la question de quelles technologies allaient se généraliser et lesquelles allaient disrupter.
L’ordinateur quantique : “winner takes all”, celui qui va réussir en premier ce défi technique prendra tout le marché. Cette techno pourrait être absolument incroyable mais, aujourd’hui nous ne sommes pas encore certains qu’elle puisse arriver un jour. Clairement disruptif, mais elle ne se généralisera jamais (on n’aura jamais un ordinateur quantique dans notre salon).
L’interface cerveau <-> machine : Elon Musk fait tout ce qu’il peut pour y parvenir. Cette techno a un fort potentiel au niveau de la santé par exemple.
La blockchain : c’est le web 3.0. Hyper hype mais, d’après lui surestimée. Il y a tout de même des cas d’utilisations valables, mais plutôt pour les entreprises, pas tellement pour les particuliers.
Le metavers : pas mal de potentiel pour les jeux video, mais guère plus. C’est encore une techno surestimée pour lui. De plus, la promesse d’“univers global dont on ne sort pas”, n’est pas très excitante.
Le low code/no code : pas hype du tout, mais en revanche très utile. Cette technologie pourrait par exemple, combler le manque de ressource humaine dans le numérique. Ce n’est pas du tout disruptif car les applications ne vont pas changer.
La 5G / IoT : cela rentre dans les mœurs petit à petit. Le potentiel industriel est énorme. En revanche, il y a un vrai coût écologique auquel il faut réfléchir.
Le cloud : déjà très généralisé. Cela permet de déployer de nouveaux projets très rapidement. Ludovic nous dit tout de même qu’avoir son infra dans un cloud sans faire du devops ça n’a pas grand intérêt.
L’intelligence artificielle : potentiellement tout pourrait être disrupté par l’AI, se diffuser partout.
Ensuite, il nous a proposé 3 scénarios possibles d’évolutions de la tech (et du monde) dans les 10 ans.
“World tech companies” : les plus grosses boites (GAFAM ou MAMAA comme on veut) vont créer des ecosystèmes
de plus en plus englobant pour qu’on puisse ne plus sortir de leur plateforme : OS, mobile, paiement, cloud, stockage, réseaux sociaux…
Il est extrêmement difficile maintenant pour un concurrent de rentrer sur ce marché. Éventuellement, des entreprises chinoises
ou des entreprises de techno “physiques” comme Tesla pourraient. En effet, la quantité de data que ces entreprises ont réussi
à accumuler est un avantage compétitif colossal. Les GAFAM vont devenir de plus en plus puissantes, de quoi devenir indépendants ?
“Digital cold war” : les états ont compris la puissance des GAFAM. Les 3 blocs que sont la Chine, les Etats-Unis et l’Union Européenne. vont se livrer une bataille. La Chine a pour elle sa population, son régime centralisé qui leur permet des prises de décisions rapides et radicales… Enfin, elle dispose d’un marché énorme et captif. L’UE possède une régulation qui est un avantage. Les Etats-Unis domine culturellement le monde et ont surtout les GAFAM.
L’interdiction des technologies va devenir une arme : par exemple, Les Etats-Unis ont complétement détruit Huawei en les banissant de l’App Store de Google (en gros).
Les conflits idéologiques vont se multiplier : typiquement la reconnaissance facile que les chinois utilisent massivement pendant que l’UE légifère contre.
Les cyber-menaces vont également s’accentuer.
Dans un tel scénario, la Chine risque d’avoir l’avantage grâce à sa population gigantesque captive. Cela lui fournit une masse de données qui permettra d’avancer beaucoup plus vite sur l’AI (car pour entrainer des algo d’AI, il faut des données). De plus, ils forment chaque année un nombre monstrueux d’ingénieurs. Chaque année, il y a autant d’ingénieurs qui sortent des universités chinoises que d’ingénieurs présents dans toute l’UE. Pour finir, le peu de contraintes légales qu’ils s’imposent leur donne une certaine latitude pour l’expérimentation.
“Digital detox” : Ludovic rappelle que les choses qui façonnent le monde sont souvent inattendues. Ce qui est certain, c’est que les reserves de matières 1ères diminuent et on ne pourra peut-être plus créer de terminaux dans 10 ans. Ce qui amènera un déclin des solutions technologiques et plus de “offline”. L’intermittence des énergies va entrainer des accès aux réseaux erratiques. Il nous invite à se demander à quoi sert la tech et évoque le concept de “right tech” : où a-t-on vraiment besoin de tech ? Où doit-on mettre nos efforts et nos ressources ?
4 critères pour déterminer cela :
- respect de l’objet ?
- respect de l’usage ?
- respect de l’environnement ?
- respect de l’humain ?
Si oui à toutes ces questions, alors c’est une “bonne” techno, sinon on doit pouvoir s’en passer.
Pour conclure, Ludovic pense que ce sera surement un mélange de ces 3 scénarios. Puis, il nous suggère de nous former à l’éco design, de développer notre adaptabilité, d’adopter la “hacker way” (réutiliser, réparer, bricoler nos propres solutions) et surtout : agir en responsabilité !
Mon avis
Keynote très intéressante. C’était à la fois accessible et instructif. Prendre de la hauteur sur les technologies que l’on utilise ou que l’on voit apparaitre fait du bien et donne à réfléchir.
Comment casser sa prod avec des logs ? (En toute efficacité) ?
Par Clément Grégoire, Cédric Charière-Fiedler
Dans ce talk très “pratico-pratique”, Clément et Cédric nous ont donnés pleins de trucs pour bien gérer quelque chose auquel par moment nous ne prettons pas assez attention : nos logs. Ils illustrent leur propos par tout ce qu’il ne faut pas faire 😃. La première chose à faire selon eux est d’être sûr qu’il y a des logs, que leur gestion est bien configurée, qu’on peut y avoir accès et que le/les fichier/s ne sont pas trop lourds (la même chose si les logs sont en DB, il faut pouvoir les requêter). Le logging est différent du tracing. Trop de données peut être contre productif, encore plus si elles ne sont pas pertinentes. Pour ça, ne pas hésiter à faire de la rotation de fichiers, purger régulièrement, etc. De plus, conserver trop de données a également un cout.
Un log utile est un log bien structuré et avec du contexte. Il est interessant également de logger en asynchrone, chose que l’on fait peu.
Quelques problèmes classiques :
- des fichiers de logs trop éclatés : trop de fichiers dans un dossier peut amener à des problèmes au niveau du “file system”.
- un fichier unique : pleins de processus essayent d’écrire en même temps ce qui amène des “race conditions”, des blocages …
- saturer une DB de logs : attention aux lenteurs. Il faut penser à monitorer cette DB voir à la “scaler” si besoin.
- changer le niveau de log : bien valider la valeur du niveau si elle est en variable d’env, et éventuellement il est préférable de “fail fast”
- extrapolation de variable : même les logs sont vulnérables à ce genre d’attaques (voir Log4J), donc soyez vigilent (vérifier, “sanitizer” les inputs).
- logs qui génèrent des logs : (celle-ci est priceless) si vos logs déclenche une requête HTTP, que cette requête plante (peu importe la raison) et que ce plantage génère un log… Je ne vous fais pas un dessin.
- coder une lib de logging maison : attention aux performances, ce n’est pas si trivial de faire ce genre de chose qui sera ensuite appelé partout dans votre app.
Mon avis
J’ai bien apprécié ce talk bien illustré par des cas pratiques. Malheureusement ma prise de note ne rend pas tellement justice à leur présentation qui était assez dense en info.
GitOps, Continuous Delivery et environnements - Comment éviter l’enfer ?!
Par Philippe Morisseau
Une CI/CD c’est top, mais si elle est bien exécutée. Quelques “patterns” ou mauvaises pratiques peuvent rendre ça très pénible. Phillipe nous expose les problèmes les plus communs et propose des solutions et bonnes pratiques pour les éviter.
- configuration complexe
- mis à jour fonctionnelle : facile d’oublier une partie de la conf d’un env
- les hotfix : compliquer de gérer les déploiements des différentes versions sur les différents env
- les variables d’environnement : penser à bien les redéployer en cas de MAJ fonctionnelle
- le renouvellement des certificats : idem, penser à les monitorer et les redployer sur tous les env
- les dépendances de déploiement : particulièrement sur une archi micro service
Pour répondre à ces problèmes, il existe des solutions :
- simplifier l’architecture au maximum (ça simplifie la CI/CD). Il parle de boring architecture, de monolithe vs micro services (l’un et l’autre ont des avantages)
- cycle de vie : chacun a son propre rythme, mais si le front et le back sont souvent déployé ensemble, pourquoi ne pas le faire systématiquement pour simplifier le process ?
- les paramètres : proscrire les paramètres inutiles réduit la complexité
Globalement, il faut toujours trouver le juste milieu : trop complexe ? trop distribué ? trop exigent ?
Gitops (qui ne s’applique pas au monolithe) est un héritage du devops. Il permet de gérer les versions des configurations. Attention à ne pas mettre des secrets, clés, certificats, etc dans le repo git. Pour finir, Philippe evoque les process de déploiement avec notamment le rôle du “configuration manager” et le fait d’avoir du cache de configuration pour être le plus robuste possible.
Mon avis
Très bon talk ! Philippe nous a fait une présentation hyper structuré et donc assez accessible à suivre. De plus, il a fait abstraction des outils pour se focus sur la théorie (mais pas en mode cours magistral, de façon très pratique).
La verticalisation du Bon Coin
Par Simon Maurin
Simon commence par poser le contexte : Le bon coin souhaite verticaliser son activité et se positionner sur des secteurs plus spécialisé comme l’immobilier, la location, les voyages, etc. Tous ces secteurs sont déjà occupés par des spécialistes et donc la concurrence est importante. Le but : réussir à avoir une UX adapté à chaque marché sur une même plateforme :
- des éléments communs
- une structure adaptée
- des spécificités
Ensuite, il parle de l’organisation et de l’architecture logicielle de l’historique (qui était complétement axé généraliste). Comme beaucoup, ils suivaient un modèle inspiré de Spotify avec des tribes, des squads mais aussi des guildes et des chapters. Les équipes ont bien scalé à une époque grâce à cette organisation et un bon découpage par domaine.
En 2020, l’organisation change, avec la création d’équipes verticales pour adresser les spécificités de chaque secteur. À ce moment-là, pleins de problèmes arrivent dus à un enfer d’interdépendances entre les équipes :
- beaucoup de work in progress, ça devient difficile de shipper
- négociations entre équipes tendues
- charge cognitive importante (beaucoup de choses à connaitre)
- ambiguité sur les périmètres
- pourrissement du code
Quand ces problèmes deviennent trop présents, les équipes de LBC décident de tout reprendre pour remettre de l’ordre :
- adapter les missions et avoir une relation client <-> fournisseur en interne
- pousser la collaboration au-dessus des process (swarm, pair programming, …)
- améliorer la developer experience (gros investissement fait pour créer des plateformes aidant l’interfaçage entre équipes)
Mon avis
Super talk, vraiment très intéressant. Simon a énormément appuyé ses propos par des exemples très clairs, ce qui aide réellement à comprendre et à se rendre compte de la pertinence des process qu’ils ont mis en place. Par contre, ce n’était pas évident de tout retranscrire tellement Simon mêlait bien à la fois le business et la technique/les process. Je recommande de regarder ce talk, mon résumé encore une fois ne lui rend pas justice.
La place de la tech dans l’agriculture
Par Mathieu Passenaud
Un talk assez inattendu : parler d’agriculture dans une conférence tech, c’est étonnant. Mathieu nous apprend que oui, il y a beaucoup de tech dans l’agriculture et il a argumenté son propos avec beaucoup d’exemples très concrets et illustrés par des vidéos (pas toujours simple à faire visiblement). Il nous montre notamment des “cockpits” de tracteur, sans volant ni pédale, mais avec des joysticks, des écrans “partout” et des boutons dans tous les sens.
Il nous parle aussi rapidement des métiers concernant les animaux qui là aussi bénéficient d’énormément de tech et d’automatisation.
Je n’ai pas relevé tous les exemples de Mathieu, mais en voici quelques-uns :
- pour respecter les sols et éviter au maximum le tassement, il y a des calculs faits en permanence pour gérer la pression des pneus et répartir le poids de façon uniforme.
- beaucoup de cas d’usages utilisent la reconnaissance d’image : pour détecter les chemins en les cultures, les fruits pas mûres (ça, c’est très impressionnant), séparer ce que l’on veut garder du reste, récolter correctement le grain sans l’abimer (avec adaption en temps réel).
- évidemment, il y a le GPS (RTK) : permet de guider d’énormes engins au centimètre près, d’épandre les engrais ou d’ensemencer en évitant au maximum le recouvrement (ce qui optimise les récoltes et font économiser énormément de ressources).
Il a également parlé de pas mal d’autres choses comme la norme ISOBUS, l’interconnexion entre les outils (par exemple entre une moissonneuse et un camion benne), l’utilisation de la 4G…
Mon avis
Talk sympa pour la culture générale. Comme l’a souligné à plusieurs reprises Mathieu, il n’y a pas tellement de choses “incroyables” techniquement, mais leur usage en pratique est assez fou je trouve.
How I made a powerful cache system using Go
Par Sylvain Combraque
Dernière conf de Volcamp pour moi (j’avoue que j’étais moins performant sur la prise de note…). Sylvain commence en nous parlant de Traefik, un reverse proxy / load balancer qui n’a pas de système de cache. Il faut donc, si on le souhaite, rajouter un outil type Varnish pour ça. Mais il s’est dit que développer en Go un clone de Varnish pourrait être pertinent pour avoir une meilleure (et plus simple) intégration avec Traefik. Il s’est ainsi lancé dans le développement de Souin.
Comment ? En s’appuyant sur les avantages de Go : les goroutines et les channels.
Souin propose déjà les fonctionnalités suivantes :
- config Yaml
- un système de middleware
- request coalescable
- API management
- cache management API
- CDN tag invalidation
Il revient ensuite sur ses diffcultés dans cette aventure, et notamment la principale : le respect des RFCs. Ce n’est pas simple à lire, il y en a de nouvelles régulièrement qu’il faut lire, analyser et implémenter.
Aujourd’hui, Souin est “production ready” (il y a une image docker dispo). Il n’est plus le seul contributeur.
Mon avis
Ce talk était très intéressant : le sujet est cool, le langage top et c’est en plus un REX donc d’autant plus intéressant ! J’ai beaucoup aimé les premiers 3/4, la fin était un peu longue avec des slides montrant un dockerfile ou autre gros bloc de code que je trouve toujours moyennement intéressant à projeter.
Conclusion
Ce Volcamp 2022 était une réussite ! On a déjà hâte d’être à l’année prochaine. Pas mal de talks orientés devops ou dans l’écosystème Java (ce qui n’est pas étonnant au vu du contexte du bassin clermontois. De mon côté, j’étais très content de proposer un talk sur PHP pour ajouter un peu de diversité (merci le commité de selection 😃). L’équipe d’orga était top évidemment. Ils ont joué sur les valeurs locales 😛 : truffade le premier jour, aligot le deuxième, agrémenté de saint-nectaire, etc pour les petites faims…
Vive la tech auvergnate 🎉