DevOops 2019 à travers les yeux du développeur

Du 29 au 30 octobre à Saint-Pétersbourg, a eu lieu la conférence DevOops . Dans cet article, je partagerai mes impressions et mes idées, ainsi que de brèves notes sur les rapports que j'ai entendus. Un petit avertissement: étant donné que je suis développeur, certaines réflexions et commentaires peuvent être biaisés en Dev plutôt qu'en Ops, mais je vais essayer d'être aussi objectif que possible.

DevOops est l'un des événements organisés par le groupe JUG Ru . Et je dois admettre que l'organisation et le niveau des rapports étaient au niveau. La conférence a duré deux jours, en trois volets. En outre, il y avait des espaces de discussion pour la communication avec les conférenciers, des ateliers, ainsi que des discussions éclair - des présentations plus faciles et plus courtes, y compris pour ceux qui n'ont pas encore parlé et qui veulent s'essayer en tant que conférencier.

Toile thématique DevOops 2019 - native du cloud. La plupart des reportages étaient directement ou indirectement consacrés aux nuages. Le sujet n'est pas nouveau depuis longtemps, mais de nombreuses difficultés non évidentes se posent dans le processus d'utilisation des technologies cloud. Et beaucoup sont venus exprès pour trouver des réponses. Cela a été particulièrement visible lors des sessions d'AQ après les présentations. On a posé aux intervenants des questions pratiques qui excitent vraiment les gens. Presque chaque question a été suivie des remarques des autres participants «Nous avons le même problème!» Et une discussion animée a commencé.

Premier jour

Personnages, communauté et culture: facteurs importants de prospérité (Timothy Lister, The Atlantic Systems Guild Inc.)

La conférence a été ouverte par Timothy Lister, qui en 1987 (!) A écrit un livre sur les pratiques DevOps. Tim a beaucoup parlé de ce qui distingue une équipe solide et performante avec une atmosphère saine et agréable d'une équipe médiocre et toxique. Je me suis surtout souvenu de la pensée:

"Une bonne entreprise est pleine de gens qui disent" je ne sais pas. "

Il s'agit d'ouverture et de confiance au sein de l'équipe. Une atmosphère d'ouverture est indispensable si vous avez un objectif ambitieux. Pour ce faire, tout le monde dans l'équipe doit se sentir à l'aise et libre. Cela ne signifie pas qu'en cas de problème, un membre de l'équipe le transmet immédiatement à tout le monde. Une atmosphère d'ouverture est importante et la capacité à tout moment de se tourner vers une personne en particulier (quelle que soit sa position) ou vers toute l'équipe et d'indiquer clairement ce qui doit être amélioré ou changé. Une telle culture constitue un cadre calme pour le travail, quand tout le monde sait que si des questions se posent, elles seront écoutées.

D'après mon expérience, pour un fonctionnement productif et stable, ce facteur est d'une grande importance. Après tout, les questions, les frictions et les changements de direction seront toujours. Et l'atmosphère d'ouverture est un outil universel qui vous permet de faire face aux défis personnels et d'équipe.

Une autre pensée qui me semble juste: il n'y a pas une seule vraie formule pour construire une culture dans une entreprise.

«Aucune culture ne peut être qualifiée d'idéal. Et pas une seule culture ne peut être considérée comme un échec complet. »

Tendance récente: de plus en plus de conférences incluent des rapports sur la gestion, la communication, le team building et la culture. DevOops n'a pas fait exception. Je pense que c'est une tendance positive, car ces facteurs ont un impact encore plus important sur le résultat final que les difficultés technologiques.

«Le leader ne gère pas l'équipe, mais la fait grandir.»

Faites-le en code (pas YAML)! Déverrouillez la puissance de Kotlin DSL pour Kubernetes (Victor Gamow, Confluent et Fedor Korotkov, Cirrus Labs)

Rapport semi-funéraire, mais il exprime pleinement la douleur d'écrire des fichiers YAML sans fin, leur support et (oh, horreur!) Débogage en cas d'erreur ou de faute de frappe. Cela a même conduit à l'émergence de postes séparés de l'ingénieur YAML.

Comment tout a commencé? Il était une fois des scripts. Ensuite, il y en avait plus. Et bien plus. Il était nécessaire d'unifier, de simplifier et de mettre à l'échelle les solutions. Ainsi, dans le monde DevOps, le format YAML est apparu et est devenu la norme dans de nombreux outils.

