Entretien avec Alexander Titov, l'un des membres du comité de programme de notre
conférence de juin HighLoad ++ , dont une section distincte sera consacrée à DevOps.
Sous la coupe sur la direction dans laquelle le "vent" DevOps souffle, et quels sont exactement les aspects de ce concept qui seront discutés lors du forum.
Alexander est assez familier de notre communauté, il est l'organisateur de DevOps Moscou et de la conférence DevOpsDays Moscou, il intervient lors de nos événements depuis plusieurs années et aide à la formation de leurs programmes. Il est actuellement associé directeur chez Express 42, qui développe des DevOps dans les entreprises technologiques. Plus tôt, de 2010 à 2012, Alexander a parcouru un chemin de rachat fascinant avec Qik, de l'exploitation d'une start-up à croissance rapide à celle d'une grande entreprise internationale Microsoft. Auparavant, en 2009-2010, il était directeur technique du premier hébergement cloud en Russie, Skalaxi.- Commençons de loin: la culture DevOps évolue-t-elle? Quels changements ont été observés dans ce domaine ces dernières années? Et à quoi ressemble DevOps en Russie?Bien sûr, dans un monde où la technologie se change tous les trois ans, tout change constamment et beaucoup. Initialement, le problème de base était la production et l'exploitation du logiciel lui-même à l'ère numérique. Autour de ce problème, le mouvement DevOps s'est rassemblé. Maintenant, le problème de base a été divisé en plusieurs sous-catégories - gestion des infrastructures, surveillance, intégration continue, livraison continue, travail avec les gens (en particulier, le problème de l'épuisement professionnel des personnes engagées dans l'exploitation et le développement), certaines choses technologiques (par exemple, l'apparition de Kubernetes, comme norme de facto pour l’ensemble de la plate-forme d’infrastructure des entreprises). C'est à bien des égards que des détails sont apparus: nous sommes passés par l'étape de la compréhension de ce qui doit être fait différemment qu'auparavant, avons essayé de nombreuses nouvelles approches et sommes parvenus à la formation de processus standardisés pour résoudre des problèmes communs (typiques). Mais dans le même temps, les outils et processus de nombreuses entreprises à travers le monde restent de mauvaise qualité ou très mal formalisés.
Dans le contexte russe, un problème supplémentaire est que nous ne comprenons pas pourquoi tout cela est nécessaire. Cela en désoriente beaucoup. Nous avons le développement, les tests et le fonctionnement séparément, puis certains Kubernetes interviennent pour résoudre certains problèmes, mais ils essaient de le mettre en œuvre sans changer les processus, les approches et les compétences des personnes. Tout tombe en panne. Et pourquoi ces nouvelles technologies ne sont pas claires.
- Et quelle est la raison d'une telle transformation radicale?Comme je l'ai déjà mentionné, nous avons commencé à résoudre un autre problème. Initialement, l'informatique classique a résolu le problème de l'automatisation des processus métier au sein d'une entreprise. Toute l'infrastructure a été adaptée à cela - bases de données, bus, etc. Depuis 2000, après la crise des dot-com, l'informatique est passée à la création de produits numériques capables de fournir massivement des services personnalisés, apportant une certaine valeur. Si auparavant, la société produisait un certain modèle de voiture, elle est maintenant passée à la personnalisation pour chaque client. Il s'agit d'une solution à un autre problème, pour lequel des approches et des technologies fondamentalement différentes sont nécessaires - un processus de production de logiciels différent. Ici, il n'est plus possible de faire le développement, les tests et le fonctionnement séquentiellement. Maintenant, ces processus démarrent simultanément.
Soit dit en passant, malgré cela, il y a une idée fausse selon laquelle DevOps concerne le fonctionnement. Les administrateurs système classiques qui effectuent des tâches opérationnelles sont simplement renommés ingénieurs DevOps, discréditant le terme en principe. En fait, le concept est beaucoup plus large. Il s'agit d'un ensemble distinct de pratiques, d'un cadre distinct qui vous permet de résoudre des problèmes spécifiques dans certaines conditions et avec des personnes d'une certaine compétence - ni plus, ni moins. Peu de gens comprennent pourquoi cela est nécessaire. Et c'est l'un des problèmes que nous essayons de résoudre par le biais de conférences.
-
Quels rapports sont prévus pour se concentrer sur les sections du Siberian HighLoad?Si auparavant, il y avait principalement des rapports opérationnels, cette année, nous voulons ajouter plus d'informations sur la connexion avec le développement, par exemple, sur les processus de livraison continue, d'intégration continue, de test. Un exemple intéressant est un rapport de Maxim Lapshin sur RIT ++ (dans le cadre du printemps RootConf 2018) sur la façon d'utiliser DevOps dans le développement de boîtes. Une telle entreprise n'a fondamentalement aucune exploitation - elle fabrique une boîte qu'elle vend à un client. En même temps, elle a DevOps à l'intérieur. Cette approche rompt le modèle, mais en même temps aide à démystifier le mythe mentionné que DevOps ne concerne que le fonctionnement. C'est notre premier objectif de base.
Le deuxième objectif est les nouvelles technologies. Maintenant, c'est à la mode de parler de Kubernetes, Prométhée et autres. Et nous recherchons des personnes qui ont pu ressentir ces technologies dans la pratique. Autrement dit, non seulement configuré et fait pour fonctionner, mais également inclus cela dans leur processus de développement. En général, nous essayons de considérer toutes les technologies sous le prisme de la façon dont elles sont incluses dans le processus de production de logiciels - quel problème elles résolvent, quels objectifs elles sont fixées, etc. Si vous n'en parlez pas, les gens commencent à travailler avec la technologie comme un culte du fret: "Mettons Kubernetes et nous pouvons créer Google." Cela ne fonctionnera pas de cette façon.
- Le concept d'intégration continue est déjà bien accepté par le marché. En plus des outils spécifiques, y a-t-il quelque chose à dire?Bien sûr. Le concept fondamental, on peut même dire, est que dans le contexte de DevOps, la qualité des produits n'est pas testée dans le cadre du processus d'intégration continue. Autrement dit, peu importe la maturité fonctionnelle du produit. Il est important de vérifier son bon démarrage et s'il est prêt à s'intégrer à d'autres composants.
Il s'agit d'un changement majeur, car il y a une intégration continue dans le développement, le fonctionnement et les tests cohérents. Mais là, à ce niveau, la qualité du produit est vérifiée selon les exigences de l'utilisateur, et dans le cadre de DevOps, les qualités fonctionnelles sont vérifiées. C'est cette étape qui permet l'intégration la plus rapide possible de services individuels dans le cadre de l'infrastructure de microservices (et DevOps dans son ensemble n'existe pas sans une architecture de microservices).
- Quels outils sont au centre cette année?Tout d'abord, le Kubernetes déjà mentionné. Il est apparu il y a quelque temps, mais n'a atteint que récemment le stade où il peut être utilisé. Désormais, il peut être utilisé par toutes les entreprises développant un service numérique mis à jour, par exemple en fournissant des services via des sites Web ou des applications mobiles.
Souvent appelé Prometheus - un système de surveillance, GitLab - comme un système d'intégration continue. Et aussi la totalité de la pile HashiCorp - Vault, Terraform (tous deux développés par HashiCorp). Eh bien, bien sûr, Docker - comme format de livraison.
- Y a-t-il eu des changements récents dans le cadre du concept de «tout comme un code»?La pratique de «tout en tant que code» lui-même est évidemment utile. C'est l'un des principes fondamentaux sur lesquels repose le processus DevOps. Kubernetes ne fait que poursuivre cette idéologie.
Dans DevOps, l'histoire principale est «l'infrastructure en tant que code». Et ce n'est pas seulement un concept, mais aussi un processus dans lequel tous les composants sont présentés sous forme de code qui permet à des «morceaux» d'infrastructure individuels d'interagir les uns avec les autres. Il n'y a pas de changements drastiques ici, mais, en tant que pratique, il se développe maintenant à l'intérieur de Kubernetes. Par exemple, des outils de gestion des dépendances tels que Helm sont développés, des outils pour créer des modules séparés, des descriptions d'infrastructure, par exemple, des opérateurs (et il existe des cadres pour écrire des instructions dans Kubernetes), etc. En d'autres termes, il y a un développement sain de l'instrument et une pénétration de la pratique en son sein.
- La pratique de «tout comme un code» distinct de l'instrument mérite-t-elle d'être discutée?Nous n'avons pas encore complètement formé un programme, donc je ne peux pas dire si nous aborderons ces sujets spécifiquement sur HighLoad ++. Mais cela en soi est possible.
Il existe de nombreuses approches pour organiser l'infrastructure, gérer la dépendance au sein du code d'infrastructure et le tester. Bien sûr, nous parlerons de concepts pour travailler avec la pratique - par exemple, le code d'infrastructure devrait être divisé en modules. Il me semble qu'affiné, isolé de la pratique, de tels sujets ne cadrent pas très bien. Mais, peut-être, nous choisirons un rapport où toutes les approches possibles seront rassemblées dans le cadre d'une description unique du système. Cependant, il est beaucoup plus précieux lorsque les gens disent et montrent comment ces concepts théoriques sont réalisés dans la réalité. À propos de la théorie qui sous-tend les pratiques, vous pouvez ensuite parler avec les mêmes personnes en marge.
- Il existe une opinion selon laquelle la popularité de l'architecture événementielle augmente avec le temps. Êtes-vous d'accord avec cette affirmation?L'infrastructure événementielle a toujours fait partie de l'approche chatops - par événement, nous décidons dans le chat de ce qui devrait arriver à un élément d'infrastructure. Cette histoire est très nécessaire pour les grandes grandes entreprises, mais pour le reste du public, elle n'est pas encore tout à fait mature. Afin de prendre des décisions sur ce qui devrait arriver (ce que nous devrions faire), il est nécessaire de développer un cadre pour les règles au sein des équipes sur la façon dont nous prenons ces décisions, afin que tout le monde le fasse plus ou moins de la même manière - regardez d'un côté. Et avec ça, tout est compliqué. Le format pour développer un tel cadre est ce dont tout le monde parle maintenant: comment il peut être automatisé, transformé en outil, comment cela doit être fait au niveau du renforcement d'équipe et comment se coordonner avec différentes équipes.
- Cela se reflète-t-il d'une manière ou d'une autre dans les rapports de conférence?Non, HighLoad ++ concerne davantage les systèmes et outils très chargés, nous pouvons donc parler ici d'outils, mais pas de développement d'un tel framework. Mais à l'automne, nous aurons une conférence RootConf distincte, qui se tiendra les 1er et 2 octobre. Jusqu'en 2011, il était consacré aux questions opérationnelles (c'est-à-dire une seule composante de l'ensemble du processus «développement-test-opération»). En 2015, nous l'avons réincarné dans le contexte de l'ensemble des DevOps - nous avons donc progressivement élargi le sujet. Chez RootConf, nous discutons de la façon d'assurer l'interaction des développeurs et des ingénieurs de maintenance, nous parlons de nouveaux processus et technologies, des plates-formes d'infrastructure et de la gestion des infrastructures, qui dans le paradigme DevOps ne sont pas seulement impliquées dans le fonctionnement, mais aussi dans le développement (ils font juste des tâches différentes).
- Existe-t-il des technologies intéressantes pour améliorer la résilience des projets au cours des deux dernières années? Seront-ils discutés lors de la conférence?Aujourd'hui, nous sommes tombés sur un paradoxe lié au fait que «tolérance aux pannes» ne signifie pas «fiabilité». La tolérance aux pannes est désormais supplantée par la fiabilité.
La tolérance aux pannes est un concept du paradigme des systèmes monolithiques, où le problème de fiabilité a été résolu par la duplication, l'augmentation des ressources, etc. Maintenant, de telles approches ne fonctionnent plus. La fiabilité repose sur des approches fondamentalement différentes - elle implique «l'anti-fragilité» du système. C'est-à-dire que le système devient «mou»: si nous agissons en conséquence, il change et non s'effondre. En d'autres termes, si vous allez créer une sorte de nouveau service, vous devez prévoir de telles variantes de son comportement dans lesquelles si l'utilisateur ou l'environnement dans lequel il travaille essaient de le détruire, alors le service change simplement ses propriétés, tandis que le service est toujours fourni , un résultat est donné.
Un bon marqueur de la tendance est l'émergence de l'ingénierie de la fiabilité du site en tant que pratique et des spécialistes individuels - ingénieur de la fiabilité du site (SRE) en remplacement de la compétence passée de l'administrateur système. Pour illustrer ce processus, je mentionnerai que Google a publié sa pratique d'implémentation DevOps sous la forme d'un livre sur l'ingénierie de la fiabilité des sites et promeut activement cette idée auprès des masses.
Nous en parlerons également à RootConf. Maintenant, ce sujet est sur le battage médiatique en Occident, et nous (par la communauté DevOps de Moscou) essayons de nous l'apporter progressivement.