Comment devenir maître de son multicloud ?

0:09 Je me présente, je suis Youen Chéné, je suis le fondateur de Webvert et je viens vous présenter un meet-up sur le multi-cloud. Mais si on creuse un peu le sujet, ça va aussi parler de migration de cloud, ça va parler de multi-cloud subi dans le cadre de fusion-acquisition. Et pour cela, j'ai mes deux invités qui vont arriver sur scène. Ahmed Zerzeri, qui a accompagné la société Cafeyn dans ces migrations que Marie va nous décrire derrière, de la société. Et Marine qui va nous joindre. En attendant, je vais me présenter du coup, Youen. Vas-y, on va gagner un peu de temps. Merci, Youen, pour la présentation. Bonjour, je me présente, Ahmed Zerderi. Je suis lead architect cloud pour DoIt International en France. Aujourd'hui, notre principal rôle, c'est d'aider nos clients à surmonter tous les challenges concernant leur utilisation du cloud à travers

1:12 pas mal de services, notamment du consulting technique et d'architecture, du training, un support technique en Follow the Sun, donc 24-7, et une panoplie d'outils autour de la gouvernance multi-cloud, FinOps. Voilà, donc nous sommes partenaires revendeurs AWS, GCP et Azure. Et bien sûr, tous nos services sont illimités et surtout gratuits pour nos clients. Je laisse la main à Marine, du coup. Merci Marine. Marine, je vais te présenter avant qu'on attaque les questions. Donc bonjour à tous, je suis Marine Saffar, je suis CTO chez Cafeyn depuis maintenant 8 ans. Donc Cafeyn, vous connaissez peut-être un petit peu plus sous le nom de Le Kiosque, on a changé de marque il y a presque 2 ans maintenant. Donc on distribue des magazines et des journaux sur notre application US, notre application Android et notre site internet. Voilà.

2:14 Merci. Et du coup, on va discuter pendant une bonne demi-heure et à 45, vous pourrez dans le public tous poser vos questions. N'hésitez pas à utiliser justement l'onglet Q&A tout au fur et à mesure. Vous pouvez voter pour les questions et on sélectionnera les meilleures questions à 45. Alors, je vais commencer par une question simple pour débuter le sujet tranquillement. C'est quoi votre définition à chacun des multiclones? Chacun peut entendre des choses un peu différentes derrière. Je te vois sourire Ahmed, vas-y. Je vais peut-être commencer du coup. Alors, il y a plusieurs définitions du multi-cloud. La définition littérale, justement, c'est le déploiement de services applicatifs qui font partie d'un seul et même système et qui a une architecture homogène sur plusieurs... Cloud public, pardon. Donc, en pratique, c'est l'extension de votre réseau privé sur un cloud public avec un autre réseau privé en les interconnectant via de multiples solutions, via interconnection directe ou les tunnels VPN.

3:20 Après, on peut se définir aussi comme utilisateur multi-cloud quand on est justement utilisateur d'un seul cloud, mais que l'architecture est définie de manière que ce soit portable d'un cloud à un autre sans trop d'efforts. Donc attention là, quand je parle de portabilité, ça ne veut pas forcément dire cloud native. Donc on peut très bien être portable sans être forcément dans les conteneurs ou dans les plateformes uniformisées multi-cloud. Pour moi, la vraie définition du multi-cloud, ça consiste en quatre critères. Donc, il y a la portabilité des charges de travail, la portabilité du workflow, la portabilité de la data et la portabilité du trafic. Si on revient dessus rapidement, la portabilité des charges de travail, c'est un truc qui est assez difficilement atteignable, on va dire.

4:33 Parce que quand on écrit ou on développe ces applications, on veut justement tirer parti de ces services cloud natifs. Je prends l'exemple d'une fonction Lambda développée et on veut avoir une gestion des logs pour cette fonction-là. On veut bien tirer profit de l'intégration de CloudWatch sur AWS pour gérer les logs de cette fonction. Donc, ce qui fait que notre charge de travail derrière est un peu moins portable. La portabilité de la data, ça dépend vraiment de la quantité de data qu'on a, parce que les transferts, ça peut coûter cher, ça peut prendre beaucoup de temps. Et justement, c'est de là qu'émane un peu le principe de la gravité data. Il y a des choses sur lesquelles on pourra revenir tout à l'heure. D'accord, ok. Je passe rapidement. Je voudrais juste insister sur le critère le plus important, c'est la portabilité du workflow.

5:33 Et je l'expliquerai peut-être tout à l'heure en plus en détail. Les autres critères sont un peu moins importants. Ok, très bien, merci Ahmed Jossori, parce qu'il y a Tommy Dessine qui commence ses œuvres. Marine, c'est quoi ta définition pour toi? Alors pour moi, c'est peut-être un peu plus simpliste, on va dire, mais c'est tout simplement d'avoir des applications ou des services, qu'ils soient B2C ou B2B2C ou internes, qui sont déployés sur des clouds différents, donc AWS, GCP, Azure. C'est comme ça que je voyais le multi-cloud. Et donc, ça veut dire que ce n'est pas parce qu'on a toutes ces applications, par exemple, sur AWS, mais qu'on est un client Google Workspace, qu'on fait du multi-cloud. Pour moi, c'est vraiment les applications qui sont hébergées sur plusieurs clouds. Pour des raisons soit historiques, soit de besoins spécifiques. De services qui sont sur un cloud et pas sur l'autre. Ça m'enchaîne sur la prochaine question.