Les auteurs du rapport ont pensé et déclaré: "quelque chose ne va pas dans la véranda".

• Il n'est pas clair comment tester les fichiers YAML.
• Il est facile de se tromper. De plus, certaines erreurs sont presque impossibles à détecter et très douloureuses à corriger. Par exemple, vous pouvez facilement spécifier la version d'une dépendance sous forme de nombre, au lieu d'une chaîne. Et puis découvrez pendant longtemps pourquoi la mauvaise version est utilisée, ce qui est indiqué dans la configuration. Et tout tourne autour de la fonte et de l'arrondi des caractères.
• Si l'erreur est syntaxique, elle sera détectée assez rapidement, dans CI. Mais ce n'est pas exact.

Le point culminant du rapport a été le téléchargement d'une configuration invalide vers Kubernetes, à laquelle il a répondu calmement: Trop d'erreurs .

Victor et Fedor proposent d'écrire des configurations sur le DSL Kotlin, ce qui aide à faire face à tous ces problèmes. Oui, la solution est intéressante et pratique, mais elle n'est pas universelle et ne fonctionne que pour les k8. De plus, en cas de mise à jour de l'API, vous devez également mettre à jour la bibliothèque.

Pipelines et pods: DevOps avec Kubernetes (Burr Sutter, Red Hat)

Un rapport léger sur le concept général et les principaux composants de Kubernetes, ainsi que d'autres outils et pratiques Ops à la mode. Pour un débutant dans le sujet - ce qui est nécessaire. Cela s'intégrerait parfaitement dans le programme de la conférence pour les développeurs, mais c'était étrange d'écouter un rapport de ce niveau lors d'une conférence spécialisée sur DevOps. Néanmoins, l'examen s'est révélé bon, simple et clair.

Mais former JSON à partir de code Java à l'aide de StringBuilder est en quelque sorte trop. Même en considérant qu'il s'agit d'un projet de démonstration.

Modèles et antipatternes de mises à jour continues dans la pratique DevOps (Baruch Sadogursky, JFrog)

Dans le rapport de Baruch, il est difficile de distinguer une idée ou une direction. Il s'agit plutôt d'une collection d'expériences personnelles, d'histoires de vie, d'exemples de «comment faire le bien et le mal», de contes, d'autres hi-hacks et de «fakapchikov».

Surtout à partir de ce rapport, je me suis souvenu de l' histoire où, en raison d'une erreur dans le processus de déploiement, le Knight Capital Group a perdu 440 000 000 $ en 45 minutes et a fait faillite.

À la fin, Baruch a raconté une histoire sur un bug dans le logiciel Airbus A350. En raison de ce bug, les compagnies aériennes ont été obligées de redémarrer l'avion toutes les 149 heures, et pour cela, il a dû être planté au sol. Et si quelqu'un oublie de le faire, l'avion gèlera. Un tel bug désagréable. Le problème est simple - un débordement se produit dans le code. La correction est également simple. Mais supposons qu'ils aient encore oublié de redémarrer l'avion, il a décollé sur un vol Los Angeles → Londres et 3 heures avant l'atterrissage, les pilotes ont réalisé que dans une heure l'avion allait geler. "Houston, nous avons un problème." "Maintenant, nous le réparons!" Les répartiteurs ont répondu, assemblé les programmeurs AirBus, corrigé, tout fonctionne. Que faire ensuite? Déployer une nouvelle version en avion par avion? Ou ne pas prendre de risques? Baruch était déterminé: «Déployez. Ce ne sera pas pire. »

Deuxième jour

CDK et infrastructure en tant que code (Sergey Kurson, AWS)

Sergey a parlé de l'AWS CDK (Cloud Development Kit). Il s'agit d'un ensemble de bibliothèques qui vous permet de gérer votre infrastructure de code. La décision est controversée, car la gestion des infrastructures dans un style impératif est une sorte de retour en arrière. Tous les outils d'automatisation modernes vous permettent de décrire l'infrastructure dans un style déclaratif (c'est-à-dire l'état qui devrait en résulter). Cependant, cette approche présente des avantages. Par exemple, le processus de test de l'infrastructure déployée est grandement simplifié, et le processus de déploiement et de décision sur quoi et comment déployer devient beaucoup plus flexible. De plus, il existe de grandes opportunités pour une gestion d'infrastructure dynamique et extrêmement flexible par événements, attributs ou métriques.

