Home >> Blog >> DevOps Days Zurich 2023 – Feedback

DevOps Days Zurich 2023 – Feedback

05 mai 2023

Par Lionel Gurret et Fabrice Vergnenègre.

Jour 1

DevOpsDays Zurich est une conférence annuelle très attendue qui rassemble des professionnels de la communauté DevOps pour partager des idées, apprendre les uns des autres et explorer les dernières tendances en matière de technologie. En tant que participants enthousiastes de l’événement de l’année dernière, nous avons été ravis de participer à la conférence de cette année, qui a duré deux jours de discours inspirants, d’ateliers informatifs et de discussions animées.

Dans ce blog, nous allons partager mon expérience et mes perspectives de la conférence. Nous résumerons les talks auxquels nous avons assisté, mettrons en évidence les points clés et offrirons notre point de vue sur les sujets abordés. Que vous n’ayez pas pu assister à DevOpsDays Zurich 2023 ou que vous souhaitiez simplement revisiter certains moments forts, nous espérons que cet article sera informatif.

Alors, sans plus tarder, allons-y !

Talk 1 : Construire des équipes performantes : le rôle crucial de la sécurité psychologique

Résumé

Laurence Kozera et Arjanna van der Plas ont animé une session pratique sur la façon de favoriser la sécurité psychologique au sein de votre équipe. La session a abordé l’importance de la sécurité psychologique dans les équipes performantes et a fourni des exemples concrets sur la façon de l’augmenter, en particulier pendant le travail à distance ou hybride et avec des personnalités diverses ou des tensions héritées.

Points clés

  • Implication d’une forte sécurité psychologique
    • moins de stress
    • plus d’énergie au travail
    • productivité accrue
    • moins de jours de maladie
    • engagement accru
    • moins de burnout
  • La sécurité psychologique est la base essentielle d’un excellent travail
  • Travaillez sur votre attitude face au risque et à l’échec
  • Ayez des conversations ouvertes
  • Soyez disposé à aider
  • Adoptez la diversité et l’inclusion

Talk 2 : Reporting on Reliability – Améliorer les conversations avec les parties prenantes

Résumé

Ramón Medrano Llamas discute des meilleures pratiques pour communiquer sur la fiabilité, en particulier pendant et après les incidents. Les ingénieurs en fiabilité pratiquent depuis longtemps des rétrospectives sans blâme pour apprendre des incidents passés, mais les parties prenantes en dehors de l’équipe des opérations peuvent ne pas être aussi indulgentes.

Points clés

  • Quoi ? – État de l’incident
    • Utilisez des canaux appropriés (évitez les appels de conférence, utilisez des chats et des documents en direct)
    • Soyez prévisible (mises à jour régulières)
    • La plupart des gens devraient surtout écouter
  • Qu’est-ce que c’était ? – Post-mortem
    • Critiquez les systèmes, pas les personnes
    • Supposons que tout le monde impliqué dans un incident avait de bonnes intentions
    • Les erreurs "humaines" sont des problèmes de système
  • Comment ça se passe ? – Examens périodiques de la fiabilité
    • NE PAS se concentrer sur le nombre d’incidents
    • Se concentrer sur l’impact global des incidents

Pause

Talk 3: Du développeur Backend au rôle de DevOps – LE RÉVEIL DE LA FORCE

Résumé

Dans cette présentation, Mey Beisaron partage son parcours de transition du rôle de développeur Backend à celui d’Ingénieur DevOps. Elle discute des défis qu’elle a rencontrés, notamment l’apprentissage du pipeline CI/CD complexe et de l’architecture de plusieurs systèmes. Elle explique comment elle a transformé son approche de résolution de problèmes d’une perspective d’application étroite à une approche d’architecture système globale.

Points clés à retenir

  • Apprendre par soi-même (créer des pipelines, lire la documentation, écrire votre propre documentation, enseigner aux autres)
  • Écouter les demandes des utilisateurs en plus des exigences non fonctionnelles
  • Améliorer vos compétences (sessions de découverte, commentaires sur la documentation)

Talk 4: Combler le fossé entre Dev et Ops avec eBPF: Étendre l’observabilité vers le haut et vers le bas

Résumé