6:36 Comment tu es arrivée à du multi-cloud de ton côté, Marine? Alors moi, j'y suis arrivée par des chemins différents. J'y suis arrivée au départ par... Donc quand je suis arrivée chez Cafeyn, ils étaient déjà passés sur le cloud, donc en 2013, donc assez tôt, on va dire. Donc ils étaient déjà passés de OVH vers Azure et on était sur du tout Microsoft. Et quand je suis arrivée, on a commencé à s'étendre un petit peu en dehors de Microsoft. On a commencé par exemple par utiliser, comme beaucoup de monde à l'époque, S3 sur AWS. Et puis en découvrant de plus en plus les services AWS, on a décidé de faire une migration de Azure vers AWS pour des raisons techniques, pour des raisons de coût, pour des raisons, un peu ce que disait Ahmed aussi, de portabilité. On sait tous, ce n'est pas un grand secret que Microsoft a encore, malgré des efforts vraiment considérables, encore des technos propriétaires. Et donc, c'est beaucoup plus difficile d'être cloud agnostique, on va dire, avec Microsoft.

7:36 Donc, on est passé sur AWS. Et ensuite, alors qu'on était en pleine migration d'Azure vers AWS, on a fait l'acquisition de deux autres sociétés. Donc, Blandel et Milibris, pour ne pas les nommer. Et bien sûr, une des sociétés était sur OVH et AWS, et l'autre était sur AWS et GCP. Donc, on s'est retrouvés avec six comptes cloud. Voilà, donc c'est bien parce que ça permet à toutes les équipes d'étendre leurs compétences, mais bien sûr, ce n'est pas vraiment facile à gérer. Et toi Ahmed, avec vos clients, est-ce que tu as d'autres cas qui ont amené des clients à du multi-cloud? On a parlé de fusion et acquisition et tout ça. Aujourd'hui, DoIt a à peu près un peu plus de 1200 clients, il me semble. Et on constate que... Il y a à peu près 80% de nos clients qui sont en mode multi-cloud, utilisateurs de plusieurs clouds. Les raisons derrière...

8:42 Alors, il y a la question de, est-ce qu'on choisit le multi-cloud? Parce que souvent, on ne choisit pas le multi-cloud, c'est le multi-cloud qui nous choisit. Tu as des clients qui l'ont choisi? Il y a des clients qui le choisissent pour certaines raisons. J'ai cité les raisons que je rencontre le plus avec mes clients. Il y a des clients qui choisissent le multi-cloud pour la minimisation des risques. Donc éviter de mettre tous ses oeufs dans le même panier pour éviter les cas de panne globale. Et c'est arrivé dans AWS, dans GCP, d'avoir une panne globale pendant plusieurs heures où le service est interrompu de manière... À l'échelle. Chez le mondial, on va dire. Donc là, c'est vraiment une stratégie d'entreprise. Oui, oui. Il y a une autre raison pour laquelle on peut choisir le multi-cloud, c'est ce qu'on appelle avoir accès au best of breed.

9:43 C'est ne pas se priver d'utiliser les meilleurs services chez chaque cloud provider. Par exemple, certains cloud providers ont une meilleure plateforme AI que d'autres cloud providers. Il y en a qui ont une bonne... meilleure plateforme data. Donc voilà, ne pas se priver d'aller sur ces services-là. Donc ce serait dommage. Une raison qu'a citée Marine, c'est les acquisitions. On arrive vers l'équipe IT d'une entité lui disant, voilà, on a racheté une nouvelle entité avec un nouveau cloud, débrouillez-vous, intégrez-moi tout ça. Donc ça, c'est un cas où on ne choisit pas le multi-cloud, c'est le multi-cloud qui nous choisit. Il y a aussi la raison de ce qu'on appelle le pricing pressure. Des fois, tu as le DAF d'une entreprise qui négocie un deal avec un autre cloud provider pour obtenir des crédits, pour obtenir un discount.

10:53 Et ça fait que derrière, pareil, la même situation. On arrive vers une équipe IT en lui disant, voilà, le nouveau cloud provider, utilisez-le du mieux que vous pouvez. Il y a une dernière raison, mais qui n'est pas très pertinente, c'est d'éviter le vendor locking. J'ai entendu plus d'un CTO dire« je veux zéro vendor locking». Pour moi, ce n'est pas réaliste parce qu'en fait, si on veut être vraiment zéro vendor locking, il faut réduire tous les services de tous les clouds au plus petit dénominateur commun. Et ce serait se priver de l'appeler. plupart des services très utiles de chaque cloud. Donc, notamment se limiter uniquement à la plateforme Kubernetes. Voilà. Donc, la plupart du temps, c'est le multi-cloud qui nous choisit. Est-ce que tu as des cas de clients qui vont aller chercher du gain d'échelle sur les coûts?

11:54 C'est-à-dire que je passe de tel code à tel code parce que je vais gagner tant de millions sur les opérations. Que ça, c'est trop encore émergent ou c'est des cas que tu n'as pas du tout? Il y en a pas mal. Et je pense que la raison pricing pressure et vendor locking sont un peu liées. Parce que qu'est-ce que le vendor locking? Le vendor locking, c'est quand le coût de bouger sur un nouveau cloud est supérieur au coût de rester sur le même cloud, même en tenant compte de la réduction ou des crédits négociés avec le nouveau cloud provider. Donc voilà, dans ces situations-là, ce qu'il faut faire, c'est ce qu'on appelle un TCO, le Total Cost of Ownership, faire une étude, comparer les deux coûts. Et puis, la décision est prise par la suite, par l'organisation, de bouger ou pas sur un nouveau cloud provider. On va maintenant attaquer le plat de résistance.

