Zenika aux DevOps Days Montréal

3 décembre 2018 Cédric Chatelain

Les mercredi 10 et jeudi 11 octobre se tenaient les premiers DevOps Days au centre de Montréal. L’événement avait de quoi attirer les curieux : automatisation, cloud, sécurité, infrastructure, culture… Nous y sommes allés et nous vous proposons un retour d’expérience.

Accueil, ambiance et environnement

L’événement a lieu non loin du Vieux Port de Montréal dans une grande salle contenant plusieurs annexes. Superbe nouvelle à notre arrivée, un petit déjeuner autour duquel les conversations vont déjà bon train. Nous nous glissons vers les viennoiseries et entendons déjà des mots clés qui nous font sourire (« Kubernetes », « déploiement continu », « conteneur »…).
Nous retrouvons les stands des différents sponsors, qu’ils soient fournisseurs de services ou propriétaires d’une solution qui s’inscrit dans le mouvement DevOps. Très rapidement, des outils nous interpellent et nous échangeons avec les personnes sur les stands. Nous ne rapportons ici que les principaux outils nous ayant marqués.

AppDynamics : Cette entreprise propose un outil de monitoring très complet des applications Java. À travers l’interface web ergonomique, nous sommes capable de voir les différentes requêtes HTTP faites sur notre application. En cas d’erreur, nous pouvons étudier le chemin pris par la requête, depuis l´API jusqu’à la méthode ou même la requête SQL. Ceci permet bien sûr de diminuer le temps nécessaire aux développeurs dans le cadre d’opérations de maintenance. Elle nous permet également d’obtenir une carte globale de l’ensemble des noeuds qui sont monitorés.
SignalFX : Cet outil nous a été présenté très brièvement. Il propose une interface très ergonomique pour monitorer des applications en utilisant une architecture de streaming. Les noeuds sont ainsi reliés en permanence au système de monitoring ce qui permet de détecter les erreurs très tôt après leur apparition.
Mesospère : Cette société fournit du support à Apache Mesos, un orchestrateur open source. Cet outil commence à être reconnu. Il permet une gestion vraiment précise de clusters en simplifiant la gestion des ressources matérielles des machines mises à disposition.

Pour lancer les deux jours de conférences, une vidéo nous est présentée. La première partie montre des images, des memes, des blagues relatives aux développeurs et à leur travail. La même chose est faite pour les Ops. Et c’est ensuite une petite présentation de Montréal avec des images de la ville et des éléments culturels qui la représentent. Sur scène, arrivent alors trois personnes. La première avec une affiche Dev, la seconde avec une affiche Ops et enfin une personne déguisée en mur. À travers un petit sketch, ils illustrent le conflit entre les deux partis et le mur qui les empêche de communiquer et de travailler ensemble. Cette vidéo et ce sketch, pleins d’humour et d’autodérision, démarrent donc deux jours de partagent autour de ces problématiques DevOps.

Jour 1, culture et échange

Ce qu’il faut retenir de la keynote d’Alistair Croll

Alistair Croll est entrepreneur et auteur de plusieurs livres et articles. Son expérience inclut de la performance, de l’analytique, du cloud ainsi que la création ou le conseil auprès de nouvelles entreprises.
Son sujet nous emmène à l’intersection entre la technologie et le social.
En 1950, une entreprise avait une durée de vie d’environ 70 ans, aujourd’hui cette durée de vie est passée à environ 15 ans. L’innovation est un élément perturbateur qui bouleverse le modèle de l’entreprise actuelle. Les systèmes établis doivent s’adapter pour survivre aux changements qu’apporte l’innovation. (Taxis vs VTCs) La vitesse à laquelle les changements ont lieu force les entreprises à devoir prévoir les changements notamment avec beaucoup d’analyse de données et peut-être du Machine Learning dans certains cas. Selon lui, quatre choses doivent être mises en place afin de prolonger la durée de vie d’une entreprise.

