Sorry, this entry is only available in French. For the sake of viewer convenience, the content is shown below in the alternative language. You may click the link to switch the active language.
Montréal (Québec) – le 25 octobre 2018 – Gologic, expert DevOps, vous livre aujourd’hui ses commentaires et impressions de cette première mouture du célèbre devopsdays qui a eu lieu pour une première fois à Montréal, le 10 et 11 octobre derniers.
Quels dynamisme et coordination exceptionnelle de l’événement! Bravo aux organisateurs…CloudOps, Agile Tour Montréal et tous les autres.
Deux journées bien remplies qui ont permis au collectif Gologic d’assister à diverses présentations, périodes de discussion « openspace », de réseauter avec les gens du milieu DevOps et d’approfondir les connaissances techniques.
Conférences qui font réfléchir
Nos coups de cœur … discontinuité, industrie 4.0 et culture.
Tous s’entendent pour dire que le conférencier Alistair Croll a commencé l’événement avec un sujet qui porte à réfléchir; les effets que provoquent l’innovation, les perturbations et la discontinuité dans nos sociétés.
« Ce n’est pas tant une technologie en particulier qu’il faut observer, mais bien la transformation de la culture sociale qu’elle implique. »
Le DevOps est signe de transformation, car il s’agit bien d’une nouvelle culture à laquelle les équipes TI doivent adhérer si elles veulent que leur organisation demeure concurrentielle. Les grandes entreprises veulent livrer plus vite. Voilà pourquoi, elles exigent un changement de culture et une adaptabilité de la part de leurs collaborateurs TI.
Puis, le jour 2, nous avons eu droit à Daniel Koffler qui est venu nous parler de l’intégration du DevOps dans l’industrie 4.0. Les DevOps de ce monde seront sollicités et amenés à contribuer à la transition technologique que vit l’industrie manufacturière.
Cette culture s’intègre graduellement dans le monde manufacturier. Le cycle est long, mais les équipes de développement utilisent de plus en plus les microservices, ce qui annonce une livraison continue des plus prometteuses pour les PLC (Programmable Logic Controller), donc une meilleure productivité de la chaîne de montage.
Conférences qui nous instruisent
Nos coups de cœur
Next Generation Config Mgmt : The Language
James Shubin, hacker avec un excellent sens de l’humour, a présenté son outil de configuration du futur qui aborde les problèmes d’automatisation : Mgmt. Voici un petit clin d’œil comparatif de l’outil avec Chef et Puppet, de la part de notre collaborateur Wassim El-Asmar.
Automatisation déclarative d’un état pour les serveurs
- Se compare avec Chef et Puppet
Trois principales différences :
1. Exécute des tâches en parallèle (plus rapide)
- Chef et Puppet configurent des éléments de façon linéaire.
Ex.:
Fichier 2 dépend de fichier 1
Fichier B dépend de fichier A
La configuration linéaire se fait avec le fichier 1, le fichier 2, le fichier A, puis le fichier B. Si chaque fichier prend 10 secondes, la configuration totale prend 40 secondes.
- Mgmt fait de la configuration parallèle, mais nous pouvons aussi lui donner des dépendances. Ex.: si nous reprenons notre exemple précédent, voici comment Mgmt procède avec la configuration. Il débute avec le fichier 1, ensuite le fichier 2 mais il commence à configurer le fichier A puis le fichier B en même temps qu’il a commencé avec le fichier 1. Le tout prend donc 20 secondes.
Cette façon est bien plus rapide.
2. Fonctionne avec des événements
- Chef et Puppet s’exécutent et vérifient les éléments un par un et détectent ce qui a changé ou pas. Ensuite, le tout est remis à l’état désiré.
- Mgmt reçoit une alerte quand quelque chose change. Il vient rétablir l’état désiré uniquement de cet élément, sans scanner les autres.
Encore une fois, ceci est plus rapide et demande moins de travail, car Mgmt ne perd pas de temps à tout scanner, puis vérifier s’il y a eu des changements.
3.Topologie distribuée contrairement à Chef et Puppet qui ont une topologie centralisée
- Chef et Puppet fonctionnent tous les deux avec des « masters » qui centralisent la configuration désirée des autres serveurs. Les serveurs-clients doivent ensuite se connecter à ce serveur master pour qu’il puisse les remettre à l’état désiré.
- Mgmt fonctionne par cluster de serveurs. Tous les serveurs se configurent entre eux. Puis pour certaines charges, il va élire des « masters temporaires », parmi les serveurs du cluster. Il suffit de déclarer le nombre de masters désirés et Mgmt se charge de les nommer dans notre cluster de serveurs, si nécessaire. Ces « masters » font partie des autres serveurs.
Ceci évite d’avoir un point de faille centrale et nous permet d’agrandir notre cluster plus facilement (plus scalable).
Voici un vidéo qui explique tout ceci et plus :
https://www.youtube.com/watch?v=jB992Zb3nH0
Deuxième coup de cœur de l’équipe, le seul et unique talk en français, celui d’Alex Gervais, de AppDirect. Il a partagé avec nous les diverses expériences, cas et défis que lui et son équipe ont rencontrés pour décommissionner et réacheminer le trafic loin du fameux monolithe. Grâce au modèle« strangler », ils ont réussi à trouver une voie de passage afin de migrer sans affecter les clients des API, avec les solutions Kubernetes « cloud native ».
Merci!
Toute l’équipe a bien hâte à la prochaine édition du devopsdays Montréal 2019!
Contact
Lise-Andrée Duperré, développement des affaires et marketing
lise-andree.duperre@www.gologic.ca
438-385-7188 Ext. 211