DevOops hier et aujourd'hui

Aujourd'hui, nous allons parler un peu du présent, du futur et du programme de la conférence DevOops 2019. DevOps change chaque jour. Vous souvenez-vous de l'année 2004? Nous avons un conférencier qui a travaillé avec des nuages ​​à une époque où il n'y avait pas un tel terme. Amazon Web Services lancé en 2006. Quelque part en même temps, les premières références à DevOps ont commencé à apparaître. Une vie entière s'est écoulée depuis.

Récemment, ils ont rappelé "retour mon 2007". Imaginez ce monde sans les virtuels omniprésents sur Amazon, sans GitHub (il n'est apparu qu'en 2008), sans dockers confortables et sûrs. N'oubliez pas de configurer iptables, les gestionnaires de paquets GNU / Linux, de reconstruire manuellement les modules du noyau, les nuits blanches. Vous voulez toujours y aller? Ce serait votre 2019, sinon pour les progrès de l'ouragan de ces années.



La technologie et les entreprises ont changé. Permettez-moi de vous donner quelques exemples. Par exemple, nous avons tous vu la merveilleuse transformation de Microsoft - de Ballmer's `` Linux is Cancer ' ' en 2001 à la transition généralisée vers l'open source, le sauvetage de GitHub en 2018 et les plans à l'été 2019 pour introduire le noyau Linux dans le cadre de la livraison Windows. Parallèlement à tout ce mouvement, les préférences des ingénieurs concernant les informations reçues ont changé.


En 2016, le livre de Google « Site Reliability Engineering » est apparu. D'une part, ce livre ni alors ni maintenant ne peut être considéré comme un guide pour tout le monde et tout le monde - après tout, " vous n'êtes pas Google ", vous n'avez pas Borg, et il peut ne pas y avoir de telles tâches. En fait, étant initialement un produit de Google PR intelligent, il a eu un effet à l'échelle mondiale. Peu de gens n'ont ni lu ni entendu parler d'elle. En août 2018, sa traduction en russe nous a rattrapés , ainsi que la poursuite du manuel de fiabilité du site .

Les conférences évoluent constamment avec la situation. Apparue en 2017, la conférence DevOops dans son programme a reflété les principaux enjeux qui étaient à ce moment occupés par les spécialistes des solutions DevOps. La copie d'archive pour 2017 ne vous laissera pas mentir: le premier élément était les conteneurs, l'orchestration et la virtualisation, y compris Docker et AWS. Docker, Docker, Docker partout. Nous avons fait venir des gens qui pouvaient en parler sans fin, et la conférence a été ouverte par Corey Quinn, rédacteur en chef de Last Week dans AWS .

En 2018, il est devenu clair que Docker en avait déjà marre de tout. Il est devenu la norme, il a commencé à nous regarder de partout. Les nouveaux messages de la semaine dernière dans AWS ont commencé à apparaître plus de 60 fois par jour. Il n'est plus logique de construire une conférence autour de choses aussi évidentes. La Keynote 2018 a été faite par John Willis, un homme célèbre non seulement comme directeur du développement des écosystèmes chez Docker, mais aussi comme l'un des pères originaux de DevOps, auteur du DevOps Handbook et Beyond the Phoenix Project. C'est bien que John ait commencé à parler non pas toujours de réglage, mais de la mise en œuvre de DevOps en tant que culture organisationnelle - un sujet qui est constamment oublié, distrait par les jouets lumineux des nouvelles technologies.

Le deuxième thème principal de 2018 est Kubernetes. Comment l'utiliser, comment le mettre en œuvre, ça vaut le coup. Ce sujet a parcouru la ligne rouge tout au long du programme, Kubernetes était, sinon dans le titre, alors non, non, et il est apparu sur les diapositives.

Salut, 2019. Kubernetes, comme Docker une fois, est devenu la norme. Les guerres chaudes se sont éteintes, les victimes des premières introductions ont disparu des yeux et lui seul est resté sur le champ de bataille. Tous les nouveaux projets se font d'une manière ou d'une autre en gardant un œil sur le nouveau roi.