Aller vers la productivité Lean : réduction du gaspillage dans un processus de production, diminuer les coûts inutiles et se baser sur la réalité du marché.
Analytique : utiliser l’analytique pour permettre des choix stratégiques plus pertinents
Adaptation des ressources
Livraison continue permettant une mise à jour constante en réaction ou en prévision des changements du marché.

Aujourd’hui, au sein des entreprises classiques, le modèle dominant est la notion de coût de la technologie par employé. Pour M. Croll, c’est une erreur. L’automatisation, la modernisation doivent être la priorité, il faut donc investir dans la technologie. La technologie est le nouveau « business » (« Technology is the new business »).

Catherine Proulx : code Legacy et testing

Tout code est voué à décliner. Quelque soit sa qualité et sa robustesse.
Cette conférence commence fort. Avec l’évolution des technologies, l’évolution des conventions de développement et même le fait que les développeurs initiaux, le code finira toujours par être ce code que personne dans l’entreprise ne veut toucher. Et ceci est encore accentué dans les environnements innovants. Le « POC effect » (ou le fait d’utiliser un code à but éducatif en production) pousse le code à décliner encore plus vite.
Selon elle, il y a deux recettes pour gérer du code legacy.

La première est de stopper les nouvelles fonctionnalités pour une longue durée et de tester l’intégralité de l’existant. Cette solution n’est pas viable. Aucun client n’acceptera ce genre d’arrêt dans les développements et les développeurs seront moins motivés. De plus, il est difficile de justifier ce genre de travaux pour la demande de budget annuel.
La deuxième solution consiste à ajouter des tests de non-régression et de validation au fur et à mesure de l’ajout de nouvelles fonctionnalités. Ces tests permettront de gagner en confiance sur le code historique et d’aller de l’avant sur les développements. Les clients sont plus critiques envers les erreurs qui ont lieu dans des fonctionnalités historiques que dans les nouvelles. Ce fonctionnement permet donc de s’assurer une couverture de tests de plus en plus importante tout en ajoutant de la valeur à la base de code.

Le discours se poursuit avec les tests et les environnements de tests. Quelques points à retenir :

Se méfier des statistiques que peuvent nous apporter les outils de couverture de code.
Ne tester que ce qui est important pour ne pas s’ajouter une charge de travail inutile.
Les tests doivent être pertinents et faciles à mettre à jour. Ils doivent être robustes pour ne pas être rouge et négligés.
Les tests manuels sont toujours nécessaires.
Les testeurs doivent être intégrés aux équipes de production au même titre que les développeurs.

Le code legacy est une question de culture.

Lorsque l’on rédige du code il faut toujours penser et respecter ceux qui seront responsables du code à l’avenir. La suppression de code n’est pas une solution viable. Le code legacy a de la valeur, mais nous avons tendance à le voir comme un boulet que traînent les plus anciens projets. Pour pouvoir avancer et innover, il faut bâtir une base solide de code documenté qui représentera la plus petite source de problèmes possible.

John Lee : DevOps, bien-être au travail et burnout

La présentation commence avec plusieurs statistiques intéressantes sur le taux de personnes perdant le sommeil à cause du stress (40%) et le nombre de personnes considérant ou ayant déjà pensé quitter le domaine de l’informatique (82%). C’est un problème de communauté. Il nous propose alors une liste de choses à faire pour aider à réduire ce problème.

Faire attention à soi, notamment en évitant les erreurs qui mènent au burnout : surcharge de travail, manque de contrôle de son travail, manque de récompenses et d’estime, un trop grand découpage des projets ou des communautés, l’absence d’équité entre les personnes de l’équipe.
S’équiper de moyen pour détecter les risques que Burnout. Plusieurs méthodes existent pour cela :
- MBI (Maslach Burnout Inventory : Fatigue, cynisme, efficacité)
- SMBM (fatigue physique, fatigue émotionnelle, fatigue cognitive)
Ne pas être seul, s’entourer d’amis ou de support.
Être capable de différencier le burnout de la dépression. D’après lui, 86% des personnes faisant un burnout possèdent les critères de la dépression mhfa.ca