12:55 Racontez-nous tous les deux votre histoire de qu'est-ce que vous avez fait ensemble entre telle année. telle année, de quoi vous avez migré, vers quoi, les difficultés que vous avez eues, etc. Je vous interromperai à quelques moments pour zoomer sur des pratiques qui peuvent sembler intéressantes. Vas-y, Marine. C'est intéressant parce que vu la situation dans laquelle on s'est retrouvés avec de l'Azur, de AWS et GCP, l'arrivée de DoIt a été vraiment au bon moment. Donc en fait, c'est eux qui nous ont contactés ou qui ont contacté nos services financiers. Et c'est vrai qu'au point de vue facturation, c'était bien sûr un cauchemar pour le département finance de suivre toutes les factures des clouds, notamment... C'est quand même difficile pour un département finance qui n'a pas forcément la connaissance technique de comprendre ce qui se passe dans chaque service. Et ce que DoIt apporte, et ce qui est vraiment intéressant, c'est donc une console unifiée et une facturation unifiée.

14:04 Donc, ils prennent en charge, en fait, on leur... On leur donne accès à nos clouds et ils prennent en charge tout ce qui est facturation sur les clouds. Et ça permet d'avoir une bien meilleure maîtrise pour la finance. Donc ça, c'était le premier aspect. Et le deuxième aspect sur lequel ils nous ont beaucoup aidés, c'est puisqu'on était en train de passer d'Azure vers AWS, ils nous ont aidé à mettre en place le programme d'AWS qui s'appelle MAP. Donc, Migration Acceleration Program, qui permet d'avoir des discounts, en effet, pour tous les workloads qui sont migrés d'Azure vers AWS. Sachant qu'on sait que les providers sont très agressifs en ce moment, c'est ce qu'on vient de dire. C'est un peu comme les forfaits téléphoniques, ça me fait penser en fait. Ils essaient toujours de nous attirer, de vous faire changer de forfait. Là, c'est un peu la même chose. Ils essaient de nous attirer avec des discounts. Et c'est vrai qu'à l'OS, c'est particulièrement... efficace là-dessus. Et donc, on en profite grâce à Douy.

15:06 Alors, pour ma part, je crois que Marine, notre collaboration a commencé en début d'été, c'était au mois de juin ou mai, si je me rappelle bien. Donc c'est assez récent. Comme l'a dit Marine, la première problématique adressée, c'était la partie financière, donc gérer ses coûts multi-cloud. Et justement, DoIt a une panoplie d'outils qui sont axés là-dessus, qui sont... Qui sont accessibles gratuitement pour tous nos clients, notamment la Cloud Management Platform. On a des outils comme le Cloud Analytics, qui est un outil de reporting qui permet d'agréger tous ces coûts de tous ces clouds et avoir une vue centralisée de tout ça. Qui est un outil très flexible et très puissant.

16:11 Donc voilà, ça c'est une première chose. Et la seconde partie, c'est la partie FinOps. Donc on a pas mal de services qui sont intégrés dans la CMP aussi, qui sont axés sur la FinOps, la détection d'anomalies. On a le service FlexSave que je présenterai. peut-être tout à l'heure. Et puis, on a une équipe spécialisée d'architectes qui sont spécialisés dans la FinOps, justement, qui aident les clients à réduire leurs coûts. Et cela de manière proactive, dans le sens où on a des strategic account managers aujourd'hui qui vont analyser par eux-mêmes le bidding du client et vont aller vers eux pour leur proposer de l'optimisation. Et puis, le principal sujet de l'été, c'était justement la migration, la migration MAP, Migration Acceleration Program avec AWS.

17:18 C'est justement ce programme-là qui... Qui offre aux clients AWS une partie de financement pour la migration à travers des crédits. C'est un programme assez fastidieux. Il y a beaucoup de documentation, beaucoup de pas de presse à faire. Et Marine en a fait l'expérience. Nous, on en fait assez souvent, on est partenaire MAP avec AWS. Ce programme-là, il se divise en trois parties. Il y a la première partie ACS qui consiste en la découverte de l'existant du client. Il y a la MRA, Migration Readiness Assessment. Donc, c'est... C'est faire l'assessment de ce qu'on appelle business capability et technical capability pour une éventuelle migration. Et puis, il y a le TCO aussi. Il y a la seconde phase qui est le mobilize où on commence la planification avec les mappings de services, la mise en place de la landing zone.

18:24 Faire des premières expériences de migration, migrer quelques workloads, voir comment ça fonctionne et tout. Ahmed a prononcé le mot de landing zone. Oui. Ça veut dire quoi? Qu'est-ce que c'est? Alors, la landing zone, c'est le setup de l'environnement du client, l'organisation, les accounts sur AWS, donc les différents comptes, avec en tête la... Ce qu'on appelle separation of concerns, j'ai oublié en français, c'est séparation des responsabilités. Donc, on a des comptes qui sont axés sur la sécurité, des comptes pour le billing, des comptes pour la production, des comptes pour le staging. Ça permet de séparer un peu les différentes responsabilités. Et donc on fait ça, enfin on délivre cette prestation là via soit des documents d'architecture au client, soit on travaille sur des plans terraform qui structurent un peu l'organisation.

19:30 initial du client avec un setup initial qui contient une configuration sécurisée, une configuration avec des services d'observabilité en place et ça fait un livrable sur lequel le client peut construire derrière. S'il doit faire un récapitulatif, Marine, vous partiez de quelle clause en début d'année pour aller vers quelle cible? Pardon ? En début d'année, vous étiez sur combien de clouds et vous allez vers quelle cible pour que les gens mesurent bien l'ampleur du chantier? En fait, on part de 4 et on va vers 2. On part de OVH, Azure, AWS et GCP et on va vers AWS et GCP. Et pourquoi WCGCP du coup? Alors c'est à la fois des raisons bien sûr financières, des raisons techniques et des raisons de compétences.