Et en parallèle, la question se pose: que devrait dire la conférence DevOops cette année? Il s'agit d'une question ouverte sur laquelle le comité de programme travaille actuellement.

Le programme de la conférence peut être présenté de deux manières. Tout d'abord, vous pouvez immédiatement présenter une grille de rapports prête à l'emploi et dire - regardez comme c'est cool. Cela produit un effet wow, conduit à un achat rapide de billets, mais ne répond pas toujours pleinement aux demandes des visiteurs.

Par exemple, récemment, un ami m'a écrit sur VKontakte et m'a demandé de dire ce qu'il y aurait dans le programme. "Mais après que la conférence dure encore six mois, pourquoi en avez-vous besoin?" Il s'est avéré que dans son entreprise, il était de coutume d'écrire à l'avance un poème pour le leadership sur le thème «Pourquoi est-ce que je veux aller à la conférence». Et comme l'entreprise est grande, tout est planifié longtemps à l'avance, alors vous devez écrire pendant six mois. Elle ne correspond absolument pas à l'option du formulaire "le programme sera un mois avant le début".

Cela peut sembler être un cas spécial, mais à partir des nombreux cas spéciaux de ce genre, l'image globale est formée. Il existe une autre approche: au lieu de l'instantané final du programme, vous pouvez télécharger des mises à jour en petits morceaux. C'est quelque chose d'agile et de maigre. Si vous vous souvenez, il existe un tel concept de cartographie des flux de valeur , et bien qu'il ne soit pas entièrement applicable à la consommation d'annonces de rapports sur Habré, il y a quelque chose de similaire. Par exemple, si nous jetons trop de texte, vous ne pourrez tout simplement pas avoir le temps de le lire, et vous devrez vous souvenir de ce que vous lirez jusqu'à la prochaine fois. Les descriptions des rapports sont mises à jour et mises à jour de temps à autre, les conférenciers modifient les noms des sujets au fur et à mesure qu'ils travaillent sur le rapport, et ce flux d'informations n'est pas facile à comprendre et plus encore - pour en faire une compréhension de «pourquoi ai-je besoin de cette conférence». En d'autres termes, publier le programme en morceaux au fur et à mesure qu'il est rempli est une bénédiction.

Nous avons maintenant publié sur le site Web les premiers conférenciers qui seront certainement à DevOops 2019. Bientôt, les sujets des rapports apparaîtront. Pour ne rien manquer, vous pouvez lire notre blog sur Habré ou vous abonner à la liste de diffusion (pour cela vous devez vous rendre sur le site de la conférence et cliquer sur le bouton "s'abonner"). Si vous voulez soudainement faire un rapport vous-même, vous en avez toujours la possibilité .

Et pourtant, sur quoi porteront les rapports? Voyez comment la description de la conférence a changé. Kubernetes est toujours en première place, mais pas en tant que discipline indépendante, mais dans le cadre du mouvement Cloud Native, à côté de Helm, Istio et des maillages de service. Notez qu'en troisième position, le mot observabilité est apparu explicitement (par exemple, dans le livre de Practical Monitoring de Mike Julian, ce mot n'a pas encore été utilisé, une année s'est écoulée - et maintenant). Les rapports seront approximativement dans cette direction. Bien sûr, les anciens sujets sur Docker et Kubernetes seront également ignorés, mais à un niveau supérieur.

J'ai également des réflexions sur ce sujet. Par exemple, pour moi, DevOps a toujours été avant tout une méthodologie et une culture, et non un ensemble de réglages. Vous déployez votre application Web Java d'entreprise sur les serveurs du client, mais elle ne se déploie pas, quelque chose s'est cassé et vous devez vous orienter instantanément et tout réparer. Et il vaut mieux faire du déploiement à la prod pas un cauchemar. C'est à propos de cette conférence - comment ne pas avoir de cauchemars avec les gens et les libérations. Quels outils cela sera fait est la deuxième question, nous sommes cool et pouvons gérer tout. Je voudrais moi-même plus de rapports sur la culture et les façons de faire - c'est bien, même dans la liste originale des orateurs il y a de telles personnes (par exemple, Anton Weiss, Barukh Sadogursky, Roman Shaposhnik).