Il nous donne ensuite le nom de ALGEE, un outil de premier secours psychologique.

Assess for risk of suicide or harm : mesurer le risque de suicide ou de blessure
Listen nonjudgmentally : écouter sans jugement
Give reassurance and information : rassurer et informer
Encourage appropriate professional help : conseiller une aide professionnelle appropriée
Encourage self-help and other support strategies : encourager à chercher une solution en soi et à travers des méthodes d’aides extérieures.

La question qui peut vite revenir lors d’échange sur ce sujet est « Comment convaincre la hiérarchie que c’est un problème auquel il faut faire attention? » D’après lui, les personnes qui ne sont pas conscientes de ce problème sont trop souvent absorbées par les chiffres de leur entreprise. La réponse est donc simple : il suffit de leur répondre par des chiffres comme ceux présentés au début de cette présentation.
Regarder la vidéo qui traite du burnout

Conférence de James Shubin sur mgmt

Cet outil de sa création permet la gestion de la configuration de manière distribuée, parallèle, événementielle et réactive. Il se base sur 3 principes le différenciant des outils existants:

Exécution parallèle, les ressources sont utilisées de façon concurrente lorsque cela est possible
Événementiel, pour surveiller et réagir dynamiquement au changement (lorsque cela est nécessaire)
Topologie distribuée, pour remplacer les problèmes d’échelle et de centralisation par un système robuste et distribue

Par-dessus ces trois points majeurs, on retrouve aussi un DSL créé spécifiquement pour le projet.
Le projet est plein de promesses et semble pouvoir être utilisé en production malgré qu’il soit non feature complete. L’outil mérite un article a lui seul, heureusement l’auteur en a écrit un lors de la genèse du projet.

Lenore Adam : l’évolution des pratiques de déploiement continu

Selon elle, il est essentiel que nous expérimentions tous les jours. Nos pratiques de livraison ont évolué. Nous livrons rapidement, plus souvent, mais il faut également pouvoir livrer de manière mesurée.
Les feature flag sont des tests conditionnels mis dans le code qui permettent d’activer ou de désactiver une fonctionnalité. C’est une des solutions possibles pour permettre un déploiement et des tests directement en production. Ces flags permettent également d’assurer qu’un déploiement continu n’augmente pas dramatiquement les risques. Pour mettre en place ces flags, il est important d’avoir une stratégie d’activation progressive auprès des utilisateurs, d’abord avec un groupe restreint puis en étendant à des groupes de plus en plus importants. Tester en production permet de diminuer les risques des différences entre production et environnement de test. Une expérimentation est un ensemble de mesures en rapport avec un flag (productivité, échange, utilisation, taux de retour, visite…). Des mesures pertinentes doivent être choisies en fonction de la fonctionnalité, elles permettent d’identifier les impacts de la fonctionnalité. Ces feature flags permettent aux développeurs et aux gestionnaires du projet de travailler ensemble depuis la définition du besoin jusqu’à l’analyse et donc la modification rapide des fonctionnalités.
Pour pouvoir mettre en place ces expérimentations :

Commencer avec des buts atteignables
Mettre en place des tests d’utilisation avec deux groupes de personnes différentes
Accepter et encourager l’échec pour permettre l’amélioration
Investir sur l’expérimentation (temps et ressources notamment sur les feature flags)
Proposer une manière de voir les résultats pour aider les décideurs et donner de la motivation aux participants.

Petit focus sur les ignites

Ces présentations de cinq minutes abordent des sujets très variés et la rapidité du passage rend l’ensemble très dynamique. En contrepartie, le présentateur doit être très concis et précis sur ses mots, un exercice difficile.