20:32 C'est bien sûr, on n'en a pas encore parlé, mais pour moi le nerf de la guerre c'est quand même les compétences des équipes. Même si... Une fois qu'on a été sur un cloud, ce n'est pas forcément extrêmement difficile de comprendre les concepts de l'autre. Il y a quand même des terminologies différentes, des usages différents, les CLI sont différents. Il y a quand même une grosse montée en compétences. Et du coup, l'idée d'avoir moins de cloud, on ne peut pas se dire qu'il faudrait vraiment des ressources illimitées pour avoir des équipes techniques qui puissent maîtriser tous les clouds à tout moment. Donc, j'ai vu la question dans le chat sur la taille des équipes dev et DevOps de Cafeyn. Donc, en effet, on est 45 en tout, mais côté DevOps, il n'y a que 4 personnes, dont un ingénieur sécurité. Du coup, on ne peut pas demander aux personnes de tout maîtriser à tout moment. C'est ça l'idée vraiment de la réduction pour moi des clouds, c'est l'idée de resserrer les compétences.

21:36 Entre AWS et GCP, c'est vraiment, je trouve, ceux qui sont les plus proches les uns des autres. Comment tu répartis les cas d'usage entre les deux? C'est des cas d'usage différents ou c'est les mêmes? Alors aujourd'hui, on a des choses équivalentes sur les deux, mais quand on aura fusionné les applications Cafeyn, les applications Blendle, on devrait avoir tout ce qui est applicatif sur AWS et garder tout ce qui est data sur Google Cloud. D'accord. Et Amel, plutôt, a parlé de Terraform. Est-ce que vous avez déjà beaucoup d'infrastructures à The Code avant? Ou est-ce que ça fait partie des problématiques que vous adressiez? Non, justement, c'est là où on a beaucoup évolué et on est en train de mettre ça en place. On est en plein en train de mettre ça en place. Et en partie grâce à Blendle parce qu'eux le faisaient déjà, donc ils nous ont montré comment ils faisaient et on a vite vu que c'était très très efficace. Donc c'est ce qu'on est en train de mettre en place. Donc là tu veux dire que la culture de la société a diffusé chez vous?

22:39 Oui, tout à fait. D'ailleurs, c'est l'équipe data qui a commencé à utiliser Terraform. Et ensuite, on est en train de l'intégrer dans l'équipe backend. D'accord. Et comment tu gères les compétences, tout ce qui est conduite du changement quand tu dois demander à des spécialistes au VH Azure de passer? À autre chose. Alors, ça peut être difficile. C'est d'ailleurs, je pense que c'est vraiment le challenge, c'est-à-dire que des personnes qui sont très attachées à leur cloud et qui sont en zone de confort, et notamment des personnes qui ont tout construit eux-mêmes, donc c'est leur bébé, donc on sait comment ça se passe dans ce cas-là, c'est vraiment un vrai exercice de conduite de changement, tout simplement, j'ai envie de dire. Donc, c'est vraiment montrer les avantages d'autres pratiques et les bénéfices qu'on peut trouver. Et c'est vrai que j'ai eu le cas d'une personne qui avait tout monté, toute une infra, en plus en bare metal sur OVH. Donc, non seulement c'était son bébé, mais il avait une maîtrise totale.

23:41 Et il m'a longtemps... Donner comme argument qu'il aurait moins de maîtrise sur GCP, sur des aspects qu'il maîtrisait lui complètement. Donc il a fallu que je fasse un exercice, qu'on fasse des démos, qu'on commence par des petits exemples et puis qu'on mette ça en place. Et maintenant, il est complètement convaincu et il est en train de tout migrer lui-même. Mais c'est vrai que c'est forcément... C'est forcément un voyage. J'ai peur de ce que Tommy Dessine va faire là, mais je suis en train de regarder. Et est-ce que vous avez juste fait du, et là vous pouvez répondre tous les deux, je prends les applications et je les dépose, ce qu'on appelle du different shift, ou est-ce que vous avez adapté les choses dans l'architecture? des migrations techniques pour être un peu plus, on va dire, plus natif dans l'usage des services de chaque clouda. Alors, un peu des deux. Il y a certaines parties qu'on a en effet, toute notre partie API qui a plutôt été du déplacement, on va dire, même si de toute façon,

24:50 déjà quand on est passé d'Azure vers AWS, on a changé la façon dont on déployait, on a changé les outils pour déployer, on a changé le CI-CD. Donc, c'est plutôt ça qu'on a changé que l'architecture. elle-même, on va dire. Et puis, dans d'autres cas, comme le cas de la base de données, là, en passant classiquement d'une base de données monolithique à plusieurs bases de données, donc d'un gros SQL Server à plusieurs post-grès, en découpant les concerns, comme tu disais, en découpant les responsabilités. Et tout à l'heure, tu as parlé de quatre personnes, même pour toute la partie DevOps. Du coup, pour les formes de migration, vous avez eu des renforts de la part de DoIT. Il y a la question d'Evin qui était combien de personnes ont travaillé sur cette migration? Oui, tout à fait. Alors, c'est en moitié interne, en moitié externe. Donc, j'ai spécifiquement pour la partie base de données, parce que c'est vraiment de loin la partie la plus sensible, surtout quand on passe de SQL Server sur Azure à... À WS, là, on a pris un expert des BA externes. Et d'ailleurs, on est encore plein de...

25:52 C'était mon call de juste avant la conférence. On est en plein dedans, ce qui nous permet de faire plein de choses super intéressantes comme du clean, des purges, des politiques de rétention. Bien plus efficace, on va dire. Donc oui, là, il y a un gros travail de clean. Et c'est vrai que changer de clade, quelque part, c'est aussi une super opportunité. Donc nous, on a 13 ans d'existence. Donc c'est vraiment le bon moment. Bien sûr, on aurait dû le faire avant. Mais il est temps, on va dire, de faire tout cet exercice de clean et de mettre en place des politiques plus... Plus efficace sur notre gestion de base de données. Et justement, en parlant de politique, il y a tout ce qui est authentification. Déjà, quand on a un seul cloud, c'est compliqué. Quand on en a plusieurs, ça va être beaucoup plus drôle. Donc, on va voir comment vous faites. Alors, c'est vraiment intéressant. Là, c'est plus entre AWS et GCP qu'il y a des grosses différences, puisque sur GCP, on a des comptes de services, des service accounts, qui étaient extrêmement utilisés.

