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.

Alex a rejoint D2SI après avoir passé trois années au sein du département Sécurité Cloud chez Orange, dans le cadre de sa thèse sur le sujet du multi Cloud. Il s’est spécialisé dans les sujets de virtualisation, et plus particulièrement les conteneurs. A ce sujet, vous pouvez également lire l’interview de Hello Future : « Comment la conteneurisation informatique accélère le développement des applications ». Alex s’intéresse aussi aux sujets Data, et il a contribué à l’ebook Data as a Service.

Peux-tu présenter le projet sur lequel tu travailles ?

J’ai rejoint une petite équipe D2SI chez le client avec pour objectif de monter en compétence et faire du DevOps. L’équipe a pour mission de construire des services communs visant à faciliter l’intégration d’infrastructures Cloud Azure et OpenStack. Nous construisons des services de monitoring à la demande pour superviser les applications existantes et celles qui seront développées.

Mon travail s’est ensuite orienté vers les applications Cloud Native et le Container as a Service, notamment Kubernetes. L’équipe a grandi, et nous avons travaillé sur le déploiement sur Azure de plateformes basées sur du Kubernetes non managé. A ce moment, AKS n’existait pas donc il fallait déployer dans des VM, et c’est ce que nous avons appris à faire. Aujourd’hui nous gérons encore la production de ce projet, en fonctionnant en mode DevOps. Nous construisons et opérons les clusters Kubernetes.

Tu travailles également sur plusieurs providers Cloud ?

Oui, nous avons ensuite commencé à travailler sur Google Cloud Platform, pour y construire des clusters Kubernetes partagés entre applications. Notre objectif est de simplifier le travail des développeurs, et d’optimiser les coûts. Cela permet aux développeurs de bénéficier de Container as a service, de ne pas avoir à gérer Kubernetes, et cela simplifie la portabilité des applications d’un cloud provider à l’autre.

Quelles sont les connaissances et compétences que tu mets en oeuvre dans ce projet ?

Il y a une partie Infrastructure as code “classique”, avec Terraform, et beaucoup d’Ansible pour la configuration et le déploiement des VM et des ressources Cloud. Je code de plus en plus également, en Python et un petit peu en Go, pour instrumenter Kubernetes et rendre le client le plus autonome possible. Par exemple concernant l’allocation de ressources, les développeurs ont le droit de consommer un certain nombre de CPU, et s’ils ont besoin de plus, ils doivent faire une demande manuelle, donc nous allons automatiser ce process.

Mon travail demande aussi de connaître en profondeur l’architecture de Kubernetes et les extensions qu’elle permet, pour customiser le comportement de Kubernetes et créer des ressources à plus haut niveau. Ces objets peuvent représenter des entités métier ou des composants applicatifs, et leur cycle de vie peut être géré directement à l’intérieur de Kubernetes. Par exemple dans le cas d’une application qui met à disposition des bases de données, on crée un objet “base” et un ”opérateur”, lancé sur Kubernetes, qui se charge de faire toutes les actions nécessaires pour instancier cette base, par exemple discuter avec l’API Kubernetes ou du Cloud Provider sous jacent pour la mettre à disposition.

Est-ce que tu as un rôle de développeur ou de devops ?

Je dirais que c’est un rôle de DevOps, dans le sens où la mission première est d’assurer le fonctionnement du service. Ensuite, nous automatisons le plus plus possible. Tout ce qui est susceptible de générer une action manuelle doit être automatisé, et c’est là où nous entrons dans le développement puisque ça implique de coder.

Comment mettez-vous en place le monitoring ?

