Stack Labs Blog moves to Dev.to | Le Blog Stack Labs déménage sur Dev.to 🚀
Retour de conf Snowcamp 2019, partie 1
Temps de lecture estimé : 9 minutes
Cette année, tous les stackers ont eu l’occasion de participer à la conférence Snowcamp qui se déroulait fin janvier à Grenoble. Pour nous ce Snowcamp 2019 aura été marqué par d’excellents workshops le mercredi et de passionantes conférences les jeudi et vendredi, mais également par les nombreuses conférences données par nos Stackers (1 workshop et 4 conférences) !
❄ Retour en texte et en images sur quelques morceaux choisis de cette édition 2019 neigeuse du Snowcamp. ❄
Jour 1 : Workshops
Pour des logiciels de qualités, dites stop au TDD et passez au TDD ! ¯_(ツ)_/¯
A travers cet excellent workshop de 3 heures, Thomas Haessle nous initie non pas au
Test-Driven Development mais au Type Driven Design. Ce “TDD” permet d’encoder bon nombre de concepts au sein de notre code
grâce à un système de types algrébriques qui permet de raisonner très différemment de nos approches classiques.
Le workshop s’est déroulé en plusieurs itérations, en partant de l’exercice “TennisKata” disponible sur Github. Armés de nos ordinateurs, nous avons choisi un langage parmi les 4 proposés et autorisant les types algébriques (OCaml, ReasonML, Rust et Kotlin) et nous avons commencé à essayer de raisonner (et de coder !) autour du comptage des points au tennis, le but étant d’arriver à coder un maximum de choses en utilisant des types statiques, ce qui permet de ne coder que les cas pouvant exister (0, 15, 30, 40 et avantage dans un jeu de tennis par exemple) et de ne pas représenter les états impossibles (par exemple le score 12-30 qui n’existe pas au tennis).
Ce workshop était passionant, il permettait à la fois de découvrir un des langages proposés tout en s’essayant à une nouvelle manière de raisonner pour encoder les états de nos applications, merci à Thomas !
Una-Gitlab, le TP à Roulette !
En s’inspirant de Perceval et Karadoc de Kaamelott, notre stacker Kevin Davin et son comparse Logan Weber nous ont fait découvrir les nombreuses fonctionnalités de Gitlab, et notamment de sa partie CI (intégration continue).
A partir de la version hébergée Gitlab.com, nous avons ainsi pu découvrir et apprendre à manipuler un process complet de CI : runners, fichiers yaml incluant des “jobs” et des “stages” nous permettant de builder, tester et déployer sur de nombreuses plateformes : PostgreSQL, Artifactory, Google Cloud Platform, …
Un très bon workshop qui permettait d’aller assez loin avec Gitlab CI, mais ausi éventuellement de redécouvrir le très vaste univers de la CI en général.
Jour 2 : Conférences
Des microservices aux migroservices
Les microservices c’est bien mais les implémenter n’est pas une mince affaire. C’est à travers sa prise de recul et son retour d’expérience que François Teychene nous expose les travers et les pièges auxquels il a été confronté.
Les microservices induisent inévitablement un effort plus important pour architecturer son application d’autant plus quand ce concept est nouveau pour les développeurs. Souvent en voulant faire des microservices les développeurs accouchent de “migroservices” à savoir des services qui ne sont en fait qu’un monolithe distribué avec des services dont les périmètres se recoupent (beurk) et qui sont donc fortement couplés… ce qui au final complexifie l’architecture et n’amène que des contraintes notamment en termes de maintenabilité…
Je me suis régalé à suivre le talk de François car au lieu de présenter de façon académique les microservices, il nous a vraiment partagé les problèmes qu’il a rencontré et en nous disant clairement que faire des microservices ça ne s’improvise pas. Il faut commencer petit et y aller par étapes ! Ca n’est que comme ça que les gains seront visibles mais dans le temps.
Rust 101
Derrière ce titre très académique se cachait une conférence… très académique! Alessio Coltellacci nous a présenté les éléments qui font que Rust est aujourd’hui un language à considérer sérieusement pour nos développements.
Il a bien sûr était introduit la notion de Borrow Checking qui permet de se passer de garbage collector et d’avoir une appli qui est sécurisée au runtime (plus de risques de runtime exceptions). Le fait d’avoir intégré la notion d’appartenance d’une variable au niveau du système de type est très élégant à utiliser et à comprendre. Cependant, en tant que développeur, il faudra s’adapter à ces nouveaux adages 👍.
Rust intègre de nombreux éléments émanant de la programmation fonctionnelle, ce qui ravira les développeurs venant de mondes comme Scala, Haskell voire même Kotlin. De plus, Rust apporte un niveau de performance aujourd’hui très élevé (même quasiment équivalent au C dans certains cas) et permet donc de construire des applications sûres, performantes et portables ! Que demander de plus ?
DevSecOps ou comment faire aimer la sécurité aux Devs (-IoT) ?
Quand vos équipes de développeurs et vos équipes d’opérationnels arrivent à travailler conjointement pour aboutir à une approche DevOps, c’est déjà un pas en avant. Quand vous rajoutez vos aspects sécurité en transverse de ce travail, c’est encore mieux, surtout dans des domaines où c’est essentiel (domotique, systèmes médicaux, satellites, …) !
C’est ce que propose Alexis Duque à travers une étude de cas sur des projets IoT impliquant des ingénieurs hardware, firmware, mobile et cloud. Alexis présente plusieurs méthodologies (application de standards dans la conception, écriture de user stories spécifiques sécurité, intégration continue poussée jusqu’au hardware, …) permettant d’impliquer au quotidien la sécurité dans les équipes de développement et même le client ! Une belle source d’inspiration pour faire participer tout le monde à la sécurité.
DevSecOps ou comment faire aimer la sécurité aux Devs (-IoT) ? - Speaker Deck
Zero-downtime deployment with Kubernetes, Spring Boot and Flyway.
Le Zero-downtime deployment est une notion très recherchée dans le monde des opérations car la non-disponibilité d’un service est largement préjudiciable notamment pour la réputation du fournisseur ainsi que pour ses revenus. Combien de fois avez-vous tenté d’accéder à Gmail, Facebook ou autre mastodonte et vous êtes vu répondre une page 500 ?
Nicolas Frankel nous présente comment tenter de s’en approcher à travers certains outils, notamment le fameux et désormais incontournable Kubernetes, et le plus méconnu Flyway. Il nous propose de déployer en douceur les nouvelles versions de notre application à travers les Rolling Updates de K8s en gérant comme souhaité l’évolution du nombre de noeuds dans l’une et l’autre version.
Mais l’un des problèmes principaux à l’évolution d’une application, notamment si les deux versions sont amenées à cohabiter ne serait-ce qu’un court instant, se pose lorsqu’il s’agit de modifier les schémas de la base de données. Pour cela, Nicolas nous propose de se munir d’un outil de versioning de la database : Flyway. Celui-ci stocke toutes les évolutions de schémas depuis l’initialisation du projet et permet d’appliquer intelligemment celles-ci sous forme de migration quand cela est nécessaire. Il nous montre également qu’il s’utilise facilement avec Spring Boot.
La combinaison de ces deux outils nous permet donc de gérer une transition fluide lors de l’évolution de notre application tout en laissant ouverte la possibilité de rollback si nécessaire.
Zero-downtime deployment with Kubernetes, Spring Boot and Flyway.
Hashistack : orchestrer des applications Cloud Native avec simplicité
Pour automatiser le déploiement, la montée en charge et la gestion des applications conteneurisées dans un cluster, on pense immédiatement à Kubernetes. Il est vrai que Kubernetes est devenu très populaire : il est maintenant un service managé dans de nombreux fournisseurs de Cloud (AWS, GCP, Azure) et il est également présent dans de nombreux PaaS (VMWare/Pivotal PKS, Red Hat Openshift, Suse CaaS, CoreOS, etc.)
Pourtant, il existe d’autres solutions d’orchestration. Yves Brissaud nous présente l’une d’entre elles dont la brique principale est Nomad d’Hashicorp.
Nomad est un scheduler open-source qui se présente sous la forme d’un simple binaire pour ordonnancer des applications et des services sur Linux, Windows et Mac. Nomad prend en charge des applications conteneurisées, virtualisées ou standalone comme une application Java. Il veille à ce qu’elles continuent de fonctionner en cas de panne d’un ou plusieurs noeuds du cluster en les redéployant sur d’autres noeuds. En plus des services de longue durée, Nomad peut planifier des jobs batch, ponctuellement ou de façon récurrente comme cron. Plusieurs stratégies de déploiement (blue-green, rolling updates) sont également supportées pour mettre à jour les applications. Au contraire de Kubernetes, qui est une boîte tout-en-un, Nomad doit être utilisé conjointement avec Consul (d’Hashicorp) pour la découverte et la configuration de services. La solution doit être complétée avec un proxy pour router les appels et équilibrer la charge vers les services ou les applications, comme Traefik, Fabio ou Envoy.
Après la partie théorique, Yves termine sa présentation par une démo live : il construit une image système comprenant Nomad, Consul, Docker avec l’outil Packer (d’Hashicorp, comparable à Chef ou Puppet) et la déploie avec Terraform (d’Hashicorp, Infrastructure as Code) sur plusieurs noeuds. Pour finir, il déploie une application de test avec Nomad et …Hello World!
Tout se passe bien.
Hashicorp, une stack pour le Cloud à surveiller!
Hashistack : orchestrer des applications Cloud Native avec simplicité
Monitoring OVH: 300k servers, 27 DCs and one Metrics platform
Horacio Gonzalez, qui assume le rôle de Developer Advocate chez OVH, nous explique dans sa présentation comment ils ont mis en place la plateforme de monitoring en partant du besoin suivant :
Comment monitorer 27 data centers, plus de 300 000 serveurs, et des centaines de solutions afin d’héberger efficacement les 1.3 million de clients OVH.
Il aborde dans un premier temps les différentes solutions de monitoring existantes qu’ils ont évaluées. En abordant aussi les problématiques pour prendre en compte les cas d’usage et l’existant des différentes équipes. Il explique ensuite comment la plateforme a été développée et comment elle peut absorber une quantité gigantesque de logs chaque jour. Il nous parle aussi de la manière dont les différents projets ont pu adopter cette nouvelle plateforme de monitoring et comment de nouveaux usages ont émergés de par les performances accrues de la plateforme.
Enfin, il conclut sur l’avantage que procurent l’automatisation et le monitoring.
En résumé, c’était un retour d’expérience intéressant qui ouvre des cas d’usage innovants grâce au monitoring de masse.
Il ne faut pas vendre la peau de YARN parce qu’un Mesos vaut mieux que deux Kubernetes
Derrière ce titre bien mystérieux, notre stacker Pascal nous a offert un tour d’horizon des technologies les plus populaires dans le domaine de l’ordonnancement et de l’orchestration. Sa présentation nous permet en effet de comprendre quels sont les points communs mais aussi les différences entre les différentes solutions proposées aujourd’hui : YARN, Mesos et Kubernetes bien sûr, mais également Nomad d’Hashicorp.
Si cette présentation s’adressait déjà à un public un peu averti, elle a permis de se rappeler qu’il n’existe pas que Kubernetes dans le monde de l’orchestration et que d’autres technologies, bien que voisines, proposent des fonctionnalités différentes permettant de répondre à d’autres besoin. Nous avons ainsi comparé différentes technologies, notamment sur des critères de haute disponibilité, de programmation distribuée, de prise en charge de conteneurs ou d’environnements virtuels, etc.
Il ne faut pas vendre la peau de YARN parce qu’un Mesos vaut mieux que deux Kubernetes
Crédits photos
Toutes les photos ont été prises et sont gentiment prêtées par Bruno Lavit et Ludovic Poitou, un grand merci à eux !