MicroFront End chez GLC

Il y a 4 ans …

En 2017, le site Lacentrale.fr est un monolithe à l’ancienne en Php, dans le cadre de refonte fonctionnelle nous avons souhaité pousser le principes de microservice côté Front. Cela faisait plus de 5 ans que le groupe avait mis en pratique les principes de microservice côté back, mais les frontaux restaient sur un monolithe.

Notre objectif et principe stratégique

Nous souhaitions à travers le principe de MicroFrontEnd implémenté par Mozart (nom donné à notre framework qui compose une page HTML avec plusieurs fragments) :

  • Augmenter la résilience des pages du site, jamais d’indisponibilité totale mais (seulement) partielle par fragment
  • Réaliser les features de bout en bout (back+front)
  • Eviter les couplages forts et des dépendances entre fragment (un fragment est une partie d’une page) : augmenter la résilience des sites et le défaut d’un fragment n’entraine pas le défaut de la page
  • Isoler le travail entre Feature Teams : permettre à plusieurs Feature Team de travailler sur une même page (eviter les dépendances inter-feature team, gestion de la base de donnée jusqu’à la l’interface)
  • Casser le monolithe lors de la construction de la page et de penser composant dès la conception du front
  • Gagner en time to market lors de la construction des pages
  • Composer des fragments venant de stack potentiellement avec des technos différentes (permettre ainsi une migration continue sans faire de big bang)

