[{"command":"settings","settings":{"pluralDelimiter":"\u0003","suppressDeprecationErrors":true,"ajaxPageState":{"libraries":"eJzLL0jNi0_KyU_Ojs_NT0nM0c8HCuiCBXTBAro5mUlFiUWVAFJtD_4","theme":"open_theme","theme_token":null},"ajaxTrustedUrl":[],"openModal":{"titleId":"opn-modal-title"},"user":{"uid":0,"permissionsHash":"4ce75e09bb32af0d486cf6a9146d7d94d64135625abbb351edff805078a47c67"}},"merge":true},{"command":"add_css","data":[{"rel":"stylesheet","media":"all","href":"\/sites\/default\/files\/css\/css_upqMR8pm6B1YoMWhN5WMzAfrAkOt_tj9xnGv76nl4Ps.css?delta=0\u0026language=fr\u0026theme=open_theme\u0026include=eJxLzi9K1U8pKi1IzNFLzEqs0ElGEkjJTMzJTwcA8A8NXQ"},{"rel":"stylesheet","media":"all","href":"\/sites\/default\/files\/css\/css__CwdRQc2BoGzOkUac0LXHykTRUXXFCQrIg4pyCkR5Zc.css?delta=1\u0026language=fr\u0026theme=open_theme\u0026include=eJxLzi9K1U8pKi1IzNFLzEqs0ElGEkjJTMzJTwcA8A8NXQ"}]},{"command":"add_js","selector":"body","data":[{"src":"\/sites\/default\/files\/js\/js_rAMus9XbdssolZiLHY8M1KsiysZOp7sW8k2zt9ECOnA.js?scope=footer\u0026delta=0\u0026language=fr\u0026theme=open_theme\u0026include=eJzLL0jNi0_KyU_Ojs_NT0nM0c8HCuiCBXTBAro5mUlFiUWVAFJtD_4"}]},{"command":"openDialog","selector":"#drupal-modal","settings":null,"data":"\n\n\u003Csection class=\u0022opn-modal\u0022\u003E\n  \u003Cdiv class=\u0022opn-modal__content\u0022\u003E\n          \n\n\n\n\n\n  \u003Ch2\n     id=\u0022opn-modal-title\u0022     class=\u0022visually-hidden opn-title opn-title--h2\u0022\n      \u003E\n    Multi-Cloud \u0026amp; On Premise, d\u00e9passons les fronti\u00e8res ! Tirez le meilleur de chacun des mondes\n  \u003C\/h2\u003E\n              \n\n  \u003Cdiv class=\u0022opn-paragraph-img\u0022\u003E\n    \n\n\n\n\n\n\n  \n\n\n      \u003Cdiv class=\u0022opn-video opn-video__youtube-player youtube_player\u0022\n         videoID=\u0022POD8ig2AFHk\u0022\n         height=\u0022100%\u0022\n         width=\u0022100%\u0022\n    \u003E\u003C\/div\u003E\n  \n\n          \n  \u003Cdetails class=\u0022opn-details\u0022\u003E\n    \u003Csummary class=\u0022opn-details__summary\u0022 tabindex=\u00220\u0022\u003ELire la transcription\u003C\/summary\u003E\n    \u003Cp\u003EBonjour et bienvenue \u00e0 tous et \u00e0 toutes. Nous sommes r\u00e9unis aujourd\u0027hui pour la session multicloud et une pr\u00e9misse : d\u00e9passons les fronti\u00e8res, tirons le meilleur de chacun des mondes. \u003C\/p\u003E\n\u003Cp\u003EAlors je vais me pr\u00e9senter. Je m\u0027appelle S\u00e9bastien Thomas, je suis cloud architecte Azure apr\u00e8s avoir un long pass\u00e9 de d\u00e9veloppeur et de software architecte. \u003C\/p\u003E\n\u003Cp\u003EJe suis Francis Besson, je suis cloud solution architecte AWS apr\u00e8s un pass\u00e9 tant en infra et en dev dans un petit peu tous les domaines de l\u0027IT.\u003C\/p\u003E\n\u003Cp\u003EEt donc nous travaillons tous les deux pour la soci\u00e9t\u00e9 Open. Open est une ESN qui compte 4000 collaborateurs r\u00e9partis dans 16 implantations dont 14 en France. Open accompagne ses clients dans leur transformation digitale et IT. Open compte plus de 500 experts et architectes dans les domaines Cloud et DevOps, data IA et modern digital workspace.\u003C\/p\u003E\n\u003Cp\u003ESuite \u00e0 des discussions entre diff\u00e9rents architectes chez Open, nous avons d\u00e9couvert que nous avions tous une exp\u00e9rience ou plusieurs exp\u00e9riences sur diff\u00e9rents clouds, potentiellement aussi sur plusieurs clouds \u00e0 la fois chez certains de nos clients. Et suite \u00e0 ces discussions, nous avons vu que nous pouvions avoir une d\u00e9marche un petit peu diff\u00e9rente de celle qui est classiquement admise, qui est souvent une opposition entre Kubernetes et les solutions PaaS cloud native, donc les services, les plateformes as a service. \u003C\/p\u003E\n\u003Cp\u003EEt donc cette opposition, souvent les clients choisissent l\u0027un ou l\u0027autre, l\u0027une ou l\u0027autre des implantations. Et nous, notre approche c\u0027est plus de choisir ce qui correspond le plus au contexte du projet et peut-\u00eatre aussi de choisir l\u0027une et l\u0027autre des implantations selon le cloud ou le fournisseur.\u003C\/p\u003E\n\u003Cp\u003EDonc dans la d\u00e9marche que nous allons vous pr\u00e9senter aujourd\u0027hui, nous allons donner le choix au projet, faire en sorte que ce soit vraiment le contexte du projet, le besoin de chacun des diff\u00e9rentes solutions n\u00e9cessaires qui fasse que le choix va se porter et permettre de faire en sorte que le code m\u00e9tier puisse \u00eatre d\u00e9ploy\u00e9 sur n\u0027importe quel cloud. On va faire en sorte aussi dans cette d\u00e9marche de permettre d\u0027adapter potentiellement des applications legacy qui en appliquant la d\u00e9marche puissent faire du move to cloud. On va aussi permettre une meilleure r\u00e9partition des comp\u00e9tences, aussi \u00e0 garantir une meilleure gouvernance avec cette d\u00e9marche. \u003C\/p\u003E\n\u003Cp\u003EBienvenue dans le multicloud. Alors pour le reste de la pr\u00e9sentation nous allons consid\u00e9rer que le on-premise, des data centers, sont un cloud comme un autre. Donc on pourra parler aussi bien de AWS, Azure, on va pouvoir citer les cloud providers mais on pourrait aussi bien citer OVH, Scaleway, Ionis et bien d\u0027autres, mais aussi le d\u00e9ploiement on-premise donc dans des data centers ou dans des Kubernetes.\u003C\/p\u003E\n\u003Cp\u003EAlors il y a beaucoup de raisons de multiplier les clouds. \u00c7a peut \u00eatre parce qu\u0027une \u00e9quipe data va avoir un besoin sp\u00e9cifique, \u00e7a peut \u00eatre parce qu\u0027on fait une fusion acquisition d\u0027une soci\u00e9t\u00e9, qu\u0027on se retrouve avec deux tenants diff\u00e9rents, des applications qui vont \u00eatre r\u00e9parties chez diff\u00e9rents cloud providers. On peut avoir les besoins de respecter des conditions contractuelles ou des conditions r\u00e9glementaires comme le RGPD et faire en sorte qu\u0027on puisse d\u00e9ployer les donn\u00e9es le plus proche possible des clients. \u00c7a peut \u00eatre parce que le type de ressource que l\u0027on souhaite doit \u00eatre disponible le plus proche possible de nos clients. \u00c7a peut \u00eatre pour des besoins d\u0027utilisation de clouds souverains ou \u00e7a peut \u00eatre parce que pour des raisons sp\u00e9cifiques on ne veut pas \u00eatre d\u00e9pendant d\u0027un cloud provider.\u003C\/p\u003E\n\u003Cp\u003EQuel que soit le cloud provider, on va avoir des contraintes. On va avoir des besoins de comp\u00e9tences sp\u00e9cifiques parce que chaque cloud provider, m\u00eame s\u0027il impl\u00e9mente des types de ressources qui sont similaires, on va avoir des petites diff\u00e9rences dans l\u0027impl\u00e9mentation, dans la gestion de la s\u00e9curit\u00e9, la gestion des d\u00e9ploiements. Et donc toutes ces petites diff\u00e9rences font qu\u0027on va avoir des besoins d\u0027expertise sp\u00e9cifiques. On va avoir aussi des besoins de comp\u00e9tences pour pouvoir faire du cloud public parce que cloud public veut dire que si on fait une mauvaise manipulation, on va se retrouver \u00e0 exposer des donn\u00e9es ou exposer des ports qui permettront peut-\u00eatre \u00e0 des pirates de pouvoir exfiltrer ces donn\u00e9es.\u003C\/p\u003E\n\u003Cp\u003EOn va avoir aussi, si on a du multicloud, on va avoir besoin d\u0027avoir une vision des bonnes pratiques et une gouvernance qui sera n\u00e9cessairement pour tous les clouds r\u00e9unis. Donc il va falloir contr\u00f4ler que les applications qui sont d\u00e9ploy\u00e9es selon le cloud respectent les bonnes pratiques. On va pouvoir, on va devoir mettre en place un certain nombre de contr\u00f4les pour respecter sur chacun des clouds que ces bonnes pratiques sont bien respect\u00e9es. \u003C\/p\u003E\n\u003Cp\u003EEt enfin, on va avoir des besoins pour chercher des comp\u00e9tences. Si on cherche d\u00e9j\u00e0 une personne qui connaisse fonctionnellement notre m\u00e9tier, qui connaisse la technologie, c\u0027est d\u00e9j\u00e0 compliqu\u00e9 \u00e0 trouver ces personnes-l\u00e0. Si en plus on leur demande de faire du cloud, on cherche des moutons \u00e0 5 pattes. Si on leur demande de faire tout \u00e7a et en plus conna\u00eetre chacun des clouds sur lesquels on va s\u0027implanter, on va pouvoir d\u00e9ployer, en fait on ne cherche plus des moutons \u00e0 5 pattes, on cherche des licornes.\u003C\/p\u003E\n\u003Cp\u003EEt donc le choix Kubernetes ou full native pour nous, c\u0027est pas vraiment en fait un choix qu\u0027il faut faire de fa\u00e7on brutale parce que chacun va avoir des avantages et des inconv\u00e9nients. Par exemple, en cloud natif on va avoir des services manag\u00e9s par le provider et qui vont avoir des niveaux de service garantis. On va avoir un support existant sur du service PaaS, des \u00e9volutions r\u00e9guli\u00e8res et des patchs de s\u00e9curit\u00e9 et une excellente r\u00e9silience par d\u00e9faut, parce que les providers cloud mettent les moyens mat\u00e9riels pour garantir que la solution soit toujours up. Et on a un choix de service complet. N\u00e9anmoins, dans certains cas, la personnalisation peut \u00eatre limit\u00e9e. De plus, \u00e0 fonctionnalit\u00e9 \u00e9quivalente, les services PaaS selon les cloud providers vont \u00eatre l\u00e9g\u00e8rement diff\u00e9rents. Et surtout, il y a toujours, c\u0027est le pendant en fait de ces mises \u00e0 jour r\u00e9guli\u00e8res impos\u00e9es par le provider, et on a toujours un risque de r\u00e9gression lors de ces mises \u00e0 jour qui sont impos\u00e9es.\u003C\/p\u003E\n\u003Cp\u003E\u00c0 c\u00f4t\u00e9 de \u00e7a, Kubernetes, on va avoir d\u0027immenses possibilit\u00e9s de personnalisation. On va avoir une scalabilit\u00e9 ultrafine, on va pouvoir h\u00e9berger n\u0027importe quel conteneur applicatif ou de services type Kafka, type base de donn\u00e9es, type IA. Mais on va avoir et on va avoir une ma\u00eetrise totale de la mise \u00e0 jour et surtout on va retrouver Kubernetes en local chez tous les cloud providers ou m\u00eame en on-premise sur un data center.\u003C\/p\u003E\n\u003Cp\u003EN\u00e9anmoins, les inconv\u00e9nients de Kubernetes, c\u0027est que c\u0027est malgr\u00e9 tout du IaaS dans du IaaS, c\u0027est-\u00e0-dire que la configuration, la r\u00e9silience et la s\u00e9curit\u00e9 sont \u00e0 la charge des \u00e9quipes. C\u0027est-\u00e0-dire qu\u0027au lieu d\u0027utiliser par exemple une base de donn\u00e9es h\u00e9berg\u00e9e dans le cloud, si je d\u00e9cide de mettre mon MySQL ou mon Postgres dans mon Kubernetes, toute cette charge d\u0027administration, tout ce qui est le patching, tout ce qui est la r\u00e9silience et tout \u00e7a, c\u0027est embarqu\u00e9 par l\u0027\u00e9quipe de d\u00e9veloppement. Ce n\u0027est plus g\u00e9r\u00e9 par le cloud. Donc c\u0027est quand m\u00eame quelque chose qui n\u0027est pas anodin. \u003C\/p\u003E\n\u003Cp\u003EEt de plus, le fait de mettre un maximum de services dans un Kubernetes en se disant \u0022j\u0027h\u00e9berge mon appli, mes bases de donn\u00e9es, mon queuing, je vais effectivement pouvoir le porter d\u0027un cloud provider \u00e0 un autre\u0022, mais \u00e7a fait en sorte que mon cluster devient un SPOF (Single Point of Failure). Et donc c\u0027est quand m\u00eame une consid\u00e9ration qu\u0027il faut avoir. Et surtout c\u0027est un \u00e9cosyst\u00e8me donc on risque d\u0027avoir des d\u00e9pendances sur des produits et des \u00e9diteurs associ\u00e9s.\u003C\/p\u003E\n\u003Cp\u003EEt je pourrais continuer. Si on fait du multicloud en ayant fait le choix de Kubernetes, il faut savoir que quel que soit le provider sur lequel on va avoir, on va devoir respecter le rythme de d\u00e9ploiement de Kubernetes qui est une livraison d\u0027une release majeure tous les 3 mois. Avec par exemple la version 1.26 o\u00f9 le d\u00e9marrage de cette version c\u0027est en avril 2023 en version stable et elle se termine \u00e0 peu pr\u00e8s une ann\u00e9e apr\u00e8s, donc on a un rythme d\u0027une release tous les 3 mois avec jusqu\u0027\u00e0 14 mois de support maximum et des risques de breaking change \u00e0 chaque release.\u003C\/p\u003E\n\u003Cp\u003ECe rythme impos\u00e9 \u00e0 nos \u00e9quipes, \u00e7a peut \u00eatre le rythme qui est impos\u00e9 \u00e0 nos \u00e9quipes de d\u00e9veloppement, \u00e0 nos \u00e9quipes d\u0027administration. Ce rythme impos\u00e9 fait qu\u0027il va falloir suivre le rythme et donc appliquer ces mises \u00e0 jour avec les risques de r\u00e9gression que \u00e7a implique, ou alors devoir multiplier les clusters Kubernetes.\u003C\/p\u003E\n\u003Cp\u003EEt donc ce rythme-l\u00e0, si on prend l\u0027impl\u00e9mentation des cloud providers, en fait le support assur\u00e9 par les cloud providers, on a un support des trois derni\u00e8res releases uniquement, les trois derni\u00e8res releases stables. Si on prend ce que \u00e7a implique de n\u0027avoir que les trois derni\u00e8res releases stables, si on est donc en dehors de ces trois derni\u00e8res, on n\u0027a plus de support, on ne b\u00e9n\u00e9ficie plus de niveau de service garanti. Donc on n\u0027est pas certain que la machine puisse d\u00e9marrer et ex\u00e9cuter notre charge de compute. Et on ne pourra pas faire non plus de mise \u00e0 jour vers une version sup\u00e9rieure si on est en dehors du support. Et on ne pourra pas non plus cr\u00e9er d\u0027instances. Donc si notre cluster vient \u00e0 faillir, on ne pourra pas cr\u00e9er une version dans une version qui n\u0027est pas qui ne fait pas partie des versions stables et on ne pourra pas le recr\u00e9er dans le temps.\u003C\/p\u003E\n\u003Cp\u003EDonc le choix entre Kubernetes et le full cloud native pour nous, en fait c\u0027est un choix qui a de toute fa\u00e7on des avantages et des inconv\u00e9nients et il faut permettre au projet de choisir le meilleur compromis pour eux \u00e0 un instant donn\u00e9 par rapport au budget, par rapport aux comp\u00e9tences qui sont disponibles \u00e0 un certain moment. Et peut-\u00eatre qu\u0027il y a une \u00e9quipe d\u0027administration qui est pr\u00eate donc on peut utiliser Kubernetes. Si on n\u0027a pas d\u0027\u00e9quipe d\u0027administration parce qu\u0027on veut se d\u00e9ployer sur un cloud en avance de phase pour pouvoir le tester le temps de mettre en place une \u00e9quipe d\u0027administration pour ce cloud provider en particulier, ce choix n\u0027est pas possible donc il faut leur permettre de quand m\u00eame pouvoir d\u00e9ployer sur ce cloud.\u003C\/p\u003E\n\u003Cp\u003EEt ce choix, il n\u0027est pas unique parce que les services des cloud providers changent r\u00e9guli\u00e8rement. On peut avoir un service qui sera beaucoup plus utile, beaucoup moins co\u00fbteux \u00e0 g\u00e9rer ou qui permet de faire des choses plus int\u00e9ressantes. Et donc ce choix-l\u00e0, il faut le laisser au projet dans le temps parce que dans 6 mois, dans un an, il faut pouvoir rechallenger ce choix et il faut permettre du coup au projet de pouvoir d\u00e9ployer l\u00e0 o\u00f9 il le souhaite. Peut-\u00eatre pour se d\u00e9ployer sur AWS pour un projet data dans le Kubernetes en local et se d\u00e9ployer en m\u00eame temps sur Azure ou sur GCP, il faut leur donner les moyens de d\u00e9ployer leur code m\u00e9tier.\u003C\/p\u003E\n\u003Cp\u003EDonc nous allons vous pr\u00e9senter une d\u00e9marche qui permet de coller \u00e0 tous ces besoins-l\u00e0 et Francis va vous pr\u00e9senter donc le fruit de ces tests.\u003C\/p\u003E\n\u003Cp\u003EDonc l\u0027exemple que je vais vous pr\u00e9senter, en fait on va impliquer peu de services volontairement sur les diff\u00e9rents clouds. L\u0027objectif c\u0027est pas de voir la richesse fonctionnelle de l\u0027application qu\u0027on pr\u00e9sente mais c\u0027est de plut\u00f4t d\u0027avoir en t\u00eate la d\u00e9marche qu\u0027on a voulu mettre en \u0153uvre et c\u0027est une d\u00e9marche que nous, on verrait bien g\u00e9n\u00e9raliser.\u003C\/p\u003E\n\u003Cp\u003EDonc nous sommes dans le cas par exemple d\u0027un d\u00e9veloppement sur une architecture hexagonale. Donc quand on a un d\u00e9veloppement en architecture hexagonale, on va avoir une premi\u00e8re partie qui est le code m\u00e9tier qui est isol\u00e9 en fait de toute la partie interaction avec l\u0027\u00e9cosyst\u00e8me dans lequel se trouve l\u0027appli. Ce code m\u00e9tier, c\u0027est celui qui contient la business value, qui va \u00eatre complexe fonctionnellement parce que c\u0027est lui qui impl\u00e9mente les r\u00e8gles m\u00e9tier de l\u0027entreprise et il va avoir une \u00e9volution fonctionnelle fr\u00e9quente. C\u0027est l\u0027agilit\u00e9, on a des sprints, on impl\u00e9mente des features, c\u0027est la vraie vie.\u003C\/p\u003E\n\u003Cp\u003EOn va avoir une partie infra as code, c\u0027est la partie qui va impl\u00e9menter les services qui vont h\u00e9berger l\u0027application. Donc j\u0027ai pris un exemple simple : S3 et storage container qui sont deux services similaires. Et entre nos deux couches en archi hexagonale, on va voir ce qu\u0027on appelle un adaptateur. C\u0027est port\u00e9 par le nom, c\u0027est ce qui va adapter l\u0027application \u00e0 son contexte infrastructure.\u003C\/p\u003E\n\u003Cp\u003ESi on regarde un petit peu plus loin, on voit que cet adaptateur en fait c\u0027est quelque chose de simple fonctionnellement mais c\u0027est tr\u00e8s technique au niveau IT, parce que dans cet adaptateur on va retrouver une partie du code que j\u0027ai appel\u00e9, que nous avons appel\u00e9 SDK cloud. C\u0027est ce code-l\u00e0 en fait qui va impl\u00e9menter toute la couche technique d\u0027interaction avec les services d\u00e9ploy\u00e9s. C\u0027est ce code-l\u00e0 qui va impl\u00e9menter la biblioth\u00e8que de l\u0027hyperscaler. Par exemple, je dois, mon appli doit utiliser du S3, elle est en Python, bah \u00e7a va \u00eatre Boto3. On va, c\u0027est l\u00e0 o\u00f9 on va impl\u00e9menter Boto3 pour les interactions.\u003C\/p\u003E\n\u003Cp\u003EN\u00e9anmoins, ce qu\u0027on remarque, c\u0027est que c\u0027est ce code-l\u00e0 avec l\u0027infrastructure, ce code qui impl\u00e9mente la s\u00e9curit\u00e9. C\u0027est-\u00e0-dire que si mon application doit interagir avec une base de donn\u00e9es, c\u0027est ce code-l\u00e0 qui va \u00eatre responsable, selon l\u0027archi qui a \u00e9t\u00e9 d\u00e9ploy\u00e9e par exemple, d\u0027aller lire un secret, de r\u00e9cup\u00e9rer les login, de se connecter \u00e0 la base ou d\u0027y aller de mani\u00e8re transparente parce que l\u0027infra as code a mis en place les r\u00f4les. Et surtout c\u0027est un code qui est en fait intimement li\u00e9 avec la couche IAC. En fonction de la fa\u00e7on dont j\u0027ai s\u00e9curis\u00e9 par exemple mon bucket S3 ou ma base de donn\u00e9es, je ne vais pas me connecter forc\u00e9ment de la m\u00eame fa\u00e7on.\u003C\/p\u003E\n\u003Cp\u003EEt je rajouterais que dans cette configuration-l\u00e0, si on containerise l\u0027application et qu\u0027on la d\u00e9ploie sur un autre provider, on reste d\u00e9pendant du S3 du storage. Donc on reste d\u00e9pendant du cloud provider qu\u0027on a utilis\u00e9 dans notre partie adaptateur. Donc il y a quand m\u00eame un travail \u00e0 faire pour rendre notre application agnostique.\u003C\/p\u003E\n\u003Cp\u003ED\u0027un autre point de vue, si je prends cette architecture hexagonale, on va voir qu\u0027on va avoir des dev m\u00e9tiers qui vont faire l\u0027application, le c\u00f4t\u00e9 vraiment applicatif, et des dev IT qui vont faire le c\u00f4t\u00e9 infra as code. Ici je parle volontairement de r\u00f4le, c\u0027est en fonction de la taille des \u00e9quipes. On va avoir des personnes qui vont \u00eatre peut-\u00eatre d\u00e9di\u00e9es sur un r\u00f4le particulier comme on peut avoir des gens qui vont cumuler les r\u00f4les si c\u0027est une petite \u00e9quipe pour une petite application, on voit que l\u0027adaptateur en fait il est cod\u00e9 par les deux. C\u0027est le d\u00e9veloppeur qui va faire l\u0027API, qui va donner les pistes pour le SDK cloud. C\u0027est le d\u00e9veloppeur m\u00e9tier qui va consommer en fait ce SDK cloud. Et surtout, on se rend compte qu\u0027on en arrive \u00e0 avoir un besoin de ressources o\u00f9 on va cumuler un petit peu les deux r\u00f4les : d\u00e9veloppeur m\u00e9tier et d\u00e9veloppeur infrastructure. Et on retombe en fait sur ce que disait S\u00e9bastien un petit peu plus t\u00f4t : on en est \u00e0 rechercher des moutons \u00e0 cinq pattes, c\u0027est-\u00e0-dire des gens qui ont une expertise sur un langage, qui ont une expertise sur un m\u00e9tier, mais qui ont en m\u00eame temps les comp\u00e9tences au niveau de l\u0027infrastructure, de la s\u00e9curit\u00e9 pour faire les choses proprement.\u003C\/p\u003E\n\u003Cp\u003EEt c\u0027est l\u00e0 o\u00f9 on arrive \u00e0 une \u00e9quipe \u00e9largie o\u00f9 on va avoir des r\u00f4les qui ne vont pas suivre le m\u00eame cycle de d\u00e9ploiement. Moi, je sais que pour \u00eatre intervenu en mission en tant que d\u00e9veloppeur infrastructure sur un d\u00e9ploiement applicatif dans le formalisme agile, je me trouvais - vous avez peut-\u00eatre v\u00e9cu des choses similaires de votre c\u00f4t\u00e9 - je me retrouvais sur des c\u00e9r\u00e9monies, embarqu\u00e9 dans des c\u00e9r\u00e9monies o\u00f9 on me demandait de me positionner sur des choix m\u00e9tiers pour lesquels je n\u0027\u00e9tais pas pertinent parce que ce n\u0027\u00e9tait pas mon objectif de mission. Donc voil\u00e0, \u00e7a faisait une situation que je trouve qui n\u0027est pas tr\u00e8s confortable au niveau de l\u0027agilit\u00e9.\u003C\/p\u003E\n\u003Cp\u003EEt donc dans ce cadre-l\u00e0, le fait de mieux r\u00e9partir les comp\u00e9tences devient une obligation. Alors beaucoup de soci\u00e9t\u00e9s mettent en place des Cloud Center of Excellence. \u00c7a peut \u00eatre aussi en charge de la DSI, \u00e7a peut \u00eatre aussi la premi\u00e8re \u00e9quipe qui va d\u00e9ployer dans un cloud, qui va mettre \u00e0 disposition des autres \u00e9quipes, des autres projets, l\u0027adaptateur qui va bien mais qui respecte les bonnes pratiques.\u003C\/p\u003E\n\u003Cp\u003EApr\u00e8s, si on regarde l\u00e0, on raisonnait sur une application. Si on regarde sur un ensemble d\u0027applications au sein d\u0027une entreprise, beaucoup de soci\u00e9t\u00e9s font des \u0022move to cloud\u0022 avec des centaines d\u0027applications \u00e0 bouger. Si on garde toujours cette approche, admettons j\u0027ai trois applications qui vont consommer un bucket S3, donc je vais avoir trois SDK cloud qui vont \u00eatre d\u00e9velopp\u00e9s chacun dans leur coin. Et avec pour cons\u00e9quence, en fait, le m\u00eame travail est fait plusieurs fois. C\u0027est le fait de coder ces interactions S3. On a une impl\u00e9mentation h\u00e9t\u00e9rog\u00e8ne.\u003C\/p\u003E\n\u003Cp\u003EC\u0027est alors un cas d\u0027\u00e9cole qui ne se fait plus maintenant, mais \u00e7a sera une base de donn\u00e9es typiquement. Sur mes centaines d\u0027applications, je vais peut-\u00eatre en retrouver une avec mon login et mot de passe en clair dans le code. On va avoir des mont\u00e9es de version longues. Par exemple, je suis sur AWS, mon SDK cloud je l\u0027ai cod\u00e9 en Boto 3. Donc j\u0027ai mes centaines d\u0027applications qui utilisent Boto 3 par exemple pour interagir avec AWS. AWS sort Boto 4 avec correction de failles de s\u00e9curit\u00e9, nouvelles fonctionnalit\u00e9s et tout \u00e7a. Eh bien, \u00e7a veut dire que mes centaines d\u0027applications vont devoir repasser, vont devoir recoder, vont devoir retester, vont peut-\u00eatre devoir int\u00e9grer de nouvelles choses parce qu\u0027il y a des choses d\u00e9pr\u00e9ci\u00e9es entre le 4 et le 3.\u003C\/p\u003E\n\u003Cp\u003EEt l\u00e0 o\u00f9 c\u0027est probl\u00e9matique, c\u0027est que c\u0027est ce fameux code en fait qui va garantir toutes les bonnes pratiques en termes de s\u00e9curit\u00e9 et d\u0027observabilit\u00e9. Alors il faut aussi savoir que cette multiplication des impl\u00e9mentations, cette complexit\u00e9 dans l\u0027impl\u00e9mentation et dans la multiplicit\u00e9 fait que \u00e7a devient du cloud legacy, du code historique qui est difficile \u00e0 maintenir, \u00e0 faire \u00e9voluer et qui du coup reste et devient le boulet de l\u0027entreprise, qui a saut\u00e9 une mise \u00e0 jour par faute de temps.\u003C\/p\u003E\n\u003Cp\u003EDu coup, cela devient encore plus compliqu\u00e9 \u00e0 mettre \u00e0 jour et ralentit probablement la totalit\u00e9 des \u00e9quipes. Donc en fait, nos r\u00e9flexions nous ont amen\u00e9s \u00e0 penser une approche un petit peu plus moderne de l\u0027IT que ce qu\u0027on a constat\u00e9 actuellement. C\u0027est en fait, plut\u00f4t que chaque \u00e9quipe fasse sa couche basse, on va avoir un socle commun. Dans ce socle commun, on va retrouver, je prends l\u0027exemple avec Terraform, on va faire un module Terraform qui va impl\u00e9menter par service, qui va impl\u00e9menter vraiment proprement mon service cloud ou on-premise. Pour nous, un data center est un cloud comme un autre, qui va l\u0027impl\u00e9menter proprement avec tous les \u00e9l\u00e9ments de s\u00e9curit\u00e9, qui va \u00eatre conforme \u00e0 la politique de l\u0027entreprise.\u003C\/p\u003E\n\u003Cp\u003E\u00c0 \u00e7a, on va avoir associ\u00e9 une portion de code qui va \u00eatre d\u00e9di\u00e9e vraiment aux interactions avec le service et qui est tr\u00e8s intimement li\u00e9e en fait \u00e0 ce qu\u0027on a fait en Terraform. Et en fait, c\u0027est ce code-l\u00e0 qui va \u00eatre consomm\u00e9 par les adaptateurs. L\u0027int\u00e9r\u00eat de cette approche, c\u0027est qu\u0027on peut tr\u00e8s bien dire que ce code-l\u00e0, ce socle-l\u00e0 peut \u00eatre d\u00e9velopp\u00e9 par les r\u00f4les d\u00e9veloppeur IT, avec l\u0027int\u00e9r\u00eat que c\u0027est une \u00e9quipe qui va \u00eatre en contact direct avec les contraintes IT de l\u0027entreprise. Parce que les DSI, en fait les services IT, mettent en place des solutions qui sont globales, qui vont couvrir toutes les applications de la bo\u00eete et qui vont imposer des normes de fait au niveau du fonctionnement, ne serait-ce que pour la s\u00e9curit\u00e9, le protocole d\u0027authentification, tout ce qui va \u00eatre monitoring, tout ce qui va \u00eatre la landing zone, les int\u00e9grations landing zone. Et donc ce sont des contraintes qui peuvent \u00eatre embarqu\u00e9es par ces r\u00f4les de dev qui vont les impl\u00e9menter dans les modules, permettant ainsi aux applications qui s\u0027appuient dessus d\u0027atterrir proprement dans l\u0027\u00e9cosyst\u00e8me cloud de l\u0027entreprise.\u003C\/p\u003E\n\u003Cp\u003EAlors l\u0027int\u00e9r\u00eat de \u00e7a, c\u0027est que du coup, les \u00e9quipes de dev m\u00e9tier se centrent vraiment sur ce qui est l\u0027objectif absolu de l\u0027agilit\u00e9, c\u0027est la business value. J\u0027ajoute aussi que sur un aspect, ce qu\u0027on voit de plus en plus maintenant dans les grandes soci\u00e9t\u00e9s, c\u0027est que d\u00e8s qu\u0027une application doit \u00eatre pos\u00e9e dans le cloud, il y a toute une \u00e9tape de validation au niveau de la cybers\u00e9curit\u00e9. \u00c7a peut \u00eatre un acc\u00e9l\u00e9rateur de cette validation puisque si une application est b\u00e2tie sur un ensemble de briques qu\u0027on va retrouver dans notre socle, qui ont d\u00e9j\u00e0 \u00e9t\u00e9 valid\u00e9es par la cybers\u00e9curit\u00e9, de fait cette validation est acc\u00e9l\u00e9r\u00e9e.\u003C\/p\u003E\n\u003Cp\u003EDonc cette approche de pouvoir faire en sorte de d\u00e9velopper en transverse des assets, effectivement \u00e7a va donner de la rapidit\u00e9, de la flexibilit\u00e9 au projet. Il n\u0027y aura pas besoin que le projet devienne un expert sur un cloud en particulier pour pouvoir d\u00e9ployer sur ce cloud. \u00c7a va \u00eatre un travail qui va \u00eatre partag\u00e9 entre l\u0027expert du cloud, qui mettra \u00e0 disposition un asset particulier, et le code m\u00e9tier. L\u0027\u00e9quipe projet se concentrera sur le code m\u00e9tier qui pourra \u00eatre d\u00e9ploy\u00e9 partout.\u003C\/p\u003E\n\u003Cp\u003EDu coup, pour le moment, on n\u0027a pas vraiment parl\u00e9 de multicloud, mais en fait dans notre r\u00e9flexion, on s\u0027est rendu compte que prendre une approche multicloud, quelque part \u00e7a revient \u00e0 prendre, modulariser le code et retrouver les best practices de l\u0027informatique. Le fait de factoriser tout dans des modules sp\u00e9cifiques, c\u0027est ce que font les d\u00e9veloppeurs usuellement. Et en fait, on se rend compte que les services cloud fonctionnellement, ils sont similaires. On va prendre S3, Storage Container, on va prendre AWS Lambda, Azure Function, RDS ou Azure Database. On se rend compte qu\u0027il est tout \u00e0 fait possible de d\u00e9finir des param\u00e8tres d\u0027infrastructure as code qui vont \u00eatre communs, que ce soit l\u0027un ou l\u0027autre.\u003C\/p\u003E\n\u003Cp\u003ESi je suis sur le S3 object storage, \u00e7a va \u00eatre le nom qu\u0027on va lui donner, le nom court du high-level design ou le nom complet quand on d\u00e9ploie le service, \u00e7a va \u00eatre des ACL et \u00e7a va \u00eatre par exemple les notifications que ce service est en capacit\u00e9 d\u0027\u00e9mettre. Au niveau d\u0027une fonction, elle a un nom et elle a un runtime. Au niveau d\u0027une base de donn\u00e9es, elle a un nom, elle a un engine. \u00c0 c\u00f4t\u00e9 de \u00e7a, on va avoir des interfaces qui vont \u00eatre communes c\u00f4t\u00e9 code. Par exemple, que ce soit S3 ou object storage, on n\u0027a pas 150 000 fonctions qu\u0027on utilise. On va lire, on va \u00e9crire, on va renommer, on va supprimer, on va lister les objets. Une fonction, on l\u0027invoque. Une base de donn\u00e9es, on r\u00e9cup\u00e8re la connexion pour passer nos SQL derri\u00e8re.\u003C\/p\u003E\n\u003Cp\u003EEt enfin, on peut trouver et faire un travail de r\u00e9flexion pour trouver des classes communes, un nommage commun pour toutes ces classes, pour les remettre un petit peu dans le m\u00eame cadre. On va dire que par exemple un S3 et Storage Container, c\u0027est un object storage. Une fonction ou basiquement une database. Alors cette approche-l\u00e0, elle n\u0027est pas... enfin, on n\u0027est pas les premiers \u00e0 la faire. On peut citer Dapr, qui a d\u00e9j\u00e0 cette approche de pouvoir modulariser les diff\u00e9rents types d\u0027objets et de pouvoir aussi bien attaquer de l\u0027EventHub, du Kafka que des services bus, et en changeant la configuration, faire en sorte que notre application soit totalement agnostique.\u003C\/p\u003E\n\u003Cp\u003ELe but de se dire que d\u00e9j\u00e0 de se mettre dans cette approche-l\u00e0, c\u0027est de peut-\u00eatre choisir Dapr ou d\u0027impl\u00e9menter quelque chose qui correspond v\u00e9ritablement \u00e0 votre contexte si vous avez des besoins soit techniques, soit pour impl\u00e9menter les concepts de s\u00e9curit\u00e9 ou de s\u00e9gr\u00e9gation r\u00e9seau dont vous avez besoin sp\u00e9cifiquement pour votre soci\u00e9t\u00e9. Vous pouvez aussi impl\u00e9menter pour vos besoins des types d\u0027objets et donc les adaptateurs qui correspondent pour un cloud en particulier.\u003C\/p\u003E\n\u003Cp\u003E\u00c0 c\u00f4t\u00e9 de \u00e7a, donc on va pouvoir, partant de ce constat, on va pouvoir au niveau du code par exemple faire un ensemble d\u0027objets. C\u0027est-\u00e0-dire que l\u0027id\u00e9e, l\u00e0 je pars de S3, au niveau de mon code quand je vais coder mon SDK, je vais avoir une classe, on va dire abstraite ou une interface, tout d\u00e9pend, c\u0027est un choix d\u0027impl\u00e9mentation. Je vais d\u00e9finir une interface que je vais appeler \u0022object\u0022 qui va impl\u00e9menter toutes ces fonctions et je vais pouvoir la d\u00e9cliner en fait par service, par hyperscaler ou on-premise.\u003C\/p\u003E\n\u003Cp\u003EElles vont \u00eatre, et cette interface-l\u00e0, elle va \u00eatre unique pour tous les clouds. Elle va \u00eatre \u00e9troitement li\u00e9e au module Terraform correspondant et elle va impl\u00e9menter les m\u00e9thodes en utilisant le SDK du cloud provider. \u00c0 cette classe-l\u00e0, on va rajouter ce qu\u0027on appelle une couche d\u0027abstraction qui va \u00eatre initialis\u00e9e d\u0027apr\u00e8s l\u0027ensemble des services. C\u0027est-\u00e0-dire que je vais impl\u00e9menter ma fonction Lambda, dans ma fonction Lambda je vais lui passer au format JSON en variable d\u0027environnement la liste par exemple des services AWS auxquels elle doit acc\u00e9der, telle base RDS, tel S3, et cette couche va s\u0027initialiser et va cr\u00e9er des instances de type object storage qu\u0027on a en bas et elle va proposer par exemple, un acc\u00e8s simplifi\u00e9 en mode dictionnaire avec le logical name. Le logical name, \u00e7a va \u00eatre ce que je vais avoir dans mon high level design, c\u0027est par exemple mon bucket CRM dans le high level design versus le nom d\u00e9ploy\u00e9 : nom d\u0027environnement, un ID, CRM et tout \u00e7a.\u003C\/p\u003E\n\u003Cp\u003EAlors bien s\u00fbr, cette approche en fait est \u00e0 adapter dans votre contexte selon les cloud providers. Le but n\u0027est pas d\u0027impl\u00e9menter imm\u00e9diatement pour tous les cloud providers l\u0027adaptateur pour le S3, pour l\u0027event hub ou pour la base de donn\u00e9es, mais de le faire au fur et \u00e0 mesure selon vos comp\u00e9tences disponibles, selon les besoins, et de vous permettre en fait de gagner en agilit\u00e9 assez rapidement.\u003C\/p\u003E\n\u003Cp\u003E\u00c0 c\u00f4t\u00e9 de \u00e7a, je vais avoir un travail similaire au niveau de mon Terraform. C\u0027est-\u00e0-dire que je vais fonctionner par module, je vais impl\u00e9menter mes modules par provider, par service, et je vais appliquer un pattern. Par exemple, dans mes inputs de modules, je vais d\u00e9finir tout ce qui va \u00eatre les ACL. Dans mes outputs de modules, je vais d\u00e9finir tous les composants d\u0027identit\u00e9 type, les r\u00f4les, plus des r\u00e9f\u00e9rences \u00e0 mon service. Et je vais cr\u00e9er ce qu\u0027on appelle un module de relation o\u00f9, par exemple, je vais cr\u00e9er ma Lambda, je vais cr\u00e9er mon bucket S3, et entre les deux, je vais cr\u00e9er mon module Terraform. Je vais appeler mon module Terraform en passant l\u0027identit\u00e9 de ma Lambda, l\u0027identit\u00e9 de mon S3, le niveau d\u0027acc\u00e8s que je veux, et c\u0027est en fait ce module Terraform qui va faire l\u0027attachement au r\u00f4le.\u003C\/p\u003E\n\u003Cp\u003ECette approche-l\u00e0, en fait, avec des modules qui sont cod\u00e9s en \u00e9tant extr\u00eamement attentifs \u00e0 tout ce qui va \u00eatre least privilege, s\u00e9curit\u00e9, tout \u00e7a, ce sont ces modules-l\u00e0 qui vont permettre de garantir que chaque service sera correctement d\u00e9ploy\u00e9 en respectant tous les aspects de s\u00e9curit\u00e9. C\u0027est en \u00e9tant particuli\u00e8rement aussi attentif aux politiques de tag, c\u0027est l\u00e0 o\u00f9 je vais pouvoir mettre en \u0153uvre tout ce qui va \u00eatre FinOps, Green IT, parce que c\u0027est syst\u00e9matis\u00e9. \u00c7a va \u00eatre syst\u00e9matis\u00e9 au niveau de mes services, \u00e7a va \u00eatre syst\u00e9matis\u00e9 au niveau de ma s\u00e9curit\u00e9, \u00e7a va \u00eatre syst\u00e9matis\u00e9 au niveau de mon r\u00e9seau.\u003C\/p\u003E\n\u003Cp\u003EDonc en fait, le fait d\u0027avoir des interfaces uniques et simplifi\u00e9es, dans notre esprit, c\u0027est cette vision-l\u00e0 qui est tr\u00e8s orient\u00e9e vision d\u00e9veloppeur m\u00e9tier. On va vraiment raisonner au niveau high level design, donc avec un ensemble de modules. Et avec la souplesse que Terraform... on l\u0027a impl\u00e9ment\u00e9 en Terraform, mais \u00e7a serait tout \u00e0 fait faisable en CDK ou autrement. Dans le mod\u00e8le, dans la d\u00e9mo que nous avons cod\u00e9e, en fait ce qui va d\u00e9terminer mon infrastructure, c\u0027est un fichier YAML o\u00f9 je vais d\u00e9crire les services que je veux et les relations que je veux leur donner.\u003C\/p\u003E\n\u003Cp\u003EDonc \u00e0 titre d\u0027exemple, je vais d\u00e9clarer... Je suis d\u00e9sol\u00e9, je parle beaucoup d\u0027AWS, c\u0027est... Donc j\u0027ai le... je vais avoir mon object storage qui va \u00eatre un bucket S3. Le d\u00e9veloppeur, par exemple dans la section du fichier, va dire \u0022object storage\u0022, va dire \u0022j\u0027ai un object storage, son logical name c\u0027est CRM\u0022. Par contre, Terraform va le d\u00e9ployer avec le nom complet en respectant les conventions de nommage de l\u0027entreprise. Il va dire \u0022j\u0027ai une fonction, je veux qu\u0027elle s\u0027appelle CRM import et son r\u00e9pertoire sources est \u00e0 tel endroit\u0022. \u00c7a va le cr\u00e9er avec le nom complet, et cette fonction-l\u00e0, dans le mod\u00e8le qu\u0027on a d\u00e9ploy\u00e9, va inclure une layer avec la couche d\u0027abstraction en Python.\u003C\/p\u003E\n\u003Cp\u003EVa inclure le Lambda qui est unique pour toutes les fonctions, qui impl\u00e9mente la couche d\u0027abstraction, qui initialise tous les objets en fait qui repr\u00e9sentent les services. On va cr\u00e9er une relation. La relation, l\u00e0 j\u0027indique que je veux que ma CRM import fonction acc\u00e8de \u00e0 un object store. On peut m\u00eame donner des niveaux assez fins en termes de param\u00e9trage.\u003C\/p\u003E\n\u003Cp\u003EEt enfin, finalement, le code du d\u00e9veloppeur m\u00e9tier vient par-dessus cette stack et est invoqu\u00e9 par mon Lambda handler standard qui va lui passer tous les objets de configuration, toute la couche d\u0027abstraction layer. Et \u00e0 ce moment-l\u00e0, le m\u00e9tier intervient. Alors dans ce cadre-l\u00e0, en fait, l\u0027\u00e9quipe m\u00e9tier d\u00e9ploie, enfin cr\u00e9e v\u00e9ritablement uniquement son code fonctionnel. Il va d\u00e9finir les relations entre les diff\u00e9rents objets, les droits n\u00e9cessaires, et si vous avez des \u00e9quipes s\u00e9curit\u00e9 ou des \u00e9quipes r\u00e9seau qui vous demandent des sch\u00e9mas de flux ou les d\u00e9pendances que vous avez sur telle ou telle application, en fait \u00e7a permettrait, cette approche, de fournir extr\u00eamement rapidement, vu que c\u0027est dans la configuration pour le d\u00e9ploiement, \u00e7a permettrait de bien d\u00e9finir qu\u0027on n\u0027a pas besoin de plus parce que sans \u00e7a, on ne d\u00e9ploie pas.\u003C\/p\u003E\n\u003Cp\u003EDonc, et du coup pour aller un petit peu plus dans le code, le code m\u00e9tier, c\u0027est... Alors dans ce que, dans l\u0027exemple qu\u0027on a fait, nous, on appelle une fonction qui s\u0027appelle \u0022process\u0022 et c\u0027est dans cette fonction-l\u00e0 que le d\u00e9veloppeur m\u00e9tier va attaquer son code. Cette fonction \u0022process\u0022 en fait, elle est d\u00e9finie, re\u00e7oit un event. L\u0027event, alors je ne sais pas si vous voyez vraiment bien l\u0027event, en fait, l\u0027event va \u00eatre... j\u0027ai le terme anglais, j\u0027arrive plus... va \u00eatre traduit. L\u0027event va \u00eatre traduit depuis l\u0027event JSON re\u00e7u par exemple depuis le cloud provider.\u003C\/p\u003E\n\u003Cp\u003ESi on a boss\u00e9 avec S3, les notifications de S3 arrivent avec un JSON qui va \u00eatre \u00e9norme o\u00f9 on va avoir le nom complet du bucket. Voil\u00e0, l\u00e0 l\u0027id\u00e9e c\u0027est que la couche d\u0027abstraction en fait fait une traduction de l\u0027event pour se ramener \u00e0 nouveau sur les nommages high level design. Par exemple, l\u00e0 on voit clairement ma source c\u0027est un object storage, mon event c\u0027est un object created, le nom de mon object storage c\u0027est \u0022incoming\u0022 et mon objet c\u0027est \u0022customer.csv\u0022, alors qu\u0027en r\u00e9alit\u00e9 le nom complet du bucket c\u0027est le nom qu\u0027on a l\u0027habitude de voir dans AWS.\u003C\/p\u003E\n\u003Cp\u003E\u00c0 c\u00f4t\u00e9 de \u00e7a, quand je vais vouloir invoquer mes services, du coup je suis en capacit\u00e9, en utilisant cette biblioth\u00e8que-l\u00e0, je suis en capacit\u00e9 de rappeler en fait mes classes que j\u0027ai utilis\u00e9es pour faire mes interactions, toujours au travers du nom logique. Et ce qui fait que j\u0027ai un code, c\u0027est ce que vous pouvez voir \u00e0 l\u0027\u00e9cran, qui en termes de biblioth\u00e8que est compl\u00e8tement agnostique du cloud provider. Et l\u0027int\u00e9r\u00eat, c\u0027est que ce code-l\u00e0, je suis en... c\u0027est dans la d\u00e9mo que nous avons faite, \u00e7a fonctionne en local. Ce code-l\u00e0, il va tourner... Je reprends le m\u00eame code, je d\u00e9ploie dans AWS, mais avec les couches sous-jacentes pour AWS, mon code va tourner \u00e0 l\u0027identique sans modification. Et donc il pourrait tourner sur Azure, sur OVH, Scaleway, tous les cloud providers.\u003C\/p\u003E\n\u003Cp\u003EEn conclusion, d\u00e9j\u00e0 merci. La d\u00e9marche, donc \u00e7a va reprendre trois principes :\u003Cbr \/\u003E\n- G\u00e9rer la qualit\u00e9 de code, faire en sorte que les \u00e9quipes puissent utiliser les assets mais tout en respectant les bonnes pratiques en termes de s\u00e9curit\u00e9, de clean code, de testabilit\u00e9, de mettre en place aussi des tests automatis\u00e9s, donner la possibilit\u00e9 de mettre les tests automatis\u00e9s.\u003Cbr \/\u003E\n- En termes de robustesse, c\u0027est r\u00e9sister au breaking change, permettre, en ayant un adaptateur qui n\u0027est plus dans chacune des applications mais qui sera transverse, de plus facilement pouvoir mettre \u00e0 jour pour ne pas subir le breaking change.\u003Cbr \/\u003E\n- Et en termes de maintenabilit\u00e9, toujours encore une fois mettre \u00e0 jour le plus vite possible, le plus simplement possible sans impacter les \u00e9quipes projets.\u003C\/p\u003E\n\u003Cp\u003EAlors on parle de tous ces avantages-l\u00e0 : masquer la complexit\u00e9, laisser les \u00e9quipes se concentrer sur le code m\u00e9tier, pouvoir faire en sorte qu\u0027on puisse aller tr\u00e8s vite. Donc beaucoup d\u0027avantages.\u003C\/p\u003E\n\u003Cp\u003EMerci beaucoup de votre attention. Alors en fait, on d\u00e9passe un petit peu le temps, on aurait beaucoup, beaucoup de choses \u00e0 dire en plus. Donc venez nous voir sur le stand, on a aussi une d\u00e9mo de toute cette impl\u00e9mentation qui fonctionne et qu\u0027on va vous pr\u00e9senter sur le stand. Donc venez nous voir.\u003C\/p\u003E\n\u003Cp\u003EMerci. Alors si vous avez des questions, c\u0027est maintenant. On sera ravi d\u0027y r\u00e9pondre.\u003C\/p\u003E\n\u003Cp\u003E[Question du public] Bonjour. Merci. Si je comprends bien, \u00e0 chaque fois les couches d\u0027adaptation, elles sont embarqu\u00e9es avec le code qui a besoin de tourner. Est-ce qu\u0027il n\u0027y a pas une possibilit\u00e9 d\u0027aller un peu plus loin et puis de d\u00e9ployer \u00e7a de mani\u00e8re unique avec des liens RPC entre l\u0027adaptateur et un service qui serait d\u00e9ploy\u00e9 ? Tout \u00e7a peut \u00eatre soit sur du d\u00e9ploiement dans Kubernetes avec des sidecars, donc qui seraient en fait d\u00e9di\u00e9s \u00e0 ces couches d\u0027adaptation. \u00c7a peut \u00eatre en mettant en place des NuGet packages qui seraient r\u00e9cup\u00e9r\u00e9s lors de la compilation, qui ferait qu\u0027on t\u00e9l\u00e9charge toujours la derni\u00e8re version disponible.\u003C\/p\u003E\n\u003Cp\u003E[R\u00e9ponse] \u00c7a, on peut avoir beaucoup d\u0027impl\u00e9mentations diff\u00e9rentes de cette mise \u00e0 disposition des adaptateurs. Moi, je pense surtout au c\u00f4t\u00e9 multi-techno. C\u0027est que l\u00e0, on a vu l\u0027exemple en Python, mais si on a du Go, du Python, du Java, effectivement, on pourrait avoir en .NET, en Java, donc des adaptateurs qui sont li\u00e9s. On pourrait aussi avoir des passe-plats qui feraient qu\u0027en .NET, on appellerait une technologie qui ferait ce r\u00f4le d\u0027adaptation. Et du coup, en fait, on a juste des passe-plats qui font qu\u0027on peut facilement appeler le m\u00eame adaptateur selon la technologie. C\u0027est tout l\u0027utilisation de Dapr, par exemple.\u003C\/p\u003E\n\u003Cp\u003E[Question du public] Oui, on parle de multicloud, mais il y a un des trucs que vous avez omis, c\u0027est le transfert des donn\u00e9es entre les applications. Et en fait, si on est multicloud, on ne va plus tellement voir, enfin avec votre syst\u00e8me, on ne va plus tellement voir le fait qu\u0027on transf\u00e8re d\u0027un cloud \u00e0 un autre. Or, \u00e7a a un co\u00fbt assez \u00e9norme de transfert multicloud. Donc cacher l\u0027h\u00e9t\u00e9rog\u00e9n\u00e9it\u00e9 des clouds, ce n\u0027est pas forc\u00e9ment une bonne id\u00e9e.\u003C\/p\u003E\n\u003Cp\u003E[R\u00e9ponse] On ne cache pas l\u0027h\u00e9t\u00e9rog\u00e9n\u00e9it\u00e9, tu facilites le transfert entre les deux. Certes. Mais de toute fa\u00e7on, quel que soit le cloud, quand tu prends un d\u00e9veloppeur d\u00e9butant, tu lui fais un appel de m\u00e9thode locale ou un appel de m\u00e9thode distante, lui, il ne voit pas la diff\u00e9rence, il est d\u00e9butant. Absolument. Donc il faut conna\u00eetre le co\u00fbt de ce qu\u0027il y a derri\u00e8re.\u003C\/p\u003E\n\u003Cp\u003EEffectivement, c\u0027est bien ma vigilance par rapport \u00e0 \u00e7a. Dans le cadre d\u0027une mise \u00e0 jour sur un cloud provider quel qu\u0027il soit, effectivement, il y a le co\u00fbt de passage de l\u0027un \u00e0 l\u0027autre. Mais si tu te rappelles le passage o\u00f9 on d\u00e9finit les d\u00e9pendances entre chaque couche, en fait, le fait de conna\u00eetre ces flux-l\u00e0 permettrait \u00e0 un architecte, au moment de la validation, de pouvoir se dire : \u0022Bah, les donn\u00e9es sont au Japon et on les fait transiter par la Chine et ensuite on les envoie au Danemark\u0022. Et en fait, le fait de pouvoir avoir cette approche et de d\u00e9finir les relations entre les applications, \u00e7a permet de lutter contre \u00e7a.\u003C\/p\u003E\n\u003Cp\u003EOn... de toute fa\u00e7on, si on fait du multicloud, quelle que soit la technologie, ce que tu d\u00e9cris ici, d\u0027avoir les donn\u00e9es qui sont pass\u00e9es de l\u0027une \u00e0 l\u0027autre, on l\u0027aura. Donc il faut se donner les moyens de, au moins, le citer, d\u0027au moins le d\u00e9crire.\u003C\/p\u003E\n\u003Cp\u003EJe dirais, c\u0027est d\u00e9crit par d\u00e9faut parce que l\u00e0, on est rest\u00e9... nous, ce qu\u0027on voulait mettre vraiment en avant, c\u0027est cette d\u00e9marche de faire une abstraction. Maintenant, ce qu\u0027il faut... on est rest\u00e9 sur un mono-cloud, on est en on-premise, on est dans AWS. Maintenant, le fichier YAML que je pr\u00e9sentais tout \u00e0 l\u0027heure, qui pr\u00e9sentait tous les services qu\u0027on d\u00e9ploie, si je suis en mode multicloud, je peux tr\u00e8s bien imaginer avoir un fichier YAML avec une portion AWS, une portion Azure, une portion GCP. Et \u00e7a va \u00eatre le choix de l\u0027architecte aussi d\u0027\u00e9tablir \u00e7a, de mettre en place les liens. Les liens vont \u00eatre visibles dans le fichier.\u003C\/p\u003E\n\u003Cp\u003EC\u0027est ce que je veux dire, c\u0027est que le d\u00e9veloppeur dans ce contexte-l\u00e0 n\u0027a pas \u00e0 se poser cette question-l\u00e0. C\u0027est... il y a eu un architecte, il y a eu un tech lead qui a d\u00e9cid\u00e9 qu\u0027on faisait cette ventilation de ressources, mais elle est document\u00e9e par d\u00e9faut. Le fait d\u0027avoir ce besoin de gouvernance, de tout, quel que soit l\u0027outil qu\u0027on utilise, on en a besoin. Par contre, on permet, nous, d\u0027avoir un fichier qui le d\u00e9crit.\u003C\/p\u003E\n\u003Cp\u003ED\u0027autres questions ? Pas d\u0027autres questions ? Merci beaucoup.\u003C\/p\u003E\n\n    \n\n\n\n  \n\n\n  \u003C\/details\u003E\n      \u003C\/div\u003E\n\n      \u003C\/div\u003E\n\u003C\/section\u003E\n","dialogOptions":{"dialogClass":"opn-custom-modal-wrapper","width":"50%","closeText":"Fermer","modal":true,"title":"","classes":{"ui-dialog":"opn-custom-modal-wrapper"}}}]