Transcription

• Speaker #0

  Salut à toi, et bienvenue sur le podcast d'AxeOpen. Ici, tu peux écouter tous les mois une bande de développeurs pro qui parlent sans aucun filtre de leur quotidien dans le monde de la tech. Allez, c'est parti !

• Speaker #1

  Salut les techos ! Et 3, 2, 1... Bonne année ! Pire intro de tout le monde !

• Speaker #0

  Mais c'est pas grave ! J'espère que tout le monde a passé de bonnes fêtes, que vous avez bien profité des proches et que vous êtes chaud bouillant pour démarrer cette nouvelle année en notre compagnie. Qu'est-ce qu'on peut vous souhaiter cette année ? Pas de bug en prod déjà.

• Speaker #2

  Un nouveau serveur gris. Plein petit ton.

• Speaker #0

  Pas trop d'incidents de cyber parce que ça a été quand même pas mal dans les actus. Et puis surtout de vous éclater dans votre job je pense et de faire si possible les bons choix. Et en parlant de bons choix, on va parler de celui de l'hébergement. Transition sans transition ? Ça fait des années que le cloud est présenté comme la solution miracle, qui est simple, performante, flexible. Et les géants américains nous ont promis depuis des années monts et merveilles. Mais depuis un moment, je crois qu'on arrive à un ras-le-bol qui est généralisé, et pas seulement à cause des factures qui sont démentielles, mais le service aussi se dégrade. Et il vient avec lui l'hyperdépendance, qui fait vraiment de plus en plus peur, et on le voit avec les gens avec lesquels on discute. Et heureusement, dans ce contexte brumeux, une étoile brille, Kubernetes. Cet orchestrateur de conteneurs est probablement la meilleure manière de reprendre le contrôle sur votre ESI, de revenir à l'essentiel et de sortir de la dépendance du cloud. Alors pourquoi c'est une solution qui vaut le coup d'être étudiée et comment la mettre en place ? On vous explique tout ça aujourd'hui avec les petits gars autour de la table. J'ai comme d'hab Philippe, le Java Manégré. Oui,

• Speaker #3

  elle a fait l'intro, le développement, la conclusion.

• Speaker #4

  C'est la meilleure partie dans l'intro déjà.

• Speaker #2

  On peut arrêter là ? Le podcast est fini.

• Speaker #4

  Le ton est donné.

• Speaker #0

  Bon, Philippe le jamané gris.

• Speaker #4

  Bonjour à tous.

• Speaker #0

  Jacques le grand sage.

• Speaker #4

  Salut.

• Speaker #0

  Nathan le monsieur propre du code. Hello. Loulou alias Louis ou Ouk alias Loulou.

• Speaker #4

  Salut tout le monde.

• Speaker #0

  Et Arthur le javascript lover. Bonjour.

• Speaker #4

  Et Camille bien sûr, bon anniversaire quand même Camille. Oui, bonjour.

• Speaker #0

  Merci les gars.

• Speaker #5

  Après cette belle intro.

• Speaker #0

  Ouais, c'était il y a trois semaines. Je te laisse démarrer, on fait comme d'hab, on pose les bases, on va peut-être revenir effectivement à l'hébergement pour démarrer. Donc l'hébergement dans les grandes lignes, qu'est-ce que c'est et de manière simple.

• Speaker #6

  On va poser les bases.

• Speaker #3

  Alors, l'idée de l'hébergement, c'est comment on fait fonctionner une application en production. En gros, ça veut dire qu'une fois que vous avez écrit votre code et qu'il fait quelque chose, il faut bien le mettre quelque part pour qu'il soit exécuté sur une machine. En gros, l'hébergement, c'est ça. Qu'il soit accessible à tous parce que sur son poste de dev, ça ne compte pas.

• Speaker #0

  Et c'est quoi les enjeux des entreprises par rapport justement à cet hébergement ?

• Speaker #3

  Alors, l'enjeu principal de l'hébergement, enfin, je dirais qu'il y en a deux. Il y a un enjeu de disponibilité. Il faut que l'application tourne, elle soit toujours disponible, elle fonctionne et compagnie, elle soit capable d'encaisser la charge, tout ça. Et le deuxième enjeu, c'est la stabilité slash sécurité, qui est un terme un peu flou, mais qui veut dire que, un, on ne se fasse pas hacker et que l'application, elle fonctionne 24-24, ou en tout cas avec le temps de la disponibilité qu'on s'autorise.

• Speaker #4

  Le troisième enjeu, c'est le coût ?

• Speaker #3

  C'est vrai. Et d'ailleurs ça va faire une transition pour Camille.

• Speaker #0

  Je vais la chercher. Non mais du coup comment,

• Speaker #3

  enfin je pense peut-être pour expliquer un petit peu plus dans le détail comment ça fonctionne l'hébergement, on peut peut-être repartir d'un petit point historique.

• Speaker #0

  C'est le moment historique.

• Speaker #3

  Allez, je vais vous faire un petit point historique. On va revenir au tout début. C'est assez simple, l'hébergement, ça fonctionne sur un PC, un petit peu comme votre ordinateur portable. Historiquement, on hébergait directement ça sur des machines physiques, ce qu'on appelle les machines physiques. Et j'emploie volontairement ce thème parce que derrière, on va parler beaucoup de virtualisation. Donc en gros, ça veut dire quoi ? Vous avez un programme qui s'exécute sur votre machine qu'on rendait disponible à travers la carte réseau. En gros, globalement, c'était ça l'hébergement pendant de très nombreuses années. C'est un défaut principal, c'est que si votre machine physique crash, le disque dur crash, le CPU crash, enfin n'importe quelle raison matérielle qui fait que ça crash, votre service était indisponible. Donc pour pallier à ces problèmes là, on a inventé la virtualisation. La virtualisation c'est un bien grand mot pour dire que globalement votre système d'exploitation il s'exécute à l'intérieur d'un conteneur qu'on appelle machine virtuelle qui lui-même va passer à travers un hyperviseur qui va choisir une machine physique qui fonctionne. En gros ça veut dire quoi ? C'est à dire que quand vous exécutez un programme, il s'exécute dans une machine... où il a l'impression que c'est une machine physique, mais en fait au moment où il s'exécute, l'hyperviseur va dire « Tac ! Tac ! » Il va choisir une machine physique réelle dans laquelle ça va vraiment fonctionner et il va choisir la machine qui est généralement la plus disponible dans l'ensemble des machines qu'il a. Donc il a plein de machines physiques à sa disposition et il choisit un instant T là-dessus. Ce qu'il faut voir, c'est que c'est vraiment presque à la seconde qu'ils changent de machine physique. C'est-à-dire qu'ils peuvent changer une machine parce qu'ils décident que celle-là est morte ou compagnie. Et comme vous avez cette couche de virtualisation, si vous avez une machine physique qui meurt, ce n'est pas bien grave parce qu'automatiquement, la machine virtuelle va migrer vers une autre machine physique sur laquelle ça va s'exécuter. Donc ça, c'est un petit peu les années 2010.

• Speaker #4

  Les belles années de VMware. Après, sur l'hébergement, c'est un moment aussi où on a décorrélé ce qui tournait de la capacité de calcul, de la capacité mémoire et du stockage. C'est un point qui est important parce qu'en fait, derrière et jusqu'aux années d'après, on va continuer cette séparation sur la partie stockage et calcul.

