DevOpsDays Montréal 2018 – Jour 2

IMG_3767.JPG

Dans mon précédent article, je suis revenu sur les faits saillants de la première journée de la nouvelle conférence DevOpsDays Montréal. C’est maintenant le temps de faire le tour de la deuxième journée. Au menu, nous avions Keynotes, API Gateway, changement de culture et sécurité. Let’s go!

Industry 4.0 – Daniel Koffler

Pour faire suite à la conférence d’hier portant sur les changements menant à la discontinuité, Koffler a présenté les changements que subissaient présentement les secteurs manufacturiers et industriels. La quatrième révolution industrielle est en marche et elle se nomme cyber-physique. Après la vapeur, l’électricité et l’électronique, cette révolution est reliée à l’interconnexion des éléments automatisés.

cyberPhysicalRevolution

(image : https://people.duke.edu/~mp275/research/evm.html)

Pour Koffler, ces secteurs ont besoins des pratiques DevOps et ils auront besoin des habiletés des gens experts dans le DevOps. Rien pour régler le problème de main-d’œuvre…

Voyage en Tanzanie – Adrian Hooper

En relatant son voyage en Tanzanie, Hooper rappelle les fondements du développement agile et DevOps. Livrez fréquemment, mais pour une bonne raison : parler aux utilisateurs. L’intention est de leur parler afin de comprendre leurs besoins et de pouvoir réagir au feedback obtenu rapidement.

Étouffez-vous ? Un cas d’API Gateway – Alex Gervais

Alex Gervais a été le seul à faire sa présentation en français. Ce n’est pas la seule chose qui m’a plus, au contraire. Il a présenté un retour d’expérience sur l’introduction d’un API Gateway dans leur solution kubernetes. Étape par étape, il a expliqué le chemin qu’ils avaient pris chez AppDirect pour en arriver à utiliser ambassador.

Pour cette entreprise, les principes suivants étaient très importants :

  • Pas de dépendances à un fournisseur cloud
  • Pratiques gitops
  • Architecture cloud-native

C’est pourquoi ils ont utilisé Kubernetes pour gérer leur infrastructure. Toutefois, l’exposition de leurs différents services était faite au départ de manière traditionnelle avec un balanceur de charge. Ils géraient leurs entrées DNS et les ports d’accès des nœuds de manière statique, ce qui est vite devenu compliqué. En plus, ils ont voulu simplifier l’API exposé à leurs clients afin d’abstraire différents détails internes. Ils en sont donc venus à opter pour un API Gateway.

APIGateway.JPG

Implementing DevOps in an International multi-cultural and multi-geography environment – Jesse Hurkens

Malgré le titre, cette présentation a davantage parlé de l’importance de la culture DevOps au sein d’une entreprise. M. Hurkens a marqué avec énergie qu’il ne suffit pas d’avoir un beau « pipeline » DevOps pour avoir un vrai succès. C’est d’abord une affaire de culture et il faut que cette culture change, au besoin, pour accueillir les échecs et en apprendre. Mais par où commencer?

IMG_3772

Il recommande d’initier ce changement par un petit projet qui, lorsqu’il aura eu son succès, pourra rayonner sur les autres. La pollinisation peut se faire de manière organique et elle créera une fondation solide dans l’organisation. Un truc intéressant qu’il mentionne est de donner des objectifs communs à tous les silos de notre organisation afin de faire travailler les gens dans la même direction.

Voici aussi les principaux challenges qu’il note dans les entreprises qui amorcent le voyage DevOps :
IMG_3773

Security Considerations for Containers as a Service (CaaS) and Serverless Architectures – Tsvi Korren

Cette présentation a été selon moi une des mieux structurée. Le présentateur a réussi à bien expliquer les enjeux de sécurité autour du serverless et des conteneurs hébergés et gérés. Si j’essais de résumé, l’enjeu est que l’abstraction de l’infrastructure demande aux spécialistes de sécurité de revoir leurs mécanismes de mitigation des risques. Traditionnellement, on avait l’habitude de mettre en place des antivirus et des contrôles d’accès à l’exécution, mais il n’est pas toujours aussi facile de bien contrôler ces éléments dans un monde où on a aucune visibilité sur ce qui héberge notre code. Comme l’OS et le runtime d’exécution est complètement abstrait, on ne peut pas le sécuriser.

Il propose donc quelques mesures qui peuvent aider comme de baser les images docker sur les versions les plus légères des OS et d’intégrer les validations de sécurité dans le pipeline de livraison. (« Shift-left »).

IMG_3776

Comme ce n’est pas suffisant, il recommande de faire en sorte que si un conteneur est compromis, qu’il ne donne pas accès à de multiples ressources. On doit donc pratiquer la micro-segmentation et donner les accès qui sont vraiment requis à chaque ressource. (Shift-up).

IMG_3775.JPG

Pour finir, voici les différents contrôles de sécurité généraux qu’il recommande :
IMG_3777.JPG

Le DevSecOps a encore de la maturité à prendre, mais certains outils sont déjà utilisables dans nos pipelines de développement pour détecter les vulnérabilités dans les images Docker que l’on construit et que l’on déploie. En voici quelques exemples :

  1. Microscanner
  2. Kube-Hunter
  3. Kube-bench
  4. Arachni

Conclusion

La conférence s’est achevée avec des Open Spaces qui ont été assez diversifiés. Pour moi, cette conférence a été grandement teintée d’infrastructure et de gestion des opérations. J’avais une conception du DevOps un peu plus équilibrée entre le développement et les opérations. Peut-être que c’est seulement parce que les pratiques en émergences sont surtout du côté de l’infrastructure. Je me demande maintenant s’il faut voir le DevOps comme étant plutôt les pratiques de développement adoptées par les gens des opérations… Mon côté développeur s’est senti un peu délaissé durant ces deux jours… Malgré tout, c’est une conférence que je recommande pour ceux qui veulent apprendre des expériences des autres et aussi à ceux qui veulent partager ou faire des rencontres.

DevOpsDays Montréal 2018 – Jour 1

logoDevOpsDays

J’ai la chance de participer à la conférence DevOpsDays Montréal 2018 qui en est à sa première édition. Comme cette conférence est relativement nouvelle, je vous décrirai les présentations auxquelles j’ai assisté, mais je tenterai aussi de dépeindre un peu l’ambiance et l’organisation de l’événement en guise de conclusion.

KeyNote #1 – Alistair Croll

Dans sa conférence principale, M. Croll a placé les bases qui justifient, selon lui, l’adoption des pratiques DevOps et surtout, le changement de culture que les entreprises doivent prendre pour survivre. En relatant les évolutions fulgurantes dans plusieurs domaines comme l’agriculture et l’émergence de nouveau modèles comme la rémunération pour les youtubeurs, il a mis l’emphase sur la discontinuité. Pour lui, ce qu’il faut surveiller, ce ne sont pas les éléments de rupture ou perturbateurs dans notre marché, mais plutôt ceux qui vont mener à discontinuer certaines façons de faire ou certains produits. Chaque industrie et chaque entreprise doit se poser les bonnes questions pour être en mesure d’innover.

Traditionnellement, les entreprises commençaient par avoir du succès en développant un procédé ou une approche et faisaient en sorte de l’étendre à plus grande échelle par la suite. Exemple : trouver une façon de vendre un produit facilement et ensuite engager plusieurs vendeurs qui adopteront la même approche pour vendre les mêmes produits. Cependant, le passé n’est plus garant du futur. L’adaptation l’est.

Pour la plupart des organisations d’aujourd’hui, la performance passe par les TI. Tout est maintenant TI. C’est donc logique de devoir automatiser et améliorer les processus TI pour être en mesure de s’adapter aux changements qui surviennent rapidement tout en innovant. Le DevOps est la clé pour y arriver. Les autres compagnies vont le faire. À vous de choisir votre destiné.

Shaky to solid: a test-based approach to legacy code – Catherine Proulx (CNRC)

Cette présentation avait pour but d’indiquer aux gens que le code legacy est inévitable et que l’on doit le considérer et surtout le respecter. On ne peut pas penser tout refaire le code qui ne répond pas aux critères de qualité actuels sur cette seule base.

La seule façon de prendre le contrôle du code legacy et d’inverser la vapeur est d’ajouter des tests automatisés. Mme Proulx propose de commencer par la correction des anomalies plutôt que de viser une approche TDD sur l’ensemble d’un système. Lorsqu’on travaille sur une anomalie, il est recommandé d’ajouter des tests pour d’abord prouver qu’elle existe et aussi prouver que nous avons bel et bien réglé le problème avec notre modification. Elle ne croit pas aux projets qui visent à ajouter des tests sur une partie majeure d’une application. Ça doit se faire de manière itérative, un changement à la fois.

Elle mentionne aussi qu’il faut faire attention à la métrique de couverture de code. Étant déjà discutable en contexte d’un nouveau développement, elle ne représente pas grand chose dans un contexte de code patrimonial. Comme il y forcément un paquet de bouts de code qui ne sont pas couverts par des tests automatisés, on ne peut s’y fier pour nous donner un sentiment de sécurité.

Catherine Proulx fait aussi mention d’un type de tests qu’elle utilise avec du code patrimonial. Elle le nomme « test canary ». Ça ressemble davantage aux tests de caractérisation que présente Michael Feathers dans son livre « Working Effectively with Legacy Code« . Ces tests permettent de comprendre ce que fait un bout de code patrimonial avant de le modifier. Une fois ce harnais de sécurité en place, on peut procéder à la modification avec confiance.

Mme Proulx a aussi profité de l’occasion pour mentionner que les tests manuels ne sont pas choses du passé. Bien que plusieurs se plaisent à dire qu’il faut tout automatiser, elle n’a pas vu un endroit encore où les tests manuels ont été annihilés. Elle dit même que plutôt que de les appeler tests manuels, certaines firmes les appellent maintenant tests utilisateurs. 🙂

Burnout: community problem & community solution – Jason Yee (DataDog)

M. Yee a présenté les enjeux du surmenage et de l’épuisement professionnel. Il a donné plusieurs conseils sur la manière de le détecter et sur les façons de le prévenir. Une multitude de ressources ont été citées. Vous pouvez trouver sa présentation à l’adresse suivante.

http://bit.ly/dodyul-burnout

IMG_3763[1]
Le lien avec le DevOps était un peu tiré par les cheveux. En se référant à une autre présentation, il dit que le DevOps, par sa stabilité, crée un climat plus serein dans les équipes de développement et qu’il contribuerait donc à diminuer le taux d’épuisement.

L’élément le plus troublant dans la présentation selon moi a été le parallèle qu’il a fait entre le CAP Theorem pour les systèmes distribués et celui pour la vraie vie. Il y trois composantes : Famille, Travail et Santé physique. Malheureusement, pour ceux qui croient à ce théorème, on ne peut avoir que deux des trois composantes à la fois.

Next Generation Config Mgmt: The Language – James Shubin

Cette présentation portait sur un projet open source créé par le présentateur. Il vise à rendre dynamique la gestion de la configuration à différents niveau à l’aide de la programmation réactive et d’un nouveau langage inventé pour l’occasion. Basé sur Etcd, on peut y définir des règles définissant la configuration à différents niveau de nos VMs ou cluster.

Ce projet demeure expérimental pour le moment, mais il est vrai qu’il y a du potentiel à ce niveau. Par exemple, on peut définir des règles beaucoup plus complexes d’auto-scaling basées sur autre chose que le CPU et la mémoire. La seule limite est l’imagination des développeurs. Reste à voir si ce projet connaîtra l’envol que son créateur lui souhaite.

https://github.com/purpleidea/mgmt

Open Spaces

J’ai découvert ce concept aujourd’hui. En bref, on a proposé aux participants à la conférence de cibler des sujets dont ils voulaient parler. Les gens se sont regroupés autours des sujets qu’ils jugeaient les plus intéressants afin de discuté.

Pour ma part, la séance que j’ai le plus apprécié est Scaling Kubernetes. Certaines personnes ont partagé leur expérience autour de Kubernetes, Docker, Istio, Weave Net etc. Il semble, bien que l’engouement soit présent, qu’il n’est pas si facile de faire fonctionner ces technologies. Il a été fait mention de plusieurs problématiques dans le déploiement de Kubernetes à plus grande échelle comme la latence DNS, la segmentation réseau complexe et la gestion des clusters proprement dite.

Le découpage des cluster et namespace semble être un enjeu de taille. Est-ce qu’il est mieux d’avoir un gros cluster en production ou plusieurs? Le groupe penchait plutôt vers le plusieurs. Toutefois, en avoir trop occasionne une maintenance difficile et ardue. La question n’a pas été réglée.

Mon constat est que ces technologies fonctionnent, mais elles ont un coût important en apprentissage et en maintenance. Les efforts et la complexité demeurent considérables. Soyez prêts à configurer des vnet, des politiques réseaux et des ingress/egress à profusion. Et bonne chance quand surviendra une mise à jour de ces technologies. Ce qui devrait arriver… il y a tout juste une minute… 🙂

Conclusion

Les présentations ont été un peu légères à mon avis, mais c’est quand même réussi pour une première journée de conférence. L’ambiance est conviviale et dynamique. Les fournisseurs commerciaux ont peut-être une trop grande place, mais la conférence n’aurait pas lieu sans eux. Je souhaite que cette conférence puisse prendre de la maturité afin de rendre justice au DevOps. Je pense qu’on pourrait y ajouter un peu de professionnalisme, mais les intentions sont louables. Je suis convaincu que ça s’améliorera dans le futur vu le succès de l’édition 2018.

À suivre demain pour le résumé de la deuxième journée!