26:53 Donc, tout était service account, ce qui n'est pas du tout le cas d'Azure et même pas forcément d'AWS. En tout cas, il faut les faire soi-même. Ce n'est pas tout à fait la même logique. Oui, alors bien sûr, gros problème d'authentification. Chaque personne a plusieurs authentifications différentes selon le cloud sur lequel il intervient et selon le service sur lequel il intervient. Donc pareil, c'est une bonne opportunité pour mettre en place des choses. Des choses plus efficaces, plus normées, puisque quand on commence, on n'a pas forcément en tête qu'il va falloir tout normer, plus découper entre services pour pouvoir justement identifier la facturation. Donc, c'est un gros challenge, mais pour moi, ce n'est pas un challenge aussi gros que celui de... De migrer la base de données. Et on a quelques petites choses qui bloquent. J'en ai parlé déjà à Ahmed, mais par exemple, on utilise Google Workspace dans les deux sociétés dans lesquelles on était, Blundell et Cafeyn. Et bien sûr, c'est le même login Google pour Workspace et pour GCP.

27:58 Et du coup, je ne peux pas merger nos deux Google Workspace. Pour en faire qu'un seul à cause de ça. Et parce que chez Cafeyn, on utilise aussi Google Login pour tous nos autres services RH. Voilà, donc il y a des petites problématiques comme ça. D'ailleurs, on va en parler avec Google la semaine prochaine. Mais d'ailleurs, en plus, les projets Google, les environnements, c'est basé en plus sur le même système d'authentification. Donc, c'est-à-dire qu'entre Blendol et vous, c'est des projets Google qui peuvent être différents. Tout à fait, tout à fait. En fait, je me suis rendu compte que c'était mieux dans ce cas-là. Ça s'est mieux passé avec Millibris qui n'utilisait pas du tout Google qu'avec Blendle où on utilisait tous les deux Google. D'accord. Bizarrement. S'ils nous écoutent, ils vont se préparer. Oui, ok. Amel, est-ce que toi, tu vois dans les obstacles que tu as vécu avec Cafeyn ou avec d'autres clients, c'est quoi les obstacles principaux que tu vois sur le terrain? Les quoi, pardon? Les obstacles principaux. Les challenges, oui.

28:58 Les challenges, oui. Pourquoi on t'appelle en vrai? Oui, justement l'authentification c'est une grosse contrainte ici. Il y a des solutions mais c'est spécifique aux contraintes du client. Par exemple pour gérer l'authentification centralisée en mode multi-cloud, il y a la fédération de SSO, les différents cloud providers aussi offrent des services d'intégration, ce qu'on appelle la fédération Active Directory. Si l'organisme est basé sur Active Directory. Donc, c'est des solutions qu'on travaille avec le client au cas par cas. Il y a aussi le challenge de l'observabilité en mode multi-cloud parce que chaque cloud provider a ses outils d'observabilité, ce qui n'est pas forcément pratique quand on est en multi-cloud. Donc, avoir à utiliser Stackdriver sur GCP et...

30:00 CloudWatch sur AWS, ce n'est pas forcément pratique. Du coup, il y a des solutions qui sont en mode SaaS, qui sont multi-cloud. Aujourd'hui, je nomme par exemple Datadog, qui pourrait être une solution viable à ce problème. Il y a le challenge FinOps, donc la gestion de ces coûts multi-cloud, on en a parlé tout à l'heure, il y a pas mal de solutions offertes déjà par les produits DoIt et les équipes DoIt aussi interviennent de manière proactive sur ça. Et puis, il y a le challenge humain, le challenge des compétences. Et tout à l'heure, je parlais de portabilité de workflow et j'ai insisté là-dessus parce que si notre workflow n'est pas portable, ça peut être catastrophique en termes d'impact sur les équipes qui vont intégrer

31:04 le nouveau cloud. Parce que ça va entraîner un coût et une charge de travail énorme pour l'intégration. Si je peux développer un peu le concept de portabilité des workflows, Youen? Vas-y. Oui. Je regardais les bêtises de Tommy Dessines, c'est bon. C'est vrai que c'est un peu distrayant. Donc, qu'est-ce que la portabilité des workflows? La portabilité des workflows, c'est en fait la portabilité de sa chaîne de déploiement, ses normes de sécurité, son réseau. En fait, c'est une tool chain, ce qu'on appelle une chaîne d'outils à construire qui vous permet de déployer vers n'importe quel cloud. C'est ça la portabilité du workflow. Je nomme les services de contrôle de versionning comme GitHub, GitLab.

32:09 Il y a les services CI comme Jenkins, CircleCI. Les package management, par exemple, il y a JFrog Artifactory. Qui est un repository de gestion de package, que ce soit les binaires applicatifs ou les containers. Pour l'anecdote, JFrog, c'est un client, c'est un client Do It, c'est un de nos clients préférés. Il y a le déploiement d'applications, donc tout ce qui est orchestration, notamment l'utilisation de Kubernetes ou autres solutions d'orchestration. L'observabilité centralisée, j'en ai parlé, Datadog, la sécurité et la gestion des secrets. Comme Volt. Donc, toute... Cette chaîne d'outils-là, c'est elle qui permet la portabilité du workflow. Et une fois cette chaîne d'outils-là est en place et qu'elle est bien solide, même si on est sur un seul cloud, on peut se dire multi-cloud.