• Speaker #3

  En gros, la virtualisation arrive avec tout ce qu'a dit Greg. Et c'est vraiment important de comprendre qu'on va changer complètement de paradigme de structure de matériel. C'est-à-dire que historiquement, dans une machine, vous avez votre CPU, vous avez votre RAM et vous avez votre disque dur. En gros, c'est ça une machine si on le résume très grosse maille. Mais pour faire de la virtualisation, vous allez vite comprendre que le disque dur à l'intérieur de la machine, c'est très problématique parce que si ça meurt, vous perdez les données qui sont dedans. Donc pour faire ça, en fait, on a quelque part virtualisé le disque dur, et on l'a virtualisé en le déplaçant de la machine dans laquelle il s'exécutait vers des emplacements réseau. Et vous avez des disques durs qui sont montés en réseau. Ce qu'il faut imaginer, c'est que vous avez dans les sales servers tels que vous l'imaginez, dans les gros racks que vous voyez à la télé, vous avez des racks avec des machines qui ne font que du CPU et de la RAM, donc vraiment la partie ce qu'on appelle compute aujourd'hui. Et vous avez d'autres baies qui ne font que du disque dur. Donc des espèces de gros SAN. Et entre les deux, vous avez du réseau. Ce qui veut dire que quand vous avez une machine virtuelle qui veut accéder à ces données, en fait elle n'accède pas à ces données comme vous à travers le disque dur en direct, elle va faire un accès réseau vers ces disques durs-là. Cette architecture permet d'avoir 100% de disponibilité ou d'immodibilité très important parce que du coup on n'a plus ce problème de dépendance au matériel. Ça c'était les grandes années VMware, on a virtualisé tout ça. Mais en fait quand on a virtualisé ce qu'on a fait c'est qu'on a ni plus ni moins pris votre machine, et on a fait une couche d'abstraction avec la machine physique et du coup ça fonctionne. C'est ça qu'on a fait. Après est arrivé nos amis du cloud avec un paradigme qui est un peu différent, qui va se construire par-dessus la virtualisation mais qui va essayer de construire des services de plus haut niveau, qu'on va venir consommer. C'est à dire que vous n'allez plus avoir une machine virtuelle directement Pourquoi c'était compliqué d'avoir une machine virtuelle ? C'est parce que vous aviez le système d'exploitation à maîtriser, vous avez les pages de sécurité, vous avez tout un tas de raisons qui font qu'avoir une machine virtuelle, c'est quand même assez compliqué. Donc ils ont essayé de venir avec des services de plus haut niveau. On pourrait faire tous les modèles OSI et tout ça, mais on ne va pas rentrer là-dedans aujourd'hui, ce n'est pas le sujet. On va avoir des services de plus haut niveau, on va utiliser une base de données as a service et en fait, on n'utilisera que la partie base de données vue utilisateur et puis le cloud provider se débrouille à faire ça. Donc en gros, ce qui s'est passé dans les années depuis 2008, depuis que nos amis d'AWS sont arrivés, c'est qu'on a construit des services de encore plus haut niveau. Et le but de l'hébergement, c'était justement pour les gens comme nous qui font du développement, d'avoir le moins d'infrastructures à gérer et de transférer la responsabilité de plus en plus vers l'hébergeur.

• Speaker #4

  Sur la technologie, il n'y a pas eu de changement majeur. Il y a eu beaucoup de changements. Mais si on se place d'un point de vue macro sur la virtualisation, on reste sur la virtualisation. Par contre, on a un gros enrichissement en termes de service. C'est ça surtout qui a changé ? sont construits au-dessus de la virtualisation. C'est-à-dire, c'est de la virtualisation de virtualisation, si on peut le dire.

• Speaker #0

  Et donc ensuite, après ce chapitre de virtualisation, est arrivé après tout ce qui est l'histoire autour de Docker, Kubernetes et tout ça ?

• Speaker #4

  Ouais, alors,

• Speaker #3

  ça c'est beaucoup plus récent dans l'histoire. Et en gros, l'idée, c'est de dire... Avec Grégory, on a vu vraiment la jeunesse de ce truc-là arriver, on se marrait pas mal. C'est qu'il est venu de Docker, qui est en fait un autre mécanisme de... Alors, c'est pas un autre mécanisme de virtualisation, il serait faux de dire ça, mais C'est ce qu'on appelle des micro-conteneurs. Donc, c'est des tout petits conteneurs dans lesquels vous venez mettre votre application et qui vont s'exécuter au sein d'un Kubernetes. Il faut imaginer comme un espèce de cluster de machines qui eux-mêmes s'exécutent à travers des machines virtuelles. Donc, en gros, si je fais un schéma très simple, vous avez votre petite application qui tourne dans ce qu'on va appeler un pod et qui va s'exécuter au travers Kubernetes sur un ensemble de nodes qui sont peu ou prou des machines virtuelles qui vont elles s'exécuter dans un hyperviseur qui vont elles s'exécuter sur des machines physiques.

• Speaker #4

  C'était simple ça ? C'est pas échéant de faire ça. mais en fait on va être au service unitaire. C'est ça qui change le plus dans la vision de cette virtualisation-là. Par contre, chaque couche de virtualisation porte un OS à chaque fois. avec le poids d'un OS. On s'en rend bien compte quand c'est un OS Windows, on se dit que l'OS est hyper conséquent. Quand c'est un OS Linux, c'est plus petit. On a créé des OS de plus en plus petits, de plus en plus light, pour éviter d'empiler des poids énormes à chaque couche de virtualisation. Mais on porte quand même l'OS à chaque fois. Ça veut dire que là, si on résume, on est à trois OS sur trois couches de virtualisation si on les empile.

• Speaker #0

  Aujourd'hui, on l'a dit en intro, tout ça, c'est géré par des hébergeurs ? Enfin, en tout cas, en partie. Et aujourd'hui, c'est quoi le sujet autour des hébergeurs ?

• Speaker #3

  Il y en a plein. Moi, je pense que le sujet principal... Alors, on pourrait citer la facturation, mais c'est un sujet un peu facile. Moi, je trouve que le sujet principal, c'est la perte de contrôle total. C'est-à-dire qu'aujourd'hui, on est dans un système où, parce qu'on utilise des services de plus en plus haut niveau et de plus en plus imbriqués, qu'on a la sensation de... plus contrôler quoi que ce soit. Et quand on dit qu'on ne contrôle plus quoi que ce soit, c'est qu'en fait, on passe son temps à essayer de maintenir, en fait, on passe plus de temps à essayer de maintenir cette espèce d'énorme bouzou et d'interconnexion là-dessus. Et qu'on voit qu'en fait, ce qu'on nous avait promis, pour faire les promesses du cloud, de dire on va avoir une résilience à toute épreuve, elle est un peu faux. On a eu je ne sais pas combien d'outages ces six derniers mois et on s'est aperçu que même nos amis d'AWS là-dessus, ils étaient extrêmement dépendants de datacenter à datacenter et qu'en fait, il y en avait un qui toussait en vergie de l'île du Nord et tout le monde s'effondrait. Donc je pense que le problème principal, c'est qu'aujourd'hui on n'a plus du tout le contrôle de ce qu'on fait, on a un contrôle qui est très parcellaire, et en plus on a des factures de cloud qui deviennent strictement stratosphériques sur lesquelles on ne maîtrise pas et qui ne sont pas prévisibles. Je ne sais pas si toi Grégory, tu vois d'autres problèmes encore, mais moi je pense que c'est les problèmes principaux.

