Holly Cummins

[00:00:15] L'année dernière, j'ai eu la la discussion joyeuse sur la façon de s'amuser au travail. Cette année, j'ai la euh la discussion malheureuse sur ce qui se passe quand on fait des erreurs. Euh j'espère qu'il y aura un peu de de plaisir là-dedans aussi parce que c'est toujours à la fois agréable et instructif d'entendre parler des erreurs des autres. Euh donc le le point de départ euh de cette conférence est que je suis consultante au sein de l'IBM garage. Et donc l'une des choses que je fais, c'est que je vais travailler avec des startups et des grandes entreprises et elles disent, nous aimerions vraiment passer au cloud, nous aimerions vraiment les obtenir. Et puis elles me racontent ce qui s'est passé jusqu'à présent et je me dis, oh, je n'aurais pas fait ça comme ça. Euh mais comme pour toute chose intéressante, il y a beaucoup de façons de bien faire les choses et je pense qu'il y a beaucoup de façons de mal faire aussi ou de d'obtenir un résultat que vous ne vouliez pas vraiment. Euh, donc un problème que nous voyons, le le premier problème que nous voyons, c'est juste de comprendre ce qu'est le cloud natif. Et ça devrait être une chose facile, mais ça s'avère être très difficile. Et j'ai commencé à réfléchir à la définition de "cloud native" parce que j'ai vu euh un tweet de Daniel Bryant qui écrit pour InfoQ. Et il avait un article euh d'une personne qui travaille chez Red Hat, Bilgan Ibrahim. Et euh, il a dit, oh, j'aime vraiment la façon dont Bilgan a encadré, euh, la relation entre l'ESB et les microservices et le cloud.
[00:02:01] Et si vous regardez l'image réelle, euh, vous pouvez voir que ce que Bilgan a fait, c'est qu'il a en quelque sorte montré une progression à partir d'il y a 20 ans, nous faisions tous du SOA ou de l'Enterprise Service Bus. Et puis nous sommes passés aux microservices, et puis nous sommes passés au cloud natif. Et ce qui définit le cloud natif, c'est que vous avez beaucoup de petits services et que la plateforme est intelligente et que les services sont stupides. Et j'ai regardé et j'ai pensé, ceci ceci ne correspond tout simplement pas à ma compréhension du cloud natif. Et c'est un très bon article, euh, et Bilgan fait tellement de bonnes choses. Mais je me suis juste dit que j'ai l'impression de faire du cloud natif et pourtant rien de ce que je fais n'a une architecture qui ressemble à celle de l'article de Bilgan. Alors, euh, est-ce que je me trompe ? Ou que se passe-t-il ? Et en particulier, l'accent était tellement mis sur les microservices. Euh, et encore une fois, si vous regardez le titre de l'article, le titre de l'article est microservices. Donc, bien sûr, ça allait être à propos des microservices. Mais j'avais toujours l'impression que l'accent mis sur les microservices n'était pas tout à fait juste. Euh, alors je suis allée voir la définition de "cloud native" de la Cloud Native Computing Foundation. Et ils ont en fait quelque chose de très similaire. Donc ils ont dit qu'il utilise des microservices et des conteneurs et l'important est qu'il soit orchestré dynamiquement. Et j'ai pensé, ça ça ne me semble pas juste. Mais ça me met dans une position vraiment étrange parce que je suis ici à Flocon et je dis, moi, Holly Cummings, je sais ce qu'est le cloud natif. La Cloud Native Computing Foundation, elle ne sait pas ce qu'est le cloud natif. Et bien sûr, c'est la Cloud Native Computing Foundation. Ils, ils en savent beaucoup sur le cloud natif, et pourtant leur définition ne me semblait pas juste.
[00:04:18] Euh, et puis c'est un peu, j'ai l'impression qu'à tout moment où je dis ça, quelqu'un va dire, oh, nous avons fait une petite erreur en invitant Holly parce qu'elle dit que la Cloud Native Computing Foundation a tort. Peut-être pourrions-nous simplement désinviter Holly. Mais en fait, ce n'est pas, euh, ce n'est pas seulement moi qui me suis, qui m'inquiète de cette définition du cloud natif. Euh, c'était un tweet que j'ai vu hier de Sam Newman. Euh, et il dit qu'un effet secondaire intéressant du CNCF est que maintenant il parle souvent à des gens qui pensent qu'ils doivent être dans Kubernetes pour être cloud native. Et vous pouvez voir que Sam Newman n'est pas d'accord avec ça non plus.
[00:05:07] Donc il y a euh quelques mois, je regardais euh encore, et j'ai réalisé qu'en fait, le CNCF a changé sa définition du cloud natif. Donc avant, vous alliez sur leur site web et il y avait juste une page qui disait, qu'est-ce que le cloud natif ? Mais maintenant, si vous allez sur leur site web, vous devez aller sur une autre page, qui est la définition du Cloud Native. Et si vous allez sur cette page, c'est en fait un dépôt Git. Et donc quand vous voyez Git là-dedans, vous vous dites, hmm, cela change probablement beaucoup. Euh, et vous pouvez voir, oui, il y a 18 personnes qui ont apporté des modifications à cette définition. Et si vous regardez l'historique de la définition, il y a beaucoup de changements qui ne cessent de s'accumuler. Et certains d'entre eux sont des choses comme la traduction. Mais beaucoup d'entre eux changent en fait la formulation de la définition. Et puis si vous remontez encore plus loin, si vous regardez le tout premier morceau de la définition, même avant qu'il n'arrive dans Git, ils avaient 11 brouillons. Donc je n'étais pas dans ces conversations, mais je pense qu'ils ont passé beaucoup de temps à essayer de comprendre ce qu'était le cloud natif. Et c'est à peu près la même chose pour nous tous dans l'industrie. Si vous demandez à 10 personnes ce qu'est le cloud natif, elles sauront toutes ce qu'est le cloud natif, mais vous obtiendrez 10 réponses différentes. Donc, certaines personnes diront, cloud natif signifie qu'il est né sur le cloud. Il a été conçu pour fonctionner sur le cloud.
[00:06:55] Certaines personnes disent que le cloud natif, ce sont des microservices, comme le CNCF le faisait auparavant.
[00:07:04] Certaines personnes disent, comme les gens qui parlent à Sam Newman, que le cloud natif signifie Kubernetes.
[00:07:11] Certaines personnes disent, elles ne le disent peut-être pas en tant de mots, mais quand elles décrivent comment fonctionne le cloud natif, cela ressemble presque exactement à la définition de comment fonctionne DevOps. Et certaines personnes, je pense, pensent que "cloud natif" signifie simplement quelque chose qui a été construit au cours des cinq dernières années et qui est moderne et agréable et qui n'est pas un héritage. Je pense parfois que nous sommes tellement habitués à dire "cloud natif" que nous oublions qu'il est en fait possible de dire simplement "cloud". Nous n'avons pas besoin d'ajouter "cloud natif" à la fin. Mais j'ai en quelque sorte presque oublié qu'il existe un mot, qui est "cloud".
[00:07:54] Et parfois, les gens entendent par là l'idempotence. Euh, et puis le problème avec l'idempotence, c'est que quand vous dites l'idempotence, tout le monde fait, l'idempotence quoi ? Euh, mais "idempotent" signifie vraiment "réexécutable", donc il s'agit de cet état qui signifie que vous pouvez le désactiver et le réactiver et il vous donnera le même comportement.
[00:08:20] Donc ça fait tout un tas de définitions.
[00:08:28] Mais je pense que ce qui est peut-être le plus utile à faire, c'est de réfléchir à ce que le natif n'est pas. Euh, du moins pour moi, je pense que le cloud natif n'est pas un synonyme de microservices. De nombreuses applications de microservices sont natives du cloud, mais il existe de nombreuses applications natives du cloud où, en raison du modèle de domaine, de la taille de l'application, il n'était pas logique de la diviser en microservices, et c'est très bien. Et je pense que si le cloud natif devait, pour moi du moins, si le cloud natif devait être un synonyme de quelque chose, ce serait l'idempotence. Et vous pouvez en quelque sorte voir pourquoi j'ai vraiment besoin du synonyme.
[00:09:14] Je ne peux pas, je trouve difficile de même dire "idempotent".
[00:09:20] Donc, revenons à cette définition que nous avions en 2019. Euh, bien qu'ils parlent de microservices.
[00:09:33] puis en 2020, ils parlent toujours de microservices, mais c'est différent car ce qu'ils disent, c'est qu'il s'agit d'une infrastructure immuable. Et donc encore une fois, je pense que c'est un peu cette idée de l'idempotence et l'infrastructure en tant que code et ce genre de choses. Et ils parlent de microservices, mais ils ne disent pas que vous devez être des microservices. Les services exemplifient cette approche, ce qui, je pense, me semble beaucoup plus acceptable. Mais même dans leur définition de 2019, une chose que j'ai vraiment aimée, c'est qu'elle a été lue après avoir dit microservices. ont un pourquoi. Et le pourquoi est que vous voulez créer de super produits plus rapidement, ce qui est juste comme, oui, c'est pourquoi nous faisons cela. C'est pourquoi nous avons changé la façon dont nous architecturons les choses, c'est parce que nous pensons que sur le cloud, nous pouvons créer de super produits plus rapidement. Et dans la version moderne de celle-ci, euh, ils ont toujours un pourquoi, mais ils sont un peu plus précis à ce sujet. Donc, au lieu de simplement dire que nous allons être très rapides et que nous allons être géniaux, ils disent que nous faisons des changements à fort impact, donc des changements non triviaux. Nous le faisons fréquemment. Et quand nous faisons ces changements, les choses fonctionnent en quelque sorte, elles sont prévisibles, et il y a un minimum d'efforts. Donc nous n'avons pas à faire beaucoup de travail manuel. Et j'aime vraiment, vraiment ce pourquoi. Mais avec les deux définitions et les deux pourquoi, je pense que nous devons revenir à quel problème essayons-nous, essayons-nous même de résoudre ? Et cela s'avère être un autre échec. Souvent, je pense que les organisations estiment qu'elles devraient être natives du cloud, mais elles ne savent pas vraiment quel problème elles essaient de résoudre.
[00:11:31] Donc, et je pense que quel problème essayons-nous de résoudre est presque toujours la question la plus importante dans toute conversation. Et pour le cloud natif, nous voyons ce genre de euh moteur social, à savoir que tout le monde fait du cloud natif, ça doit être une bonne idée, peut-être. Et je pense que nous supposons que si nous avons les mêmes modèles architecturaux que des entreprises comme Netflix, nous aurons le même succès en ingénierie que des entreprises comme Netflix. Et ça ne fonctionne pas vraiment comme ça. Donc il y a cette sorte de mimétisme souhaitable où nous prenons les rituels visibles.
[00:12:13] Mais nous ne prenons pas réellement ce que je pense être les parties les plus importantes.
[00:12:22] Et je pense que pour vraiment comprendre pourquoi, nous voulons prendre du recul et comprendre, eh bien, pourquoi allons-nous même vers le cloud ?
[00:12:32] Avant, la motivation pour aller dans le cloud était juste une question de coût. Euh, fonctionner dans le cloud était moins cher.
[00:12:39] Et la raison pour laquelle c'était moins cher était en partie due à une économie d'échelle et à la gestion de votre infrastructure par d'autres. Mais c'était aussi que vous n'aviez pas à payer pour la majeure partie de votre infrastructure la plupart du temps. Vous aviez cette élasticité, vous pouviez augmenter, vous pouviez diminuer. Et donc, aujourd'hui, le Black Friday, vous pouvez avoir beaucoup de serveurs, le reste de l'année, vous pouvez avoir un petit nombre de serveurs, et c'est ce qui, c'est ce qui permet vraiment les économies de coûts.
[00:13:07] Un autre avantage du cloud est la vitesse. Et cela concerne en partie un matériel plus rapide, mais surtout la rapidité de mise sur le marché. Le cloud nous permet de livrer tellement plus vite parce que nous n'avons pas besoin d'imprimer des CD et ensuite de les envoyer aux gens. Un autre avantage du cloud est que nous commençons à voir des capacités exotiques sur le cloud, ce qui revient en quelque sorte à la vitesse également. Donc si vous voulez faire de l'apprentissage automatique et que vous voulez un tas de GPU pour faire cet apprentissage automatique, vous ne voulez probablement pas les acheter pour votre propre centre de données parce qu'ils sont vraiment chers. Donc vous voulez juste les utiliser dans le cloud. De même, si vous voulez faire du calcul quantique, vous ne voulez certainement pas un ordinateur quantique pour votre propre centre de données car vous devez le maintenir à environ 0,5 Kelvin, ce qui est plus froid que l'espace entre les étoiles, et vous ne voulez pas cela dans votre centre de données. IBM a donc été le premier à rendre les ordinateurs quantiques disponibles sur le cloud et c'est tellement évidemment un modèle d'approvisionnement sensé pour ce genre de calcul.
[00:14:17] C'est donc très bien.
[00:14:20] Alors pourquoi voulons-nous le cloud natif ?
[00:14:23] Eh bien, il s'avère que beaucoup de gens, lorsqu'ils sont passés au cloud pour la première fois, se sont électrocutés. Il peut arriver toutes sortes de mauvaises choses si vous essayez d'écrire des logiciels de la même manière que vous les avez toujours écrits dans le cloud. Et donc en 2011, l'industrie a proposé les 12 facteurs.
[00:14:47] Et j'aime considérer les 12 facteurs comme la façon d'écrire une application cloud pour ne pas se faire électrocuter. Ce sont donc les bonnes habitudes que vous devez avoir. Et nous en parlons moins et certaines n'ont plus vraiment de sens. Certaines, nous n'y pensons même plus.
[00:15:04] C'était donc en 2011, mais même avant cela, il y avait une autre idée, qui était le cloud natif. Et le cloud natif a été inventé pour la première fois en 2010, donc avant les 12 facteurs, euh, et les microservices étaient en 2013, du moins dans ce, euh, genre de contexte distribué. Donc l'idée du cloud natif est venue en premier. Et ce dont Paul Freeman parlait, c'est que le cloud natif, c'était les choses que vous deviez faire à nouveau pour ne pas vous faire électrocuter dans le cloud. Et donc pour moi, parce que je me souviens de cela, ce genre de définition a beaucoup de sens.
[00:15:48] Euh, et vous pouvez voir que d'autres personnes pensent toujours à cette définition également. Ainsi, lors de la conversation Twitter d'hier, un autre, je dois dire qu'Ian n'est pas un très jeune développeur et il pensait que "cloud native" signifie construit pour fonctionner dans une infrastructure cloud, né sur le cloud. Et maintenant, nous voyons parfois que cela signifie simplement fonctionner sur Kubernetes. Ou parfois, nous voyons une idée comme "lift and shift" vers le cloud natif, ce qui pour moi n'a pas de sens, mais je le vois de plus en plus. Donc nous avons toutes ces définitions du cloud natif.
[00:16:30] Et si nous essayons de faire quelque chose avec autant de définitions, pouvons-nous, allons-nous tous être d'accord sur l'objectif ? Eh bien, peut-être, mais il y a beaucoup d'occasions de malentendus.
[00:16:43] Et donc, nous obtenons des choses comme, vous retournez voir votre partie prenante et vous dites, j'ai j'ai fait cette incroyable application cloud native et ils espéraient des microservices. Et puis il y a un, vous savez, il y a un désaccord. Euh, ou ils espéraient une meilleure rapidité de mise sur le marché et le cloud n'a fini par économiser que de l'argent. Donc nous avons alors cette opportunité de problèmes. Mais je pense que l'un des plus grands problèmes est cette "wishful pre" et en particulier pour les microservices.
[00:17:13] Les microservices sont un excellent modèle architectural, mais ils ne sont pas un but en soi. Ils sont un moyen d'atteindre un autre objectif, et nous devons découvrir cet autre objectif et ensuite déterminer si les microservices aident. Et nous avons eu une conversation avec une banque et ils avaient beaucoup de cobol, et il y a de nombreuses bonnes raisons de se débarrasser de votre cobol.
[00:17:41] Il peut être coûteux à maintenir, il se peut que tous vos développeurs cobol prennent leur retraite et donc juste pour acquérir les compétences, vous devez passer à un langage plus récent. Mais dans ce cas, leur concurrence leur mangeait le nez. Ils allaient trop lentement, ils devaient aller plus vite. Alors ils ont dit que nous devions nous débarrasser de Cobal et faire des microservices. Et nous avons pensé, super, oui, nous pouvons totalement vous aider avec ça. Et puis ils ont ajouté, le comité de publication ne se réunit que deux fois par an. Et donc, à ce stade, peu importe le nombre de microservices que vous avez, si vous n'êtes autorisé à publier que deux fois par an, ils seront tous publiés en lot et vous auriez aussi bien pu ne pas vous embêter avec le coût des microservices parce que vous n'allez pas réellement aller plus vite tant que vous n'aurez pas réparé le comité de publication. Et nous voyons cette idée que, je pense que c'est peut-être presque une sorte de, vous savez, nous voulons montrer à quel point nous sommes de bons ingénieurs. Et donc nous regardons ce que font les autres et nous pensons aux conteneurs, c'est génial. Plus je gère de conteneurs, plus je suis cool. Si j'ai cinq microservices, je vais plutôt bien, mais si j'ai 500 microservices, je suis un ingénieur génial. Ce qui est vrai, mais seulement si vous faites réellement fonctionner ensemble ces 500 microservices. Et souvent, ce que nous voyons, c'est qu'au lieu d'avoir un système vraiment beau et découplé, nous avons une distribution, c'est distribué, mais c'est toujours tellement couplé qu'en fait, c'est un monolithe distribué, et c'est pire qu'un monolithe normal. Parce qu'il n'a pas la vérification au moment de la compilation, il n'a pas la sécurité des types que vous obtenez d'une base de code unique. Et quand une fonction en appelle une autre, si elle est distribuée, cette exécution n'est pas garantie, les erreurs de calcul distribué s'appliquent, donc l'autre chose aurait pu disparaître, ce qui n'arrivera pas si elles sont toutes dans le même processus. Il y a donc un coût à la distribution.
[00:19:48] Et donc, lorsque vous déterminez si les microservices ont un sens pour vous, il y a un certain nombre de choses à considérer. Si vous êtes une petite équipe, c'est une bonne raison de ne pas faire de microservices. Si vous ne prévoyez pas de publier indépendamment, ne vous embêtez pas. c'est pire qu'un monolithe normal parce qu'il n'a pas la vérification au moment de la compilation, il n'a pas la sécurité de type que l'on obtient d'une base de code unique. Et quand une fonction en appelle une autre, si elle est distribuée, cette exécution n'est pas garantie, les erreurs de calcul distribué s'appliquent, donc l'autre chose aurait pu disparaître, ce qui n'arriverait pas si elles sont toutes dans le même processus. Il y a donc un coût à la distribution. Et donc, pour savoir si les microservices ont du sens pour vous, il y a un tas de choses à considérer. Si vous êtes une petite équipe, c'est une bonne raison de ne pas utiliser de microservices.
[00:19:58] Si vous ne prévoyez pas de publier indépendamment, ne vous embêtez pas. Lorsque l'on réfléchit à la manière dont ces microservices vont communiquer et gérer la sécurité entre eux, ainsi qu'à certaines de ces préoccupations transversales, habituellement, le modèle pour faire cela est d'avoir un maillage de services. Et beaucoup de gens entendent parler de maillage de services et se disent, oh, j'ai entendu de mauvaises choses sur les maillages de services. Ils sont vraiment chers. Ils sont vraiment difficiles à gérer, je ne veux pas de maillage de services. Au lieu de cela, je vais écrire mes propres protocoles de sécurité, et je vais écrire mes propres protocoles de découverte, et je vais écrire mes propres protocoles d'équilibrage de charge. Et à un certain point, vous avez juste écrit un maillage de services. Et vous auriez été mieux avec une solution open source. Et puis parfois aussi, le modèle de domaine ne se divise pas bien. et quand cela arrive, ce que vous obtenez, c'est du spaghetti natif du cloud. Et j'ai travaillé, j'ai été intégré à un projet, et Je suis arrivée et ils m'ont montré leurs microservices, et ils ont dit : « Chaque fois que nous modifions un microservice, un autre tombe en panne. »
[00:21:12] Et je pense qu'ils ont en quelque sorte supposé, et je pense que beaucoup d'entre nous supposent maintenant que si vous avez des microservices parce que vous êtes distribué, vous êtes découplé. Mais ce n'est pas nécessairement le cas, vous pouvez avoir quelque chose qui est, vous aurez toujours un certain couplage. Tout ce qui communique sera couplé. Et si le simple fait que ce soit distribué ne change rien. Vous devez donc examiner votre couplage ou votre modèle architectural. Parce que vous pouvez complètement avoir du spaghetti dans le cloud. Et c'est plus effrayant que des spaghettis normaux. Donc ceci est une image de Nuageux avec un risque de boulettes, et j'adore ça parce que ça montre la terreur des spaghettis du cloud.
[00:21:57] Euh, quand j'ai approfondi la raison pour laquelle ces microservices étaient si couplés, J'ai regardé le code et j'ai vu le même code dans presque tous les microservices. Et j'ai dit, qu'est-ce qui se passe avec ça ? Pourquoi n'avons-nous pas extrait cela dans une bibliothèque commune ?
[00:22:17] Et ils ont dit, eh bien, nous ne l'avons pas mis dans une bibliothèque commune parce que nous ne voulons pas de ce couplage. Ce qui est juste, et parfois cela vaut vraiment la peine de couper-coller du code pour éviter le couplage.
[00:22:30] Mais dans ce cas, le couplage était là parce que chaque fois qu'ils changeaient un nom de champ, chaque fois qu'ils corrigeaient une faute de frappe dans une classe, cela cassait tout le reste. Ils auraient donc été mieux avisés d'avoir une source unique de vérité. Et le problème était que dans un monde idéal, ce que vous avez avec vos microservices, c'est que vous avez tout un tas de microservices, et chacun correspond très précisément au modèle de domaine. Dans ce cas, ce qui s'était passé, c'est que le modèle de domaine était commun à tous les services.
[00:23:06] Donc, ce n'était pas bon. Une autre illustration non-logicielle du couplage, euh, est celle-ci : l'explorateur climatique de Mars.
[00:23:18] Euh, et ça ressemble un peu à ça. Donc, il a eu une fin un peu triste, et on peut voir qu'il semble être assemblé avec un sac poubelle et du ruban adhésif, et je pense qu'il a en fait été construit de manière plus professionnelle que cela. Mais malgré cela, au lieu de faire le tour de Mars, ce qui était censé se produire, il est allé s'écraser sur Mars, ce qui n'était pas censé arriver. Et quand ils ont fait l'analyse pour comprendre ce qui s'était passé, il s'est avéré qu'il y avait deux sous-composants qui contrôlaient la navigation. L'un était sur l'explorateur et l'autre sur Terre. Ainsi, celui de la Terre envoyait des corrections occasionnelles, et l'explorateur faisait le reste.
[00:24:05] Sur l'explorateur lui-même, il utilisait des unités métriques, comme le centimètre. L'unité de base utilisait des unités impériales. Et donc, bien sûr, ça n'a pas fonctionné. Et le problème était que les unités étaient suffisamment proches pour que ce ne soit pas manifestement faux. Ce n'était faux que lorsqu'il s'est écrasé sur Mars. Donc dans ce cas, vous savez, on ne pouvait pas avoir un système plus distribué, une partie était sur Mars, mais la distribution n'a pas aidé. Donc, la façon de résoudre ce genre de problème, la façon de s'assurer que vos interactions ne seront pas interrompues, est d'avoir des tests de contrat consommateur. Et ils sont assez rares dans notre industrie, et je pense que c'est en partie parce qu'ils sont difficiles à comprendre et parce qu'ils demandent du travail et de la coordination entre les équipes pour les écrire. Mais cela vaut vraiment la peine de faire cet effort, cela vaut cet investissement parce qu'ils vont vous donner la confiance que vos microservices fonctionnent réellement ensemble.
[00:25:04] Et quand il n'y a pas la confiance que les microservices fonctionnent ensemble, alors nous obtenons le système d'intégration continue et de déploiement continu qui n'est pas réellement continu. Et je m'inquiète toujours quand je parle à quelqu'un et qu'il dit, nous avons du CICD, parce que CI CI, l'intégration continue, c'est un verbe.
[00:25:22] Ce n'est pas quelque chose que vous achetez, c'est quelque chose que vous faites.
[00:25:27] Et donc j'entends des choses comme, je fusionnerai ma branche dans notre CI la semaine prochaine. Eh bien, si vos branches ne sont intégrées qu'une fois par semaine, ce n'est pas continu, peu importe le nom de l'outil. Et puis parfois j'entends des choses, vous savez, comme il y a beaucoup de conversations sur le CICD, le CICD, et puis on dit, et on sort une version tous les six mois avec notre CICD. Et encore une fois, si vous ne publiez, si vous ne faites du déploiement continu que tous les six mois, ce n'est pas continu. Alors le mot continu a commencé à signifier, enfin sa signification a été presque oubliée. Et bien sûr, il y a un éventail de fréquences auxquelles vous devriez faire ces choses. Alors quand vous pensez à pousser vers le master, vous savez, ce qui est, vous savez, l'intégration. Euh, si vous intégrez chaque caractère, ce serait vraiment continu, mais ce serait évidemment une façon ridicule de faire du logiciel, ça causerait le chaos. Si vous faites chaque commit et que vous commitez plusieurs fois par heure, c'est plutôt bien. Si vous le faites tous les quelques commits et que vous le faites plusieurs fois par jour, je pense que c'est aussi très bien. Si vous êtes une fois par jour, une fois par semaine ou certainement pas. Une fois par mois, certainement, certainement pas. Euh, et si vous le faites une fois tous les six mois, cela semble aussi ridicule que de le faire à chaque caractère. Mais quand j'ai, euh, quand j'ai commencé chez IBM, et je devrais dire que c'était il y a 20 ans, ce n'était pas récemment. Euh, et bien sûr, je ne savais rien de l'ingénierie logicielle professionnelle. Et un coéquipier me montrait comment utiliser le système de contrôle de version. C'était WebSphere et vous ne vouliez pas être sur l'appel de build WebSphere, et si vous cassiez la build, vous seriez convoqué à l'appel de build WebSphere, ce qui arrivait tous les jours, y compris le samedi. Et donc la meilleure façon d'éviter de casser la compilation et d'être sur l'appel de compilation websphere était de ne pas intégrer le code. Alors ils gardaient toutes leurs modifications pendant littéralement six mois sur leur ordinateur portable avant de les pousser. Je pense que nous savons tous maintenant que ce n'est pas une bonne chose, mais nous voyons toujours des modifications ne pas être validées très souvent. Je suis donc une grande partisane du développement basé sur la branche principale, et la ligne officielle pour le développement basé sur la branche principale est une fois par jour. Donc, si vous êtes à gauche de cette ligne, vous pouvez dire que vous faites du développement basé sur la branche principale. Euh, et vraiment si vous êtes du bon côté de cette ligne, je pense que ce n'est pas une bonne pratique. Mon est remonté tous les quelques commits.
[00:28:04] Alors, à quelle fréquence devriez-vous publier ? Eh bien, même histoire, il y a un spectre. Euh, et sur ce point, je pense, vous savez, que nous voyons beaucoup d'entreprises qui poussent vraiment et elles parviennent à publier à chaque push, ce qui est plusieurs fois par jour, ce qui est génial.
[00:28:17] Euh, et encore une fois, vous savez, le D de CD est pour déployer, donc vous devez vraiment faire cela si vous parlez de CD. Nous ne publiions qu'une fois tous les deux ans, évidemment, ce n'est plus suffisant. Si vous comptez le faire plusieurs fois par jour, vous devez maîtriser parfaitement les indicateurs de fonctionnalité et ce genre de choses. Je pense que le minimum pour une bonne pratique est probablement une fois par sprint, tout ce qui est moins que cela. c'est, vous savez, définitivement assez vieille école. Euh, tout ce qui est plus que ça, c'est génial. Chaque push, ce sont des compétences assez pointues. Je pense que chaque user story est peut-être un objectif légèrement plus réalisable pour la plupart d'entre nous, et toujours bon. Donc, qu'en est-il de la livraison continue, qui est essentiellement le test et la mise en scène ? Vraiment, je pense que vous devez le faire à chaque push, je ne pense pas qu'il y ait un tel spectre là-dessus.
[00:29:23] Et en quelque sorte la barrière avec le CD qui ne se transforme pas réellement en releases, c'est qu'il y a une peur de la release. Alors c'est un client qui dit, on ne peut pas je veux le défaire et dire, pourquoi ? Qu'est-ce qui nous empêche ?
[00:29:39] de faire des déploiements plus fréquents. Et souvent, cela revient à la question des microservices. Ce qui est le le le point des microservices, l'objectif est un déploiement indépendant. Mais certaines organisations les déploient toutes en même temps. Certains écrivent même leurs pipelines pour forcer le déploiement simultané de tous les éléments.
[00:30:08] Et parfois, c'est parce que nous voulons que chaque fonctionnalité soit complète. Et c'est là que je pense que nous voulons revenir à certaines de ces idées de démarrage allégé. Et dites, si vous êtes, vous savez, c'est bon de faire sortir les choses, d'obtenir le feedback. Parce que l'objectif du cloud natif est la vitesse. Et donc si vous avez l'air d'être dans le cloud, mais que vous avancez très lentement,
[00:30:35] à quoi bon ? Alors pourquoi avoir cette belle architecture qui a une surcharge qui vous permet d'aller plus vite ? Si vous n'allez pas plus vite.
[00:30:49] Et quand vous pensez à la valeur du feedback, et je pense que je suis probablement avec un public qui suit, je suis en train de prêcher des convertis. Mais vous ne conduiriez jamais comme ça parce que vous voulez le retour d'information sur la personne que vous êtes sur le point d'écraser. Mais nous livrons souvent des logiciels comme ça, et nous travaillerons pendant des mois sans obtenir de feedback. Mais ce retour, c'est une bonne ingénierie.
[00:31:14] Et ce n'est pas seulement une question d'ingénierie, ce retour est aussi bon pour les affaires, il aide l'entreprise à prendre des décisions plus précises. Et si c'est trop effrayant d'expédier des choses, alors tous ces outils que nous pouvons utiliser. Donc nous pouvons utiliser le câblage différé, ainsi le code est en quelque sorte là. Mais rien ne lui parle. Nous pouvons utiliser la fonction pour s'assurer que le nouveau code est masqué. Nous pouvons l'exposer à une petite proportion de nos utilisateurs pour voir si quelque chose de grave se produit. Nous pouvons donc faire des tests A/B, nous pouvons faire des déploiements canaris. Et souvent, la raison pour laquelle ces choses n'arrivent pas est un manque d'automatisation. Et souvent, la raison pour laquelle nous ne pouvons pas publier plus rapidement est que nous n'avons aucune idée si cela fonctionne. Donc nous devons faire une longue phase de QA manuelle parce que les tests ne sont pas automatisés. Et en gros, si j'entends que nos tests ne sont pas automatisés, ce que j'entends en réalité, c'est : nous ne savons pas si notre code fonctionne. Et bien sûr, si vous ne savez pas, vous savez, les choses vont changer, les systèmes vont se comporter de manière inattendue, même si votre code est parfait, sa mise à jour de dépendance peut changer le comportement, donc vous avez besoin de ces tests.
[00:32:27] Mais ce manque de confiance dans la qualité empêche les organisations de livrer.
[00:32:35] Et, vous savez, surtout s'il s'agit de microservices, vous avez besoin de ces tests d'intégration automatisés et de ces tests de contrat automatisés.
[00:32:42] Une autre chose que je vois avec l'automatisation, c'est que la construction, qui devrait être la chose à laquelle nous tenons tous beaucoup, est en quelque sorte enfouie et les gens doivent aller chercher une page web. Et nous devrions afficher l'état de notre build partout de manière très passive, donc penser à avoir des choses comme des radiateurs de build, des choses comme des feux de circulation pour nous montrer quand il y a un problème et agir rapidement. Donc quelque chose comme ça, vous savez, où il y a juste un moniteur qui affiche toujours l'état de la construction, j'aime beaucoup avoir ça dans mes équipes.
[00:33:14] Et le problème, c'est que si vous n'avez pas cela, et/ou si vous n'agissez pas rapidement, alors la build se casse, et elle reste cassée, et tout le monde espère que c'est le problème de quelqu'un d'autre. Alors parfois je regarde la build et quelqu'un dit, oh oui, cette build est cassée depuis quelques semaines. Et je me dis, eh bien, pourquoi ne l'avons-nous pas réparé ? S'il est cassé, car il cesse de nous donner des informations utiles s'il est toujours lu.
[00:33:40] J'ai donc voulu changer un peu de sujet et réfléchir à nouveau au pourquoi et au comment nous utilisons le cloud. Parce que souvent nous voyons un cloud qui a perdu ses caractéristiques de cloud, il est en quelque sorte tellement verrouillé qu'il n'est plus un cloud.
[00:33:57] Et cela peut arriver pour toutes sortes de raisons. J'ai donc parlé à une banque aujourd'hui, et bien sûr, ils sont très réglementés et doivent faire certaines choses que, vous savez, le reste d'entre nous préférerait peut-être ne pas faire. Mais la façon dont ils avaient leur réseau, ils étaient en route vers le cloud.
[00:34:14] Mais vous pouviez choisir, donc quand vous aviez un ordinateur portable, il pouvait soit accéder aux systèmes cloud, soit accéder à leur réseau, qui était sur le réseau. Vous ne pouviez pas faire les deux. Et donc si vous vouliez faire les deux, vous deviez avoir deux machines. Et cela a introduit tellement de frictions à tout. Alors, s'ils voulaient commencer à coder sur un nouveau projet, il leur faudrait une semaine juste pour écrire cette première ligne de code. Parce qu'il faudrait deux jours pour obtenir un repo, deux jours pour obtenir un pipeline.
[00:34:44] Une autre chose que je vois, c'est que parfois nous ne changeons pas les processus même si nous sommes sur le cloud. Donc, pour revenir à ce tableau de publication, parfois le sera prêt à être expédié. Mais le conseil d'architecture n'a pas encore eu lieu. Mais aussi, nous mettons souvent trop de gouvernance autour du cloud.
[00:35:04] C'est une histoire qu'on m'a racontée, je ne l'ai pas. Euh, mais le client, nous avons vendu un logiciel de provisionnement à IBM, ou à euh, IBM a vendu le logiciel. Et c'était il y a quelques années, quand le provisionnement était encore quelque chose d'excitant et de nouveau. Et nous leur avons dit que ce logiciel est incroyable, vous pouvez provisionner une machine virtuelle en 10 minutes. Et ils ont dit, oh oui. Mais ensuite, ils sont revenus vers nous et ont dit : « Ce logiciel que vous nous avez vendu ne fonctionne pas, il nous faut trois mois pour provisionner quelque chose. » Et nous avons dit, oh non, il doit y avoir un problème technique ici. Et donc, mais quand nous avons regardé, nous avons réalisé que ce qui s'était passé, c'est qu'ils avaient mis un processus de pré-approbation devant la formation. Et c'était un processus de pré-approbation en 84 étapes. Je suis étonné qu'ils aient réussi à le faire en trois mois, vraiment.
[00:35:55] Donc ce qu'ils avaient fait, ils prenaient ce magnifique cloud et ils mettaient tellement de gouvernance autour. Et ça ne va tout simplement pas fonctionner.
[00:36:07] Une autre histoire. Euh, et ils avaient un fournisseur de cloud et ils nous ont dit, oh, nous changeons notre fournisseur de cloud. Et puis ils ont ajouté que la raison pour laquelle ils le faisaient était qu'il leur fallait tellement de temps pour provisionner des choses chez le fournisseur d'origine à cause du processus d'approvisionnement interne. Et j'ai pensé, changer de fournisseur ne va pas résoudre ça. Le problème n'est pas avec le fournisseur, le problème est avec vos structures internes. Et vous pourriez avoir un peu de temps avant que les achats ne rattrapent leur retard, mais vous aurez le même problème, vous devez réparer quelque chose d'autre.
[00:36:39] Et donc, en général, si seuls les développeurs sont enthousiastes à l'idée de devenir natifs du cloud, cela ne fonctionnera pas. Et quand nous avons cette organisation où tout génère tant de friction, vous savez, il y a un coût réel parce que les développeurs partiront.
[00:36:59] Mais bien sûr, cette gouvernance est là pour une raison. Ce qui signifie que parfois le cloud peut être coûteux. Euh, et ce que beaucoup d'organisations voient, c'est que le cloud, il rend si facile le provisionnement de logiciels, c'est la joie du cloud. Mais bien sûr, cela ne signifie pas que le matériel est gratuit, il fonctionne toujours dans un centre de données quelque part. Et souvent, nous provisionnons des choses et ensuite elles deviennent, elles cessent d'être utiles, mais nous les avons oubliées.
[00:37:33] Et je, vous savez, j'ai fait ça, quand j'apprenais Kubernetes, j'ai créé un cluster pour comprendre comment ça marchait. Mais j'avais trop de travail en cours. Alors je l'ai oublié pendant deux mois. Et puis, quand je l'ai repris, j'ai réalisé qu'il avait fonctionné et que c'était en quelque sorte un cluster spécifié, donc c'était 1 000 livres par mois. juste gaspillé. Et donc, vous savez, j'étais occupée à faire d'autres choses. Euh, je pense que je n'étais pas réellement en vacances, je pense que je faisais d'autres travaux en cours. Mais l'effet est le même : l'argent s'évaporait pendant que je faisais autre chose. Et cela se produit partout dans l'industrie. Ils ont réalisé une enquête en 2017 auprès de 16 000 serveurs. Et ils ont constaté qu'un quart d'entre eux ne faisaient aucun travail utile. Et ils ont en quelque sorte, les auteurs de cette étude ont dit, peut-être que quelqu'un a oublié de les éteindre. Et ça nous arrive à tous et ça s'accumule vraiment. Et bien sûr, il y a un impact climatique à cela, ainsi qu'un impact financier si nous avons tous ces déchets. Et c'est pourquoi nous obtenons la gouvernance. Mais quand on pense à ce qui se passe avec le cloud, J'adore cette citation de Peter Drucker. Parce que le cloud rend si facile le provisionnement de logiciels, mais si nous n'aurions pas dû le provisionner, alors c'est très, très inutile, cette capacité du cloud. Et beaucoup d'organisations ont vraiment, vraiment du mal à maîtriser leurs dépenses cloud parce que, vous savez, chaque organisation est multi-cloud. Et donc c'est réparti entre différentes organisations et ensuite nous obtenons la loi de Conway au niveau du développement. Et puis cela signifie qu'il est vraiment difficile d'avoir une vue d'ensemble du cloud. Alors, je pense que c'est un domaine où le cloud aide réellement, car nous commençons à voir des clouds pour gérer votre cloud. Et des choses comme, euh, la gestion multi-cloud vous permettra de déplacer les charges de travail là où cela a le plus de sens financier de les exécuter. Et aussi simplement obtenir cette visibilité de ce qui se passe. Et je pense que nous en voyons plus dans ce domaine également. Ainsi, Fino est, euh, un domaine émergent, c'est en quelque sorte, vous savez, le cousin du design et des opérations et du dev ops et du dev sec ops et de tout. Mais il s'agit de s'assurer de la responsabilité des coûts du cloud, mais je pense que cela aide aussi à identifier qui a oublié d'activer son cloud. Et en général, les opérations dans le cloud, si vous avez beaucoup de cloud, si vous avez beaucoup de microservices, vont être plus difficiles. Nous devons donc adopter ces nouvelles disciplines comme le SRE, euh, l'ingénierie de la fiabilité du site.
[00:40:28] Et ce que nous tous, le DevOps et le SRE et toutes ces nouvelles disciplines, ce qu'elles vont nous aider à faire, c'est de rendre les releases si ennuyeuses. Que nous pouvons les faire souvent.
[00:40:42] Et je pense que nous imaginons parfois que nous ne pouvons pas publier souvent parce que notre cas d'utilisation est spécial. Et il existe des cas d'utilisation qui sont véritablement spéciaux. L'espace en est un. C'est donc la sonde Phobos, une sonde spatiale russe. Mais elle a aussi eu une fin très triste. Euh, parce que ce qui s'est passé, c'est qu'il y a ces ailettes qu'il fait tourner pour capter l'énergie solaire. Et un ingénieur a fait un déploiement, et il y avait une sorte d'équivalent du linting pour le code machine, mais c'était cassé. Ou vous savez, ne fonctionnant pas correctement, alors l'ingénieur a contourné le linting. Et ils avaient un zéro supplémentaire quelque part dans le code machine que le linter aurait détecté. Mais parce qu'il n'y avait pas de tests automatisés, c'est allé directement à la sonde spatiale. Tout semblait fonctionner correctement. Mais ce qu'ils n'avaient pas réalisé, c'est que ces bras qui étaient censés pivoter pour suivre le soleil ne pivotaient pas. Et ils ne l'ont découvert que lorsqu'il est tombé en panne de batterie. Une fois qu'elle était à court de batterie, rien de ce qu'ils envoyaient à cette sonde ne pouvait la réanimer. Elle était donc dans l'espace, ils ne pouvaient donc pas, vous savez, aller donner un coup de pied au serveur, l'éteindre et le rallumer. Alors, c'était mort.
[00:42:02] Et dans ces cas-là, s'il y a un problème, il n'y a pas de récupérabilité. Mais dans la plupart des cas, la récupérabilité est très bonne, et nous pouvons faire des efforts d'ingénierie pour obtenir une récupérabilité encore meilleure. Donc, sonde spatiale, irrécupérable. La plupart des autres choses sont assez récupérables. Et donc si nous pensons à l'éventail, à l'extrémité la plus mauvaise de l'éventail se trouve cette chose complètement irrécupérable. S'il y a beaucoup de transferts pour récupérer un service, ça va être mauvais. S'il nécessite une intervention manuelle, ce sera mauvais. Euh, si nous le remettons en ligne rapidement mais avec perte de données, eh bien, c'est un peu dommage, mais, vous savez, nous sommes toujours assez récupérables. Et bien sûr, l'idéal est de le récupérer en millisecondes sans perte de données. Donc, globalement, le déploiement d'automatisation, nous voulons essayer d'automatiser cette récupérabilité, ce qui nous donne la confiance de publier souvent. J'ai donc raconté un tas d'histoires tristes et Je veux juste terminer par quelques points qui, vous savez, nous savons qu'ils vont vous aider à réussir dans le cloud natif, euh, le premier est d'avoir cet objectif clair de ce que vous essayez d'atteindre avec le cloud natif, au-delà de la simple conformité aux mots-clés à la mode. Tout est optimisé pour le feedback, optimisé pour le feedback. Et regardez l'ensemble du système. C'est donc une excellente opportunité pour la pensée systémique. Alors si vous automatisez quelque chose, regardez les processus environnants qui supposent que le processus qui était auparavant manuel est coûteux ou sujet aux erreurs, car ce n'est plus le cas.
[00:43:44] Maintenant que c'est automatisé.
[00:43:47] Donc quand nous regardons à nouveau le cloud natif, c'est une très bonne opportunité pour la cartographie des flux de valeur. Si nous examinons l'ensemble de notre processus de publication, si nous faisons un tas d'organisations dans un domaine, mais que ce n'est qu'une optimisation locale, cela ne nous donnera pas les résultats que nous voulons. Et avec ça, je vais m'arrêter et nous pourrons faire des questions-réponses. Merci.

Transcription (Traduit)