33:17 Parce que partir sur un autre cloud serait beaucoup moins contraignant en termes de coûts. Donc, ce n'est pas être agnostique. Si on voit tous les derniers articles en ce moment, c'est essayer d'être sans penser à l'analyste du cloud, ça coûte très cher avec peu de valeur ajoutée. Je fais un résumé des articles depuis un an. Là, c'est vraiment avoir le socle d'outillage. Qui permet d'avoir les fonctions support, que c'est là où on les rend un peu plus diagnostiques pour pouvoir gagner du coup sur sa gestion, si on fait la différence. Important, très important, j'ai oublié de noter, le provisioning d'infrastructures. L'infrastructure as code, c'est une brique très importante dans le workflow. Pour être portable justement, donc l'utilisation de Terraform, Ansible et les outils comme ça. Donc tu vas privilégier ces outils-là à des outils comme CloudFormation par exemple chez Amazon. Absolument, ou Deployment Manager chez GCP. Il n'y a pas photo. Oui, garder, ok.

34:19 En plus, garder les... Ok, ça pourrait peut-être être la phase de conclusion. Donc, il nous reste cinq minutes avant les questions. Je voulais vous poser la dernière question qui est la suivante. Dans le public, je sais qu'il y a des studios qui ont eu des fusions acquisitions et qui se retrouvent avec plusieurs clouds, comme la Youen Marine. Quel serait votre conseil principal de tech leader à tech leader? Le premier conseil, c'est de regarder les compétences, je pense. C'est vraiment ce qu'il y a de plus important parce que ça ne sert à rien d'avoir des outils très avancés. Et Dieu sait si, comme Ahmed vient de le dire, il y a des tonnes d'outils pour tous les besoins. si on ne sait pas les utiliser. Du coup, vraiment le plus important des équipes, c'est les compétences. Et ensuite, nous, on a fait un inventaire de tout ce qu'on avait. Et on a essayé de voir les pros. En fait, quand on a fait la fusion, on s'est fait des démos. Chaque équipe a fait une démo de ce qu'ils avaient aux autres, et vraiment en disant les bénéfices et les inconvénients de chaque outil.

35:27 Et ça, ça permet de faire une comparaison. Donc après, on a tout mis sur Confluence, en disant les bénéfices et les avantages et les inconvénients de chaque. Ça permet à chacun de défendre ses arguments et ça permet aussi du transfert de connaissances. Donc ça, c'était vraiment bien. Mais pour moi, le plus important, c'est les compétences. Alors oui, pour ma part, c'est vraiment bien préparé cet aspect-là de portabilité de workflow. J'ai vu pas mal d'équipes IT se dissoudre, partir, juste parce qu'il y a un nouveau cloud qui arrive et que la toolchain n'est pas complète et cette portabilité-là n'est pas assurée. Ça peut être très frustrant miser aussi sur la formation des équipes parce que la formation joue un rôle très important sur la prise du bon choix architectural

36:31 Et puis voilà. Du coup, on va avoir quelques minutes de plus pour prendre des questions. Il y en a pas mal. J'en ai peut-être une ou deux de mon côté aussi. Alors, je vais commencer par le haut. On va parler de data pour commencer. Comment gérer un data, un data lake multi-cloud, surtout en termes de network, de réseau. Et pour ceux qui connaissent un petit peu moins, en gros, le cloud, c'est l'inverse d'une boîte de nuit. Pour entrer, c'est gratuit et pour sortir, c'est payant pour la data. Donc, est-ce que Marine, tu as ce cas-là? Et pareil, je suis tes clients, Ahmed. Moi, je n'ai pas vraiment ce cas-là. Du coup, pour tout ce qui est data, comme tout est au même endroit, je n'ai pas ce cas-là. Pour ma part, je ne suis pas expert data, mais je vais essayer de répondre au mieux. Tous les fournisseurs de services cloud aujourd'hui utilisent des stacks open source pour construire le produit au-dessus.

37:38 Et il y a pas mal de produits. Qui sont très similaires sur les différents clouds. Je nomme Airflow, par exemple, et bien d'autres outils. Après, quand on part sur des systèmes de gestion de base de données, Là, ça devient un peu plus compliqué. Si on utilise, par exemple, BigQuery sur Google Cloud, ça peut nous restreindre derrière. Après, pour la partie réseau, le conseil que je donne toujours aux clients, quand on est en multi-cloud et qu'on a un système où plusieurs briques communiquent, il y a pas mal de trafic entre les deux clouds, il faut rapprocher les régions. Donc, si vous êtes utilisateur AWS et GCP, que vous êtes...

38:40 Je ne sais pas, en Belgique, pour GCP, il faut prendre la région la plus proche pour limiter ce coût de trafic. J'espère avoir répondu à la question. Ça marche. Deuxième question, comment accompagner au mieux son équipe interne à la migration vers le multiclone? Ahmed a parlé de dissolution d'équipe tout à l'heure, donc c'est pour ça. Pour ma part, d'expérience antérieure, il faut vraiment miser sur la formation, donc inclure les équipes dans un process de learning pour qu'ils puissent... Avoir les compétences requises pour intégrer un nouveau cloud provider.

39:44 Et puis, je reviens toujours là-dessus, la portabilité du workflow, c'est un truc qui se prépare à l'avance et c'est très important pour l'intégrité de l'équipe. Moi, je dirais formation et accompagnement. accompagnement externe et interne. Donc, s'il y a des personnes qui ont les compétences en interne, bien sûr, ça, c'est idéal parce que ça permet un accompagnement, on va dire, quotidien. Et surtout, quand il s'agit de former des nouvelles habitudes, c'est là où, voilà, c'est bien d'avoir une formation, mais c'est très bien qu'une formation, ça ne suffit pas. Pour changer les habitudes. Donc, il faut former et ensuite accompagner. D'ailleurs, tu as fait... Ah, vas-y, Ahmed, je poserai. Je rajoute juste un petit truc pour dire que Do It, aujourd'hui, on est un partenaire training GCT, on est partenaire Immersion Day avec AWS, et puis nos prestations de training sont à la demande, et c'est illimité. Donc, nos clients en profitent.