• Speaker #4

  En fait, c'est des problèmes qui sont induits par le modèle. Ce qu'a promis Azure ou AWS ou Google à l'origine, c'est de se dire, on va vous aider sur votre infrastructure, on va manager des services, pour vous, on va vous aider à optimiser vos coûts. Là, il y a eu un abus de langage parce qu'en fait l'optimisation des coûts n'est pas réelle, elle est faite par le fait que vous allez pouvoir éteindre les services que vous n'utilisez pas la nuit et là vous allez économiser. En réalité, si on prend sur un même temps de travail, on n'économise pas du tout, loin de là. Et ça induit une surdépendance déjà à ses fournisseurs. Parce qu'effectivement, comme le disait Philippe, avant on était dépendant de notre hébergeur qu'on avait pris nous et puis on gérait toute la couche de virtualisation. Enfin après la virtualisation, là eux ils gèrent tout. C'est-à-dire qu'ils gèrent l'hébergement, la couche de virtualisation, le service managé, la partie logicielle qu'on va utiliser en tant que service. Et on nous avait dit avec ça vos équipes d'exploit vous les dégagez et puis on prend tout en charge. Vous allez payer un peu plus cher mais par contre du coup vous allez économiser sur vos équipes. Ce qu'on s'aperçoit aujourd'hui, avec un peu de recul, c'est que les équipes d'exploit sont toujours là. Elles sont voire même plus nombreuses parce qu'elles ont plus de services à gérer et par l'over-complexité de l'informatique aujourd'hui, on a besoin de plus de monde.

• Speaker #3

  Il faudrait faire les ratios, mais vous n'imaginez pas, je pense qu'on ne s'imagine pas quand on n'est pas de ce monde-là, le nombre de lignes de code qui existent, ne serait-ce que pour maintenir l'infrastructure dans un état cohérent. C'est-à-dire qu'on est passé d'une infrastructure qui n'était pas en... en code, à une infrastructure en code. Moi j'ai un problème avec YAML, mais peu importe. Vous avez des tonnes et des tonnes de descriptifs d'infrastructures, et sur des petits projets il y a presque plus de codes d'infrastructures que de codes d'applications. Donc ça devient un peu ridicule.

• Speaker #5

  Ça devient ridicule, mais en même temps, grâce à ça, on a pu rentrer dans l'ère de versionner notre infrastructure et de savoir l'historique de tout ce qui s'est passé. Ça a des inconvénients, mais aussi beaucoup d'avantages. Complètement, complètement.

• Speaker #4

  Je ne suis pas sûr que ce soit totalement corrélé au problème du cloud, pour le coup, parce que même sur la virtualisation, on avait commencé avec Ansible à faire de l'infrastructure Ascode. On sait que c'est hyper lourd, c'est complexe à mettre en place, c'est pénible à maintenir. D'ailleurs, au début, on hésitait à y aller, clairement, vu la complexité par rapport aux petits clients. Le coût était quand même assez énorme de le faire. Aujourd'hui, on s'aperçoit que c'est devenu plus standard, donc quand même un peu plus facile à faire, un peu plus facile à mettre en place. Et comme le disait Louis, c'est une bonne pratique. C'est-à-dire que maintenant, en fait, si on se se fait auditer et que l'infrastructure n'est pas gérée à ce code, la gestion de conf est dure à comprendre, elle est dure à suivre et c'est devenu vraiment une bonne pratique à faire. Je ne suis pas sûr que c'est quelque chose qui a imputé au fournisseur cloud beaucoup ce truc-là.

• Speaker #3

  Il y a quand même beaucoup de vendeurs locking, il y a beaucoup de trucs que tu peux utiliser que leur API à eux.

• Speaker #4

  Évidemment, on est dépendant de toute manière en faisant ça, on a créé une dépendance au fournisseur cloud, elle est certaine.

• Speaker #3

  Parce qu'on a créé des dépendances sur des technologies qui sont à la base open source. C'est un truc qui est assez rigolo, c'est-à-dire que tu ne peux plus utiliser une base de données post-gray qui est une technologie full open source sans passer par l'interface qu'ils t'ont créée pour utiliser la base post-gray.

• Speaker #4

  Tu peux le faire mais tu vas la manager toi-même. Oui, c'est ça. C'est le service, en fait, qu'ils proposent. Et c'est pour ça qu'il y a eu des conflits, que ce soit avec Elasticsearch et avec Redis, parce qu'effectivement, c'est des technologies qui se sont appropriées et qu'ils ont revendues aux participants plus ou moins au projet initial. Mais ils se sont fait quand même pas mal d'argent là-dessus.

• Speaker #2

  Je trouve bien un dernier point aussi dont on n'a pas parlé, c'est l'opacité. C'est qu'en fait, on ne sait pas trop ce qu'ils utilisent, mais aussi ce qu'ils font des données, parce qu'ils nous promettent des choses. Mais par exemple, pour tout ce qui est des transferts réseaux, on ne sait pas si on veut promettre à un client que... nos données restent en France parce qu'on l'a mis sur le data center à Paris. On n'est pas sûr et on ne peut pas prouver que les données ne vont pas partir aux États-Unis pour x ou y raison. Et je pense que dans un monde où aujourd'hui, on a beaucoup de questions de souveraineté qui sont revenues sur le tapis avec tout ce qui se passe aux États-Unis, ça peut être un point aussi. Moi, j'ai des clients, des fois, où je leur ai dit « On part sur AWS parce qu'on a déjà la moitié de leur infra. » Ils me disent « En fait, nous, on vend qu'on ne fait que du français à nos clients Et puis en plus,

• Speaker #3

  je pense que quand tu lis les petites docs d'AWS et compagnie, tu peux avoir les informations, mais c'est devenu tellement opaque que même nous qui sommes dedans toute la journée, on n'est même pas vraiment certain de ce qu'on fait.

• Speaker #0

  C'est rassurant ça Philippe ?

• Speaker #3

  Non mais c'est vrai, parce qu'il y a tellement de services différents qu'ils ont tous eu des politiques différentes et compagnie. C'est très compliqué de savoir là-dessus quoi.

• Speaker #5

  C'est presque impossible de savoir où est-ce que va exactement ton trafic ? Je sais qu'Azure met en place une vente de pouvoir passer par leur tunnel trafic privé à eux, etc. Mais en fait, tu n'es pas garanti à 100% de passer forcément par là et tu as du mal à le vérifier.

• Speaker #4

  C'est une question technique, c'est une question juridique. Je sais que AWS promet un cloud souverain européen sur les prochaines années. On est quand même, même si techniquement tout est isolé, je ne sais pas comment c'est fait, je n'ai pas cherché les détails et de toute manière ce n'est pas transparent du tout. Donc pour le moment ce qui est publié, c'est assez difficile à comprendre. juridiquement, on est quand même sur une boîte, même si elle travaille en Europe, qui est détenue par une boîte américaine. Donc il faut se poser la question de, ok, techniquement c'est peut-être séparé, à la limite on s'en fout. Effectivement, si la Virginie du Nord demain tombe, peut-être que l'Europe sera indépendante, ce qui n'est pas le cas aujourd'hui. Par contre, juridiquement, si la boîte AWS américaine a envie d'aller taper les données de l'Europe, il n'y a que leur bon vouloir qui fait que ça nous sécurise, mais c'est tout.

• Speaker #0

  Du coup, du côté de vos clients, notamment des DSI, qui ont quand même la responsabilité de se dire parcs informatiques sur tel ou tel hébergeur, il se passe quoi dans leur tête là en ce moment ? Est-ce que c'est des choses dont vous discutez beaucoup avec ?

• Speaker #3

  Alors c'est des choses...

• Speaker #4

  Ça dépend des clients.