La présentation de Raphaël Pinson porte sur l’utilisation d’eBPF (extended Berkeley Packet Filter) pour améliorer l’observabilité dans les systèmes Linux. En utilisant eBPF, il montre comment cela peut combler le fossé entre les équipes de développement et d’opérations en fournissant des informations plus approfondies sur le noyau, les systèmes d’exploitation et les applications en cours d’exécution. La présentation couvre également la façon dont eBPF peut être utilisé pour étendre l’observabilité vers le bas en accédant aux informations système de bas niveau et vers le haut en offrant des capacités de traçage au niveau de l’application.

Points clés à retenir

  • Du monitoring basique à l’expertise
  • Apportez des métriques aux développeurs et le droit de déployer
  • Plus de métriques avec eBPF
  • eBPF : rend le noyau Linux programmable de manière sécurisée et efficace
  • Cas d’utilisation d’eBPF : protection contre les attaques DDOS, équilibrage de charge, patching en direct du noyau
  • Cilium
    • Amélioration des performances (pas d’iptables, contournement TCP/IP)
    • Architecture plus simple (pas de proxy sidecar pour le service mesh)
  • Hubble
    • Observabilité fine-grain du réseau
    • Exportation vers SIEM
    • Support de la norme OpenTelemetry
  • Tetragon
    • Observation et exportation des événements du noyau
    • Action sur les événements (par exemple, SIGKILL)

Talk 5: Les priorités – l’art de dire non

Résumé

La présentation de Dorota Parad se concentre sur la gestion efficace de la charge de travail lorsqu’il y a toujours plus de travail

Talk 5: Priorités – l’art de dire non

Résumé

La présentation de Dorota Parad s’est concentrée sur la manière de gérer efficacement sa charge de travail lorsqu’il y a toujours plus de travail que de temps. Elle a partagé des stratégies pour reconnaître les tâches qui méritent d’être prioritaires, apprendre à dire non et éviter de se retrouver piégé dans une boucle de lutte contre les incendies.

Principales conclusions

  • Faire : Tâches urgentes et importantes
  • Planifier : Tâches importantes mais non urgentes
  • Déléguer : Tâches urgentes mais non importantes
  • Supprimer : Tâches non urgentes et non importantes
  • Tâche importante : Contribution directe ou facilitation de mon objectif
  • Le temps est fini et il y a toujours plus de travail que de temps
  • L’urgence est un piège. Faites ce qui est important !
  • Si je fais cela, que ne ferai-je pas ?

Déjeuner

Ignite talks

Résumé

  • Matthias Fritschi – 6 ans et 15 meetups plus tard – comment organiser un meetup (DevOps)
  • Iris Hunkeler – DevOps, ClickOps, GitOps, CloudOps, AIOps… donner un sens au Buzzword-Bingo en 5 minutes
  • Ralf Winter – Permettre de véritables organisations DevOps avec la gestion du flux de valeur
  • Daiany Palacios – Les ingénieurs DevOps full-stack : un mythe ?
  • Sebastian Graf – Équipes de plateforme et Innersource, comment favoriser l’acceptation et générer des synergies
  • Mike Long – GitHopes et Terrorforms

Ateliers

Atelier 1 : Masterclass pour les leaders de l’ingénierie

Résumé

L’atelier de Thomas Krag couvre les compétences de leadership essentielles pour les ingénieurs, les chefs techniques et les managers. Il propose des conseils pratiques sur le mentorat efficace, l’utilisation de la pensée systémique, l’élimination des goulots d’étranglement, la mesure des performances, l’influence sur les équipes et les individus, et le recrutement. L’atelier est interactif et utilise un tableau Miro, donc les participants doivent apporter leur ordinateur portable.

Points clés à retenir
  • Swarm ?
    • Arrêtez de commencer, commencez à finir !
    • Les revues de code synchrones sont formidables.
  • Entretiens
    • Transformez-le en conversation
    • Trouvez un sujet qui intéresse votre candidat
    • Pouvez-vous me parler d’un moment où vous avez $situation ?
  • Enseignez pour apprendre plus rapidement
  • Boîte à outils du mentor
    • Encourager
    • Défier
    • Coaching
    • Partager
    • Définir des règles
    • Faire des choses ensemble

Atelier 2 : Comment gérer la résistance de vos membres d’équipe

