Quel est le quotidien de nos consultantes et consultants en projet ? Quels sont les challenges techniques à relever et quelles solutions sont apportées ? Derrière une mise en production réussie, un déploiement ou un Proof of Concept, il y a des consultantes et des consultants, une équipe, des technologies et beaucoup d’expertise et d’intelligence collective ! Cette série d’articles vise à vous dévoiler l’envers du décor, à travers leur témoignage.

Développeur de formation, Rodrigue s’est rapidement intéressé au Cloud, à l’automatisation et au CI/CD. Après être monté en compétence sur la partie Ops dans le Cloud AWS, il a souhaité compléter son parcours en travaillant sur des sujets Data. Rodrigue partage ici son retour d’expérience sur un projet Data où il a mis en oeuvre ses compétences d’Ops, tout en se formant sur la partie Data.

Sur quel sujet travailles-tu actuellement ?

Dans un premier temps, j’ai travaillé sur la mise à disposition d’infrastructure destinée à des data scientists. Plusieurs projets demandaient en effet aux data scientists de travailler sur des calculs et des modèles, et pour ce faire il fallait leur fournir des machines avec tous les outils nécessaires installés, et une infrastructure permettant de travailler dans de bonnes conditions. Comme ce sont des machines volumineuses (avec des services Python comme Jupyter, des librairies Conda), et coûteuses, et donc nous optimisons les coûts en automatisant l’arrêt des machines quand elles ne sont plus nécessaires.

Nous avions tout d’abord besoin de comprendre comment les data scientists travaillaient et quelles étaient les spécificités de leur environnement, afin de comprendre leurs besoins et pouvoir les traduire dans une architecture. Nous avons donc procédé par itérations, tout d’abord avec une machine avec Python, nous avons ensuite ajouté les librairies, puis Jupyter et enfin Jupyter Hub pour partager les notebooks entre différents utilisateurs d’un même projet. Ensuite, nous avons ajusté au fur et à mesure en fonction des besoins des data scientists.

Quelle est la part d’automatisation dans cette mission ?

Par défaut, chez D2SI, nous automatisons tout ! Si le plus souvent nous travaillons avec Terraform, dans ce contexte nous avons utilisé Cloudformation, la politique interne du client privilégiant l’usage des outils AWS quand ils existent. Cloudformation a donc été utilisé pour toute l’infrastructure as code : Réseaux (VPC, subnets, etc), bastions, EC2, RDS, etc, toute la base d’architecture.

Quels outils sont utilisés pour optimiser l’usage des machines et les coûts ?

Nous utilisons des outils AWS comme Instance Scheduler, qui nous permet de programmer des instances les jours de semaine de 9h à 18h, et Ops Automator pour les backups automatiques des instances (des sauvegardes des données sont faites à intervalles réguliers). Si nous gardons la main sur la création des instances, les data scientists peuvent accéder librement aux machines dans les horaires définis sur simple demande.

Sur quoi as-tu travaillé ensuite ?

L’étape suivante était de préparer la construction d’un datalake. L’équipe D2SI chez le client a été renforcée, et ensemble nous avons commencé par une phase de définition des besoins. Comme il s’agit d’un projet à grande échelle (Europe dans un premier temps, puis international), il a été nécessaire de rassembler toutes les parties prenantes du projet pour définir les besoins et mettre en place l’organisation de l’équipe et du projet. Puis nous sommes passé à la traduction des besoins fonctionnels en besoins techniques, et à la définition de l’architecture cible : quels services utiliser, quel type de datalake pour l’ingestion (voir l’article de Damien pour plus de détail sur cette architecture).

Quel était ton rôle au sein de l’équipe Data ?

Je suis arrivé dans l’équipe avec une bonne expérience des infrastructures sur AWS, et l’objectif était que je puisse faire le lien avec la partie Data, sur laquelle j’avais peu de connaissances. J’ai travaillé en peer to peer avec Jonathan, consultant D2SI Data, et chacun a apporté ses compétences et connaissances sur son sujet. Nous avons tous les deux monté en compétence, et nous sommes aujourd’hui au même niveau, sur la Data et sur AWS.

Quelles étaient tes tâches ?

J’ai travaillé sur la mise en place de l’architecture globale, et à la révision de ce qui existait déjà sur AWS : normaliser, documenter, et automatiser. Beaucoup de machines étaient créées via la Console, on ne savait pas quelle machine servait à quoi, nous avons donc dû créer une infrastructure globale en Infrastructure as Code : VPC, bastions, alerting, règles du réseau…

Cette phase de normalisation s’est faite avec les équipes Core IT du client, de façon à pouvoir appliquer les best practices groupe aux comptes AWS (tagging, naming, flux, etc.). Pour comprendre le contexte, nous sommes dans une software factory, donc détachés du core IT du client, et nous utilisons nos propres bastions et nous gérons nos flux. Cependant nous devons suivre certaines règles (sécurité, tagging, naming…) parce que nos projets sont susceptibles de migrer dans les infrastructure core.