• Speaker #3

  Ouais ça dépend des clients et par contre je pense que les... Enfin je veux dire ils sont dans le même état que nous, c'est à dire qu'ils ont beaucoup de mal à... à comprendre exactement ce qui se passe, par où ça passe... Aujourd'hui c'est le problème d'avoir éloigné l'infrastructure des entreprises, c'est que c'est très... Alors pour le coup ils sont virtuels pour eux. Ils ont du mal à maîtriser tout ça et il y a une sensation qui est globale, qui est de perte de contrôle. Et donc, du coup, ils aimeraient bien reprendre le contrôle. Ils ne savent pas forcément comment faire. C'est peut-être la transition d'ailleurs avec...

• Speaker #2

  C'est une longue intro juste pour introduire le sujet.

• Speaker #0

  Est-ce que Kubernetes pourrait être cette solution ?

• Speaker #3

  Alors, vous prêchez un convaincu. Le discours va être orienté. Il est complètement orienté parce que je trouve que c'est le bon niveau d'abstraction et c'est, à mon avis, la bonne manière d'utiliser les cloud providers parce qu'on va être clair, on ne va pas remettre des infrastructures chez nos clients, ça serait beaucoup trop compliqué. Oui, chacun ses salles serveurs. C'est beau dans la théorie mais dans la pratique ce n'est pas du tout accessible. Par contre, c'est peut-être le bon niveau sur lequel s'arrêter quand on parle de, j'ai envie de dire, d'infrastructures qu'on veut utiliser chez les hébergeurs. Pourquoi ? Parce que créer un cluster Kubernetes soi-même avec des machines, ce n'est pas évident. Ce n'est pas facile de créer un data center qui soit fiable et résilient avec tout ça. Par contre, l'avantage d'un Kubernetes, c'est qu'aujourd'hui, avec Kubernetes, vous pouvez faire tout ce que vous pouviez faire dans les autres services managés, vous pouvez directement le mettre dans votre Kubernetes. Et l'avantage de Q26, c'est que c'est une technologie open source et standard. Et donc du coup, l'effort de migration d'un cloud vers un autre, ou l'effort de montée en compétence de vos équipes, est plus limité. Ça ne veut pas dire que votre cluster, vous allez faire clic droit, save, et vous allez le loader sur un autre hébergeur. Ce n'est pas ça, mais je veux dire que c'est quand même faisable, et beaucoup plus faisable que d'utiliser des services tout packagés, tout managés.

• Speaker #4

  On va dire que ça libère le fait d'être cloisonné avec un cloud provider. Ça n'enlève pas forcément les défauts du cloud provider, c'est-à-dire qu'on va toujours payer la ressource plus chère, sauf si on l'arrête et on a cette flexibilité avec Kubernetes de pouvoir arrêter des pods la nuit dont on ne sert pas, de pouvoir autoscaler, etc. Ça n'empêche pas qu'on est avec un cloud qui est hébergé où on ne sait pas où, donc qui n'est pas forcément souverain comme le disait Arthur. En fait, ça n'empêche pas non plus qu'on a cette couche d'abstraction qui est énorme, parce qu'on tape de la vertu, de la containerisation, on a la couche de management de kube qui vient en plus. Même un kube managé, aujourd'hui ce que disait Philippe, c'est qu'on ne vous conseille pas de faire un kube vous-même sur vos machines et à configurer, parce qu'il faut quand même avoir pas mal de compétences et il faut le maintenir à jour, mais même un kube managé vous rend interdépendant de votre cloud provider, et s'il y a un incident chez cloud provider... votre cube il se prend le même incident dans tous les cas alors il sera peut-être moins impacté parce qu'il utilisera moins de services managés parce qu'on les a mis dans le cube concrètement si les capacités de calcul sont impactées derrière votre cube est mort donc ça empêche pas ça et ça empêche pas ce surcoût là

• Speaker #5

  Et on garde pas le problème de switch provider, je dis ça parce que j'ai vraiment cette sensation quand on part sur un service quoi qu'il arrive on va souscrire un service Kubernetes quand on va aller sur un provider le fait de switch sur un autre provider souvent on a cette rétention client qui font que les confs ou ce genre de choses sont quand même différentes. Je vais m'expliquer, si je fais mon infrastructure Kubernetes avec un Terraform, si je veux switch de provider, ça va quand même me demander beaucoup de charges.

• Speaker #3

  Ça va clairement te demander de la charge et ça serait mentir de dire que c'est transparent. Par contre, si tu construis une application sur Azure ou AWS en utilisant que des services managés, ça sera beaucoup plus dur que si tu as juste un Kubernetes. C'est ça le sujet. Tu auras toujours des adhérences et ce n'est pas le sujet de les gommer, mais c'est-à-dire que c'est possible et c'est jouable Là où ce n'est pas du tout possible de le faire, c'est un service manager ou alors à des coûts extrêmement stratosphériques qu'on ne fait jamais.

• Speaker #5

  Et question un peu, je me mets du côté diable en mode je cherche la petite bête. Est-ce que la solution la plus simple, ce n'est pas d'avoir une VM, de faire ton DOM d'image et de la remettre sur un autre provider ?

• Speaker #3

  Alors, retourner à la VM, moi je le verrais vraiment comme une régression. Pourquoi ? Parce que les cloud providers apportent un niveau de sécurisation qui est difficile à atteindre pour une PME classique. arrivé avec un Docker, avec un Kubernetes, tu as déjà quand même tout un tas de sécurisations qui sont faites par l'hébergeur de choses intéressantes. Et du coup, si tu voulais refaire la même chose avec des VM, ce n'est pas à la portée de n'importe qui. Moi, à mon avis, le bon niveau aujourd'hui pour une PME, c'est Kubernetes as a service et ce n'est pas la VM.

• Speaker #0

  Aujourd'hui, Kubernetes, on l'utilise dans toutes les boîtes que tu utilises ? en gros, celles qui font un peu d'informatique.

• Speaker #3

  Alors je sais pas si toutes les boîtes utilisent aujourd'hui ça devient quand même de facto un standard.

• Speaker #2

  On en prend énormément.

• Speaker #4

  Si on a besoin d'un hyperviseur, on utilise Kube mais tout le monde n'utilise pas Kube. En fait c'est quand même une grosse marche à passer.

• Speaker #0

  J'allais dire, philosophiquement, même dans les équipes, est-ce que c'est un truc qui est accessible à n'importe qui ou est-ce que vraiment il faut que tu penses un peu le sujet pour comprendre ?

• Speaker #3

  Moi je suis pas tout à fait d'accord avec vous, je pense que c'est extraordinairement accessible ramener à ce que ça fait. C'est-à-dire par rapport à... tu vois, il n'y a pas d'alternative. Moi je trouve qu'aujourd'hui il n'y a pas d'alternative pour faire la même chose. Simple.

• Speaker #6

  Il y en a qui proposent moins de choses mais qui font quand même des alternatives. Tu penses à ? Docker Swarm par exemple. Alors en fait c'est beaucoup plus simple, tu as moins de fonctionnalités mais tu peux orchestrer tes contenants et les déployer et tu es indépendant du cloud.