Résumé

Mark Heistek et Peter Nijenhuis ont créé un jeu sérieux pour aider les individus à comprendre et à expérimenter les différentes phases de la résistance au changement. Dans cet atelier, les participants apprendront les différentes étapes de la résistance, y compris l’insécurité, la résistance, la colère, la joie et le bonheur. Le jeu est conçu pour aider les joueurs à passer d’un état d’esprit fixe à un état d’esprit

Atelier 2 : Comment gérer la résistance de vos membres d’équipe

Résumé

Mark Heistek et Peter Nijenhuis ont créé un jeu sérieux pour aider les individus à découvrir et comprendre les différentes phases de résistance au changement. Dans cet atelier, les participants apprendront les différentes étapes de la résistance, y compris l’insécurité, la résistance, la colère, la joie et le bonheur. Le jeu est conçu pour aider les joueurs à passer d’un état d’esprit fixe à un état d’esprit de croissance en moins d’une heure. En plus du jeu, les participants recevront également une théorie de fond sur les différentes phases de la résistance.

Atelier 3 : La session de sensibilisation au numérique

Résumé

Par Alessandra Patti & Theo Roblot
Cette session interactive explore le concept de bien-être numérique, en mettant l’accent sur l’impact de la technologie sur notre santé mentale. En tant qu’experts de l’espace numérique, les animateurs de la session guideront les participants à travers les déclencheurs potentiels des médias sociaux et de la constante "disponibilité", et fourniront des conseils sur la manière de naviguer dans le monde numérique de manière à promouvoir le bien-être et à éviter l’épuisement professionnel.

Talk 6 : DevOps – comme faire du vélo ou plutôt jouer au golf ?

Résumé

Pour certaines personnes, DevOps est une routine quotidienne, pour d’autres c’est encore un nouveau terrain. Dans cette présentation, Dr Martin Wechsler parle des défis d’une organisation informatique, et de la manière dont Migros Group IT aborde DevOps.

Points clés

  • Comment aborder DevOps :
    • permettre aux équipes de progresser avec des objectifs
    • apprendre à faire du DevOps avec votre situation actuelle (même si c’est SAP)
  • DevOps est plus comme le golf que le vélo
    • Nécessite un effort important pour apprendre
    • Pas de progrès sans pratique
    • La condition mentale est importante
    • Parfois cela ne fonctionne pas, et vous ne savez pas pourquoi

Migros a adopté SAFe dans sa transformation. La culture DevOps "Vous le construisez, vous le gérez" reste un levier essentiel pour les équipes Migros. Il n’y a pas de "chemin d’or" ou d’outils standard pour les équipes, elles sont libres de choisir leurs propres outils. Les communautés de pratiques sont le canal pour partager leurs pratiques et leurs outils, mais aucune imposition n’est faite.

Soirée

Jour 2

Après une première journée formidable et quelques bières, nous sommes ravis de plonger dans une autre journée de présentations informatives et d’ateliers engageants. L’événement de la soirée d’hier a offert une merveilleuse occasion de se connecter avec d’autres professionnels de la communauté DevOps, et nous avons hâte de poursuivre ces conversations tout au long de la journée. Allons-y !

Présentation 1 : L’ingénierie de la productivité des développeurs – la prochaine grande chose dans le développement de logiciels

Résumé

Lors d’une présentation de type keynote, Justin Reock, Field CTO et Chief Evangelist chez Gradle, a expliqué pourquoi l’ingénierie de la productivité des développeurs (DPE) est importante pour l’ingénierie logicielle. Il a expliqué comment la DPE utilise des technologies d’accélération et des analyses de données pour accélérer le processus de construction et de test de logiciels, améliorer l’efficacité des développeurs et atteindre des cycles de rétroaction plus rapides. Reock a également présenté un aperçu des concepts et outils clés de la DPE, de l’impact commercial sur les objectifs clés, du cas d’affaires pour la DPE et du rôle de l’IA/ML dans la DPE à l’avenir.

