Team Darwin : les futurologues de l'ingénierie
Ils font de la recherche, implémentent et bricolent : L'équipe Darwin de l'ingénierie de digitec est l'endroit d'où vient l'avenir de la boutique en ligne. Un coup d'œil dans les coulisses de notre site.
"Je n'ai été en vacances que deux semaines", dit l'ingénieur Michal Nebes, "je ne reconnaissais plus mon propre travail."
Ses camarades de l'équipe Darwin rient. Oui, dit l'un d'eux, c'était un sprint prototype pendant lequel Michal était en vacances. Rien n'était plus pareil après.
Team Darwin est l'une des plus jeunes équipes d'ingénierie de Digitec Galaxus AG. Leur mission est de construire la boutique en ligne du futur.
"Nous ne savons pas encore exactement comment cela va se passer", explique Daniel Zürrer, ingénieur junior.
La mission de Darwin est de déterminer, au niveau technologique, comment vous utiliserez digitec et Galaxus dans un avenir proche et comment le site réagira à votre égard. C'est pourquoi les planifications de l'équipe ressemblent plus à des notes. Les méthodes sont discutées, les solutions s'affrontent et, de temps en temps, quelque chose est complètement abandonné.
L'intelligence dans les nuages
Darwin est opérationnel depuis six mois et ne sort pas seulement du lot par sa mission. C'est aussi l'une des rares équipes à ne pas porter le nom d'un film de James Bond. Les équipes Skyfall, Octopussy, Spectre, Goldeneye, Goldfinger et Thunderball travaillent certes juste à côté, mais Darwin avance à grands pas.
Ils s'en tiennent à leurs sprints de deux semaines au travail, toujours pressés par le temps. Ensuite, les cinq ingénieurs back-end, les deux designers d'expérience utilisateur, l'ingénieur frontend, le Product Owner et le chercheur en expérience utilisateur - c'est-à-dire toute l'équipe - se réunissent et discutent. Qu'est-ce qui a fonctionné ? Qu'est-ce qui n'a pas fonctionné ? Où quelque chose pourrait être adapté.
"Nous travaillons avec beaucoup d'inconnues et dans un domaine inexploré", explique Daniel Zürrer.
C'est pourquoi Agile Development est parfaitement adapté à Darwin.
L'agilité est une approche incrémentale et itérative qui consiste à développer un projet par petites étapes. L'état actuel est vérifié après chaque étape et d'éventuels changements de cap peuvent être effectués. Darwin reste ainsi suffisamment flexible pour s'adapter aux développements actuels, aux tendances, aux meilleures pratiques et aux normes de sécurité.
Darwin a commencé à fonctionner en août dernier. L'objectif semble toujours aussi utopique : ne vous montrer que les choses qui vous intéressent dans la boutique. Si votre frère ou votre sœur accède à la boutique, il y a des choses complètement différentes de ce que vous y trouvez. Cela implique beaucoup d'analyse de données et de réflexion abstraite.
Avant que Darwin ne s'attaque à la boutique, les neuf membres de l'équipe se sont attelés à la construction d'un recommander dans le cloud pour les blogs. Une preuve de concept (PoC).
"Nous voulions pousser les événements View dans Google PubSub, d'où ils seraient traités avec Cloud Dataflow et stockés dans BigQuery. Pour le calcul, un job Cloud Dataproc serait ensuite lancé chaque nuit, qui lirait les données de BigQuery, ferait du filtrage collaboratif et stockerait le résultat par client dans Cloud Datastore. Pour extraire les données calculées, il était prévu d'avoir une instance AppEngine qui serait accessible via un point d'accès cloud et qui extrairait les résultats de Datastore. Le tout serait ensuite enregistré de manière centralisée dans Stackdriver", écrit l'équipe sur le site de développement.
Peu après : " La version actuelle, en janvier 2018, est un peu différente. Cloud Dataflow s'est avéré être un peu trop lourd, c'est pourquoi nous avons maintenant une application .net core légère qui s'exécute dans un conteneur Docker et qui traite les messages PubSub et les stocke entre autres dans BigQuery. Nous avons nommé ce composant Héphaïstos, d'après le dieu grec des forgerons, car il forge lui aussi les messages PubSub dans de nouveaux formats. Le calcul fonctionne toujours comme prévu dans Dataproc, mais nous avons ici aussi une image Docker .net core, qui met en place l'environnement pour Dataproc, démarre le travail et ferme l'environnement à la fin.
Pour la lecture des résultats, nous utilisons comme prévu un cloud endpoint. Cela nous facilite la journalisation et la sécurité. Cependant, après plusieurs itérations d'Appengine, le backend a été remplacé par une application ASP.net core, qui fonctionne à son tour sur Kubernetes."
En français, se contenter d'ajouter de la technologie au problème n'est pas assez bon pour Darwin. Il s'agit de trouver une solution aussi performante que possible et aussi légère que possible. En effet, plus une solution est légère, moins elle nécessite de ressources, plus le magasin est rapide et moins il y a de pannes.
Avec le PoC du lecteur de blog, Darwin a mentionné le domaine d'activité principal de son travail : Le cloud. Un stockage de données décentralisé, réparti sur plusieurs systèmes redondants. Plus de stabilité, plus de temps de fonctionnement, tout est mieux. Tout est mieux?
Le problème du cloud
La migration des boutiques, dont Darwin développe l'avenir, présente quelques problèmes. Le document de conception et de développement décrit, outre l'objectif de légèreté du système, d'autres défis auxquels l'équipe est confrontée.
Par-dessus tout, Darwin s'inquiète en ce moment de la Pythie. "La Pythie est plus visible dans le contexte du développement Agile", écrit l'équipe. En effet, la Pythie - nommée d'après l'oracle de Delphes dans les légendes grecques - est le gestionnaire de toutes les recommandations et représente majoritairement un adaptateur pour un datastore.
Le concept de Pythias était simple au départ. En se basant sur les fonctions cloud récemment présentées par Google, Darwin voulait utiliser les applications Node.js sans serveur. En effet, les Functions seraient parfaites pour leurs besoins.
Mais le monde leur a joué un mauvais tour : les Cloud Functions ne peuvent actuellement être hébergées qu'aux États-Unis. Cela signifie que les données commerciales critiques de la juridiction suisse devraient être transférées au-delà des frontières si Pythia est exploitée avec les Cloud Functions. Mais ce n'est pas tout:
- Après quelques recherches, il s'avère que les Functions ne sont pas compatibles avec les Cloud Endpoints
- La latence à l'étranger est tout simplement trop élevée
- L'authentification et la journalisation auraient dû être implémentées par Digitec Galaxus lui-même
En bref, les Cloud Functions sont un no-go.
Mais la mission tient toujours. Une alternative doit être trouvée. La solution actuelle s'appelle AppEngine. AppEngine offre un environnement simple pour héberger des projets logiciels dans des langages allant de Python à Go en passant par Java et C#. Le moteur est donc à mi-chemin entre les fonctions minimales du cloud et les machines virtuelles entières dans le cloud.
Darwin commence le travail : AppEngine en version standard avec Python 2.7, car la version 3 n'est pas supportée, et le développement se heurte à un mur. Les librairies Google Python pour cloud endpoints n'ont tout simplement pas fait bon ménage avec le datastore. "On pourrait penser que les librairies Google seraient compatibles entre elles, mais ce n'est malheureusement pas toujours le cas."
Ce n'est pas tout : à l'incompatibilité s'ajoute la contrainte du Cloud Endpoint Framework, qui prévoit que l'on crée des définitions d'API Swagger à partir du code. Cette création était programmée en Python (par Google) et était terriblement instable.
Après le déploiement, c'est avant le déploiement
"Pas de problème" est néanmoins l'opinion dominante dans l'équipe Darwin. La solution:
- Python 3
- AppEngine Flex
Là, les ingénieurs peuvent définir le point de terminaison en JSON. Il s'ensuit un backend Python. Ou il le serait. Car Python est jugé trop cher. "Exactement, exactement le même prix que Docker", admettent les ingénieurs. Ils travaillent désormais avec C# et Docker.
Encore.
Lors des réunions, on discute déjà de l'évolution. Loin de la technologie. Car là, on se disperse volontiers, dit-on dans l'équipe. Au lieu de cela, on discute de la direction à prendre. Quelles sont les fonctions que vous voulez avoir dans la boutique ? Comment les implémenter de manière légère, rapide et fiable ?
Car après le déploiement, c'est avant le déploiement. Darwin poursuit ses recherches. Car les ingénieurs de l'équipe savent une chose : l'avenir vient de leur bureau.
En parlant de cela, l'équipe Darwin veut que vous sachiez que notre équipe d'ingénierie cherche à se renforcer. Si vous souhaitez rejoindre l'équipe, consultez les postes vacants suivants :
En outre, il existe d'autres postes en ingénierie ici.
Si vous souhaitez en savoir plus sur la façon dont nous développons, consultez ici.
Journaliste. Auteur. Hackers. Je suis un conteur d'histoires à la recherche de limites, de secrets et de tabous. Je documente le monde noir sur blanc. Non pas parce que je peux, mais parce que je ne peux pas m'en empêcher.