• Speaker #4

  En fait tu le vois chez nos clients, il y a différentes étapes. Ils sont sur des VMs. Après ils commencent à s'intéresser à la partie dockerisation, donc ils se disent : "bah maintenant on a nos dockers en dev, au final on aimerait bien les déployer tels quels en prod" donc il faut commencer par les déployer avec du docker compose. Donc c'est un peu manuel machin, c'est dur à suivre mais ça reste à leur hauteur parce que c'est juste une ligne de commande que tu lances, qui te lance un démon sur ta machine. Franchement, t'as pas beaucoup de choses à changer dans l'infra et après on passe sur la partie hyperviseur et en fonction des compétences des équipes, comme le disait Nathan, soit ils vont se dire, bon, on fait un gros step et on passe à cube, mais ça veut dire qu'on change énormément de choses. on balance le concept de VM, on paramètre tout correctement. Parfois on se dirige vers un cloud provider pour ça, pour avoir un cube managé. Ou alors on se fait un Docker Swarm qu'on peut peut-être même installer on prem et puis gérer un peu plus facilement qu'un cube et c'est de différentes étapes selon la maturité du client et puis sa capacité à changer et à faire changer ses équipes. Je vois les équipes d'exploit qui gèrent des VM à la main, qui suivent les métriques des VM. C'est basique, c'est CPU, mémoire, etc. Quand tu leur dis on va suivre les pods qui sont instanciés à la consommation des pods etc. sur quel nœud, combien il y a de potes, comment ils sont répartis.

• Speaker #3

  Alors tu expliques, t'as des VCPU qui sont déjà des bons morceaux de VCPU, qui sont des morceaux de VCPU.

• Speaker #4

  Non mais on a... Eux ça leur fait peur.

• Speaker #3

  Oui je suis là. Ce que tu dis c'est un peu la même chose. Tu dis cube ça reste la cible. Mais après, c'est un chemin. C'est un chemin.

• Speaker #4

  Mais mais c'est la meilleure cible d'exploitation. C'est la meilleure cible d'exploitation pour le container blocker.

• Speaker #3

  Moi, je ne vois pas de cible d'exploitation objectivement autre aujourd'hui. Mais ce n'est pas...

• Speaker #6

  Pour moi tu vas la mettre à des niveaux différents. En fait, Kube, c'est vraiment un standard énorme tel que les cloud providers l'utilisent eux-mêmes. C'est à dire que les services qui permettent d'héberger des containers sur les cloud providers ont un cube derrière juste tu managent pas le cube. Et en fait, en fonction de ton besoin, Si tu as juste besoin d'héberger un conteneur, tu le scale à deux, tu n'as pas d'autoscaling, Ça ne sert à rien de s'embêter à prendre un cube énorme à côté.

• Speaker #3

  Alors c'est là où moi je ne serais pas raccord avec toi. Parce qu'en fait, quand tu as une vision entreprise des choses, tu t'aperçois que déjà il y a très rarement, mais je suis d'accord que c'est le cas, mais il y a très rarement de cas où tu n'as qu'une seule application hébergée. Il est là le delta. Il est important. Dès que tu as plus d'une application, en fait tu as quasiment tout le temps intérêt à passer sur un cube. Je ne dis pas tout le temps, mais c'est vraiment le cas. Et du coup, c'est pour ça que dans l'idée d'une cible d'émergement pour PME, c'est plutôt de se dire j'ai mon Kubernetes qui fonctionne et qui est dispo. Et du coup, après, je peux tout héberger ou héberger la très grande partie de ton système informatique.

• Speaker #4

  En fait, c'est important ce que tu dis. C'est hyper important parce que quand on n'a qu'un seul conteneur à déployer, on ne va pas déployer un cube juste pour un conteneur. Parce que la charge qui est induite par la gestion d'un cluster cube, C'est pas anodin non plus, on parlait de surcharge sur la partie virtualisation. En fait un cube on va avoir des nodes qui vont tourner juste pour la gestion du cube. Donc t'as un overload qui est énorme si tu parles d'un conteneur Docker. Donc à partir du moment où tu vas avoir un petit bout du SI à héberger, une application avec des microservices un peu dans tous les sens, où là ça va avoir un vrai sens de se dire je passe sur un cube parce que ça va me faciliter la tâche, là tu peux déclencher le truc de passer sur le cube. Mais avant pour un conteneur... On ne va pas monter un cube pour un conteneur, tu vois. Et en fait, c'est là que la décision se prend de savoir qu'est-ce que tu vas héberger et qu'est-ce que tu projettes aussi parce que ça peut être une roadmap. Pour le moment, on a deux applis. On monte un cube pour deux applis, ce n'est pas forcément rentable. Par contre, on sait qu'on va en déployer de plus en plus, quoi. C'est vraiment le chemin à tracer sur qu'est-ce qu'on veut pour son récit.

• Speaker #6

  Parce que vraiment, pour une petite entreprise, nous, on leur fait le déploiement, on leur fait ça, ils ont une application. Je ne veux pas mettre un cube. Un jour, on... La Presta s'arrête, on leur dit qu'on vous fournit tout ce qu'on a fait. On ne va pas leur fournir un cube avec une application dessus qui vont refiler à notre Presta. Ça me paraît être une complexité énorme pour juste déployer un conteneur alors qu'on peut juste le mettre sur un service. Pour moi, il y a un delta à trouver entre les deux. En effet, cube, ça va répondre à plein de problématiques. C'est vraiment très bien, notamment sur l'indépendance par rapport au cloud provider qui est beaucoup plus faible. Mais le fait d'être dépendant d'un cloud provider pour un conteneur ou quelques petits conteneurs La transition ne va pas être énorme d'un cloud provider à un autre. C'est dès qu'on va rentrer dans du service vraiment plus complexe, on va avoir des PQ, on va devoir se connecter dessus, on va avoir toute la partie authentification. Ce sont des choses qui vont être beaucoup plus complexes et qui vont être intéressantes d'externaliser dans une couche beaucoup plus standard qu'on pourra plus facilement déplacer. Mais pour très peu de choses, je ne vois pas déployer un cube pour ça. Ça me paraît être vraiment un mastodonte alors qu'on n'en a pas forcément besoin.

• Speaker #5

  Et surtout, l'accès à la donnée est quand même vachement différent. Je sais que des petits clients qui aimaient bien avoir des app services avec un service vraiment packagé complet, si tu le switches sur un cube, s'il a une petite appétence technique, il aimait bien aller voir ses petits logs de son application ou ce genre de choses. Et quand tu passes sur un cube, tout devient un peu compliqué à ce niveau-là. Et du coup, je pense qu'il y a quand même pas mal de clients. Enfin, il faut avoir une certaine taille et surtout une certaine compétence technique si tu veux être un peu autonome sur le truc.

• Speaker #4

  C'est là que la décision se fait entre le service full manager et puis le cube où tu as beaucoup plus la main. Parce que comme tu disais, sur un app services ou n'importe quel service qui va t'héberger juste un conteneur, tu vas avoir les logs qui vont sortir directement, ça va déjà être fait. Tu vas avoir un monitoring de base qui va être fait. Alors que sur un cube, si tu veux avoir ces choses-là, il va falloir que tu outilles le cube. Alors ça se fait, ça se fait très bien, il y a plein d'outils qui sont faits pour le faire, mais il faut le mettre en place, il faut le maintenir, il faut être conscient que pour l'exploit, tu as une charge qui est supplémentaire. Tout ça, ça se chiffre. Tu vois le coût humain sur la maintenabilité et en fonction de ça, on estime si pour le moment, on déploie juste un conteneur dans un service qui va t'héberger un conteneur, qui unitairement va te coûter plus cher qu'un cube si tu comptes au conteneur et si tu oublies la partie surcharge de coût du cube, mais qui sera plus facile à gérer. Et puis après, si on en a plus, on estime qu'on va être plus rentable avec un cube, on fait un cube.

• Speaker #0

  Du coup, si on résume un peu, on se dit que... C'est la cible,