Principaux points à retenir

  • La productivité est importante au niveau des organisations (et non au niveau des développeurs contrairement au mythe des ingénieurs 10x)
  • Les organisations productives sont plus attractives et retiennent leur personnel d’ingénierie
  • La productivité est directement liée au plaisir des développeurs au travail : le plaisir est apporté par le fait que les ingénieurs font un travail créatif et que les retours sur leur travail sont apportés aussi rapidement que possible
  • La DPE est une approche d’ingénierie de la productivité
  • 81% des professionnels de l’informatique seraient d’accord pour dire que les DPE rendent leur travail plus agréable
  • Effets sur la productivité ET la qualité
  • Des builds plus rapides améliorent le flux créatif, des builds plus lents favorisent la commutation de contexte
  • Solution pour des builds plus rapides :
    • L’utilisation de caches de builds (complémentaires au cache de dépendances) permet d’éviter la reconstruction inutile des portions du code qui ne sont pas liées et ne peuvent pas être impactées par le changement.
    • Utilisation de distributions de tests, afin de maximiser la parallélisme de la phase de test
    • Utilisation de l’IA pour la sélection prédictive de tests, une technique intéressante (pour pré-merge) qui utilise l’apprentissage automatique pour exclure les tests qui ne seront pas nécessaires à la ré-exécution en fonction du changement qui a été apporté
  • L’analyse des builds (même en local) permettra de commencer à comprendre certains des goulots d’étranglement et inefficacités qui pourraient être résolus
    • Traiter les tests flaky avec la plus haute importance, ce qui réduit considérablement la confiance dans les tests et ne provoque que de la frustration
    • Assurer une continuité de performance, en faisant de cela une routine standard qui continue d’évoluer
    • Arrêter de demander : "Le cycle de construction est-il assez rapide ?" mais plutôt "Le cycle est-il aussi rapide qu’il peut l’être ?"

Talk 2 : La sécurité parfaite ne tient qu’à une question

Résumé

Wiktoria Dalach a parlé des mythes entourant la sécurité des applications et de la façon dont elle est souvent perçue comme difficile par les développeurs. Dans son exposé, elle a partagé des conseils pratiques et les pièces les plus utiles de la théorie de la sécurité des applications pour rendre la sécurité moins effrayante et pas un sujet ennuyeux.

Principaux enseignements

  • Les préoccupations de sécurité peuvent être classées en 3 catégories (CIA)
    • Confidentialité
    • Intégrité
    • Disponibilité
  • Posez-vous la question de savoir comment le CIA peut être brisé
  • Discutez-en avec votre équipe
  • Faites-en partie de votre processus
  • Déplacez la sécurité vers la gauche

Pause

Talk 3 : Processus de développement d’applications cloud natives – une histoire de transformation

Résumé

Thomas Stein et Timon Schuele présentent le parcours cloud natif de SAP Cloud ALM, une solution SaaS avec plus de 2000 clients et 250 développeurs. Ils discutent de l’importance de poser les bonnes questions lors de la création d’un nouveau produit cloud, d’avoir les bonnes croyances fondamentales pour atteindre le niveau Elite de DORA, et des avantages d’une route pavée d’outils pour accélérer la transformation cloud. L’exposé vise à souligner que le processus de développement de logiciels devrait être considéré comme un système plutôt que comme la somme d’outils et de processus individuels.

Principaux enseignements

Le parcours décrit par les présentateurs sur la façon dont ils sont passés d’un déploiement de serveur hérité à une livraison régulière d’applications. Le plus grand défi, sans surprise, était de changer la culture et de faire appliquer aux équipes le fameux mantra devops : "Vous le construisez, vous le faites fonctionner".
Principaux éléments facilitateurs de leur transformation :

  • L’adoption d’une méthodologie unique du tronc (et donc l’utilisation d’un système et d’un portail de bascules de fonctionnalités internes)
  • Déploiement quotidien en production en améliorant l’automatisation
  • Principes de déplacement à gauche pour la qualité et la sécurité
  • Déploiement avec confiance d’une route pavée

Talk 4: Observabilité efficace dans les architectures de microservices

Résumé

La présentation de Lesley Cordero se concentre sur la gestion des architectures de microservices en construisant des architectures observables efficaces à l’aide d’une approche axée sur la plateforme standardisée. La présentation aborde les défis spécifiques aux microservices et explique comment cette approche les aborde en considérant les modèles utilisés, le soutien organisationnel nécessaire et la pile utilisée.

Points clés