En général, assez de mots généraux, passons aux choses sérieuses! Voici nos conférenciers:

Anton Weiss est copropriétaire du conseil technologique 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. Au DevOops 2018, son rapport a pris la première place!

Eric Weld de HashiCorp est dans le cloud depuis plus de 15 ans. Avant HashiCorp, il a travaillé en tant que consultant chez Xebia et est devenu le fondateur d'Instruqt, une plate-forme d'apprentissage du réglage du cloud et d'autres outils DevOps sur une véritable infrastructure.

Alex Thissen de Xpirit se développe depuis la fin des années 90 et a réussi à travailler en tant que leader et architecte partout - des petites startups aux grandes entreprises. En particulier, il est engagé dans la formation de développeurs aux technologies Microsoft et d'architectes dans les systèmes cloud distribués modernes. Titre professionnel le plus précieux de Microsoft dans la catégorie Studio et technologies de développement.

Roman Shaposhnik de ZEDEDA est un expert et consultant bien connu sur l'open source et la transition vers les technologies numériques dans les grandes entreprises. Auparavant, il a joué un rôle majeur dans la création d'une collaboration open source au sein de la Linux Foundation, et a également occupé des postes clés chez Pivotal, travaillant principalement avec les Big Data et les plateformes de gestion d'applications basées sur le cloud. Son travail chez Pivotal l'a conduit à l'intersection de la technologie des conteneurs, de la virtualisation et des architectures unikernel, qui, à leur tour, ont engendré la mission de ZEDEDA - appliquer ces technologies au développement de l'informatique de pointe. Roman est membre de l'Apache Software Foundation et de Linux Foundation Edge, ainsi qu'un contributeur actif à un certain nombre de projets open source.

Victor Gamov - Developer Advocate chez Confluent, l'un des principaux contributeurs au projet Apache Kafka. Aide les architectes et les développeurs à concevoir et développer des systèmes de traitement de données en streaming distribué. Co-auteur du livre "Enterprise Web Development" par O'Reilly. Co-fondateur et (dans le passé) leader du podcast de débogage «Flight Debugging», apprécié de nombreux programmeurs.
Anton Arkhipov - Developer Advocate chez JetBrains, un résident du podcast Debriefing . Les intérêts professionnels sont liés aux langages de programmation et aux outils de développement logiciel.

Baruch Sadogursky (alias JBaruch) - Chef des relations avec les développeurs et avocat des développeurs chez JFrog. Il aime surtout parler des technologies - c'est-à-dire qu'il aime discuter, mais une personne qui parle de technologies a un look intelligent, et 18 ans d'expérience dans le domaine des hautes technologies ne sont pas partis. Quand il ne parle pas (enfin, ou ne s'envole pas vers le lieu du prochain discours), il étudie les technologies, les gens et comment ils fonctionnent, ou plutôt, ne fonctionnent pas ensemble. Baruch est co-auteur de Liquid Software, ambassadeur de la CNCF et conférencier professionnel sur des sujets tels que DevOps, DevSecOps, Go, Java, etc. Il intervient régulièrement lors de conférences renommées telles que Joker, JPoint, DevOops, Heisenbug, DockerCon, GopherCon, Devoxx, DevOps Days, OSCON, Qcon, JavaOne et autres. Certains de ses rapports peuvent être consultés ici .
La conférence DevOops 2019 se tiendra du 29 au 30 octobre à Saint-Pétersbourg.
Venez, ce sera cool et utile!
Les billets Early Bird sont disponibles sur le site Web de la conférence .

Source: https://habr.com/ru/post/fr454626/


All Articles