• Speaker #1

  mais ce n'est pas la solution à tout.

• Speaker #0

  Ce n'est pas la solution à tout, oui. Mais du coup, ça constitue quand même un... Je pense notamment à ceux qui ont pas mal d'applications, tout ce qui est grosses PME, etc., à grands comptes. Si beaucoup de monde passe sur du cube, danger imminent pour les clouds ? Non, non,

• Speaker #1

  parce que le... Alors, danger imminent... Dans le fond,

• Speaker #0

  tu peux partir plus facilement.

• Speaker #1

  Oui, oui, après...

• Speaker #2

  Il parle de cloud en cloud. Il parle de cloud en cloud,

• Speaker #1

  donc il n'y a pas de danger imminent. Après, il y a un danger imminent... Et moi, je vois un autre intérêt qu'on n'a pas vraiment dit. Et pour le coup, c'est sur la partie facturation. C'est qu'aujourd'hui, il y a plein de services managés qui vous sont donnés par des cloud providers qui sont inaccessibles pour des questions de coûts. C'est à dire qu'en fait, je vous prenais un mécanisme de queuing, par exemple, ou vous les prenez un mécanisme d'élastique charge ou des trucs comme ça.

• Speaker #3

  À partir du queuing, ce n'est pas la plus cher chez le provider. Ouais, mais là, par contre, la partie cache et l'élastique sort. Ça,

• Speaker #1

  c'est un peu en fait hors de prix parce que leurs services managés sont hors de prix parce qu'en fait, Ils font des trucs qui sont répliqués partout, incroyables. Mais en fait, dans la majorité des applications, tu as besoin d'un petit mécanisme de queuing ou tu as besoin d'un petit Elastic Church dont tu t'embeures en fait. Et du coup, on ne peut pas les utiliser sur les cloud providers parce que trop cher pour des petites applications. Et du coup, on les remet dans le cube. Et là-dedans, je pense qu'effectivement, ils peuvent avoir une petite perte de facturation si jamais les gens se rendent compte que ça fonctionne très bien dans un cube. Oui.

• Speaker #4

  quand même ça demande une mise en place plus complexe que juste de s'abonner à un service et je pense que les entreprises qui prennent ce service là c'est qu'ils ont vraiment pas du tout d'appétence à le mettre sur un cube oui mais en fait je suis d'accord avec ce que tu dis 100%

• Speaker #1

  mais le truc c'est que quand t'as 10 applications t'as besoin de 10 systèmes de cash tu t'aperçois qu'en fait tu te factures 10 fois un truc qui est très cher, alors quand t'as une grosse app c'est pas trop gênant mais quand t'as plein de petites apps ce qui est souvent le cas dans un SI t'as plutôt intérêt à te le remettre toi-même Et ça, je trouve que c'est un peu une déception. Moi, je trouve que c'est personnellement une déception. C'est que dans le cloud, on m'avait vendu le fait que justement, je n'allais plus avoir besoin de gérer ces trucs-là et en fait, je me retrouve à les regérer parce que sinon, ça me coûte trop cher.

• Speaker #0

  Si on rentre un peu juste côté pratique, s'il y a des gens qui nous écoutent et qui se posent vraiment des questions sur le fait de passer à Kubernetes, est-ce qu'il y a des pré-triquis ou en tout cas des conditions où vous avez un petit peu des conseils à leur donner par où commencer, par où prendre les choses ?

• Speaker #1

  Moi, je pense que... Et après, je laisserai plutôt parler les amis du DevOps qui sont bien meilleurs que moi. Mais je pense qu'il y a un niveau compétence réseau qui est important de maîtriser. C'est-à-dire que si vous ne comprenez rien au réseau, n'allez pas dans le cube parce que vous allez mourir. Donc, je pense qu'il faut revoir ces basiques du réseau. Je ne sais pas si vous êtes d'accord avec moi, mais une fois que vous maîtrisez un minimum le réseau, vous pouvez aller vers le cube. Sinon, je pense que c'est vraiment trop compliqué.

• Speaker #5

  Moi, je le vois plus sur la partie si on installe nous-mêmes un cube sur des VM. Là, je suis d'accord que la notion réseau est énorme. Si on déploie simplement dessus, c'est beaucoup des règles logiques qu'on va appliquer et qui en général, par défaut je ne vais pas dire que tout est ouvert à l'intérieur du cube mais quasiment. C'est que j'ai rarement eu besoin de me dire, heureusement que je lui connaissais un peu le réseau parce que sinon je n'aurais pas réussi à le faire. C'est moins le sentiment que j'ai du fait qu'on passe principalement par des Kubernetes managés sur des cloud providers. Tu vois ce que je veux dire,

• Speaker #1

  c'est que tu as tout de suite la notion de load balancing, tu as tout de suite la notion de... Enfin tu as des IP partout tout le temps quoi.

• Speaker #5

  Je ne sais pas, je... je ne vais pas dire que je ne la prends pas en compte, mais c'est rarement là-dessus qu'il y a un problème. Mais après, c'est juste mon avis. Non,

• Speaker #1

  mais tu as le droit. Après,

• Speaker #4

  il y a aussi des compétences importantes sur la virtualisation, sur la docurisation. Ces choses-là, il faut être quand même vachement à l'aise avec ces sujets. Et après, je pense que c'est vraiment de notre utilisation du cloud, comment elle est faite à date. Si aujourd'hui, on a 10 000 services et qu'on se rend compte qu'on est surfacturés, ça vaut le coup d'apporter une réflexion ou de demander à... une société extérieure qui maîtrise encore plus le sujet, de regarder si c'est possible de passer sur un cube.

• Speaker #3

  Moi je rejoins un peu Louis là-dessus, je pense que si on a assez peu de connaissances sur la partie cube, quand on est une entreprise qui veut se lancer dedans, il ne faut pas partir tout seul dessus. Il faut aller voir quelqu'un qui va vous aider à mettre en place une première fois un cube pour voir comment c'est fait, voir comment sont faites les mises en place, parce qu'il y a quand même des notions importantes de sécurité aussi à mettre en place au sein du cube, et qu'il faut se faire accompagner, et après on est capable de reprendre la connaissance par rapport à ce qui a été fait, En ayant un exemple bien fait, bien structuré, de ne pas partir dans tous les sens. Après, sur la partie réseau, je suis un peu d'accord avec toi sur le fait qu'il faut quand même comprendre comment ça marche, comment les liens se font. Après, je pense qu'on sous-estime énormément la complexité réseau des services managés au sein d'un cloud provider. C'est-à-dire que quand on manage des services, qu'on les fait communiquer entre eux, il y a une compétence réseau à avoir pour savoir comment ça marche qui est devenue énorme aussi.

• Speaker #1

  Alors en fait, je pense qu'elle a... Elle a toujours existé, mais avant il y avait une division avec le service infra et on la voyait moins.

• Speaker #3

  Avant tout était dans une VM donc on ne s'emmerdait pas trop.

• Speaker #1

  C'est vrai que aujourd'hui utiliser un cloud provider si vous ne maîtrisez pas le réseau,

• Speaker #3

  Ça, c'est compliqué.

• Speaker #5

  Sauf si vous laissez tout ouvert.

• Speaker #3

  Ah oui, c'est ça. Tu mets 0.0.0 et t'es serein sur un peu partout.

• Speaker #5

  Tu peux accéder à votre infra, il n'y a pas de problème de réseau.