Une approche pour fournir une plateforme d’observabilité standardisée, basée sur 3 piliers :

  • Modèles : fournir des normes pour les équipes en termes de terminologie, de formats et de structure
  • Support : fournir une intégration pour les équipes pour établir des SLO (Service Level Objectives)
  • Stack : fournir l’ensemble d’outils intégrés nécessaires pour les équipes.

Recommandations :

  • Utilisez l’auto-instrumentation en premier lieu
  • Utilisez l’instrumentation manuelle de manière stratégique

Talk 5: La conformité par la conception | Conformité continue

Résumé

La présentation de Marcel Britsch traite de la nécessité d’une nouvelle approche de la conformité dans la fourniture de produits et de services. Il aborde les insuffisances des méthodes de conformité traditionnelles et préconise la "conformité par la conception" ou la conformité continue. Marcel présente un cadre pour la conformité continue tout au long du cycle de vie du produit et explique comment impliquer la conformité tôt et en continu peut conduire à de meilleurs résultats pour les produits et les opérations de conformité.

Points clés

  • La conformité sera plus complexe
  • La conformité est précieuse
  • La conformité est facultative
  • Il n’y a pas de "bonne façon" d’être conforme
  • Passage à un meilleur modèle : la conformité par la conception
  • 4 étapes à mettre en pratique
    • Définir la portée de la conformité
    • Position sur le risque
    • Identifier les parties prenantes de la conformité
    • Définir les modes de fonctionnement

Déjeuner

Ignite talks

Résumé

Ateliers

Atelier 1: Développement piloté par les tests avec Go

Résumé

Dans cet atelier, Ivan Pesenti guide les participants dans la construction d’une API REST pour gérer des tâches stockées dans une base de données PostgreSQL en utilisant le développement piloté par les tests. L’atelier suppose une certaine connaissance préalable des concepts HTTP et des API REST, de l’expérience avec les tests, la programmation avec Go, Docker et les bases de données. L’agenda de l’atelier comprend une introduction au développement piloté par les tests, à HTTP et à la conception de bases de données, ainsi que des exercices pratiques pour la construction et les tests de l’application. L’atelier vise à offrir aux participants une expérience pratique du développement piloté par les tests et à les préparer à l’utiliser dans leurs projets futurs.

Atelier 2: La puissance des portails pour développeurs : une introduction pratique à Backstage

Résumé

Par Olivier Liechti – Le projet Backstage est une plateforme de construction de portails pour développeurs, conçue pour fournir un point d’entrée unique dans l’écosystème de logiciels d’entreprise. Il offre une vue à 360 sur les actifs logiciels, à la fois du point de vue de la construction et de l’exécution. Dans cet atelier, les participants ont acquis une introduction pratique à Backstage et ont appris ses fonctionnalités de base, telles que le catalogue de logiciels, le système de documentation en tant que code et le générateur de code, ainsi que son architecture de plugin. La session a également abordé les enseignements tirés de la création de portails avec des clients, y compris les problèmes techniques et les avantages commerciaux.

Principales leçons à retenir
  • Excellent pour les grandes entreprises
  • Backstage est un cadre, pas un produit :
    • Nécessite des efforts de construction
    • Nécessite des efforts de maintenance

Ateliers 3 : Configuration d’un pipeline spécifique à une branche

Résumé

Par Marc Herren – Au cours de cet atelier, les participants ont appris à créer un pipeline Gitlab CI à partir de zéro et à ajouter un flux de travail pour effectuer des étapes différentes sur différentes branches. Le but était de créer un pipeline entièrement fonctionnel qui effectue des tests sur les demandes de fusion, construit des images sur la branche principale, analyse les images sur la branche d’intégration et déploie l’image sur la branche de production. Cela sera accompli en créant un fichier de version du tag d’image frontend/backend et en le réutilisant dans les étapes ultérieures.

Conclusion

DevOps Days Zurich 2023 était un événement formidable où nous avons beaucoup appris et où nous avons eu un aperçu des dernières tendances de l’industrie. C’était également une excellente occasion de rencontrer nos partenaires et de réseauter avec d’autres professionnels.

Dans l’ensemble, c’était une expérience enrichissante et nous avons hâte d’assister à des événements similaires à l’avenir!

Laisser un commentaire

  Edit this page