PGP With Git : signer les commits permet de protéger l’historique Git et donc protéger les informations concernant l’auteur, les dates, etc.
Documentation : il existe quatre types de personnes face à la documentation en fonction de leur motivation et de leur implication dans le projet.
Reactive Amazon EC2 : Utiliser mgmt pour déployer et provisionner une instance EC2, migrer d’un fournisseur cloud à un autre en un clic.
ElasticSearch chez Shopify : utiliser Kubernetes pour faire grandir sur demande le nombre de conteneurs jetables.
Bash CI avec SpellCheck et Bats : améliorer la qualité de scripts Bash et les tester avec ces outils pour les intégrer aux processus de CI.
Spinnaker : plateforme de déploiement continu multi-cloud pour visualiser et améliorer le pipeline et les clusters de CI/CD

Jour 1 : Fin

À la fin de notre première journée, les organisateurs nous font voter pour les sujets des open spaces, des espaces de discussions. Plusieurs sujets sont choisis et répartis dans la salle. Nous avons choisi d’aller aux sujets Scale with Kubernetes et CI for teams. Les deux séances, de 30 à 45 minutes chacune, sont très intéressantes. Les temps de paroles sont respectés et des personnes d’entreprises différentes partagent volontiers les expériences sur le sujet. C’est la première conférence a laquelle nous assistons qui organise ce type de temps d’échanges et c’est très positif. Nous rencontrons ainsi des personnes avec qui nous échangerons le lendemain.

Jour 2 : Devops partout

Le DevOps et l’industrie 4.0, par Daniel Koffler

Daniel Koffler est consultant en informatique et en IOT, et entrepreneur. Il aborde le sujet du logiciel et de son omniprésence, illustré par un exemple récent : l’explosion dans une raffinerie due à une défaillance logicielle.
Les industries peuvent être regroupées en quatre grandes époques : la vapeur, l’électricité, l’électronique (et automatisation au travers des Programmable Logic Controller PLC) et Cyber physical systems qui ne nécessitent pas d’opérateurs.
Les technologies opérationnelles utilisées dans l’industrie ont des problématiques différentes de l’informatique de gestion. Les buts, les contraintes d’efficacité, la durée de vie et les plateformes d’exécution sont différents. Par exemple, les bugs dans ces cas peuvent avoir des conséquences mortelles, contrairement à l’application d’une bibliothèque. Le versionning ou l’eXtreme programming ne sont pas encore utilisés. La QA est effectuée principalement de manière manuelle. Des nouveautés apparaissent dans l’industrie, on peut notamment nommer l’IA, mais de nombreuses choses restent à faire évoluer, dans les technologies, mais aussi dans les mentalités. Les PLC sont aujourd’hui très développés et des projets open sources apparaissent permettant le développement de nouveautés intéressantes pour le domaine.

Adam Kooper : « Everything I need to know, I learned in Tanzania. »

Ce développeur s’est porté volontaire pour aller aider une association de distribution de magazines auprès d’écoles et d’autres associations. Il nous fait donc un retour sur son expérience, les choses qui l’ont marqué et ce qu’il en a appris.
À son arrivée, il est confronté à la différence de développement technologique sur place. La machine qu’il utilisait avait trop peu de RAM pour exécuter un Linux avec trop d’applications, une connexion Internet très faible, des coupures de courant régulières. Après avoir pris connaissance du projet de l’entreprise, il est confronté à de nouveaux problèmes, organisationnels (les maisons individuelles n’ont pas d’adresse) ou technologiques (le serveur avait une capacité de stockage très faible). Finalement, il choisit de développer une application en Ruby on Rails pour remplacer les actuels fichiers Excel et répondre à des problématiques logistiques à travers des créations de relais locaux. Malgré une application fonctionnelle, le système n’était pas parfaitement intégré aux équipes. Il manquait quelque chose. Il part donc échanger avec l’ensemble des membres opérationnels de l’association. Il apprend leur langue et leur langage, les termes utilisés par chaque branche et découvre que les attentes sont différentes et que personne n’avait fait ce travail de découverte initiale avant son arrivée.
Il termine sa présentation en insistant sur le fait que dans un projet, tous les acteurs ont des éléments positifs à apporter. Il faut échanger avec tous, avoir leurs points de vue, leurs attentes pour pouvoir adapter le produit afin qu’il corresponde à ce dont ils ont besoin.