• Speaker #3

  Et puis l'app va rester à peu près ouverte pendant deux heures avant de tomber. Et après, juste sur les prérequis, il y a quand même un prérequis pour les gens qui font du développement applicatif,

• Speaker #1

  c'est qu'il faut penser les applications stateless. Ce n'est pas forcément vrai ce que je dis là, mais c'est quand même...

• Speaker #3

  Si on veut containeriser, il faut que ce soit stateless. Oui, voilà. Puis éteindre un pod et le rallumer.

• Speaker #1

  Et en fait, la conception stateless ou la conception Event-Driven ou tout ce que vous voulez, c'est quand même pas des choses qui sont... Alors, c'est natif, je pense, pour les nouveaux développeurs ou les nouvelles apps. C'est, je pense, beaucoup moins facile pour les gens qui viennent du monde du legacy, qui ont des grosses applications. Et la grosse marche à l'entrée de toutes ces technologies-là, c'est quand même de passer en stateless. Et surtout pas un serverless. Wesh, wow ! Finalement j'ai envie de flipper ce podcast. On a conçu un coup de poignard dans le cœur là !

• Speaker #2

  C'est vrai que je pense quand t'as fait que des développements en stateful, moi j'ai déjà parlé avec des gens qui avaient fait que du Java, Java ou c'était que du stateful, En fait, quand tu leur parles de stateless, t'as l'impression d'être un alien pour eux. Ils comprennent pas la logique, comment c'est possible de ne pas avoir de session, comment tu retrouves tes données.

• Speaker #1

  Quand tu développes un stateless, tu comprends même pas le concept d'avoir une session.

• Speaker #2

  Une session, c'est juste un encombrement pour rien.

• Speaker #4

  Mais en dehors des sessions, dans la conception de l'application, je sais que... Moi, un truc qui m'avait un peu étonné, c'est qu'on se rend compte de manière logique, vu qu'on parallélise nos applications et qu'on peut avoir trois fois la même API qui est en parallèle. Si on a mis un WebSocket sur notre API et que du coup du coup, on a trois WebSockets qui se lancent en même temps. En fait, ton client va se perdre sur qui communiquer. En fait, c'est de la logique, mais il faut vraiment avoir le concept en tête de comment ça fonctionne pour éviter ces petites bêtises ou des erreurs de conception à la base.

• Speaker #3

  Ça pose des problèmes à plusieurs endroits qu'il faut voir. C'est quand on fait tourner plusieurs instances de la même application, genre sur l'écran par exemple, ça pose problème parce qu'on ne va pas lancer 15 batchs en même temps parce qu'on n'a qu'un spot qui tourne. Et après, il y a plein de petites choses comme ça auxquelles il faut penser. On n'y pense pas au départ Mais si on laisse l'appli tourner comme ça avec plusieurs fois la même instance, bah on se plante parce qu'on a des trucs qui passent quatre fois quoi.

• Speaker #0

  Et du coup si on résume, on peut donner quoi comme conseil pour les gens qui se lancent vraiment dedans et qui se lancent dans la config ? Est-ce qu'il y a genre... Alors... Il faut absolument penser.

• Speaker #1

  Ouais il faut lire la doc.

• Speaker #3

  Non mais pour de vrai c'est encore dans sept hyper importants.

• Speaker #1

  Franchement tu peux coder, tu peux développer sans lire la doc parce que t'as des IDE qui t'aident et tout ça. Mais c'est pas une bonne pratique. Mais par contre je veux dire sur cube regarde toi une vidéo d'une heure et demie sur les concepts de base tout ça et seulement après tu peux te lancer c'est pas une technologie que t'apprends sur le tas je pense qu'il faut quand même comprendre les concepts si t'as aucune notion oui mais si t'as un peu des notions d'hypervision etc après

• Speaker #4

  le mieux et si on se sent pas à l'aise non plus c'est de s'entourer quoi c'est de trouver les bonnes personnes et de partir avec eux c'est très pratique apparemment le réseau est natif c'est

• Speaker #1

  C'est simple.

• Speaker #5

  Disons qu'il y a plein d'autres endroits où il y a des problèmes sur Kubernetes quand on configure tout à la main, plus que le réseau. Ce n'est pas ça qui m'a le plus frappé au moins.

• Speaker #0

  Il y a des choses où vous êtes viandé en montant votre premier compte. Jamais non.

• Speaker #1

  Alors nous ça ne nous arrive jamais.

• Speaker #5

  On va voir la question suivante.

• Speaker #1

  Moi je pense que je me suis assez peu viandé sur Kubernetes au sens pur Kubernetes. Par contre je me suis beaucoup viandé sur des applications justement comme disait Grégorye ou en fait parce que tu as plusieurs pods, tu as des batchs qui se déclenchent en asynchrone et que j'avais pas bien compris, qu'on voit pas bien. Et du coup, des fois pour le débugage, ça peut être un peu touchy.

• Speaker #3

  Oui, je suis d'accord. La partie débug, accéder au log dans les conteneurs, etc., c'est souvent la partie un peu pénible. Surtout que... En fait, se voterer, tu te votes pas vraiment, tu fais pas un truc catastrophique, juste ton truc va pas se déployer quoi. Mais arriver à choper le pote qui a voulu restart tout seul au bon moment pour choper les logs qu'il vient juste de supprimer, des fois c'est un peu speed quoi, pour arriver à diagnostiquer le problème. Et puis les logs sont pas toujours explicites dans cube, c'est jamais le truc qui te dit exactement là où est le problème quoi.

• Speaker #5

  En fait y'a plein d'endroits où faut regarder d'une manière... Enfin faut regarder des endroits différents pour avoir des infos différentes Ton conteneur qui ne marche pas, c'est des fois juste les logs du conteneur, des fois c'est les event cubes, des fois il faut aller au-dessus sur l'orchestrateur de pourquoi elle a pu réussir à mettre un node. C'est jamais facile de savoir pourquoi un conteneur se lance pas. Et tout ça,

• Speaker #1

  à la fin, tu te balades dans le truc d'Azure pour voir qu'en fait t'avais atteint un quota, que t'avais pas d'erreurs et que t'avais atteint un putain de quota.

• Speaker #0

  Vous avez encore du temps sur des conneries là ? Franchement après une fois que ça tourne Ça tourne comme une horloge Maintenant c'est Une fois que tout est vraiment bien configuré Quand c'est bien configuré ça tourne tout seul Et ça bouge pas tant que tu le bouges pas il bouge pas

• Speaker #1

  C'est vrai que pour le coup Pour revenir là-dedans C'est une fois que t'as fait toute ton infrastructure Ascode Que t'as tes pipelines qui sont bien développés et compagnie Ok t'as du temps de maintenance mais ça tourne comme une horloge

• Speaker #5

  Après, il faut quand même faire les montées de versions de cube. C'est comme tous les outils, il y a des versions... Il y a quand même des chantiers à faire sur la marque.

• Speaker #0

  C'est douloureux.

• Speaker #5

  De ce que j'ai vu pour l'instant, ça va.

• Speaker #1

  Moi, j'en ai eu une de douloureuse parce qu'ils avaient changé le format de fichier.

• Speaker #5

  C'était plus du YAML.

• Speaker #1

  Si c'était du YAML, mais dans un autre format libre. Mais sinon, ça se passe bien quand même.

• Speaker #0

  Et juste pour résumer, pourquoi on conseillerait donc de passer à Kubernetes si ce n'est pas encore fait ? plutôt pour des boîtes qui ont une petite maturité, et surtout ici avec plusieurs applications.

• Speaker #1

  Moi honnêtement, si vous avez plus de deux applications, il faut passer là-dessus, c'est clairement la cible.