En parallèle, tu as continué à travailler sur des sujets de continuous deployment ?

Oui, dans ma précédente mission j’ai acquis de l’expérience sur AWS et Gitlab, un système de versionning. Là, j’ai travaillé avec les équipes du client sur un projet Gitlab runner, sur l’optimisation et le debugging. Puis nous avons développé les Gitlab runners (la partie intégration continue de Gitlab) pour automatiquement exécuter des scripts (tests unitaires, tests fonctionnels par exemple), et ensuite faire du déploiement continu.

Quelle est ta mission aujourd’hui ?

Je travaille toujours sur la partie ingestion du datalake. Nous avons deux side-projects à mettre en place : la datavisualisation des données (mise en production), et un projet PHP. Dans le premier cas, c’est un projet d’automatisation qui utilise Cloudformation, pour mettre en place toute l’architecture avec VPC, BDD, les flux réseaux, sous domaines, etc. Le projet PHP implique des besoins de déploiement dans les infrastructures du client, avec la gestion de différents environnements (pré production, développement, production). Cela signifie que nous devons gérer les projets quand ils sont en lab, mais aussi les migrer sur les environnements de préproduction et production, avec les règles de l’IT core. Nous devons faire un travail d’adaptation, même s’il y a peu de changements au niveau de l’infrastructure. Nous devons par exemple utiliser des EC2 validées et modifiées par l’équipe IT core, utiliser des des connexions automatisées à distance depuis le bastion, et globalement les flux réseaux sont plus restreints et plus complexes à manipuler. Ce type de mission demande aussi des compétences de communication, pour faire aboutir les démarches, comme une demande d’ouverture de flux par exemple.

Qu’est-ce que tu apprécies dans ta mission ?

Je m’intéressais à la partie Data, et je voulais monter en compétence sur le sujet après avoir commencé sur AWS. Je pense que c’est un des sujets qui évoluent très vite, et où le Cloud public a beaucoup à apporter. En effet le Cloud répond bien aux problématiques de mise en place d’une infrastructure data ; il permet d’adresser les problématiques de vélocité des données, d’élasticité de l’infrastructure, et d’optimisation des coûts. Le Cloud permet aux environnements Big data de s’exprimer pleinement, et de monter de belles architectures : on peut utiliser des machines très puissantes, les éteindre et les allumer en fonction des besoins, créer des infrastructures résilientes, ou encore faire du Serverless (voir le pipeline d’ingestion 100% serverless). Apprendre à utiliser pleinement les avantages du Cloud sur ce type d’environnement, à grande échelle, c’est ça qui m’a intéressé dans cette mission. La data semble aujourd’hui indissociable du cloud public, donc en termes d’évolution personnelle il y  un vrai intérêt à faire les deux.

Qu’est-ce que tu as appris sur cette mission ?

J’ai beaucoup progressé sur la partie Data. Ca m’a permis de comprendre les bases et les grands principes, et de les mettre en pratique avec les services AWS dédiés à la data. Cela paraît évident, mais entre la théorie et la pratique, il y a un certain écart : comprendre exactement ce que peuvent apporter les services, savoir ce qu’est la manipulation de data à grande échelle (Hadoop, Horton Works), puis le retranscrire sur AWS avec EMR, Glue, Athena…

J’ai commencé mon apprentissage dans le monde de la data de cette façon, en découvrant chaque logiciel et son usage, Conda, Panda, Jupyter, Jupyter Hub…et comment les mettre en place sur AWS. Discuter avec les data scientists et les data engineers m’a permis d’avoir une vision bas niveau, de voir comment cela se traduit au niveau de l’architecture avant de participer à un projet faisant appel à l’ensemble des services pour gérer un pipeline d’ingestion élastique. J’ai pu également monter en compétence sur la partie Serverless, que j’avais découvert rapidement sur un projet précédent. Aujourd’hui le Serverless est indispensable sur tous nos sujets, et comme  j’étais développeur avant de rejoindre D2SI, cela me permet de renouer avec le développement.

Qu’est-ce que tu apprécies chez D2SI ?

L’éventail de missions est suffisamment large pour pouvoir évoluer comme on le souhaite. Je voulais faire de la data, et j’ai eu la possibilité de le faire, ce qui n’est pas forcément le cas partout. C’est bien d’avoir le choix. J’apprécie aussi le fait qu’on soit une vraie entreprise, pas juste des consultants en mission chez le client. Je passe régulièrement chez D2SI pour y travailler, rencontrer des collègues, échanger, faire un baby foot…il y a une vraie communauté technique avec qui nous avons des moments d’échange pour partager nos expériences et nos découvertes sur des technos.