Alex Gervais : Étouffez-vous ? Un cas d’api gateway

Pour cette conférence, Alex nous présente la démarche qui a guidé ses équipes vers l’utilisation du patron logiciel (design pattern) Strangler pour réussir à migrer d’une architecture monolithique vers une nouvelle architecture en micro-services.

Première tentative: 1 nom de domaine et 1 load balanceur par service. La solution s’est révélée peu scalable et les équipes de développement n’étaient plus autonomes. Chaque service possédait sa propre authentification (repeat yourself) ce qui était gênant pour les utilisateurs des API, et l’architecture applicative été expose au travers des noms de domaines.
Solution finale : Création d’une API Gateway pour exécuter le design pattern Strangler. Il s’agit ici de créer une interface entre les utilisateurs et les APIs. Cela donne la possibilité de remplacer des fonctionnalités du monolithe petit à petit de façon transparente avec les utilisateurs qui connaissent seulement le contrat offert par la gateway qui masque l’architecture des API.

La mise en place de cette solution a été rendue possible grâce à l’utilisation des outils et pratiques suivantes:

gitops: utilisation de git comme source de vérité pas seulement pour le développement, mais aussi pour la mise en production et le déploiement de ressources.
deployment canary grace a CD canary
Contract testing avec Pact

Jesse Hurkens : implémentation de la culture DevOps au sein d’un environnement international

Selon Jesse, la culture est le plus important au sein de DevOps. La technologie, dire qu’on est DevOps ou ajouter un nouveau processus de déploiement ne vont pas corriger les problèmes issus de différences culturelles. Tout est dans l’attitude adoptée entre les personnes et la confiance qui peut être instaurée. Pour pouvoir mettre en place DevOps, il faut passer par plusieurs étapes qui sont une première étude préalable pour décrire l’existant, considérer l’histoire de l’entreprise et enfin identifier la volonté de changement et les résistances.
Les défis sont nombreux dans ce type d’environnement :

Défi culturel : les origines de chacun, la hiérarchie (et la manière dont elle est perçue par chacun) et l’organisation. Chaque projet doit avoir des attentes différentes en fonction de la culture dans laquelle il va grandir.
Défi géographique : prévoir les différentes localisations géographiques ainsi que les différents fuseaux horaires.
Défi sur la confiance : identifier les ennemis de la confiance comme le Command&Control. Si les personnes intégrées à la migration vers DevOps ne se sentent pas à l’aise, elles vont résister et donc mettre le projet en péril.
Défi d’entreprise : aligner toutes les stratégies, gérer la peur du changement, accepter les compétences de tous les individus et gérer le projet en fonction du type de fonctionnement et non pas de la même manière pour chacun des projets.

Il y a plusieurs moyen d’initier ce changement :

Tout détruire et repartir de rien (nous sommes d’accord, ce n’est pas pensable),
une approche par équipe ou par département (trop de disparités entre les équipes, il est dur de trouver une méthode unique)
une approche par projet.