40:47 Est-ce que tu as fait des recrutements dédiés, Marine? Tu as cherché un devos spécialiste au Google ou Amazon pendant la dernière année? Oui, absolument. Et j'en ai un qui arrive en janvier. Donc, ce n'est pas fini. Et d'ailleurs, je reprends la question, combien de temps ça a duré? Je ne peux pas le dire parce que ce n'est pas fini, mais ça sera sûrement au moins un an ou tout, je pense, pour tout faire. Ok, très bien. Et la question d'Evelyne juste avant, c'était quel niveau de... ...À quel était nécessaire pour ce passage de 4 à 2 clones? Est-ce que vous aviez des stacks .NET déjà? Vous étiez sur Azure ou pas du tout? Oui, bien sûr, on était sur .NET. Et on était sur .NET, oui, gros refacto. énorme refacto dans plusieurs endroits. C'est très difficile de dire quel niveau, mais c'est constant, on va dire. C'est de la refacto constante. Et dans le même ordre, est-ce que la même application a été déployée sur les deux clouds ou est-ce que tu as réparti les applications et les services sur les deux clouds?

41:53 Aujourd'hui, c'est réparti. Tu ne vas pas gérer de redondance entre les deux au cas où tu as une région qui saute. Non, non, à part pendant la migration elle-même, bien sûr, où on met tout en place et après on teste, on fait tout en pré-prod, après on teste et on met en prod et on garde un moment, bien sûr, sur le cloud, au cas de rollback, même si je ne sais pas si on peut appeler ça un rollback, si on retourne sur un cloud, mais un cloudback, je ne sais pas. Mais sinon, on n'a pas vraiment de répartition de services sur le cloud. Mais par contre, ça nous est arrivé d'avoir le cache encore sur Azure et l'API sur... Sur AWS, je ne le recommande pas. Oui, c'était une étape de migration, ce n'était pas la cible. Voilà, il ne faut pas rester trop longtemps comme ça. Mais comme on est obligé de faire brique par brique, on se retrouve dans des situations assez périlleuses. Donc, je pense que même en préparant tout, quoi qu'il arrive, c'est toujours plus compliqué que ce qu'on avait en tête.

42:53 Je pense qu'il faut se garder ça. Au coin de la tête, mais bon, c'est un peu pareil pour tout, j'ai envie de dire, mais particulièrement. Non, pour le cloud, parce qu'il y a tellement de couches. Tu as des points à voter là-dessus par rapport à ce que tu vois plus globalement, Amel? Non. Prochaine question. Ça fait le ménage derrière. J'arrive à suivre. Donc, il y a une équipe assez petite pour gérer ça. Est-ce que dans ta stratégie technique, tu as dit on prend tel type de solution, mais pas les solutions très underlock? Oui, c'est toujours l'idée d'éviter ça au maximum, même si, comme disait Ahmed, c'est impossible. En vrai, c'est impossible d'avoir ça à 100%. C'est un rêve de puriste. Et puis, ce n'est pas forcément l'objectif. Il y a un moment, on ne va pas non plus changer de club toutes les cinq minutes, ni tous les ans, de préférence.

43:59 Mais on essaye, c'est plus qu'on essaye de ne pas être tributaire de quelque chose à partir du moment où c'est quelque chose d'un peu innovant et qu'on ne connaît pas bien. Après, il y a des solutions 22 heures qui sont très éprouvées et ce n'est pas très grave en fait. Mais par exemple, on prend quelqu'un qui est chevancité, souvent qu'on a beaucoup le volume de trinité, qui est BigQuery. BigQuery, ça fait partie de ta stratégie, du coup. Oui. Ou c'est ce que tu as traité. Et tout ce qui va être plus serverless, ou le Python, souvent, Il va être assez propriétaire par rapport à la pays. Tu autorises dans ta stratégie que tu expérimentes ou que tu excuses? Oui, oui. Non, non, j'autorise. Je pense que c'est un mythe de ne pas être complètement... D'être un peu plus diagnostique. Et toi, de manière globale, qu'est-ce que tu vois, Ahmed, chez différentes organisations? Pour la partie vendor lock, comme l'a dit Marine, c'est un peu l'avis de tout le monde. C'est impossible d'atteindre le zéro Wonderlock et c'est dommage de se priver de plein de services.

45:10 Tu viens de citer BigQuery. BigQuery, c'est un des produits les plus uniques au monde, on va dire, aujourd'hui. Et Google a la chance de l'avoir. Donc, on ne va pas se priver d'utiliser ce produit-là juste pour éviter le Wonderlock. Alors, tu n'avais pas répondu complètement à la question tout à l'heure, Marine. Une fois que tu avais les personnes de DoIt et ton équipe interne de DevOps, c'est combien de personnes qui ont vraiment travaillé sur la migration? Il y a peut-être aussi eu des développeurs. Oui, bien sûr. Je dirais un peu à temps plein ces quatre personnes. Après, les développeurs forcément interviennent à un moment ou à un autre. Et à chaque fois qu'on a des grosses migrations, ça peut être quasiment toute l'équipe plateforme. Et ça peut être jusqu'à dix personnes qui sont impliquées, mais pas du tout à plein temps. Ce type de migration, c'est vraiment des tâches de fond par rapport au reste de ce qu'on fait, parce qu'on peut très bien faire quelque chose, attendre deux semaines. C'est pas continu, c'est en tâche de fond.