Nous utilisons Prometheus, qui est un peu différent des outils historiques de monitoring. Prometheus s’occupe de récupérer et stocker dans une base de données les applications et les VM remontent des métriques grâce à un système d’agents. Ces métriques peuvent être ensuite requêtées pour faire une analyse plus fine et détecter des anomalies et créer des alertes. Il ne s’agit plus simplement de savoir si une VM est disponible ou pas, mais d’aller plus en profondeur et de pouvoir détecter en avance des dysfonctionnements, avant que le problème ne se manifeste. On est plus dans une logique d’observabilité, on peut maintenant instrumenter les applications pour comprendre le parcours d’une requête et les incidents. Pour l’instant nous n’en sommes pas encore là, mais l’objectif ultime est de pouvoir facilement corréler des logs et des métriques pour comprendre et répondre aux événements. Nous fournissons aussi à nos utilisateurs des instances de Prometheus que nous manageons, pour qu’ils monitorent leurs applications.

Comment as-tu évolué personnellement ?

J’ai un parcours atypique, j’étais en thèse, entre le monde universitaire et celui de l’entreprise, et ma connaissance du développement et de l’ops était très théorique. Ma thèse portait sur le multi Cloud, et je voulais vérifier par la pratique quels étaient les problèmes d’intégration dans du multi Cloud. J’ai pu constater sur le terrain qu’en effet ces problèmes sont nombreux, et voir comment gérer une migration cloud avec de nombreuses applications issues de périodes très différentes de l’IT (des applications legacy, des applications plus modernes). Avant de travailler sur ce projet, j’avais fait un peu de Terraform, un peu de code (Python), mais je n’avais jamais touché à Ansible, au langage Go ou à Kubernetes. C’était donc une découverte totale, et un challenge, parce qu’il fallait monter en compétence rapidement. Découvrir et maîtriser, utiliser Terraform et Ansible, programmer en Python et en Go, approfondir l’architecture Kubernetes et gérer une plateforme au quotidien, tout cela était très intéressant. Sur le plan technique, j’ai beaucoup appris également sur la partie troubleshooting, par exemple détecter les causes réseau, système ou applicatives d’un problème. Enfin, je n’avais jamais travaillé en mode agile. Stand up meeting, daily meetings, boards et tickets…j’ai vraiment apprécié les apports de cette méthode.

Comment s’est passé ta montée en compétence sur Kubernetes ?

L’équipe a pu bénéficier d’un coaching et de formation sur le sujet mais globalement cela demande pas mal d’investissement personnel. A vrai dire, j’ai trouvé Kubernetes tellement “beau” que j’ai eu envie d’approfondir, même si parfois c’était un casse-tête. Plus tard, D2SI m’a proposé de monter une formation sur Kubernetes, donc je me suis lancé sur le sujet avec un autre consultant. La formation a eu lieu fin 2018, la préparation m’a permis de réfléchir sur les concepts, de capitaliser sur ce que j’avais appris dans mon quotidien. En quelque sorte, c’était comme une nouvelle couche qui est venue sédimenter la connaissance, et ça m’a vraiment poussé à aller de l’avant.

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

Je travaille dans un groupe soudé où il y a bon esprit d’équipe. Il y a aussi une mentalité de l’excellence, nous essayons toujours de faire mieux, de challenger notre niveau. L’ambiance est bonne, et cela nous aide à bien vivre les moments de stress quand on a un problème en production. Globalement, c’est une très bonne expérience humaine. J’apprécie aussi de voir comment fonctionne un projet dans une grande entreprise.

Qu’est-ce que tu aimes chez D2SI ?

Comme au sein de notre équipe chez le client, il y a une bonne ambiance et l’envie de faire les choses le mieux possible. J’apprécie de pouvoir travailler avec les autres consultants, avoir autant d’expériences et de compétences différentes au sein d’une entreprise est très intéressant. C’est un milieu où on se challenge, où on s’entraide et on échange sur nos sujets, comme Kubernetes ou GCP. Ce partage est enrichissant, et quand on rencontre un problème technique, on trouve toujours de l’aide. Si c’était à refaire, je referais les mêmes choix. Cela a été un grand changement pour moi, mais je suis content d’être sorti de ma zone de confort et d’avoir découvert un autre univers.