Pour cette dernière, il faut réussir à fédérer l’équipe autour d’un but commun et avancer progressivement pour s’accorder des victoires et encourager les acteurs.
Il insiste sur le fait qu’il faille briser les silos qui isolent les membres du projet. De par la diversité, les bonnes pratiques vont émerger d’elles même dans cet environnement et dans ce mélange précis de cultures. L’identification des forces de l’équipe est importante pour pouvoir s’adapter. Avec différentes cultures apparaissent différentes manières de travailler, par exemple certaines équipes ne peuvent pas travailler en autonomie. Il est également nécessaire de séparer les POC (Proof of Concept) du reste des projets tout en les supportant. Cela permet de créer un projet exemple qui fonctionnera et qui sera utilisé pour convaincre le reste de l’organisation du bien-fondé de ce changement. Une fois les changements validés par des métriques objectives, ils peuvent être insérés progressivement. L’échec est nécessaire pour obtenir ce projet exemple, c’est ce qui permet d’affiner le chemin et de le valider.

Tsvi Korren : l’évolution de la sécurité avec l’arrivée de DevOps

Les conteneurs étant devenus la norme avec des processus complets de déploiement, il convient de se demander où se trouve le lien avec la sécurité. On se rend vite compte que le lien naturel diminue de plus en plus. Par défaut, la sécurité touche le réseau, le serveur (hôte) et les opérations (datacenter). Les offres On Premise sont parfaites pour la sécurité, tout est sous contrôle. Avec les offres Cloud ou de VM, on perd le contrôle du réseau et du datacenter. Avec Kubernetes, c’est la perte du réseau, du datacenter et de l’hôte. La solution *Container as a Service* rajoute la perte de l’orchestration… DevOps crée un vide entre l’application et le déploiement avec l’abstraction qui est rajoutée.
Pour faire évoluer ceci, il nous propose deux actions Shift left et Shift up.

Shift left est le fait de rapprocher la sécurité de la partie développement, que la sécurité ne soit plus pensée comme étant une surcouche à poser sur une application terminée. Il faut maintenant l’intégrer au développement, la garder à l’esprit en tout temps, car nous n’avons plus autant de contrôle sur le déploiement. Mais la sécurité en dehors du développement reste importante.
Shift up est le fait de sécuriser l’environnement de production en limitant les accès disponibles depuis l’extérieur à ce qui est strictement nécessaire. Pour un container cela consiste principalement à ne pas ouvrir de ports inutiles ou ne pas installer de logiciels superflus.

Pour assurer un contrôle sur sa sécurité, les contrôles communs sont la surveillance, renforcer l’immutabilité de nos livraisons, ne pas permettre de s’attacher à l’exécution d’un conteneur, sécurisé les identifiants/clefs de connexion aux systèmes de distributions. Il est important de s’assurer que la sécurité n’est pas laissée pour la fin, mais pensée dès le développement, ne pas compter sur la sécurité mise en place sur l’hôte ou le réseau et d’être conscient que l’application elle-même est la dernière ligne de défense contre les attaques.

Database in CI et Devops sans Conteneur

Notre journée de conférences se poursuit à travers deux nouveaux open spaces. Nous choisissons d’aller échanger sur Database in CI puis sur DevOps sans Conteneur. Les échanges sont encore une fois très intéressants et nous amènent à nous poser pas mal de questions. Le premier me permet notamment de remettre en question les pratiques monolithiques que j’avais utilisées chez un client : je ne peux pas modifier la base de données dans une application si une autre utilise cette même base de données, il faut prévoir une migration commune. Et les problématiques de versionning d’un schéma de DB qui sont évoqués révèlent clairement qu’aucune solution standard n’a émergé à ce jour.

Des Devops Days Montréal très riches et plein d’énergie

Les DevOps Days de Montréal ont été pour nous une excellente opportunité de découvrir cette communauté ici. Les présentations étaient diversifiées entre culture et technique, les organisateurs étaient plein d’énergie et l’accueil très agréable. Nous conseillons à tous les passionnés de DevOps ainsi qu’aux entreprises qui souhaitent en apprendre plus à aller à cet événement l’an prochain. Vous y ferez de bonnes rencontres et apprendrez toujours quelques choses des personnes qui s’y trouvent.