Pourquoi avons-nous besoin d'un tamis de service? (Anton Weiss, logiciel Otomato)

Peut-être l'un des rapports les meilleurs et les plus approfondis de cette conférence. Par «tamis de service», un orateur désigne un maillage de service - une couche distincte d'infrastructure cloud qui contrôle la communication des services entre eux. Le modèle de maillage de service délègue de nombreuses tâches du niveau de service (c'est-à-dire du développeur de l'application) au niveau du tamis de service lui-même (sur DevOps):

• gestion de la sécurité;
• surveillance du trafic;
• gestion du trafic.

Bien que le maillage du service en tant que technologie existe depuis plusieurs années, l'auteur en a fait un rapport approfondi et analysé l'histoire de son origine, comment il a évolué et comment il se développera dans les années à venir.

Le rapport est particulièrement utile pour les développeurs, car les tâches que le maillage de service résout sont désormais souvent résolues au niveau du service. Et cela prend plus de temps aux développeurs et rend difficile la concentration sur la résolution des problèmes commerciaux.

Accélérer les demandes Internet et dormir paisiblement (Sergey Fedorov, Netflix)

Sergey travaille chez Netflix pour s'assurer que le service fonctionne pour les utilisateurs finaux le plus rapidement possible. Toutes les demandes qu'il contient sont divisées en deux grands groupes:

• demandes de cloud (dynamique);
• Requêtes CDN (statiques).

Dans de nombreux cas, il est nécessaire de faire simultanément des demandes aux parties dynamiques et statiques de l'infrastructure. Mais un tel schéma a des frais généraux: vous devez établir au moins deux connexions, effectuer deux fois la négociation TLS, etc.

Il y avait une idée que si vous faites une demande uniquement à une infrastructure statique, installez un proxy intelligent sur celle-ci et lui confiez des demandes dynamiques au cloud en son nom, cela accélérera les demandes des clients. L'équipe Netflix a mis en place un tel système, a effectué des tests sur de vrais utilisateurs. Cependant, il est devenu clair que cela ne fonctionne pas toujours et pas pour tout le monde, certaines demandes commencent à être moins bien traitées.

Par conséquent, l'équipe a décidé d'aller dans l'autre sens. Ils ont mis au point un schéma qui permet à chaque client de décider individuellement comment il est plus rentable d'exécuter des requêtes dynamiques: directement depuis le client ou de confier le proxy de cette requête à la partie statique de l'infrastructure.

C'est un bon exemple de ne pas avoir à prendre du recul par rapport aux défis techniques. Vous devez être courageux et choisir une option de compromis si elle améliore le produit et la vie des utilisateurs est plus facile.

Pourquoi l'industrie des TI traverse des périodes sombres, comment DevOps est à blâmer et pourquoi Capital peut aider (Roman Shaposhnik, ZEDEDA Inc.)

Le rapport le plus «visionnaire» de cette conférence. Dans ce document, Roman a beaucoup parlé de la façon dont les technologies (et les capitaux) sont interconnectés (et inséparables). Je pense que cette thèse est très importante pour les ingénieurs et pour comprendre que les technologies sont créées pour résoudre des problèmes spécifiques des personnes et des entreprises. Avec une telle réflexion, il devient plus facile de hiérarchiser les tâches et de comprendre ce qui est important et ce qui ne l'est pas. Roman a également expliqué pourquoi les politiques et les sociétés fermées, qui augmentent de plus en plus leur influence, peuvent conduire à une crise mondiale dans le secteur informatique. Ainsi qu'un ensemble sur l'histoire et la philosophie du domaine des technologies de l'information.

DevOops concerne le développement

Plusieurs intervenants ont demandé au public qui est impliqué dans le fonctionnement et l'infrastructure et qui se développe. Les résultats m'ont surpris: la distribution est d'environ 50 à 50. C'est formidable que de plus en plus de développeurs souhaitent comprendre ce qui arrive à leur code après l'écriture, comment les applications sont déployées et communiquent entre elles. Avec cette compréhension, lorsque vous écrivez du code, vous pensez immédiatement à la façon dont cela fonctionnera dans les conditions de vie et où vous pourrez poser des pailles.