Cet habrapost est une entrevue avec Anton Weiss, copropriétaire du conseil en technologie Otomato Software, propriétaire de plus de 15 ans d'expérience dans le domaine de la haute technologie. Il est expert en enseignement technique, initiateur et co-auteur du premier cours de certification DevOps israélien. Anton participe à des conférences internationales et est connu comme un conférencier cool.
Nous parlerons des sujets suivants:
La différence entre la Russie et Israël
Oleg: Veuillez me dire qui vous êtes et ce que vous faites.Anton: Je suis Anton, je suis né à Saint-Pétersbourg, mais j'ai déménagé en Israël à l'âge de 15 ans et j'y habite depuis. Au cours des vingt dernières années en Israël, je me suis engagé dans l'informatique sous ses différentes formes. Sur ces vingt années, les dix dernières se sont spécialisées dans tout ce qui concerne la livraison de logiciels: l'intégration, ce qui était autrefois appelé la gestion de la configuration et ce qui s'appelle maintenant DevOps. J'ai travaillé dans de grandes entreprises - dans des entreprises internationales telles que AT&T, BMC. Il a travaillé dans des startups. Au cours des quatre dernières années, j'ai eu ma propre société de conseil, appelée Otomato Software, où nous nous engageons à aider les organisations à optimiser les processus de livraison et à maîtriser de nouveaux outils: c'est-à-dire que nous faisons la partie technique et tout le reste.
Oleg: Y a - t-il une différence entre la Russie et Israël en termes de travail?Anton: J'ai à peine travaillé avec des clients russes. Le fait que les 3 dernières années me mettent en relation avec la Russie est une conférence. Et dans plusieurs entreprises russes, nous avons mené quelque chose comme un audit: nous sommes arrivés, avons cherché, trié, émis des recommandations et sommes partis. Autrement dit, il n'y avait spécifiquement aucun travail quotidien de ce type, il m'est donc difficile de dire exactement en quoi il diffère. Je pense qu'il y a toutes sortes de choses différentes. C'est-à-dire que dans le même Israël, nous avons des organisations corporatives si lourdes dans lesquelles les gens travaillent depuis 15 ans, et tout bouge très dur. Et peu importe comment ils essaient de faire une sorte de transformation, d'améliorer les processus: ils parleront, ils parleront, mais ... Nous avons un client avec qui nous avons tout fait il y a deux ans et pris toutes les décisions, développé tous les programmes et dans lequel puis au moment où tout a calé, nous sommes sortis de là. Il y a quelques jours à peine, j'ai rencontré à partir de là les patrons avec lesquels nous avons travaillé, je dis:
- Et comment?
- Et bien. C'est difficile, disent-ils, nous le faisons, maintenant quelque chose commence à se produire.
Deux ans plus tard. Il y a de la politique, il y a des zones d'influence. Il y a des gens qui ne veulent pas libérer ces zones d'influence, respectivement, quand une telle situation, il est très difficile de changer quelque chose. Eh bien, la boîte à outils elle-même progresse. D'un autre côté, en Israël, il y a des start-ups dans lesquelles tout change très rapidement, il est facile de relever un nouveau statut, elles sont toutes natives du cloud et sont complètement assises dans le cloud. Soit dit en passant, cela pourrait être l'une de ces différences tangibles entre la Russie et Israël. En Israël, avec un cloud public, c'est beaucoup plus facile. D'après ce que j'ai vu. En Russie, par exemple, il semble qu'il soit très difficile pour tout le monde, sauf les startups, d'accéder au cloud public, mais en Israël, c'est encore plus facile. Aujourd'hui, même les banques et les compagnies d'assurance comprennent déjà qu'au moins une partie de leurs activités peuvent être déployées dans le cloud public. Et ici, les contrats avec Google et Amazon ne font peur à personne. D'après ce que j'ai entendu lors de conférences en Russie, c'est encore plus compliqué, enfin, même du point de vue des sanctions, pas des sanctions et de certaines questions juridiques.
La différence entre startups et géants
Oleg: Je comprends. Soit dit en passant, où est-il plus intéressant et agréable de travailler: dans des startups ou dans de grandes organisations?Anton: C'est plus agréable, bien sûr, dans les startups, parce que les grandes organisations ... eh bien, vraiment, le matériel bouge très fort. Il y a bien sûr des avantages. Si vous regardez les grandes organisations, elles ont, par exemple, bien plus que ce qu'on appelle la diversité. Les grandes entreprises simplement parce qu'elles ont besoin de beaucoup de personnel ou parce que c'est une sorte de culture organisationnelle qui s'est développée au fil des ans, sont prêtes à embaucher différentes personnes. Plus précisément, en Israël, par exemple, dans les startups, vous ne trouverez presque pas, par exemple, les Arabes, ils sont presque absents. Dans les grandes organisations, c'est beaucoup plus facile. Mais les startups se développent déjà à partir d'une sorte de contexte culturel dans lequel la plupart des participants sont pour la plupart les mêmes hommes blancs. Il y a une culture de ce qui doit être déchiré correctement, et il est conseillé de travailler 10 à 12 heures par jour, et cela ne suffit pas non plus. Il semble que Moscou (c'est-à-dire Tel Aviv) soit derrière nous, il n'y a nulle part où se retirer, et donc elle devrait saigner ici et maintenant.
Oleg: Et qu'en est-il de la différence d'approche de DevOps dans les petites et grandes entreprises? Autrement dit, si vous, par exemple, travaillez pour deux personnes, vous ne pouvez pas configurer votre propre CI / CD, mais copier des artefacts à partir de SCP.Anton: Pour une chose. D'un autre côté, configurer CI / CD aujourd'hui ne signifie pas que vous effectuez réellement une livraison continue. Mais mettre en place une sorte de pipeline, si vous êtes une entreprise de deux personnes, est très, très simple. Si auparavant vous deviez vous embrouiller, vous disposez aujourd'hui de nombreux services cloud. A écrit YAML - et avant, allons-y. C'est plus simple. En fait, le défi concerne les startups en démarrage. Ceux qui sont allés au-delà de 20 personnes, et ici ils commencent à souffrir de détartrage, car il n'y a pas de processus. Tout fonctionnait d'une manière ou d'une autre, mais tout ce gâchis commence, et on ne sait pas comment nous pouvons maintenir cet ancien dynamisme et en même temps mener des processus, et décider qui d'autre fera tout cela.
Et puis tout commence, comme «nous aurons une équipe DevOps qui sera responsable de DevOps», nous savons ce que cela mène dans la plupart des cas. Un goulot d'étranglement apparaît, et progressivement, ils se développent là où les grandes entreprises sont maintenant. Les grandes entreprises ont une catastrophe complètement différente, elles n'ont déjà pas de goulot d'étranglement, mais simplement une passerelle puissante qui ouvre une fois par jour, et le reste du temps, une énorme quantité de déchets s'y accumule. Et alors ils pensent: «Comment pouvons-nous maintenant rendre beaucoup de petites passerelles à partir de cette passerelle qui peuvent être ouvertes beaucoup plus facilement?» Autrement dit, des problèmes complètement différents. Les startups ont un problème avec le fait que «nous sommes aspirés dans l'entonnoir, comment pouvons-nous nager?», Et pour les grandes entreprises - elles sont déjà dans l'entonnoir, elles sont déjà dans le monde souterrain, maintenant elles pensent comment remonter en haut.
La tendance augmente la complexité et ce qu'il faut faire à ce sujet
Oleg: Eh bien, plus la partie technique: lorsque vous avez peu de gens, des technologies simples, vous devez connaître un Linux de base, et c'est tout. Et avec la moindre mise à l'échelle, vous devez apprendre quelques Kubernetes, et cela semble être le problème.Anton: Et c'est sans aucun doute un problème. Nous avons eu une conférence il y a à peine deux jours, et il était très visible que presque tous ceux qui ont dit quelque chose ont mentionné un mot: «complexité» (complexité). C'est devenu une sorte de mot déterminant pour l'ensemble du discours DevOps aujourd'hui.
Oleg: C'était il y a un an?Anton: Dans une tentative de tout faire rapidement, dynamiquement, afin d'atteindre la flexibilité notoire, nous nous sommes enveloppés avec une telle complexité. En effet, il y a beaucoup de petits pipelines qui fonctionnent à merveille séparément, puis nous essayons de recueillir une image du monde à partir de tout cela, et ici la complexité surgit soudainement. Parce que nous construisons maintenant un processus à partir de tous ces petits pipelines pour que toute l'entreprise fonctionne comme un être humain.
Oleg: Et quelle est la réponse? Comment gérer cette complexité?Anton: Eh bien, il n'y a pas de réponses, ils sont nés dans le processus. Mon rapport portait sur l'une de ces solutions. Dans l'ensemble, est-ce que tout cela va? J'ai déjà été infecté par la pensée systémique, beaucoup de choses sont mentionnées à ce sujet dans DevOps. Je me suis intéressée, j'ai lu les livres de Peter Senge, Russell Ackoff, Donella Meadows - des gens qui à un moment donné ont commencé à penser de façon systémique et, dans l'ensemble, ont énoncé ses principaux postulats. Les boucles de rétroaction sont l'un des principaux prismes à travers lesquels la pensée systémique regarde le monde. Avec cette complexité, ces boucles de rétroaction se posent maintenant, c'est-à-dire que la complexité devient très, très élevée, nous commençons à chercher des outils pour en quelque sorte tenir compte de cette complexité. Je ne dis pas réduire - prendre le contrôle pour ne pas se déployer.
Des solutions centralisées apparaissent, dans l'ensemble, même Kubernetes est quelque chose comme ça. Vous avez un plan de contrôle centralisé qui, au moment où vous le contrôlez, contrôlera la complexité des services qui circulent. Le tamis de service, le même maillage de service, est le même type de solution. Nous disons: «Nous avons un tas de services, il est nécessaire qu'ils puissent se parler d'une manière ou d'une autre, car ils ne comprennent pas où ils sont assis et il n'est pas clair s'ils vont y répondre ou non, et ils ne s'en sortiront pas. Alors, faisons-le maintenant, au milieu, nous allons insérer un esprit universel qui leur dira, avec qui vous pouvez parler, avec qui vous ne pouvez pas parler, et les protéger s'ils disent soudainement quelque chose de grossier en réponse. " Et il y a beaucoup de questions. D'une part, c'est une sorte de nécessité, car les organisations ne peuvent pas faire face. Au cours des deux dernières années, nous avons aidé plusieurs organisations à migrer vers le nouveau monde audacieux de Cloud Native, en particulier en ce qui concerne la croissance, la mise à l'échelle et la perte de personnes. Au milieu de tout cela, il y a une petite équipe des soi-disant DevOps, qui doivent écrire des milliers de lignes YAML afin de faire face à tout cela, et tout éclate juste aux coutures.
Natif du cloud
Oleg: Pouvez-vous expliquer un peu ce qu'est Cloud Native? Parce qu'il est devenu une sorte de mot à la mode, maintenant tout le monde l'écrit sur chaque mur. Comment voyez-vous cela?Anton: Dans l'ensemble, tout a commencé avec l'émergence de l'approche «plate-forme en tant que service», c'est-à-dire lorsque nous devions exécuter beaucoup plus de logiciels et beaucoup plus de services Web qu'avant. Nous avons réalisé qu'il n'était plus possible de déployer chaque service séparément en tant qu'animal préféré, que nous connaissons par son nom et que nous prenons soin de lui toute notre vie, nous devons les traiter comme une sorte de troupeau. Pour ce faire, nous avons besoin d'une sorte de plate-forme homogène sur laquelle nous pouvons déposer ce code, et la plate-forme sera suffisamment intelligente pour le servir. Abreuvoir de voiture, en bref, un buveur-mangeoire pour le service.
Les pionniers de cette approche étaient Heroku. Ils ont dit que pour que ces services utilisent nos infrastructures, ils devaient aussi être des vaches. Autrement dit, ils doivent avoir certaines qualités. Il y avait donc une application à 12 facteurs, qui aurait dû avoir le moins de stabilité possible. Une telle application est nécessairement assemblée par un certain pipeline dans lequel sa compatibilité avec la plateforme est vérifiée. Il doit pouvoir être résilient (stable) - savoir que si quelque chose a mal tourné, alors ne tombez pas immédiatement. D'autre part, dans un sens, s'appuyer sur la plate-forme. En général, un tel hybride. Comprenez que vous n'êtes pas seul, qu'il existe une plateforme et que vous devez respecter ses limites. Dans l'ensemble, tout a commencé à partir de là.
Mais pour une raison quelconque, cette approche de «plateforme en tant que service» ne se justifiait pas et le boom promis ne s'est pas produit. C'est-à-dire, oui, c'était Heroku, puis immédiatement après eux, tous les gros gars ont également élevé leurs analogues: Google App Engine, Amazon - Elastic Beanstalk. J'ai dû beaucoup travailler avec des entreprises qui ont commencé avec ça. Mais au moment où vous faites quelque chose qui dépasse légèrement les limites autorisées par la plate-forme, cela se transforme en un terrible mal de tête. Parce que vous commencez à tomber sur des murs qui sont partout. Et comme les gens ont tendance à trébucher sur les murs, ils commencent à chercher un moyen de traverser le mur.
Le Cloud Native moderne a grandi à partir de là: comment le faire fonctionner toujours dans le cloud, utiliser certains services de plate-forme, mais aussi fournir une flexibilité incroyable pour tout ce qui se passe. Nous équilibrons constamment entre flexibilité et simplicité. La flexibilité entraîne de la complexité, tandis que la simplification et la création d'une plate-forme claire entraînent toujours des limitations. Cloud Native est apparemment en train de trouver un certain équilibre entre les limites de la plate-forme cloud et la flexibilité que le cloud vous permet avec sa mise à l'échelle automatique, et tout cela a un prix.
Oleg: Probablement, l'organisation elle-même devrait d'une manière ou d'une autre apprendre à vivre de manière processuelle avec tout cela.Anton: Naturellement, naturellement! Tout cela laisse sa marque. Les microservices en font également partie. Dans l'ensemble, c'est l'idée que nous avons de petits services, de petites applications qui sont dispersées à travers le cloud et peuvent être n'importe où à tout moment, et il peut y avoir 10 répliques maintenant et demain - 1500, cela fait également partie du Cloud Natif L'idée que nous ne sommes pas limités par les limites physiques du centre de données. Dans l'ensemble, le monde entier est mon nuage, c'est une vision absolument merveilleuse, une poursuite merveilleuse, mais il a un prix, et ce prix est la complexité, le prix est que, dans l'ensemble, personne dans la tête ne peut s'adapter à ce qui va se passer, lorsque notre application passe soudainement de 10 instances à 1500. Personne ne peut imaginer cela, et tous les artefacts de mise à l'échelle commencent à apparaître. En tant qu'êtres humains, en tant qu'opérateurs, nous ne pouvons rien faire d'autre que répondre au chaos qui se produit. Et donc nous commençons à penser: «Mais comment pouvons-nous construire notre application et notre infrastructure de sorte que lorsque ces artefacts surviennent, premièrement, ils peuvent être prévus, et deuxièmement, d'une manière ou d'une autre, nous pouvons faire face à ces artefacts et continuer fonctionner? "
Combiner les compétences techniques et non techniques
Oleg: Avez-vous des rapports sur des choses techniques, par exemple, sur un tamis de service et il y a des rapports sur le leadership, sur la gestion, tout ça. Êtes-vous plutôt une personne technique, ou êtes-vous un gestionnaire, ou votre travail est-il différent?Anton: J'ai même commencé à écrire à un moment donné sur ce post, je ne l'ai pas encore fini. Dans un sens, je suis tiraillé purement personnellement entre ces deux choses, parce que, d'une part, j'aime comprendre comment les choses fonctionnent, j'aime y faire face. Quand il est possible de résoudre un problème technique, cela donne juste un sens étonnant de ses capacités, ce qu'on appelle la gratification instantanée, la récompense immédiate, la farce de dopamine: "Oh, cool, je peux, j'ai décidé." Et c'est difficile de refuser, c'est difficile de descendre. Et comme c'est le cas, je continue à faire des choses techniques. Les nouvelles technologies m'excitent: c'est cool de choisir quelque chose, de comprendre quelque chose. Pour cette raison, il s'avère que, comme il existe cette connaissance, les gens veulent l'acheter et je continue de la vendre.
D'un autre côté, je comprends que ce n'est qu'une petite partie de la situation dans son ensemble, je travaille dans l'industrie depuis longtemps et je ne peux m'empêcher de voir que la technologie n'est qu'un coin d'un grand système, juste l'un des composants. J'ai dirigé les équipes et je comprends combien il est important de prendre en compte l'interaction des technologies et des outils avec les personnes qui les utilisent. En fin de compte, la technologie de l'information, en fait, toute technologie, existe pour que les gens l'utilisent. Et créer des technologies sans penser à qui les utilise est complètement inutile. La technologie elle-même n'est pas du tout intéressante, sauf si vous pensez à son application, et l'application est toujours associée à des personnes qui en bénéficient d'une manière ou d'une autre. Et donc tout ce qui concerne la technologie m'intéresse beaucoup. Je sens qu'il faut en parler, je comprends que sans ça, tout n'a vraiment aucun sens. Dans la mesure où je deviens parfois haut pour m'asseoir, quelque chose à renifler pendant deux à trois jours, parfois des semaines. Je peux me laisser emporter par une sorte de problème que je ne peux pas résoudre, je peux le résoudre, en obtenir une paroisse incroyable. Mais ensuite, je lève la tête du clavier, regarde autour de moi et je comprends qu’il se passe quelque chose que je ne peux ignorer en aucune façon. Et puis le code et le picking sous Linux deviennent complètement inintéressants pour moi, sans importance, et je veux commencer à résoudre des problèmes à un niveau différent, au niveau humain.
Comment comprendre rapidement DevOps
: , - , DevOps ? ? , , , , ?: … , , . , , 10 , . , , , , . , . … , ? , , . , , — , : , , , — , . , , -? , . -, , .
«». , , - , . . . , , , , . , — , . , , , . : -, , , — , Gist' GitHub. - — .
. DevOps — . , , . , , , , - , - , , - . , . , , , , , , , . , . . ? — , , . , , . , . Quelque chose comme ça. .
: , , DevOps', , . , , . , -, , … , . - , ? . , , : « ». , ?: -, , , : « ». - , , , , . , , : « ».
: ?: , , , , , . , — . , , «, , », - . , - , . - , - . , Agile: , , , , , .
, . . , — , - — , , — , , , , , . : « — , . , , . , . , , , -, , , ». , , , .
, - , , continuous integration … , , , . , , . , 10 : , , - , , , , , , , , . — . : , , , , . E - , , .
: . , - , , - , , , , DevOps -. ?: , , , , . , , , , ? , , . . - , , .
, , . , , .
DevOps
: , : Google, Netflix, . , ?: , , ( ) , — , , , . , , lean management — value stream mapping. . , , , - : , , , , , , , , . , , , .
: ? - — - , , — . , , , , . , , , Java, , , . , :
— , .
— , ? ?
— , , .
, , , , — , . — , .
, :
— .
:
— , , . .
, , :
— .
:
— . ?
:
— , .
, — , , . . . , CI/CD — . , . , , . , , .
: , ? , CI/CD . ?: -, , . - , , , , . Kubernetes: , — Kubernetes. VMware , Kubernetes . , Google . , , .
: Google ?: , , Swarm Kubernetes, Docker. Docker , . , Microsoft, Amazon — « Docker». Docker! Docker . , , , , Google, Microsoft, Amazon? , . , , , . , . Et c'est arrivé.
Alors voilà. . — . — « Kubernetes , ». . Kubernetes . Kubernetes — - API, , . API . — , , , , : « API, , Kubernetes, Kubernetes , ».
— , Continuous Delivery Foundation, - , , Google, CloudBees, GitLab. Tekton, — API continuous delivery-. , continuous integration / continuous delivery- Kubernetes, , , . ,
. Microsoft , , SMI Spec. , , - .
Kubernetes . , , - , , Kubernetes — .
Oleg: À quels rapports allez-vous vous-même, à quoi trouvez-vous intéressant?Anton: Tout d'abord, s'il y a une nouvelle fonctionnalité technologique, une erreur que je n'ai pas encore le temps de voir par moi-même, et il y a un orateur qui peut en parler intelligiblement, alors je pense que c'est un avantage sauvage, car à la place pour lire et creuser maintenant, et peut-être avec difficulté à comprendre, vous pouvez venir écouter en une demi-heure comment une personne va vous montrer, vous le dire. Encore une fois, pour cela, vous avez besoin d'une certaine compétence et d'un désir de pouvoir parler de technologie. Et je comprends que cela ne vient pas de nulle part, nous devons y travailler. Cela m'a aussi pris beaucoup de temps. Soit dit en passant, le fait que je suis engagé dans l'enseignement technique m'a beaucoup aidé dans ce domaine. Lorsque vous avez un cours devant vous, vous devez expliquer quelque chose aux gens, et vous comprenez que, peu importe comment vous l'expliquez, ils sont stupides - vous vous rendez compte que, apparemment, le problème est de savoir comment vous expliquez, et non pas que les gens sont stupides .
Oleg: Et quel genre d'enseignement technique? Que fais tuAnton: J'enseigne des disciplines purement techniques depuis environ 7 à 8 ans. Cela a commencé avec le fait que j'ai enseigné des choses comme Maven et l'écriture de scripts shell pendant un an. Comme j'étais très occupé avec Jenkins et que je le connaissais profondément, j'ai enseigné aux gens comment travailler avec Jenkins, administration. Ces dernières années, tout ce qui concerne le cloud natif: Kubernetes, conteneurs et tout ce qui l'entoure. Je vais bientôt à Londres, je vais faire un master class sur Istio. Ce n'est pas l'essentiel de mon activité, mais quelque part dans un mois ou deux je donne des master classes.
Oleg: Allez-vous principalement à un reportage, à un sujet ou à une personne?Anton: Si je sais que l'orateur est bon, je vais voir une personne simplement parce qu'il est toujours très important pour moi d'apprendre des autres comment bien dire. L'apprentissage est toujours important. S'il y a un sujet, mais je ne connais pas l'orateur, alors je vais voir, mais comme d'habitude, comment aller au stand-up: j'ai regardé les 10-15 premières minutes, je ne suis pas entré - je suis parti. Ou il y a des conférenciers que j'irai vraiment de quelque façon que ce soit, car ils racontent toujours de manière intéressante, même les choses que vous savez peuvent montrer sous leur angle, c'est juste pour vous et cela transforme toute la question dans une nouvelle perspective. De ceux que j'aime récemment ... Tout d'abord, il y a Simon Wardley - un consultant, il a sa propre puce avec des cartes à dessiner, il explique à l'aide de cartes comment les entreprises peuvent construire correctement leur stratégie, il était une fois puis CTO, PDG des startups, il en parle beaucoup, de la technologie. Soit dit en passant, il se noie constamment sans serveur et dit que ceux qui ne le font pas aujourd'hui ont de gros problèmes.
Oleg: Est-ce le camarade qui a le livre Medium ? Il l'a fait sous forme de messages. Format inhabituel.Anton: Il parle vraiment très cool. Ses conférences des 2-3 dernières années, je m'en souviens le plus. Eh bien, John Willis, qui est venu à DevOops l'année dernière - simplement parce qu'il
sait vraiment comment le dire . Il a un problème avec lui, car il parle beaucoup de la réalité américaine, des choses qui parfois ne s'appliquent tout simplement pas à la réalité russe ou israélienne. Maintenant, ils ont une sorte de guerre avec des comités d'approbation des changements, dont ils parlent constamment. C'est, apparemment, une certaine chose qui existe dans les entreprises américaines, il existe un tel processus pour mener et approuver des changements dans les TI, une sorte d'engagements doivent être respectés.
Oleg: Mais nous n'en avons pas - je ne comprends même pas de quoi vous parlez maintenant.Anton: Donc je ne comprends pas vraiment non plus, il n'y a rien de tel en Israël non plus. Et là, ils en parlent. Si vous écoutez tous ces camarades, comme DORA, qui
font le rapport State of DevOps , ils écrivent aussi beaucoup à ce sujet. En général, je veux dire que les gens parlent d'une sorte de problème qu'ils ont seulement, et que cela ne vous intéresse pas du tout.
Oleg: Vous étiez aux derniers DevOops, quels rapports valent-ils la peine de consulter et de revoir les enregistrements?Anton: Voir
tout le monde . Peu intéressé par le sujet - allez-y.
Oleg: Il y a un certain Anton Weiss, à mon avis. Ça vaut probablement le coup d'oeil.Anton: Non, n'y vas pas, certaines choses ennuyeuses :-)
Oleg: Eh bien, merci beaucoup. C'était génial! Je vois que vous avez déjà soumis un rapport à la prochaine conférence, alors - à bientôt aux prochains DevOops!La conférence DevOops 2020 Moscou se tiendra du 29 au 30 avril, cette fois à Moscou. Nous avons décrit l'essence de la conférence sur Habré dans l'annonce "Les ingénieurs DevOps n'existent pas" . Le programme est en cours de constitution (il reste encore plusieurs mois avant la conférence), mais les premiers intervenants sont déjà visibles sur le site . Vous pouvez y acheter des billets .