• Speaker #3

  C'est plus de deux applications ou une application avec pas mal de complexités, c'est-à-dire une appli où il y a l'appli, le back, le front, un elastic search, un mécanisme de cache, du queuing...

• Speaker #1

  Quand tu dis que tu es un Qtist,

• Speaker #3

  tu es plein de composants ! Plein de composants différents dans une appli, effectivement c'est plus simple parce qu'on gère tout en plus As-Code sur la partie déploiement. Donc ça rationalise un peu les choses et il n'y a pas une grosse surcomplexité à avoir un cube sachant déjà l'appli est complexe quoi.

• Speaker #5

  Après je pense que c'est quand même vraiment complexe un cube. Il y a toute une notion de fonctionnement, service etc. Et nous lorsqu'il va être la configuration on va devoir configurer un ingress devant pour pouvoir router les différentes requêtes.

• Speaker #1

  Tu faisais pareil avec Nginx avant ? mais là c'est pas pareil quand tu mets ton Nginx sur ton queue je suis d'accord que avant c'était ça mais là c'est pas pareil, tu le gères pas de la même façon non on faisait ça avec Greg on faisait des espèces de clusters avec des VM sur VMware ça marchait pas si mal on faisait même des clusters avant sur des baremetals après ça se faisait à qui ?

• Speaker #0

  ça marchait pas ouf vous êtes jamais content dans l'informatique je serais déséquipant

• Speaker #5

  C'est juste pour dire que c'est quand même vraiment compliqué. Avant de le faire, il faut bien se poser. Le fait de se dire que ça permet aussi de se détacher du cloud provider, je ne vais pas dire que c'est plus ou moins vrai, mais ça apporte moins d'adhérence qu'un service managé plus complexe, typiquement RDS. Mais c'est quand même très lié. Tout ce qui va être stockage, ça va être les disques du cloud provider. Les VM, ça va être les VM du cloud provider. Tout ce qui va être load balancer, ça va être des load balancers du cloud provider. Si vous allez partir, vous allez quand même le faire... Un peu dans la douleur. Toutes les configs de votre cube, vous allez peut-être devoir les refaire parce que chacun les gère un peu différemment. Donc il ne faut pas se dire « je passe sur cube, comme ça je change de cloud provider pour ces années » .

• Speaker #1

  C'est pas un cube droit save ?

• Speaker #5

  Mais c'est sûr parce qu'il l'a fait pour plusieurs cloud providers. On va peut-être demander des fois de pouvoir remonter automatiquement un cube sur notre cloud provider en cas de problème.

• Speaker #1

  Très bonne demande !

• Speaker #0

  Merci en tout cas pour vos éclairages sur le sujet. Philippe, tu n'avais pas un coup de cœur à nous partager ? Vous ne voyez pas, mais sur la table il a un super télé.

• Speaker #1

  Non, non. J'ai acheté un clavier pour iPhone. C'est une coque clavier.

• Speaker #2

  On revient dans les années 2000, quoi. Avant on enlevait les claviers, maintenant on les rebaît.

• Speaker #0

  Est-ce qu'on pourrait faire un point d'historique sur tous les téléphones et les changements de téléphone ?

• Speaker #1

  Moi j'ai toujours... Ouais, c'est ça.

• Speaker #3

  Il y a toujours une nostalgie en fait. Ouais, il y a toujours une nostalgie.

• Speaker #1

  Bah tu sais, on veut revivre son adolescence. C'est souvent une erreur. Et du coup j'ai acheté une coque clavier qui honnêtement redonne la sensation d'avoir un BlackBerrys qui était plutôt sympathique Après, le problème, c'est que les téléphones ont un tel format aujourd'hui que vous rajoutez un clavier qui doit faire peut-être un quart de la taille du téléphone. Donc ça vous fait des téléphones qui sont vraiment grands.

• Speaker #3

  Pour se donner une idée du téléphone, ça doit bien faire 20 bons centimètres de haut. En plus, le pire, c'est qu'à l'usage, ce n'est pas tellement la taille... Je vais critiquer.

• Speaker #0

  C'est une pièce de thé qui compte, c'est ça ?

• Speaker #3

  Merci Camille. Je te laisse tes propos. Ce n'est pas tellement la taille, c'est que le clavier est trop léger. Ouais, et puis on tape pas bien avec. Si, c'était carré. Non,

• Speaker #1

  c'était à peu près pareil. Mais comme il est plus léger que le téléphone qui est très dense, ça donne un objet qui n'a pas une densité homogène. Ils auraient dû alourdir le clavier, je pense.

• Speaker #5

  Ils auraient eu un téléphone qui aurait doublé de poids.

• Speaker #1

  Oui, mais je pense que ça aurait été... Non,

• Speaker #3

  ce n'était pas nécessaire, vraiment.

• Speaker #5

  Tu me dirais que ça n'a pas été fait pour.

• Speaker #4

  C'est bizarre.

• Speaker #5

  Ça me surprend quand même.

• Speaker #4

  Ce qui me surprend le plus, c'est que je m'attendais vraiment à un clavier rétractable dans ta coque et que vraiment ce soit un add-on en bus. Oui, mais tu sais, tu slides et tu puisses t'en servir. Non, non, c'est lourd.

• Speaker #1

  J'espère qu'il y a une batterie complémentaire dedans. Le seul truc positif, ça génère des conversations.

• Speaker #3

  C'est-à-dire que quand je le sors n'importe où, il y a un mec qui dit « C'est quoi ? » Ah ben, tu mets ton âge. On a essayé de miniaturiser les téléphones depuis à peu près 25 ans. Ouais, c'est ça. Alors, non, nos petits 15 ans, ils grossissent comme des pas possibles. Je ne me souviens pas... Il y a une époque où on avait les trucs qui... Je vais être un peu vieux, mais on a tous commencé avec des Nokia 5110 ou 3310, où c'était des frigos. Et après, il y a eu le petit téléphone qu'il y avait dans Matrix. Il y avait une inviable quelque chose là, tout minuscule. Puis après, on a commencé à avoir des smartphones qui intégraient le clavier. Donc forcément, c'était plus grand. Là, tu as rajouté au smartphone...

• Speaker #1

  un clavier mais le problème ils ont commencé à abandonner les formats de téléphone mini ils n'en font plus maintenant Même qu'ils vont faire un téléphone pliable, quelle abomination.

• Speaker #2

  Mais est-ce que c'est bien intégré au moins à iOS ? Ah ouais, par contre ça fonctionne. Est-ce que genre tu... Ouais,

• Speaker #1

  ça fonctionne direct. Il y a des bugs ou ça... Non, pour le coup ça fonctionne plus, tu peux plus taper.

• Speaker #5

  Tu peux plus charger ton téléphone donc.

• Speaker #1

  Je disais que je peux peut-être plus taper au clavier mais je peux te taper avec. Ça muscle les pouces en plus du coup. T'as peur ?

• Speaker #5

  T'as un autre port USB en dessous pour recharger. Oui,

• Speaker #1

  en fait ça se branche sur le port USB et ça te déporte ton port USB.

• Speaker #5

  C'est un bon exemple de la virtualisation.

• Speaker #1

  Un peu plus lent.

• Speaker #0

  C'était bien ça comme le mot de la fin. Merci à tous de nous avoir écoutés aujourd'hui. Merci à vous d'être venus donner vos avis et puis on espère que ce premier épisode vous aura plu. On se retrouve le mois prochain pour voir si Philippe a toujours son abomination sur son téléphone. Salut salut !