46:15 Mais je dirais en tout une dizaine de personnes. D'accord, ça marche. Qu'est-ce que tu constates partout, Ahmed, ou il y a des équipes vraiment plus grosses, ou des fois c'est juste deux personnes? Ça dépend, ça dépend de l'organisation. Alors juste pour le... Du côté d'Ouit, principalement, c'était deux personnes. Alors, une personne qui a géré tout l'aspect map, donc tout l'aspect documentation, et elle a été aidée par une seconde personne. Donc, la première personne est spécialiste AWS. D'ailleurs, c'est un ancien d'AWS. Qui a géré tout ce process-là. Pour la partie assessment, il n'avait pas beaucoup de connaissances Azure et il fallait faire de la découverte sur Azure. Et donc, on a fait intervenir une seconde personne spécialisée sur Azure, justement, pour couvrir cette partie-là. D'accord, ça marche. Alors, avant-dernière question, je vais laisser du temps pour la dernière parce qu'elle est intéressante d'un point de vue CTO.

47:17 Donc, la avant-dernière question, c'est une question de Pierre Cornic, c'est une question un peu plus technique qui revient à un des sujets qu'on avait tout à l'heure. Donc, avec la portabilité des workflows, vous vous rendez compte de ne pas utiliser des solutions de développement des vendeurs type CodeDeploy. Alors moi je ne connais pas CodeDeploy, c'est l'interaction que tu le reprécises Ahmed. Alors CodeDeploy c'est le service de déploiement AWS il me semble. Moi je suis plutôt spécialisé dans Google. C'est un service AWS, c'est un service de déploiement continu. Je ne sais pas si ça fait de la CI aussi, je crois que oui. Parce que tout à l'heure, tu as regardé. Comment on est de prendre des solutions externes pour gérer ça mieux, avoir peut-être plus de communautés aussi derrière ? Tout à fait, parce que derrière, quand on veut être sur du multi-cloud et avoir un workflow uniforme et portable, utiliser un service de CI...

48:21 Un service de CI spécifique à un vendor, ce serait de se priver de cette flexibilité-là. Les solutions de CI, il y en a des dizaines, elles sont toutes aussi bonnes les unes que les autres, enfin, elles ont des avantages et des inconvénients. Vous avez Circuit CI, GitLab CI, GitHub Actions, Jenkins, Et pour le déploiement aussi, il y a Argo CD, il y a Spinnaker, il y a pas mal de produits qui s'intègrent très bien, surtout au niveau de l'aspect cloud native. Et donc, oui, si on veut vraiment avoir cette portabilité du workflow, après, on a des clients qui disent, moi, je suis avec AWS, je suis content et je serai toujours content avec AWS. Et donc, j'ai besoin d'utiliser CodeDeploy. Donc, dans ces cas-là, la décision est déjà prise.

49:22 Mais oui, le conseil serait de partir sur des solutions qui pourraient s'intégrer. Facilement aux autres clouds. Et dernière question, je ne vais pas pouvoir prendre la dernière, parce que j'ai une petite pression qui est mise sur le côté. Cette migration, cette cible marine, ce n'est pas un budget négligeable, que ce soit en termes de coûts opérationnels de cloud ou en termes de salaire et de paiement de fournisseurs. Comment tu as présenté le budget? Comment vous avez décidé dessus au ComEx? C'est une très, très bonne question. En fait, comme on était vraiment en pleine découverte suite à l'acquisition sur GCP, pour être entièrement honnête, on n'a pas vraiment fait l'exercice jusqu'au bout. On a plutôt parlé en termes de ressources dédiées que même d'aller jusqu'au budget, parce que je n'avais aucune idée au départ de combien de temps ça allait prendre. Mais en fait, ce n'était pas vraiment une option.

50:24 C'était plus, voilà, c'est ingérable d'avoir 4 clouds. Ça va nous coûter plus cher en termes de compétences et d'équipes sur le long terme. Donc oui, bien sûr, elle a un coût, cette migration. Ce qui est sûrement plus élevé au moyen terme, mais sur le long terme, ça n'a pas de sens de rester comme on est avec 4Cloud. Donc, je dois dire, je n'ai pas fait de l'exercice, mais ça paraissait évident à tout le monde. En tout cas, c'est très bien passé que c'est ce qu'il fallait faire. Ok, et j'ai essayé de prendre 30 secondes à Noémie pour que tu puisses prendre la dernière question sur OpenShift. Je ne sais pas si tu as le recul nécessaire pour répondre si tu as fait du OpenShift ou pas. Pourquoi ne pas faire le choix d'une plateforme type OpenShift? On prend une plateforme intermédiaire standard entre guillemets pour réduire les skills des équipes DevOps qui ne connaissent qu'OpenShift et derrière ça déploie partout. Ça revient au diagnostic. Alors justement, il y a OpenShift, il y a Google qui a un produit qui s'appelle Anthos aussi,

51:31 Il y a quelques similarités et quelques différences. C'est des plateformes qui permettent l'uniformisation un peu de son workflow de travail, du déploiement de ses applicatifs sur le cloud. Oui, c'est toujours un bon moyen si, parce qu'OpenShift c'est payant, Antos aussi, si c'est dans le budget de partir là-dessus. Après, il y a une appréhension à avoir au niveau de la montée en compétence sur ces plateformes-là. Ça vient avec sa complexité, c'est des plateformes qui sont riches de features et avec cette richesse-là, il vient une complexité derrière pour tout ce qui est management, pour tout ce qui est prise en main. On va dire. Ok. Très bien. Et du coup, je vous remercie tous les deux. Merci. J'espère que ça a été utile à un maximum de personnes dans tous les auditeurs.

52:36 Et je vais laisser la place à Noémie. Merci à tous. Merci. Au revoir tout le monde. Au revoir. Au revoir.