Nigel Kersten

[00:00:02] Alors d'abord, salut, je suis Nigel Kirsten. Euh, j'apprécie vraiment que vous soyez tous là, avant-dernière session de la journée, euh, après, après que vous ayez déjeuné. Euh, ça, ça signifie beaucoup. Je ne m'attendais pas à une foule aussi nombreuse. Je, certains d'entre vous ont peut-être vu, je ne sais pas si vous avez vu Fastflow Conf à Londres, la conférence sur les topologies d'équipe, j'y ai donné une version de cette présentation que j'ai pas mal mise à jour depuis. Il y avait un petit-déjeuner différent, il y avait du vegemite, parce que c'est ce que nous mangeons en Australie. J'ai aussi réalisé que tous les Français ne mangent pas de croissants au petit-déjeuner, tout comme je ne me bats pas avec des crocodiles en Australie pendant mon temps libre.
[00:00:38] Donc, je ne pense pas, je pense que beaucoup de gens ici ne me connaissent probablement pas. Euh, je ne suis pas revenu en France depuis un bon moment pour le travail. J'étais SRE chez Google pendant plusieurs années au milieu des années 2000. J'ai rejoint Puppet très, très tôt, euh, au début. Je devais expliquer à tout le monde ce qu'était DevOps, et à la fin, je devais expliquer aux gens pourquoi DevOps n'était pas ce qu'ils pensaient que c'était, euh, après ces 12 années. J'ai aussi passé l'année dernière à travailler dans une entreprise appelée Signadia qui fabrique nats.io. Euh, et je vous recommande vivement si vous cherchez un système de bus de messages natif cloud, un courtier de données, c'est absolument incroyable. Allez voir nats.io. Ce sur quoi une grande partie de cette présentation est basée, c'est que j'ai passé 11 ans, ce qui semble un peu ridicule avec le recul, à écrire des rapports sur l'état du développement. Donc, au début, nous avons commencé chez Puppet, nous avons fonctionné pendant quelques années, nous avons intégré tous les gens de Dora, euh, nous avons fait des rapports DevOps ensemble pendant quelques années, nous avons fini par nous séparer et faire ceux qui ont été gérés par Google pendant un certain temps. Mais ensuite, nous avons fait venir des gens de Team Topologies, Manuel et Matt, qui ont fait un très, très bon travail. Et donc il y a cette très bonne image du début où l'on se demande : qui fait réellement du DevOps ? Qu'est-ce que c'est ? Pour à la fin, tout le monde est un peu post-DevOps et se demande : quelle est la prochaine étape ? L'ingénierie de plateforme, l'ingénierie des flux, comment voulons-nous aborder ces choses ? Je pense que je suis à peu près ex-DevOps maintenant, et on m'a demandé de faire cette conférence après mon départ de Puppet, parce que je pense que c'était la première fois que je ne travaillais pas chez un fournisseur DevOps, euh, et donc je pouvais peut-être être un peu plus honnête, euh, que je ne l'avais été au cours des cinq dernières années, des années précédentes. Euh, vous pouvez me trouver sur Mastodon. Euh, je ne, je suis sur Twitter, mais je ne l'utilise plus vraiment beaucoup, ou LinkedIn.
[00:02:20] Maintenant, je sais que ce n'est pas un vrai diagramme de Venn. Je l'ai dessiné à la main, enfin, avec un outil de diagramme plus tôt dans la journée et j'ai réalisé que ça ne se chevauchait pas correctement. Mais vous allez, je vais beaucoup parler de DevOps dans cette présentation, mais vous pouvez substituer de nombreuses manières, je pense, le flux, l'ingénierie de plateforme, l'Agile. Beaucoup de ces choses concernent non pas nécessairement la pratique technique, mais la façon dont nous travaillons, euh, et elles sont toutes, je pense qu'elles sont toutes des mouvements qui ont appris les uns des autres.
[00:02:45] Vous savez, les marques sont importantes, euh, de temps en temps, il faut rafraîchir sa marque, et je pense que ce groupe de personnes, vous savez, je crois que cette conférence a commencé comme une conférence Lean Kanban, maintenant c'est une conférence sur le flux, c'est toujours le même sujet. Donc quand je dis DevOps, substituez un peu ce qui vous semble le plus pertinent.
[00:03:05] C'est Diogène, qui a fondé le cynisme, euh, c'est la boucle DevOps infinie pour ceux d'entre vous qui n'ont pas eu ça imposé par les fournisseurs au cours de la dernière décennie environ. Euh, je ne suis pas super cynique à propos de DevOps. Je crois réellement en toutes ces choses de nos jours. J'en ai un peu marre de l'engouement autour de beaucoup de ces mouvements, mais je pense que prendre du recul et réfléchir à la façon dont nous travaillons, et pas seulement au travail que nous faisons en tapant sur le clavier, est super important. Et c'est ce qui nous permet de mieux travailler, mais aussi d'être plus heureux au travail. Donc, je suis un peu idéaliste, en fait.
[00:03:41] Donc si vous n'avez pas compris le titre du sujet avec lequel j'ai commencé, le logiciel mange la culture au petit-déjeuner. Peter Drucker, qui est en fait un PDG consultant en gestion américain, qui avait juste les petites déclarations les plus incroyables et concises. Il disait de petites choses et y capturait beaucoup de sens. Et sa grande phrase était : la culture mange la stratégie au petit-déjeuner. Et ce qu'il entendait par là, c'est qu'une entreprise avec une très bonne culture qui travaille ensemble, qui peut se concentrer sur des idées, qui peut accomplir des choses, même avec une mauvaise stratégie, va battre une entreprise dysfonctionnelle, où tout le monde se déteste, mais qui a une excellente stratégie. Euh, je pense que c'est vrai, en quelque sorte. Mais je pense aussi que nous pouvons parfois, dans l'espace où nous nous trouvons tous, l'espace de réflexion sur la façon dont nous travaillons, nous pouvons trop penser à la culture et en quelque sorte oublier que nous travaillons dans une industrie technologique et que les grands changements qui peuvent réellement se produire sont en grande partie dus à la technologie. Ils nous offrent les opportunités que nous pouvons saisir. Donc, je dis essentiellement que je pense que dans la plupart des grandes organisations en particulier, les efforts délibérés pour susciter le changement culturel ont tendance à échouer, à moins qu'une technologie n'ait rendu ce changement possible. Je vais donc vous donner quelques exemples.
[00:04:56] Combien d'entre vous ont vu cette citation ?
[00:05:00] Allez, il faut être honnête. 70 % de toutes les gestions de changement organisationnel échouent. Quand j'ai écrit cette conférence pour la première fois, je me suis dit : oui, c'est un excellent point de départ.
[00:05:10] McKinsey a cité, la Harvard Business Review, Forbes, Accenture, Cognizant, toutes ces différentes entreprises. Ce n'est pas du tout vrai en fait.
[00:05:19] Il y a une très bonne vidéo que David Jay Wilkinson a faite. Mais en substance, il a cherché à trouver la source originale de cela, et il s'avère que c'est un mythe absolu, et il n'y a aucune preuve derrière cela. Ce n'est pas une affirmation basée sur des données. Et si vous regardez la déclaration originale, parce que j'ai passé un certain temps à parcourir les liens de sa vidéo et à la retrouver. C'est que ces gars, écrivant un livre en 93 sur la réingénierie de l'entreprise, avant que la transformation numérique ne soit une chose, avant que la gestion du changement ne soit la chose, notre estimation non scientifique est que jusqu'à 50 à 70 % des organisations qui entreprennent un effort de réingénierie n'atteignent pas les résultats spectaculaires qu'elles attendaient. Et puis vous déballez ça, et c'est comme si, si vous pensiez faire des choses incroyables, mais que vous étiez juste bon, cela compte comme un échec. Au moment où cette déclaration a traversé le jeu du téléphone, si c'est le jeu que vous décrirez ici, euh, 30, nous voici, 30 ans plus tard, les gens répètent encore cela sans cesse. Mais je pense que bien plus d'efforts délibérés de changement culturel à grande échelle échouent qu'ils ne réussissent. Euh, c'était une grande partie de ce que je faisais chez Puppet au cours des cinq dernières années, travailler avec de grandes multinationales, non seulement pour implémenter la technologie, mais aussi pour faire la redoutable chose de la consultation, car il s'avère que vous ne pouvez pas simplement implémenter une automatisation à grande échelle dans une entreprise de 30 000 personnes sans avoir à changer votre façon de travailler.
[00:06:45] Si vous continuez à suivre les mêmes vieux processus, vous obtiendrez les mêmes vieux résultats, même si une petite partie a été optimisée.
[00:06:55] Et donc je pense, je ressens vraiment fortement ceci, que si vous regardez où nous en sommes aujourd'hui, toutes les choses que nous sommes réellement capables de faire, lorsque nous essayons de faire du flux rapide, lorsque nous essayons de faire de l'ingénierie de plateforme, d'essayer de faire du DevOps, d'essayer de faire de l'Agile. La plupart de ces choses sont en fait très, très difficiles sans certaines des grandes avancées technologiques que nous avons eues. Nous avons eu une conversation plus tôt dans le discours de Dragan sur Git contre SVN, et comment le contrôle de version distribué a fondamentalement changé la façon dont nous pouvions travailler. Certaines choses comme GitHub et mieux pire plutôt que mieux, euh, mais je pense quand vous revenez aux anciens jours d'utilisation de RCS, Perforce, CVS, ce n'était pas génial. Il y avait beaucoup de temps perdu et une charge cognitive élevée. J'étais curieux à ce sujet, j'ai cherché sur Google "culture DevOps". Euh, je ne sais pas, je commence à devenir un vieil homme à barbe grise maintenant, et, mais je pense qu'il y a 12 ou 13 ans, quand je suis allé aux premières journées DevOps à Gand, ce modèle a vraiment commencé avec des gens parlant de culture. Et c'est devenu une chose où tout le monde, il y aurait des conférences sur la culture, des parcours sur la culture. Et ça a commencé à me tracasser parce que mon, mon parcours est en fait en philosophie et en linguistique. Et donc je me disais, nous n'avons pas vraiment de bonne signification pour ce mot, la façon dont nous le jetons tous à la figure.
[00:08:10] Donc je vais juste parcourir, vous pouvez trouver à peu près tous les modèles PowerPoint possibles ont été utilisés pour créer une diapositive de mesure et de partage de l'automatisation de la culture. Nous avons les roues rondes. Nous avons les piliers grecs ici où les gens ont commencé à se jeter à l'eau quand Jez Humble l'a fait. Nous avons de petites icônes diverses pas tout à fait sûr qu'elles aient vraiment un sens. Nous avons une autre présentation PowerPoint, un autre modèle PowerPoint, nous en avons un autre. Nous avons des cours là-dessus, nous avons des pyramides, nous avons des cercles virtuels, nous avons de terribles jeux de mots sur les affiches anglaises de guerre.
[00:08:48] Et puis celui-ci où vous pouvez réellement obtenir une certification en culture DevOps et j'ai masqué l'entreprise. Pour ceux qui ne comprennent pas cette référence, si vous avez déjà entendu l'expression "sauter le requin" en anglais. Cela remonte à un épisode de Happy Days, qui est une très, très vieille émission de télévision, où, dans une tentative désespérée de stimuler l'audience, ils ont fait sauter la star de l'émission par-dessus un requin en ski nautique. Euh, ce gars était auparavant une sorte de voyou en blouson de cuir, donc ça n'avait absolument aucun sens. C'est donc le Fonz, qui saute le requin.
[00:09:19] J'ai également partagé ce blâme. J'ai passé des années et des années à rédiger ces rapports d'état d'avancement, et pendant longtemps, nous avons parlé de culture sans vraiment remettre en question. Parce que, vous savez, nous pensions savoir ce que nous voulions dire quand nous disions culture, mais il s'avère que la plupart du temps, les gens ne savaient pas. Ils ne savaient tout simplement pas ce que cela signifiait. Alors j'ai fini par discuter avec quelques amis qui faisaient de l'anthropologie, littéralement l'étude de la culture. Et cela n'a même pas de définition utile en ce sens. La culture est cet ensemble complexe qui inclut la connaissance, la croyance, l'art, la loi, la morale, la coutume et toute autre capacité et habitude acquises par les êtres humains en tant que membres d'une société. C'est littéralement tout ce que nous faisons au travail. Ce n'est pas particulièrement utile. Euh, il y a quelques attributs différents ici qui commencent à être un peu plus utiles. Mais je pense que ce que nous avons vu avec tout le, et c'est là que je deviens un peu cynique, euh, les gens de Devrell dans l'espace des fournisseurs de développement, comme des gens qui n'avaient pas nécessairement de profils techniques approfondis, ont commencé à parler des cultures qu'ils essayaient d'atteindre sans comprendre ce qui se passait réellement. Et mais quand je dis technique ici, je déteste un peu la façon dont c'est utilisé comme une arme dans l'industrie technologique parfois. Je veux juste dire que les gens sont conscients de la façon dont nous construisons des logiciels, ce qui est bien plus que de simples programmeurs.
[00:10:35] Manuel, je pense que c'était de Team Topologies, a trouvé une citation pour l'un des derniers rapports sur l'état d'avancement que j'ai faits, que j'ai trouvée absolument brillante, où il disait : penser à vos problèmes organisationnels comme à une culture, ce n'est pas utile ou actionnable. Et j'avais souvent vu ça dans les grandes organisations, on se disait, allons implémenter ça. Ils répondaient, eh bien non, on ne peut pas, notre culture ne fait pas ça. Cela commence à ressembler au changement climatique, où vous vous sentez en tant qu'individu, impuissant. C'est un sujet trop vaste pour agir concrètement et l'améliorer. Alors, d'où tout cela est-il revenu ?
[00:11:09] L'une des choses que nous avons faites de nombreuses années auparavant, et que vous avez probablement vue dans le livre Accelerate, une grande partie de cela est venue des rapports sur l'état d'avancement que nous avons tous faits ensemble. C'est Nicole qui, je pense, a été la première à trouver le modèle de culture organisationnelle de Western.
[00:11:23] Et ils avaient une signification vraiment spécifique. Le modèle de réponse de l'organisation aux problèmes et opportunités qu'elle rencontre. C'est beaucoup plus précis que la définition anthropologique. Et vous avez peut-être vu cette idée d'avoir différents types de cultures de modèles, l'orientation pouvoir, l'orientation règles et l'orientation performance. Et nous avons tous commencé à suivre cette sorte de culte du cargo, selon lequel nous devrions nous diriger vers la droite ici. Je vais soutenir ici que beaucoup de ces choses ne peuvent être corrigées que dans une grande organisation, pas une entreprise que vous construisez à partir de zéro, parce qu'à bien des égards, il est facile d'implémenter de nouvelles idées, mais si vous essayez de changer une grande organisation, vous ne pouvez pas réellement faire la plupart de ces choses et passer de la gauche à la droite sans changement technologique.
[00:12:10] Et je pense que c'est le logiciel qui crée ces possibilités. Maintenant, je ne veux pas vous faire croire que je pense que toutes les, vous savez, clairement je ne pense pas que les sciences humaines et les arts libéraux sont des bêtises, vous savez, c'est ce à quoi j'ai consacré une grande partie de ma vie. Mais, et je ne pense pas que la technologie réponde absolument à tout, mais je pense qu'elle crée les possibilités. Et particulièrement si vous êtes en position de leadership, commencer à réfléchir aux aspects sociaux de la technologie lorsque vous la déployez, au sein de votre organisation et avec vos clients, est l'une des choses les plus utiles que vous puissiez faire. Je ne suis pas un utopiste technolibertaire. Je ne crois pas que nous allons, si nous mettons tous le gouvernement sur la blockchain, la démocratie fonctionnera soudainement correctement. Je pense juste que les humains sont beaucoup plus compliqués que ça. Mais je pense que la technologie fait progresser de manière utile. Ce n'est pas toujours bon, euh, mais ça nous offre des opportunités. Donc, si vous êtes un chef d'équipe, un cadre, un manager, une personne senior dans votre entreprise, regarder ce que la technologie fait pour la façon dont les gens changent leurs interactions les uns avec les autres, je pense que c'est super, super important.
[00:13:14] Si vous ne savez pas qui est Taylor, c'est lui qui a inventé la gestion scientifique, qui était essentiellement l'assemblage, le précurseur des chaînes de montage avec Henry Ford. L'idée est de prendre un travail, de le diviser en petites parties et de dire : ton travail est juste de faire ça. Tu estempes ce petit bout, tu estempes ce petit bout. Et c'était la mentalité prédominante pour la construction de logiciels dans les années 90, quand j'ai commencé à travailler. C'était que vous auriez des personnes spécialisées qui avaient des rôles spécifiques dans le pipeline, la méthode de livraison en cascade, et elles optimisaient pour cela. Mais je pense que, comme nous l'avons vu, nous l'avons vu dans la dernière keynote, vous savez, les optimisations locales sont nulles, elles réduisent l'efficacité du système global.
[00:13:56] Il y a des choses que le logiciel ne résout pas. Euh, juste pour que vous réalisiez, il y a encore des choses sur lesquelles nous devrions travailler, le sexisme, la méchanceté, le favoritisme, le capacitisme, la peur, le manque de clarté dans les objectifs, être terrible en planification et en communication, ne pas être capable d'écrire les choses pour que d'autres personnes les comprennent. Toutes ces choses ne peuvent pas vraiment être corrigées par le logiciel. Mais il y a énormément de choses qui affectent la façon dont nous interagissons les uns avec les autres que vous pouvez corriger. Vous pouvez corriger vos boucles de rétroaction, la facilité et la rapidité avec lesquelles vous pouvez expérimenter, à quel point est-il possible au sein de l'organisation pour quelqu'un de dire, vous savez quoi, essayons de construire une nouvelle fonctionnalité, voyons si cela fonctionne comme ça ou un tout nouveau produit. La technologie peut rendre ces choses possibles. Elle ne les fait pas se produire automatiquement, mais elle facilite leur démarrage.
[00:14:44] Nous devons donc réfléchir à l'impact social des choix techniques. J'ai l'impression d'avoir beaucoup de mises en garde ici parce que je pense qu'il est très facile, en tant que technologues, de tomber amoureux de la technologie et de penser qu'elle résout tous les problèmes. Mais je suis sûr que quelqu'un à cette conférence, je n'en ai pas encore vu, a parlé des systèmes sociotechniques. C'est très, très important depuis un certain temps maintenant. Mais la réalité est,
[00:15:08] si vous changez le travail que les gens font, les tâches, cela change les gens, vous apprenez à faire de nouvelles choses, espérons-le, pas toujours la même chose. Euh, si vous implémentez une nouvelle technologie, cela change les tâches qui peuvent être effectuées, cela peut changer la structure de l'organisation, toutes ces choses s'influencent mutuellement. Euh, et je pense que c'est la chose la plus importante que nous devions réaliser, c'est que nous ne nous contentons pas de déployer la technologie, nous modifions en quelque sorte un grand système sociotechnique pour tout ce qui est plus que, vous savez, deux personnes assises dans un sous-sol à écrire des logiciels. Donc, je, c'est essentiellement la thèse. Après avoir essayé de faire cela dans de nombreuses organisations, et je pense que cela peut être difficile quand vous êtes dans le conseil, car personne ne veut vraiment parler de ses échecs, mais je n'ai jamais vraiment réussi à changer fondamentalement le fonctionnement d'une organisation.
[00:15:56] sans changer la technologie qui y était déployée. Il est trop difficile d'enlever le tissu cicatriciel organisationnel. Je, l'une de mes convictions fondamentales est que la meilleure chose que le cloud ait jamais faite a été de permettre aux gens de faire exploser leurs organigrammes. Cela leur a permis de se dire, vous savez quoi, peut-être que nous n'avons pas besoin de l'équipe réseau, de l'équipe de stockage, de l'équipe de calcul, de l'équipe de sécurité, toutes ces étapes d'approbation séparées. Une fois que les choses sont devenues en libre-service et qu'il y a une API derrière elles et que nous pouvons en quelque sorte mettre des garde-fous autour des choses mais donner accès à plus de personnes, cela a permis aux gens de faire exploser leurs organigrammes. Et je pense que la raison pour laquelle nous voyons des gens revenir du cloud n'est pas seulement parce que les grandes entreprises de cloud sont un peu maléfiques, mais parce que c'est cher, mais aussi parce qu'elles ont appris qu'il existe différentes façons de travailler. Et je pense que je ne peux pas penser à un exemple où j'ai déjà vu une organisation dire, vous savez quoi, nous allons fondamentalement changer la façon dont nous faisons tout sans changer la technologie que vous avez déployée.
[00:16:58] Donc, c'était l'une des grandes choses qui a commencé à me tracasser, où je me disais, vous savez, si vous pensez à, je ne sais pas combien de personnes ici sont des gens d'opérations ou des SRE, mais si vous regardez ce que des outils comme l'infrastructure en tant que code ont fait. Ce qu'ils ont fait, c'est qu'ils ont pris cette matière qui était auparavant la connaissance des grands prêtres des administrateurs système qui devaient aller faire vos changements par vous-même. Euh, et ils devaient toujours répondre à une demande de quelqu'un d'autre, faire du travail pour eux, ce qui est une relation quelque peu antagoniste. Mais je pense que si nous regardons l'une des plus grandes choses qui se sont produites dans le mouvement DevOps, c'était la joie de choses comme
[00:17:33] Ansible, Chef, Terraform, Puppet, même les charts Helm, comme ils commencent à créer ces abstractions que vous pouvez transmettre à d'autres personnes. Et vous devez trouver le bon niveau d'abstraction, parce que quand c'est faux, c'est douloureux pour ceux qui le fournissent, et c'est douloureux pour ceux qui le consomment. Mais je pense que nous devons être très prudents lorsque nous essayons de faire progresser la culture de notre façon de travailler, de ne pas essayer de le faire sans penser à la technologie.
[00:18:02] Je ne pense pas que vous auriez pu faire du DevOps ou même de l'ingénierie de plateforme moderne, ou de l'ingénierie de flux, ou quoi que ce soit de tout cela sans ces technologies. Pour ceux d'entre vous assez âgés pour se souvenir de ce que c'était avant la virtualisation et le cloud, vous étiez fondamentalement limités. Pour installer un nouveau système, avant le démarrage PXE, avant toutes ces technologies que nous avions, les gens entraient littéralement dans les centres de données avec des cache-oreilles parce que c'était si bruyant, inséraient des CD, tapaient douloureusement pendant 20, 30 minutes, partaient et revenaient. Comment faites-vous la livraison continue comme ça ? Comment mettez-vous en place des environnements de test très rapidement ? Certains y sont parvenus, mais ce n'était certainement pas facile, et ils se sont battus contre la technologie tout au long du processus.
[00:18:46] Je pense que c'est une parenthèse pour moi. Je pense que l'une des choses les plus importantes qui a changé toute notre industrie a été les API REST simples et de meilleurs langages de haut niveau. Vous savez, dans les années 90, quand j'ai commencé à utiliser des logiciels, vous écriviez du Basic, des scripts shell, ou du C++ ou du Java, vous savez, il n'y avait pas beaucoup d'espace entre les deux. Perl est apparu, mais vous savez, Perl est un langage qu'on écrit une fois, qu'on ne relit jamais. Euh, mais ensuite nous avons eu Python, nous avons eu Ruby, nous avons eu tout un tas d'autres choses qui étaient beaucoup plus faciles pour les gens, et les API sont devenues plus simples. Vous ne faisiez pas d'XML RPC, vous ne faisiez pas de SOAP. Et je pense que, en simplifiant les choses et en les exposant à un public plus large, vous obtenez de nouveaux cas d'utilisation et des mouvements comme DevOps n'auraient pas eu lieu, je pense, sans toutes ces sortes de choses. Je ne sais pas pour moi. Je pense que l'une des choses les plus importantes qui a changé toute notre industrie a été les API REST simples et de meilleurs langages de niveau supérieur. Dans les années 90, quand j'ai commencé à utiliser des logiciels, vous écriviez du Basic, des scripts shell ou du C++ ou Java. Vous savez, il n'y avait pas beaucoup d'espace entre les deux. Perl est apparu, mais vous savez, Perl est un langage qu'on écrit une fois, mais qu'on ne lit jamais. Mais ensuite, nous avons eu Python, nous avons eu Ruby, nous avons eu tout un tas d'autres choses qui étaient beaucoup plus faciles pour les gens. Et les API sont devenues simples. Vous ne faisiez plus d'XML RPC, vous ne faisiez plus de SOAP. Et je pense que, en rendant les choses plus simples et en les exposant à un public plus large, vous obtenez de nouveaux cas d'utilisation et des mouvements comme DevOps. ne se serait pas produit, je ne pense pas, sans toutes ces choses.
[00:19:33] L'un de mes grands bêtes noires, c'est quand les gens essaient de, il y a toujours quelqu'un qui est, vous savez, la personne heureuse et brillante au sein d'une organisation qui dit, vous savez quoi, nous devons tous simplement collaborer davantage. La collaboration est un peu affreuse.
[00:19:44] quand vous essayez de travailler. Nous n'utilisons pas, si vous pensez aux plateformes, par exemple, vous savez, vous n'utilisez pas tous Google Cloud ou Azure ou Amazon parce qu'ils collaborent avec vous. Vous l'utilisez parce que vous ne parlez jamais à une personne. Et vous n'avez qu'à cliquer sur un bouton ou à lancer un appel API. Je pense que l'une des choses sur lesquelles nous avons trop mis l'accent et sur lesquelles nous nous sommes trop fixés est que tout tourne autour des interactions humaines. Et vous savez, je dois pouvoir parler à cette personne, et ensuite nous trouvons ce qui est le mieux, et ensuite nous allons réparer quelque chose. Ce qui est mieux, c'est de ne jamais avoir à parler à personne de nombreuses façons. Pas tout le temps, mais pour une grande partie de votre travail, vous ne voulez pas attendre quelqu'un d'autre. Vous savez, vous voulez soit être là avec eux, travailler ensemble sur la chose, soit pouvoir faire quelque chose et que cela se produise automatiquement. C'était, je pense, la grande joie de l'automatisation. La collaboration n'est donc pas toujours une bonne chose. J'ai un peu râlé à ce sujet, il y a un tas de problèmes autour du brainstorming collectif. Si vous avez déjà participé à une séance de brainstorming inutile, c'est l'une des choses les plus douloureuses au monde. Ce n'est pas le cas, une très bonne séance d'idéation guidée peut très bien fonctionner. Mais c'est l'une des choses les plus importantes. Solomon Asch, qui est un psychologue incroyable, la vie en société exige un consensus. Nous devons tous nous entendre, nous devons tous être d'accord. Mais pour un consensus productif, chaque individu doit pouvoir contribuer de manière indépendante. Parce qu'il s'avère que nous sommes tous en fait plus stupides lorsque nous sommes en groupe. Certaines personnes ont peur de proposer leurs meilleures idées. Certaines personnes pensent vite, d'autres pensent verbalement, et c'est pourquoi elles gagnent toujours les prix. D'autres sont lentes, elles prennent leur temps et proposent une meilleure idée. Les sessions de brainstorming en temps réel sont souvent un très, très mauvais moyen de trouver de nouvelles idées. C'est l'une des grandes choses que l'on voit, il y a toutes ces données qui le montrent, la régression vers la moyenne. La plupart des gens veulent s'intégrer. Ils ne veulent pas vraiment se montrer. Et donc vos personnes les plus intelligentes resteront souvent là et seront aussi stupides que la personne moyenne. Parce que c'est plus facile socialement et que les récompenses globales pour eux sont meilleures. Il y a de nombreuses bonnes façons de faire de l'idéation : amener les gens à trouver des idées, les rassembler en groupe et les débattre tous ensemble. Laisser cela se produire de manière asynchrone, puis faire en sorte que la priorisation réelle se produise de manière synchrone.
[00:22:06] Mais le brainstorming n'est pas une bonne chose pour toujours.
[00:22:11] Donc, une grande partie de cela, l'un des derniers supports DevOps que nous avons faits, était de se concentrer sur le travail avec les gens des topologies d'équipe, ce qui, je pense, intéresse le plus ce groupe. Et en gros, nous avons enquêté, je pense, sur ce que nous avons calculé, c'était 140 000 organisations sur 11 ans. En reprenant les données, nous avons montré que la plupart des organisations étaient freinées dans leur évolution vers des niveaux supérieurs. Je n'aime pas utiliser le terme de modèle de maturité car cela implique un état mature où l'on a terminé. Je pense qu'il s'agit plutôt de créer un état où l'on continue d'évoluer. La structure et la dynamique organisationnelles sont ce qui freine la plupart des gens. Et quiconque a travaillé dans une grande organisation, euh, cela semble, cela devrait probablement résonner en vous. Ce fut certainement le cas pour moi lorsque je travaillais au sein de grandes organisations très bureaucratiques. Les données ont montré que la plupart des organisations qui fonctionnaient très, très bien avaient des équipes de plateforme, dont le travail était de construire quelque chose pour que les personnes internes puissent le consommer.
[00:23:08] Et des équipes alignées sur les flux, où ils disaient, notre travail est de livrer une certaine quantité de valeur à quelqu'un. J'aurais pu coller des chaînes de valeur sur ce diagramme original, avec Agile et DevOps, car je pense que beaucoup de ces idées commencent à converger. Cependant, la grande chose que nous avons vue et que j'ai trouvée très intéressante, c'est que les organisations les plus évoluées avaient des mandats bien compris pour leurs équipes. Si je suis dans cette équipe, je sais quel est mon travail, je sais quel est le travail de cette équipe, et nous connaissons nos dépendances et nos relations mutuelles. Tout le reste, vous pourriez utiliser une technologie terrible, vous pourriez en fait suivre une mauvaise stratégie, toutes ces choses différentes. Mais si vos équipes comprennent réellement, quel est le but de cette équipe et quel est le but de cette équipe et comment elles se rapportent les unes aux autres ? C'est le plus grand amplificateur. Et donc il y aurait un conseil pour les gens, si vous êtes dans une grande organisation et que vous ne le savez pas, c'est le travail de la direction. C'est le travail de la direction d'aller régler ça pour vous. Et j'espère que cela résonnera pour les gens, que si vous le saviez, vous auriez l'impression d'être dans une organisation plus productive. C'est donc le modèle réussi que nous observons dans l'ingénierie des flux et des plateformes.
[00:24:24] Alors, pourquoi cela résout-il les problèmes, cette idée d'équipe de plateforme ? Combien de personnes connaissent les topologies d'équipe ? Je suppose.
[00:24:33] D'accord, pas mal. Permettez-moi de couvrir rapidement cela pour ceux d'entre vous qui ne le savent pas. Donc, euh, il y a essentiellement les gens des topologies d'équipe, un. Vous savez quoi, si vous avez juste un petit nombre de types d'équipes au sein de votre organisation et des interactions bien définies entre ces types d'équipes, tout le reste devient facile. Et le principal sur lequel les gens se sont concentrés sont les équipes de plateforme. Donc, plutôt que d'avoir un administrateur système ou un SRE responsable d'un système, votre travail est de construire une plateforme pour que d'autres personnes en interne puissent la consommer.
[00:25:05] Vous avez des équipes de plateforme, des équipes alignées sur les flux, des équipes de sous-systèmes complexes, et équipes habilitantes, c'est l'autre. Donc les équipes habilitantes sont celles qui vont autour du coaching, en disant, hé, vous savez, il y a probablement beaucoup d'entre vous ici qui sont des consultants agiles qui font cela dans vos organisations. Vous allez aider les gens à s'améliorer dans une chose spécifique. Les équipes de sous-systèmes compliqués sont des choses comme là où il y a juste des connaissances très spécialisées qu'il n'est pas logique que tout le monde connaisse, euh, et donc vous, vous enterrez cela dans la structure de votre organisation.
[00:25:36] Maintenant, la raison pour laquelle cette idée de base, parce que je pense que les deux grandes sont les équipes de plateforme et les équipes alignées sur le flux, fonctionne. est que les transferts entre équipes sont coûteux. Saisir le contexte, comme c'est l'une des choses qui, je pense, a été si frustrante dans les services informatiques. est le redoutable comité de contrôle des changements, où vous devez aller, Je fais quelque chose. Maintenant, je dois expliquer cette chose à quelqu'un qui ne l'a jamais faite.
[00:26:01] Je dois expliquer tout le contexte de ce que je prévois de faire, si ça tourne mal, ce que je ferai si ça tourne mal, écrire tout ça de manière plus linéaire. que ce que j'y pense réellement dans ma tête, le leur donner et ensuite ils le comprendront mal et diront, non, vous devez faire autre chose. Transmettre le contexte est vraiment très coûteux. C'est pourquoi je pense que les équipes autonomes ont le plus de sens. Vous créez ces équipes de chaîne de valeur, vous leur donnez tout le contexte de l'entreprise, mais vous les laissez faire des erreurs, mais vous les laissez assumer leurs erreurs et assumer leur succès. Parce que ce qui est coûteux, c'est de se dire, qu'est-ce que je fais et d'aller l'expliquer à quelqu'un d'autre au lieu de le faire réellement. Donc, transmettre ces choses est coûteux. Si vous avez l'organisation informatique traditionnelle d'équipe de stockage, d'équipe réseau, d'équipe de sécurité, qui existe toujours dans un grand nombre de grandes entreprises conservatrices avec lesquelles j'ai travaillé. Vous devez naturellement partager le contexte de ce que vous essayez de faire, cela doit être transmis d'une personne à l'autre, car toutes ces personnes sont fonctionnellement séparées. Collaborer entre ces groupes ne résout pas réellement ce problème.
[00:27:10] Alors, pourrions-nous réellement faire toutes ces choses sans toutes ces technologies ? Euh, je parlais au dîner des conférenciers avec quelqu'un de la façon dont, j'ai grandi en tant que nerd des systèmes d'exploitation, vous savez ? Comme, j'ai mis la main sur Solaris, et l'étape suivante, et AIX, et Linux est apparu et et maintenant les enfants ne touchent même plus aux systèmes d'exploitation. Parce que pour être honnête, ils sont pénibles et il faut connaître toutes ces connaissances obscures pour y arriver. Nous avons plutôt inventé des conteneurs et nous nous sommes dit, vous savez quoi, nous allons prendre l'OS et le réduire à cela. Et c'est la partie dont les gens doivent réellement se soucier. Et si nous arrivons à, vous savez, les gens atteignent des surfaces de plus en plus petites ici. Et c'est bien parce qu'il s'est avéré qu'essayer d'abstraire sur l'ensemble du système d'exploitation, comme nous l'avons fait avec des outils comme Puppet Chef, cela ne fonctionne pas réellement car l'OS n'a jamais été vraiment conçu pour être programmable. Mais les couches au-dessus de quelque chose comme Docker peuvent l'être. Mais pourrions-nous faire toutes ces choses, vous savez, la mise en réseau définie par logiciel, vous savez, le stockage, toutes ces choses, la technologie a en fait rendu ces choses possibles. où les gens peuvent commencer à avoir des interfaces en libre-service. C'est pourquoi, vous savez, Amazon avait clairement une décennie d'avance sur tout le monde ici en ce qui concerne cela. Mais c'était très rare, comme même moi j'ai rejoint Google en 2006, 2007 et ils avaient des interfaces en libre-service où vous pouviez demander de la puissance de calcul. Je n'avais jamais eu affaire à quelque chose de pareil auparavant. J'avais l'impression de magie, de technologie extraterrestre.
[00:28:34] Donc si nous regardons Flow, vous savez, toutes ces choses, Nous avons, je pense, commencé à oublier qu'il y avait un monde avant l'intégration continue et la livraison continue. Euh, et je pense que nous combinons souvent ces deux choses. Nous nous sommes tellement habitués à CI/CD que nous oublions en quelque sorte que ce sont en fait deux choses assez distinctes. Mais si vous regardez, ce n'est pas si loin en fait. En 91, vous savez, Grady Booch disait, vous savez ce qui est une bonne idée, fusionner sur la branche principale plusieurs fois par jour. Les gens se disaient, ouah, brûlez-le, c'est une sorcière. Euh, 97, vous savez, la programmation extrême. Je pense que nous sommes encore en train de réapprendre beaucoup de leçons de l'XP qui se déroulent. Il dit, vous savez quoi, nous devrions publier plusieurs fois par jour. Les gens sont absolument fous. Cela ne fait que 20 ans. Nous avons des ordinateurs depuis bien plus longtemps. Nous avons eu la virtualisation, mais l'intégration continue et en particulier les bonnes solutions open source accessibles ne sont en fait pas si anciennes que ça. Je me souviens qu'en 2009, quand Tim Fitz a publié ce post, c'était, je crois, l'un des premiers grands articles de Hacker News à vraiment exploser partout. C'était comme, nous déployons en production 50 fois par jour. Cela semblait absolument ridicule quand il l'a dit. Et il disait, ils ont décrit tout le système qu'ils avaient construit, toutes ces choses que tout le monde fait maintenant, comme si ce n'était pas si grave de pouvoir déployer 50 fois par jour.
[00:29:54] Euh, je ne pense pas que nous puissions faire de l'ingénierie de flux et de plateforme sans toute cette technologie. Pourriez-vous réellement faire le genre de travail dont nous parlons tous ?
[00:30:02] sans avoir certains de ces énormes progrès technologiques ? Ceci étant dit, j'ai travaillé dans des organisations où le CI/CD est le plus grand goulot d'étranglement de la planète, où tout doit passer par Jenkins. Et vous savez quoi, il y a un petit groupe de cinq personnes, et ce sont les seules personnes qui peuvent installer des extensions et personne ne sait comment maintenir la chose, et c'est un véritable, vous savez, nid de rats de code spaghetti. La technologie ne résout pas automatiquement tout. Mais quelque chose comme le CI a permis aux développeurs de changer leur relation les uns envers les autres et aux équipes de fonctionnalités de changer leur relation les unes envers les autres.
[00:30:36] Alors, revenons à Westrum. Euh, qu'est-ce que la technologie rend réellement possible sur cette liste ?
[00:30:48] Je n'avais pas d'image pour celle-ci, c'est donc une de mes mauvaises blagues, celle-ci est Atkins, l'un des parrains de la techno. Euh, ce n'est même pas une si bonne blague. Alors, J'ai essayé d'utiliser des lignes plus épaisses, des lignes plus fines pour décrire les choses ici, mais si vous regardez ça, la technologie nous permet d'améliorer beaucoup de ces choses qui seraient vraiment difficiles dans un sens IT, si vous êtes à l'intérieur d'une organisation de logiciels, ce que la plupart d'entre nous, j'imagine, sont ces jours-ci. Le pontage, l'idée de travailler à travers les équipes. Euh, faire le pont, l'idée de travailler à travers les équipes, des responsabilités étroites, partager vos risques, avoir réellement une responsabilité collective, être capable de coopérer sur des projets. Nous ne pourrions pas réellement faire cela sans une grande partie de cette technologie. Sans, vous savez, CI/CD, contrôle de version distribué, frameworks de test, frameworks de déploiement, rendre le déploiement rapide, feedback très rapide, toutes ces sortes de choses.
[00:31:46] Donc, l'une des choses, c'est un peu le domaine principal sur lequel je finis par consulter des gens qui commencent à travailler sur la façon de construire, vous savez, ils disent, nous avons une équipe IT, nous avons une équipe d'infrastructure, mais nous voulons livrer des choses en tant que service en interne. Euh, je pense que c'est en fait la chose la plus critique pour débloquer une grande partie du flux au sein des organisations. Où vous avez des personnes qui sont des spécialistes du domaine, elles doivent être capables de produire un service qui est consommé par d'autres personnes. C'est ainsi que vous commencez à faire en sorte que chacun puisse travailler à son propre rythme.
[00:32:16] Et vous devez créer les bons niveaux d'abstraction ici. Euh, c'était pour ceux d'entre vous qui construisent ce genre de services en interne. Euh, il faut que vous puissiez avoir des garde-fous. Je pense que l'une des pires choses que vous puissiez faire est d'ouvrir simplement une API en libre-service. J'ai vu de nombreuses organisations détruire soit leur infrastructure en ouvrant VMware à tout le monde, soit leurs livres financiers en ouvrant AWS à tout le monde. Vous devez mettre en place des garde-fous dans un certain sens, et ce sont les experts qui définissent cela. Il faut aussi, et nous l'avons mentionné plusieurs fois dans d'autres discussions, que les communautés de pratique et les groupes horizontaux soient vraiment, vraiment importants. Les consommateurs de services doivent pouvoir les personnaliser et les composer ensemble pour trouver de nouvelles idées sur la façon de résoudre les problèmes. Parce qu'ils ont le contexte de ce qu'ils essaient réellement d'accomplir. Et enfin, vous devez réellement instrumenter la chose à fond. Si vous ne le faites pas, si vous voulez éviter de devoir parler aux gens tout le temps, vous avez en fait besoin de métriques, vous savez, ce qui fonctionne, ce que les gens utilisent réellement, où cela échoue ? Ce n'est pas un substitut à la discussion pendant la phase de conception. Mais vous devez en fait être capable d'obtenir ces métriques. Il y a une raison pour laquelle nous construisons tous des logiciels SaaS de nos jours, c'est que nous pouvons réellement savoir ce que font les utilisateurs. Ayant été dans le commerce de la livraison de logiciels sur site, vous courez à l'aveuglette, vous ne savez souvent pas vraiment.
[00:33:36] Donc, les logiciels peuvent lier étroitement les équipes entre elles. Euh, nous avons vu, je suis sûr que certains d'entre vous ont travaillé dans des domaines où c'était une architecture assez standard il n'y a pas si longtemps, où vous aviez un équilibreur de charge, vous passiez par tout un tas d'applications héritées, vous aviez des logiciels commerciaux sur étagère, des bases de données,
[00:33:52] vous commenceriez à faire des microservices, et beaucoup de ces choses étaient un peu un désordre. Et c'est devenu très, très difficile. Si vous regardez un diagramme comme celui-ci et que vous avez des équipes organisées fonctionnellement, comme, il n'est pas étonnant que tout soit lent parce que vous ne savez pas où sont toutes vos dépendances. Alors, des gens sont venus et ont dit : « Construisons un bus de service d'entreprise ». Euh, nous aurons une petite équipe, tout passera par là. Euh, il s'avère que cette petite équipe devient de plus en plus grande et vous finissez par devoir y investir massivement, et cela résout certains problèmes, mais pas tous.
[00:34:27] Ensuite, vous pouvez également voir des architectures beaucoup plus libres que les gens ont. Donc, cela utilise, pour le même type d'architecture, un courtier de messages moderne. Vous savez, vous commencez en fait à dire, vous savez quoi, il y a une chose là-bas, les gens peuvent y pousser des données et les gens peuvent en obtenir des données. Vous savez, vous commencez à mettre en place des registres de schémas, la technologie peut en fait fondamentalement changer la façon dont les équipes interagissent. Si vous revenez à cela, il est vraiment difficile de superposer une équipe axée sur la chaîne de valeur dans un environnement comme celui-ci. Parce qu'à chaque fois que vous voulez changer quelque chose, vous devrez aller chercher cette information, obtenir du contexte ou fournir du contexte à quelqu'un.
[00:35:05] Si vous avez des équipes comme celle-ci, vous pouvez en fait, vous savez, descendre dans l'enfer des microservices si vous le souhaitez, euh, ou vous pouvez essayer de maintenir une architecture assez saine.
[00:35:14] Donc, le résumé de tout cela pour ceux qui ont lu les topologies d'équipe, euh, leur argument de base est,
[00:35:22] La loi de Conway stipule que l'architecture logicielle que vous livrez reflète l'architecture organisationnelle de votre entreprise. Et ce que j'avance ici, c'est que la nouvelle technologie vous permet de créer de nouvelles topologies organisationnelles et celles-ci vous permettent de mieux exécuter de nouvelles choses avec les logiciels. Merci beaucoup. Heureux de prendre des questions.
[00:35:57] J'ai essayé d'utiliser des lignes plus épaisses, des lignes plus fines pour décrire les choses ici, mais si vous regardez ça, la technologie nous permet d'améliorer beaucoup de ces choses qui seraient vraiment difficiles dans un sens IT, si vous êtes à l'intérieur d'une organisation de logiciels, ce que la plupart d'entre nous, j'imagine, sont ces jours-ci.
[00:36:05] Euh, salut, alors je me demandais comment vous pensez que les, euh, enfin les technologies évoluent de plus en plus vite, vous savez, alors comment pensez-vous que cela va impacter les organisations ?
[00:36:18] Oui, alors quelqu'un qui a essayé de vendre, qui a essayé de vendre de la technologie à tous, je pense que la technologie entre dans la plupart des organisations par l'intermédiaire des praticiens. Euh, est-ce que quelqu'un, levez la main si vous avez déjà fait partie d'une organisation où quelqu'un, en partant du haut, a dit : 'Nous allons tous commencer à utiliser X', et ça a réellement bien fonctionné. J'aurais probablement dû ne pas formuler cela de manière aussi négative.
[00:36:42] Mais je ne pense tout simplement pas que cela fonctionne. Je pense que nous opérons dans un environnement si complexe que les personnes qui savent quels sont les meilleurs outils sont les personnes qui font ce travail. Maintenant, cela ne signifie pas laisser tout le monde faire une de chaque chose, car cela peut devenir un véritable casse-tête absolu.
[00:36:59] Euh, c'est là que je vais devenir un peu cynique. Je pense que c'est malheureusement là où se trouve l'open source de nos jours, la plupart du temps. Ce n'est pas vraiment une question de communauté et de collaboration. Il s'agit du fait que les gens reconnaissent que vous ne pouvez vraiment entrer au rez-de-chaussée des organisations que s'il y a une grande composante open source. Euh, parce que personne ne veut adopter un logiciel freemium ou, vous savez, comme un logiciel commercial mais gratuit, puis baser toute son activité dessus et ensuite se dire, oh zut, maintenant ils veulent que nous leur payions des millions de dollars. Je pense donc que les gens considèrent l'open source comme un choix pragmatique ici. Je pense donc que ce que cela signifie finalement, c'est que les praticiens, parce que les emplois sont plus fluides, les gens changent d'emploi plus souvent, ils apportent de nouvelles idées avec eux, de nouvelles technologies apparaissent. Je pense que cela doit devenir votre travail si vous êtes CTO, votre VP d'ingénierie, d'écouter les gens, de leur donner l'espace pour expérimenter.
[00:37:50] Euh, mais pour être visible à ce sujet. Et donc, peut-être que vous essayez de faire en sorte que la responsabilité et l'autorité aillent dans les deux sens, où vous dites, vous savez, vous êtes tous libres d'expérimenter avec des outils, mais vous devez vous lever et, lors de la journée de démonstration que nous faisons tous les deux vendredis ou autre, faire une présentation de 10 minutes à ce sujet. Euh, donc je pense qu'il n'y a pas de retour en arrière possible, je suppose, c'est. Est-ce que ça, est-ce que ça répond à votre question ?
[00:38:14] Euh, eh bien, en un sens, si je reformulais ce que j'ai compris de votre réponse, c'est que, eh bien, ce sont les humains qui promeuvent la technologie, donc en un sens, nous allons être le goulot d'étranglement.
[00:38:30] Non, laissez-moi reformuler, laissez-moi peut-être reformuler alors, parce que je ne pense pas l'avoir tout à fait dit. Euh, de nouvelles idées et de nouvelles technologies vont arriver dans votre organisation, quoi que vous fassiez. Euh, mais je pense que si vous êtes un leader senior, votre travail est de regarder cela et de ne pas seulement penser que, parce que quelqu'un l'a introduit parce qu'il se dit, hé, regardez, cela rend la révision de code plus facile. Euh, et donc ne l'analysez pas et ne l'évaluez pas uniquement sur cette base. Mais pensez à la façon dont cela modifie réellement la manière dont les équipes interagissent les unes avec les autres, et comment je pourrais peut-être en tirer parti.
[00:38:58] Euh, je pense que la sécurité et la conformité sont un grand domaine pour ceux d'entre vous qui y travaillent, où cela a été un gros problème. Avant, il fallait avoir des personnes externes. Mais nous nous sommes de mieux en mieux débrouillés avec des outils comme Snip, vous savez, si vous essayez de faire un sock 2, avec Vanta, comme toutes ces choses ont en fait simplifié des tâches qui nécessitaient une équipe de spécialistes auparavant. Euh, ils nous ont permis de distribuer la responsabilité. Donc je pense, essayez et je vais essayer de résumer cela un peu plus joyeusement alors. Euh, donc je pense, essayez et je vais essayer de résumer cela un peu plus vivement alors. La nouvelle technologie est inévitable. C'est votre travail en tant que leader senior de penser à l'impact social de cela et d'essayer d'en tirer parti.
[00:39:41] Je promets de prendre moins de temps pour répondre à la prochaine.
[00:39:44] Bonjour, merci. Euh, pensez-vous que les gens pensent au changement climatique et à la technologie dans votre domaine ?
[00:39:51] Oui, j'ai utilisé cette phrase de manière assez délibérée parce que je ne sais pas pour vous, mais je me sens impuissant et un peu déprimé quand il s'agit du changement climatique. Comme si peu importe combien je recycle ou si je prends le train ici ou joue, la société dans son ensemble doit changer. J'ai l'impression que tout le monde est beaucoup plus conscient de cela. Euh, je dois dire un grand bravo à ces organisateurs de conférence, comme le plastique minimal, pas de, genre, il n'y a pas de swag pourri partout, je ne retourne pas à mon hôtel en jetant un million de morceaux de plastique. Euh, l'hôtel où ils nous ont logés en tant que conférenciers, petit-déjeuner zéro plastique. Je pense juste que nous avons tous oui, je ne pense pas avoir une bonne réponse pour vous là. Euh, si quelqu'un le fait, s'il vous plaît venez me le faire savoir et aidez-moi à mieux dormir la nuit.
[00:40:48] Donc, juste concernant ce qui est écrit ici, euh, basé sur ce que vous voyez ou ce que vous pensez, quelles sont les prochaines technologies qui vont arriver dans les cinq prochaines années et qui influenceront l'organisation et l'architecture logicielle ?
[00:41:03] Oui, je pense honnêtement, euh, toutes les personnes dans l'espace où se trouve la Syrie, euh, je suis parti parce que j'avais besoin d'une pause entre deux emplois. Je n'avais pas, je n'avais pas pris de pause depuis environ 18, 19 ans. Euh, les bus de messages, comme nous avons déjà essayé de le faire, vous savez, nous avons eu des poids lourds. Je suis sûr que la moitié d'entre vous ont probablement travaillé avec Kafka à un moment donné. et il y a probablement une pauvre personne au sein de votre organisation qui doit le maintenir, et gérer le partitionnement et toutes ces bêtises. Mais je pense que ce genre de choses, comme ça l'idée de pouvoir pousser des données et consommer des données, je pense que cela change fondamentalement les choses. Quel est le service le plus populaire que tout le monde utilise lorsqu'il passe au cloud ? La base de données en tant que service. Parce que vous savez ce qui est nul ? L'entretien des bases de données. C'est juste le pire travail qui soit, désolé, tous les administrateurs de bases de données. Euh, Donc je pense, oui, je pense que ce genre de choses va prendre de plus en plus d'ampleur. Je pense que nous n'avons pas encore vu où le serverless va vraiment. Et je pense que nous allons voir les contraintes que l'edge computing impose, vous savez, je sais que c'est un mot à la mode énorme, nous entendons parler d'IoT et d'edge depuis des années et des années. Mais je pense que de nombreux éléments nous poussent vers l'edge computing, ce qui signifie des unités de calcul plus petites, plus respectueuses de l'environnement, que vous pouvez allumer et éteindre et qui sont plus flexibles pour communiquer sur de grandes distances. Je pense que cela va changer la façon dont nous pouvons nous organiser.
[00:42:30] Cool. Merci beaucoup.

Transcription (Traduit)