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!

Une réflexion sur “DevOpsDays Montréal 2018 – Jour 1

Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s