Nous sommes donc partis de la solution de Zalendo(https://www.mosaic9.org/) et apportés des ajustements par rapports à notre besoin. De la est né Mozart chez Groupe LaCentrale.

Principe des microfrontends

  • Etre agnostique de la technologie : Chaque équipe doit pouvoir choisir et mettre à jour sa stack sans avoir à se coordonner avec d’autres équipes.
  • Le code de chaque stack doit être isolé : pas de partage de runtime, les microservices sont buildés indépendamment et packagés de façon isolés. Pas da partage d’état ou de variable globale.
  • Le site est résilient : L’échec d’execution d’un fragment ne doit pas faire échouer les autres.

Concrètement comment ça marche ?

Mozart est un outil de composition front end basé sur l’assemblage de fragment HTML. Les fragments peuvent être issue de toutes stacks et quelques soit la technologie : statics snippets, statics from CDNs, micro front ends, legacy … 

Exemple ici avec la home de Lacentrale.fr, découpée en 7 fragments + 2 fragments techniques invisibles (head, tracking)

  • En fonction d’une url entrante, Mozart trouve le template associé puis le délivre en retour avec l’ensemble des fragments synchrones résolus, le résultat est donc 100% compatible SEO.
  • Le rendu final peut contenir à son tour des ressources privées liées à un fragment (css,js), pour lesquelles Mozart assurera le routage.
  • Le rendu final peut contenir des ressources publiques, servies classiquement par un cdn.
  • Le template permet de configurer chaque fragment indépendamment : timeout du fragments, les fallbacks urls en cas d’erreur, …

Pour résumer Mozart est l’assembleur de la page.

Best practices que nous avons notés au fil des réalisations :

  • Eviter le sur-découpage de fragments
  • Servir les statics CSS/JS via la façade fragment puis CDN si besoin
  • Gérer le cas aux limites (paramètres manquants, gestions des retours HTTP 4xx et 5xx, gestion du responsive en css/js uniquement )
  • Etre compatible SEO (pas de JS pour le contenu, Rewrite Apache)
  • Utiliser les librairies JS partagées pour réduire la taille globale de la page
  • Utiliser du cache (CloudFront basé sur la querty string)
  • Faire des tirs de performance sur les fragments (appel http avec Gatling par exemple) et sur la page complètement assemblée.

En terme de QOS

  • Temps de réponse < 120ms pour 95p
  • Uptime 99,9 % + MEPs sans downtime

Le suivi de la stack est fait via des alarmes Cloudwatch et Kibana

Retrospective 4 ans après :

Apres un peu plus de 4 ans de run, Mozart :

  • n’a subi aucune interruption de service connue
  • n’a eu de maintenance majeure : seulement quelques aspect au démarrage en 2018 et récemment un update d’image
  • encaisse les montées de charge et les attaques par DDOS

Les difficultés rencontrées :

  • des découpages trop micro qui ont complexifiées la page détail d’annonce de la Centrale, on apprend de nos erreurs en évitant ce type de decoupage sur les autres sites où on applique Mozart.
  • complexité de développer en local :
    • un outillage officiel a été mis en place pour le développement local
    • des archetypes de projet de type « fragment »
    • une ébauche pour passer en mode serverless

Le cout de montée en compétence en développement sur ce nouveau système (qui serait la même en choisissant n’importe quel autre framework), avec du recul je pense que c’est la montée en compétence sur serverless qui l’a induit et c’est en fonction des équipes et sur certaines problématiques on a géré directement au sein des features teams, plutôt que voir globalement. C’est ce que nous essayons de fixer notamment avec l’outillage du developpement en local pour Mozart. C’est un point que nous avions sous-estimé au départ.

Apres 4 ans on a souhaité rechallenger la solution en explorant les solutions du marché :

  • NextJS/Module Federation
  • Podium
  • Interface Framework (evolution de Zalando)
  • PuzzleJS

Nous n’avons pas trouvé d’outil qui change ou qui propose des améliorations notables par rapport à Mozart et changer d’outil engendrerait un coût important.

Les résultats de cette etude nous ont aidé à améliorer l’outillage en place et de prendre certaines notions implémentées dans les autres frameworks (bus client, …).

Glossaire :

Résilience : est la capacité d’un système ou d’une architecture à continuer de fonctionner en cas de panne d’un partie du système ou d’un autre système

Microservice : Stack fournissant un service métier léger et indépendant (STREAM et/ou une API RESTful JSON et/ou des fragments)

Fragment : Interface unitaire ou partie d’une page, généralement en Html + CSS + JS.

Micro-frontend : Microservice fournissant des fragments

Agile en seine

I wanted to share here my impressions and feedback about AgileEnSeine. It is just a sum up of my key takeaways from this event.

A few words about why I attended to this event :

I’m always passionate about the agile methods and it’s been three years that I’ve prioritized AWS technical events over agile ones.

Honestly it is really very interesting to go out your head from your daily environment et and look around, it is inspiring, it gives you some ideas and sometimes let’s be honest comforting on your organization.

I’m just going to just talk about a few conferences/workshop I’ve attended

On the first day after the inspiring keynote given by Isaac Getz, i went to a workshop/Serious Game about the prioritization animated by Moïra Degroote. She promotes a system driven by value.

She is really focusing on the value, and to make people realize that the value is more important that give an accurate estimation.

So we started the workshop with a first estimation of the effort and then by the value. She gave us different kinds of estimation : tee-shirt size, ski slope… and she put the focus on the cognitive bias we use during the estimation. We are « programmed » to put an accurate value on tasks where the meaning/value is no longer in the discussion. Her advice is to give more place to the collaboration between business and the development team, and not only be focused on an accurate estimation.

She is energetic and knows to make her audience questioning oneself! She also reminded us what’s matter for our client via the model Kano.

As a manager, I just can’t tell to the product team that we can’t estimate a task, we need to planify the projects and their delivery. But we need to collaborate more and design the product together with the business. She reminded us what is really matter.

The second conference I found interesting was the one talking about the solution focus method animated by Natixis (Jean-Marie Froux Pascal Merin). They gave an insight of being solution focus by a simple way of questioning your team. « Imagine… »

We had an example of a failed delivery, and in the first scene we had a conversation between the project manager and his manager, the project manager enumerated all the things that went wrong, and gave the justification on why things went wrong.

On the second part, the manager just ask :  » Imagine that delivery went well, what would be the situation, the consequences… ». Then we focus on the resources we had already, what we want, what’s working already etc….

It is just a way of thinking and change the mindset.

With this method we don’t focus on the root cause, but we explore in detail the things we want to have and the resources/skills we already have and can use.

Obviously it is not a new approach but the way they presented in this conference was really interesting and I need to keep it in mind every day.

The last one a really enjoyed was the one with Eduardo Alvim. To be honest I’am not a big fan of Safe. But his both talk was really interesting. He talked about the KPI in safe in a first session and in a second one, he shared about all the anti-pattern we shouldn’t use if we go through Safe.

Eduardo is the storyteller, he knows via some simple story how to keep his audience captivated on key topics.

I’m not going to put here all his recommendations and his inputs, but there are pretty obvious :

Have a system thinking perspective to define the metrics

Identify the most appropriate metrics to our context

Generate date, make interpretations and use to improve our system

…

To conclude, these three days were really interesting and would be useful !

Sentry : Frontend Monitoring, pour détecter les problèmes de vos utilisateurs

Frontend … monitoring, quel intérêt ?

Tout d’abord, rappelons rapidement de quoi on parle lorsque l’on aborde le sujet du frontend. Lorsque l’on ouvre son navigateur et que l’on va sur internet, le navigateur va charger du HTML, du CSS, du Javascript, des images, … bref, tout un tas de ressources qui a tendance à se complexifier de plus en plus. Et cela ne va pas s’arranger si l’on prend en compte des frameworks javascript qui sont de très bons outils, mais qui embarquent plus de code et peuvent donc créer plus d’erreurs.

En parlant d’erreur, est-ce que c’est grave ? Cela dépend, cela peut-être totalement invisible pour l’utilisateur, mais cela peut aussi être assez grave. Prenons l’exemple du listing de lacentrale, la majeure partie de la page étant en react, une erreur bloquante peut rendre la page inutilisable.

Evidemment, on peut se dire que l’on va vérifier par nous-mêmes que tout marche bien, malheureusement, une erreur peut être provoquée dans des circonstances particulières que l’on ne pourra pas reproduire. Dans ce contexte, un bon monitoring est indispensable.

Sentry : La sentinelle

Mise en place

Lire la suite →

Déterminer la valeur d’un véhicule pour les prochaines années

Forte de sa longue expérience en matière de cotation des véhicules, La Centrale, propose depuis ce début d’année, en plus de la cote, la valeur prévisionnelle des véhicules dans les prochaines années. Nous vous proposons dans cet article, de partager avec vous la démarche entreprise pour vous proposer ce nouveau service.

La méthodologie mise en jeu

Accumulant de nombreuses données de cotation, au fil des années, et ce depuis la création de la cote La Centrale, ainsi que l’évolution qualitative et des techniques de machine learning, nous pouvons aujourd’hui vous proposer de déterminer la valeur approchée d’un véhicule pour les prochaines années.

Après différents tests des algorithmes disponibles, le choix s’est porté sur le regressor proposé par l’algorithme de type boosting, le Catboost développé par Yandex, accompagné d’une correction exponentielle, qui vient donner un ajustement supplémentaire pour améliorer la précision.

Nous récupérons l’équivalent de 10 années glissantes de cotation qui sont préalablement agrégées à travers différents jobs ETL de type spark/glue. Le modèle les ingère après notamment quelques transformations nécessaires, telles que la transformation des variables catégorielles (marque, modèle, énergie, etc.)

Notre modèle de prédiction de la valeur future a un grain mensuel, et ce pour les dix prochaines années. C’est pour cela que nous le mettons à jour une fois par mois avec de nouvelles données plus fraiches.

Mesurer la performance

Les métriques mesurant la performance d’un modèle de régression sont connus: RMSE, MAE en tête. Comment s’assurer dès lors, que cette performance est valide pour le futur ?

Le premier élément réside dans la manipulation des variables. Au lieu de considérer l’année de la mise en circulation (absolue), nous considérons son âge (relatif) afin de reporter la dynamique « passée » vers le « futur ».

Certaines hypothèses ont été émises et validées, notamment sur l’évolution de cotation d’un véhicule similaire, mais dont les dates de mise en circulation sont différentes. En d’autres termes un véhicule A sortie en 2000, aura la même évolution de cotation au cours du temps, qu’un autre véhicule B sortie en 2002, toutes choses étant égales par ailleurs.

Comme tout algorithme, sa performance peut posséder des biais. Il est important d’analyser la performance de l’algorithme par sous-catégorie (exemple : calcul de MAPE en fonction des énergies: hybride essence etc. ), dans le but de savoir d’une part là où notre algorithme est très performant, et d’autre part où des ajustements sont nécessaires.

Enfin dans une démarche d’amélioration continue, une fois que nous aurons acquis suffisamment de données, nous pourrons également comparer les cotes prédites aux cotes courantes, et faire une analyse rétrospective de la qualité de notre modèle.

Les difficultés : problème du cold-start

Comment gérer les véhicules totalement nouveaux ? Car en effet, l’estimation de la cote future se base sur les évolutions des cotations antérieures. On peut donc légitimement s’interroger sur la façon de valider les cotations proposées pour le futur.

Afin d’évaluer la cote future, notre modèle ne se base pas uniquement sur la marque ou la version d’un véhicule mais sur des données comme la puissance, l’énergie, la catégorie, ou encore le prix neuf, qui sont elles disponibles même lorsque le véhicule n’a pas été encore recensé.  De fait, à défaut de prendre en compte la marque non fournie, l’algorithme prend les autres informations disponibles pour proposer une cotation future.

L’une des techniques basiques, pour évaluer la qualité du modèle sur ce genre de cas,  est de retirer complètement une marque d’un véhicule dans les données d’entrainement et de comparer les résultats lorsque cette marque est présente. Les tests effectués montrent que les différences sont négligeables et nous permettent d’avoir une approximation suffisamment proche.

Exemple de prédiction avec et sans la marque Renault dans le training


Notre modèle est donc capable de proposer une cote future grâce aux informations des autres véhicules présents dans notre dataset. Cette constatation nous apporte une indication forte sur la capacité du modèle à donner des prédictions de cote même pour des véhicules partiellement ‘‘inconnus’’ (marque, modèle, version).

Dernier passage obligatoire : une validation métier. Les experts métier de La Centrale ont pu vérifier la cohérence des évolutions au cas par cas, et confirmer la cohérence des résultats obtenus.

Les limites de la prédiction

Crise économique ou sanitaire sont par définition imprévisibles, elles ne peuvent être anticipées et donc être intégrées à nos modèles de prévisions. L’évolution de la cote future correspond donc à une évolution nominale, une évolution « moyenne » de ce qu’on pourrait attendre d’un véhicule.

De même il parait difficile d’anticiper un engouement soudain pour un véhicule, bien que nos modèles viendront capter cette évolution après un certain temps.

Les aspects techniques

La Centrale a fait le choix d’être full AWS, et d’utiliser pleinement les outils mis à disposition sur la plateforme. Ainsi le choix de sagemaker, framework dédié au machine learning était le plus adéquat pour mettre en place la solution de la cote future.

Architecture simplifiée

Utilisant un algorithme custom, qui n’est pas présent par défaut dans sagemaker, il était ici nécessaire de passer par la case ECR (image custom docker), pour d’une part faire le training du modèle et d’autre part utiliser une machine GPU, pour accélérer le training du modèle.

Sagemaker possède un composant endpoint auquel il est nécessaire d’y accoler une lambda passe-plat afin de l’exposer. L’architecture proposée permet de gérer efficacement la charge d’un million d’appels/jour.

Garde-fou

Tributaire de la qualité des traitements des données effectués en amont, et conscient également de l’ensemble des bugs potentiels pouvant intervenir sur l’ensemble de la chaine, il est important de maitriser ce que le modèle peut servir, c’est pour cela qu’avant chaque publication d’une mise à jour du modèle en production, nous en vérifions sa qualité.

Nous ne republions chaque mois le nouveau modèle que s’il satisfait aux critères de performance souhaités. Ainsi un RMSE trop élevé comparé à ce que l’on a habituellement, sera le signe d’une régression, qu’il est préférable de contrôler avant publication.

Conclusion

Avec cette nouvelle feature, La Centrale propose aux futurs acheteurs et vendeurs un nouvel indicateur pour l’accompagner dans sa prise de décision. Elle leur permet d’anticiper la dévalorisation du véhicule acheté en cas de revente. Les challenges techniques et algorithmiques nous ont poussé à proposer une architecture innovante et une performance au rendez-vous.

Que la force soit avec toi!

Yoda, Jedi, Star Wars, Extraterrestre

Nous avons créé  il y a un an un nouveau concept : les ORDRES à l’instar des Ordres Jedi.

J’ai trouvé un début de definition assez intéressante : l’Ordre Jedi était une ancienne communauté guidée par sa croyance et son observation de la Force et notamment de son côté lumineux. Pour les puristes je vous laisse faire un google pour une définition plus complète, quant à moi je vous donne la définition que nous, chez Groupe La Centrale, nous avons donné :

Un ordre est un sujet/projet transverse qui permet de réunir et constituer une équipe pluridiciplinaire pour travailler ensemble. Je vous fais un feedback sur ce nouveau process.

Qui : il concerne tout le monde des métiers Produit, IT ou marketing :

  • Direction technique : Développeurs, Scrum master, Manager, Ops, Architecte, CTO
  • Direction Produit : PO, UX/UI Designers…
  • Direction marketing communication
  • Direction marketing Btb
  • Analytics
  • SEO
  • COO
  • CPO

Quand

  • On alloue une journée par semaine à chaque personne pour travailler sur son sujet
  • Elle choisit sa journée mais en pratique c’est plus facile à gérer quand tout le monde a le même jour : ex le vendredi est officiellement la journée ordre pour ceux qui participent à un ordre
  • La personne s’organise comme elle souhaite sachant qu’idéalement un weekly meeting est conseillé.
  • 1 fois par mois un comité est mis en place pour donner l’avis sur les ordres proposés et actifs

Quoi

  • Tout sujet transverse
  • Nouveaux sujets innovants
  • Les POC que l’on voudrait lancer (tiens si on teste AWS Timestream avec l’ordre Annonces)
  • Un sujet technique
  • Une façon de faire (comment je dois monitorer mon application)

Comment

  • 1. Je crée un jira dans une file Projet
  • 2. Je constitue mon equipe (je « vends » mon projet et je recrute les gens) : il faut le JEDI (oui comme dans StarWars, le plus fort quoi ou plutôt celui qui porte le sujet) , les membres de son equipe et un facilitateur (un manager IT pour aider et faire un sorte d’assurer le bon fonctionnement et de solutionner les points de blocage)
  • 3. Je soumets mon idée à un comité pluridiciplinaire (Dev, architecte, Po, Manager …) avec les objectifs attendus dans un délai de 3 mois
  • 4. Une fois le projet validé, tous les mois je fais un update auprès de ce comité d’ORDRES pour présenter les avancements
  • 5. On valide chaque mois auprès de ce comité si on continue le sujet ou bien on arrête

Les questions qu’on a eu :

  • En fait c’est pour faire les projets qui ne sont pas priorisés dans notre RoadMap?
  • Ce sont les projets techniques de FE (François Emmanuel PIACENTINI le CTO) ?
  • Ce sont les projets fonctionnels de Jérôme ? (Jérome PONSIN le COO)
  • Je suis obligé de participer ? J’ai déjà les sujets de ma feature-team.

Exemples de sujets que nous avons eu :

  • Feature Flipping 
  • L’ordre JIRA (qui nous permet d’uniformiser nos boards/workflow) 
  • Redesign d’une salle de réunion sans fenêtre qui a été désertée par tout le monde (qui d’ailleurs est devenue une des salles les plus prisées pour les réunions après le redesign)

Resultat de l’ordre du redesign de la salle Caroussel 2.0 :

  • Storybook (mise en place chez GLC sur l’ensemble de nos sites)

Feedback

Effectivement nous avons eu plusieurs problématique et je vous indique ici comment nous les avons solutionnées

  • La participation : « Je suis obligé de participer ? J’ai déjà les sujets de ma feature-team »
    • Expliquer l’intérêt de participer à un ordre (donner du sens) : on contribue à un projet transverse qui nous impacte, qui impacte notre feature team. Soit tu fais partie de ceux qui vont poser les normes, les standards en participant à l’ordre, soit tu vas « juste » les appliquer par la suite lorsque ce sera fait et donc on te donne l’opportunité de donner ton avis et de construire la base qui sert pour tous. Ex : Ordre Yeoman GLC ( définit un ensemble d’artefact prêt à être utilisé pour l’init d’un projet, en gros te simplifier la vie quoi !) et ça devient une norme chez GLC
    • Ça te permet de voir un sujet que tu n’aurais peut-être pas fait car tu n’as pas de connaissance sur le sujet ex : un sujet de Machine learning alors que je suis un developpeur Web
  • Le temps «J’ai pas le temps, j’ai piscine »
    • On te donne le temps : tu crées les Jiras dans ton equipe et lors de la priorisation d’un sprint : il sera dans l’itération (bon la j’avoue que ce n’est pas aussi fluide car au sprint planning il n’y pas l’US et arrivé le vendredi la personne indique qu’il va faire de l’ordre et forcément le PO et le manager demandent mais où est le jira ???? ). Oui cela demande l’organisation ! C’est la qu’intervient le facilitateur et le JEDI !
    • Je ne vous cache pas que sur certains sujets primordiaux j’ai mis des « volontaires » de mes différentes equipes et je leur ai expliqué l’importance de leur participation pour leur feature team.
  • L’avancement : les tickets sont là, mais parfois non priorisés ou n’avancent pas. C’est là qu’intervient le facilitateur pour voir les points de blocages de manière transverse et aider cette equipe d’ordre. Certains ordres avancent sans la présence obligatoire du facilitateur, c’est le JEDI qui le sollicite en cas de besoin.

Voici un KPI sur les 41 projets que nous avons eu : (oui tout n’est pas accepté ! on a eu 5 projets refusés, des idées qui sont restées à l’ordre de proposition et 22 projets en PROD)

Next step :  les projets transverses c’est bien mais on en fait quoi ?

C’est notre next step une fois le projet réalisé et en production, une Feature team récupère la stack et donc du maintien et des évolutions. Cette partie n’est pas encore rodée car les projets restent dans l’état de cloture. Il nous reste donc à continuer à les faire évoluer.

Transférer 1 600 000 comptes utilisateurs sans douleur avec Akka Streams

Comment feriez vous pour transférer 1 600 000 comptes utilisateurs d’un système vers un autre ? Alors que vous n’avez pas de système d’ingestion en masse mais seulement des APIs REST qui prennent un seul compte à la fois. Comment rajouter une nouvelle donnée sur plusieurs millions de documents pour une évolution fonctionnelle ? Chez Groupe La Centrale il nous arrive de devoir faire des scripts de migration, d’import ou de rattrapage de données. Que ce soit parce que l’on souhaite transférer des données d’un système à un autre, parce que l’on doit corriger une donnée quelque part ou parce que l’on a changé un format et que l’on souhaite rendre d’anciens documents compatibles afin de simplifier le code.

Tous ces besoins ont en commun

  • ils n’ont pas forcément vocation à être utilisé très souvent (peut-être seulement une fois)
  • ils peuvent être amenés à devoir manipuler une quantité relativement importante de données
  • ils peuvent causer une charge importante sur les systèmes de production au moment de leur(s) exécution(s)
  • on veut avoir une idée du temps d’exécution et être capable de l’optimiser (sans écraser la prod)

    Parmi les solutions qui existent, j’aimerais vous en présenter l’une d’entre elles que j’aime beaucoup. Il s’agit d’Akka Streams.
Lire la suite →

Automatiser votre cycle de vie Machine Learning

Dans le cadre de la mise en place d’un système de détection de fraude sur le site La Centrale, un système de Machine Learning a été conçu pour entraîner des modèles de détection de fraude.

Comme on aime les choses bien faites chez Groupe La Centrale, on cherche toujours à automatiser les tâches : faire de l’infrastructure as code.

En général, pour automatiser les déploiements, on utilise des services AWS : CloudFormation, Serverless et AWS CDK.

Ce qu’on attend de ce pipeline est de nous permettre de :

  • Récupérer les datasets nécessaires pour nos trainings
  • Préparer ces données pour qu’elles soient exploitables par AWS SageMaker
  • Faire les trainings
  • Extract du meilleur modèle
  • Évaluer les performances de notre modèle

Lire la suite →

feature flipper des app

Feature Flipping : Et si on centralisait l’état de nos micro-services ?

Bonjour à tous !

Chez Groupe LaCentrale, nous prenons très au sérieux la disponibilité et la surveillance de nos applications. Nous développons tous les jours de nouveaux services utilisés par des collaborateurs aux métiers divers de l’entreprise mais aussi par des clients externes comme vous.

C’est pour cela que nous prenons soin au sein de chaque équipe de suivre nos applications à l’aide de dashboards présents dans les open space. Ils avertissent des problèmes techniques survenus en direct et nous alertent par notification dès qu’un problème survient. Chaque équipe est responsable de son périmètre.

Cependant, une erreur applicative n’est pas nécessairement provoqué par l’équipe propriétaire de l’application. Cela peut être la conséquence d’un problème survenu précédemment dans le traitement du logiciel. Par exemple lors d’un appel à un service tiers.

Lire la suite →

En passant

CBM AWS Deepracer

After attending a AWS summit where we saw the first AWS DeepRacer race, we decided we wanted one at CBM!

So the next day or almost, on March 22nd, we ordered a DeepRacer on Amazon. So exciting! We wanted to organize a race during our annual seminar planned in May.

We were told the very first model would  be delivered in April 2019, then delivery was delayed to July. Then no more date. OMG!

So we took matters in our own hands and asked our AWS sales representative to find us a car ready for our end-of-year party, because the seminar was obviously not an option anymore.

We had to be patient, because our sales representative had to activate her internal AWS network in order to find a car, and finally the “Holy Grail” arrived …. Drum roll: early December and our party was to takes place on December 19th.

We established a few rules and guidelines to follow:

  • Train in the DeepRacer simulation environment
  • Build teams with 3 people including 2 OPS/DEV max per team and one non-technical guy/girl (PO, Designer, Sales…)
  • We added a “PimpMyCar” challenge in which each team had to customize the car and then remove it for the next team.
  • Each team would have 6 minutes to perform a full round.

Lire la suite →