Actualité devOps | Spider DevOps

RDV tous les 1er mercredi de chaque mois à 18h30 pour un live ! Dans celui-là nous discuterons, entre autre, des news de la communauté, de la chaîne et du podcast. 💬 Rejoins la communauté des Compagnons du DevOps : https://www.compagnons-devops.fr ## Sommaire 00:00 Introduction 03:45 STATS : Podcast 08:40 STATS : YouTube 33:10 Les partenariats 38:24 STATS : Le forum 45:20 Les sujets du forum Sujet au Top : reconversion Admin-sys/Devops : https://forum.compagnons-devops.fr/t/bonjour-jai-un-projet-de-reconversion-admin-sys-devops/3326 Sujet déterré : Le DevOps et le climat : https://forum.compagnons-devops.fr/t/le-devops-et-le-climat/1898 59:34 💖 Tu peux soutenir mon travail et la communauté sur : https://soutenir.compagnons-devops.fr/ 01:02:27 Sur quoi je travail ? - Cloud Alpes Gagne une place gratuite : https://twitter.com/MentorDevOps/status/1683460349939400705 - Marchandisage - Réorganisation des contenu s 01:22:03 La suite 📅 Le calendrier des Lives : https://cloud.lydra.fr/apps/calendar/p/p38JJa2XyrNK2gFJ/dayGridMonth/now Pour l'intégrer dans ton agenda : https://cloud.lydra.fr/remote.php/dav/public-calendars/p38JJa2XyrNK2gFJ?export 📩 Si tu n'es pas déjà abonné, alors **abonne-toi** pour ne pas rater les prochaines vidéos. 💬 Rejoins la communauté : https://www.compagnons-devops.fr 💖 Tu peu soutenir mon travail et la communauté sur : https://soutenir.compagnons-devops.fr 🔗 Tous mes liens : https://i.mtr.bio/compagnons-devops ## Mon Jobboard 💼 Trouve ton job de rêve : https://vu.fr/jobboard-DevOps 👔 Recrute avec moi : https://vu.fr/jobboard-DevOps-recrute ## Mes antisèches 🎁 git : https://bref.lydra.fr/antisechegit 🐳 Docker : https://bref.lydra.fr/antisechedocker 🔀 Ma RoadMap DevOps : https://vu.fr/RoadmapDevOps ## Mes formations 🎓 Forge toi un état d'esprit DevOps : https://vu.fr/devops-mindset --- Crédits - Christophe Chaudier : consultant indépendant au sein du collectif Lydra. Animateur du podcast de la communauté des Compagnons du DevOps. professeur vacataire à Télécom Saint-Étienne et au CFAI Loire. Découvre le : https://lydra.fr/ea-3-le-podcasteur-christophe | LinkedIn : https://www.linkedin.com/in/cchaudier | Froggit : https://froggit.fr/ 📜 Ce contenu est sous licence libre : CC BY-SA : https://creativecommons.org/licenses/by-sa/4.0/deed.fr Si tu utilises ces contenus dans une publication, merci de nous le notifier dans les commentaires. --- ❓ Pose-moi une question : http://question.compagnons-devops.fr 💬 Rejoins la communauté : https://www.compagnons-devops.fr 🌐 Les Compagnons du DevOps est une initiative de Lydra : https://www.lydra.fr #DevOps #VLOG #Live #Communauté #CompagnonsDuDevops #bilan Vidéos similaires : https://youtu.be/MZ7j5pns0Tk https://youtu.be/oQ4c7Ji7epE https://youtu.be/66cLg-qMhQ8 https://youtu.be/VxiYmsXdxAA https://www.youtube.com/live/rOXxcZg4HHk?feature=share https://www.youtube.com/live/6VoFBG198s0?feature=share https://youtube.com/live/9CUzEQ0cn3I Chaînes similaires : https://www.youtube.com/channel/UCs_AZuYXi6NA9tkdbhjItHQ https://www.youtube.com/channel/UCVRJ6D343dX-x730MRP8tNw https://www.youtube.com/channel/UCM0mnsNbecIi_IAPXtHb-TA

📟 Des CPU x86 plus simple ? ➡️ Extrait d'Actus DevOps de Juin 2023 L'épisode complet : https://youtu.be/akltCRy0XwE https://www.theregister.com/2023/05/25/intel_proposes_dropping_16_bit_mode/ 📩 Si tu n'es pas déjà abonné, alors **abonne-toi** pour ne pas rater les prochaines vidéos. 💬 Rejoins la communauté : https://www.compagnons-devops.fr 💖 Tu peux soutenir mon travail et la communauté sur : https://soutenir.compagnons-devops.fr 🔗 Tous mes liens : https://i.mtr.bio/compagnons-devops Mon Jobboard 💼 Trouve ton job de rêve : https://vu.fr/jobboard-DevOps 👔 Recrute avec moi : https://vu.fr/jobboard-DevOps-recrute Mes antisèches 🎁 git : https://bref.lydra.fr/antisechegit 🐳 Docker : https://bref.lydra.fr/antisechedocker 🔀 Ma RoadMap DevOps : https://vu.fr/RoadmapDevOps Mes formations 🎓 Forge toi un état d'esprit DevOps : https://vu.fr/devops-mindset Crédits - René Ribaud : Software Engineer chez RedHat. J'aime apprendre et transmettre des connaissances sur le logiciel libre et le DevOps. Découvre le : https://lydra.fr/ea-6-le-podcasteur-rene/ | Linkedin : https://www.linkedin.com/in/ren%C3%A9-ribaud-44145137/ | Twitter : https://twitter.com/Uggla_ | Github : https://github.com/uggla | Sa présentation : https://forum.compagnons-devops.fr/t/uggla-floss-addict-architecte-si/ L'intro et la fin sont de : - Baptiste Gaillet : FullStack développeur avec une tendance DevOps au Centre Scientifique et Technique du Bâtiment, Fondateur et développeur de l'application BedFoodCoffee pour aider les personnes en difficultés. Après des études dans le son et différents métiers, il a effectué une reconversion professionnelle en 2015 pour devenir développeur (Formation diplômante dans le cadre d'un CIF). LinkedIn : https://www.linkedin.com/in/baptiste-gaillet-223832b4 | Twitter : https://twitter.com/bat79a - La musique d'intro est *"Tupac Lives"* de John Bartmann : https://pixabay.com/fr/music - La musique de fin est *"Passport"* de Purple planet : https://www.purple-planet.com/passport L'image est de freepik : https://www.freepik.com/free-vector/modern-cpu-background-with-linear-style_3279536.htm Le montage est de Louna HO : https://www.linkedin.com/in/louna-ho-0656801b1/ 📜 Ce contenu est sous licence libre : CC BY-SA : https://creativecommons.org/licenses/by-sa/4.0/deed.fr Si tu utilises ces contenus dans une publication, merci de nous le notifier dans les commentaires. 🌐 Les Compagnons du DevOps est une initiative de Lydra : https://www.lydra.fr #DevOps #Actualités #licenciement #processeurs #cloud #azure #outils

Je tenterai dans cet article de répondre à cette question. Tout a commencé sur un réseau social bien connu où un développeur conseillait à ses camarades d’apprendre les notions d’infrastructures (docker, cloud, Kubernetes). Il en est ressorti des discussions intéressantes et ça m’a donné envie de reparler du sujet. Apprendre l’infrastructure est toujours intéressant De manière générale apprendre de nouveaux trucs est toujours intéressant. Je pense personnellement que les meilleurs profils du marché sont des profils ayant une forte expertise dans plusieurs domaines, ce qui leur permet d’avoir une vue d’ensemble des problématiques de l’entreprise. Cela facilite également grandement la capacité à proposer puis implémenter une vision technique et à faire le pont entre différentes équipes. C’est un peu mon cas où j’ai toujours travaillé à la frontière du dev et de l’ops et donc suis capable d’intervenir et accompagner sur les deux tableaux selon les besoins. Par exemple, je considère aujourd’hui qu’il est important qu’un Sysadmin/DevOps/SRE (le nom du job est un détail) doit savoir coder. Quand je dis doit savoir coder, je ne dis pas être capable de faire du shell dégueulasse, je dis être en capacité d’être mis dans une équipe de dev et de s’en sortir dans un temps raisonnable, et donc de maîtriser à minima les bases de l’ingéniérie logicielle (design patterns, concurrence et parallélisme, tests et mocks, maîtrise basique du DDD). Soyez rassuré si vous êtes dans ces métiers mais manquez de compétences en développement: cela s’apprend. Dans mon entreprise nous formons en interne au développement par exemple. C’est aussi là que l’on se rend compte qu’avoir des équipes avec des profils venant des deux mondes est intéressant (nous recrutons également des profils purs dev que nous formons à l’infrastructure). Mais revenons aux développeurs. Apprendre l’infra sera donc en effet un gros plus pour eux. J’adore personnellement ce genre de profils. Mais apprendre la data (analyse, machine learning, stockage…) serait également un gros plus, ou bien apprendre la programmation système ou kernel, ou le réseau… La connaissance n’est jamais perdue et on ne peut de toute façon pas être expert en tout. Donc apprendre l’infrastructure est intéressant mais ce n’est pas obligatoire. Il y a pourtant certaines bases à maîtriser. Gérer son app du dev à la prod Je suis convaincu qu’une entreprise produisant du logiciel (je parle du type d’entreprise que je connais: services en ligne, sites web, solutions SaaS, services Cloud, logiciels édveloppés et utilisés en interne type SI grands groupes…) ne peut être efficace que si les développeurs peuvent travailler en autonomie du développement à la production jusqu’à l’exploitation. Qu’est ce que cela veut dire ? Les équipes infrastructure ne doivent pas être un point de blocage ou de friction lorsqu’un développeur doit déployer en production. Une mise en prod doit devenir quelque chose de simple à réaliser, qui peut être fait de manière répétable et à tout moment. Cela ne veut pas dire qu’on va donner les accès admin de la production aux dev: on va au contraire faire en sorte qu’un déploiement soit une procédure standard et automatisée. Dans ma boîte actuelle on déploie ~80 fois en production par jour, heureusement que je ne suis pas contacté à chaque fois pour valider le déploiement, hein ? Par exemple, à chaque fois qu’une nouvelle release est réalisée pour une application, ou qu’un commit est merge sur la branche principale, la plateforme d’intégration continue peut lancer automatiquement (ou via un action manuelle d’un dev comme cliquer sur un bouton) le déploiement. Ici, les dev n’ont pas accès à la prod: ils ont accès à une abstraction permettant de déclencher l’action de mise en production de manière fiable. De la même manière un rollback doit être une simple action accessible également aux dev. Il est également important ici pour les dev de connaître la façon dont le déploiement va se réaliser, notamment son déroulement, quel que soit le type d’infrastructure utilisé (PaaS, Kubernetes…): On a très souvent plusieurs instances d’une application en production pour la tolérance aux pannes, et on met à jour généralement ces instances une par une à la nouvelle version, en arrêtant le déploiement en cas de soucis. Cela permet d’éviter les downtime en cas de problème. Lorsqu’une ancienne version de l’application est arrêtée, la plateforme de déploiement envoie généralement un signal (SIGTERM) à l’application pour lui dire de s’éteindre. L’application doit capter ce signal et se stopper proprement, sans perdre aucune requête HTTP (par exemple celles en cours de traitement): l’ordre d’arrêt des composants internes de l’application est donc importante (il serait dommage de stopper son threadpool de base de données alors que le serveur HTTP reçoit toujours des requêtes). L’application doit également démarrer proprement: les applications exposent habituellement un endpoint HTTP /health indiquant qu’elle est prête à accepter du traffic réseau. Là aussi l’ordre de démarrage des composants de l’application est imoortant. Il est courant d’exécuter des changements de schémas de base de données au démarrage des applications: il faut garder en tête qu’il faut pouvoir rollback. On voit dans ces quelques exemples que l’infrastructure a un impact sur la conception de l’application et que cette dernière doit avoir un certain comportement pour fonctionner sans problème. Il est extrêmement courant d’avoir des applications perdant des requêtes HTTP (donc retournant des erreurs aux clients finaux) during les mises à jour par exemple car les contraintes infrastructures ne sont pas comprises. De même, si l’application a un problème en production (par exemple une application HTTP commence à retourner des erreurs 500), ce ne sont pas les équipes infrastructure qui doivent être alertées en premier. Pourquoi ? Car ce sont les équipes de dev qui ont la connaissance de l’application. En tant que SRE, que puis-je faire si un bug applicatif cause un problème dans une application sur lequel je n’ai jamais travaillé, voir dont je ne connais ni le langage ni le métier ? Il n’y a donc aucun intêret à avoir un intermédiaire "ops" qui se contentera de toute façon de retransmettre l’alerte aux équipes dev concernées, cela fera perdre du temps à tout le monde. Cela veut dire que les dev doivent aussi maîtriser la partie observability de leurs applications: Compréhension de la différence entre logs, métriques, et traces, de quand et comment les utiliser (types de métriques, labels, cardinalité, logs structurés, fonctionnement du tracing…). Capable de mettre en place des métriques techniques et business et de définir des SLO et alertes dessus. Capacité à aller explorer ces informations (dashboards, outils de recherche de logs…) et de savoir en autonomie investiguer des problèmes liés à leurs applications. Capable de comprendre l’impact d’une panne d’un composant système externe (base de données, autre service…) sur son application et de prévoir des mécanismes pour que l’application réagisse correctement (éviter des états inconsistants dans la base de données, réconciliation…). Cela ne veut pas dire qu’il n’y a pas des équipes ops/SRE en support, qui seront là pour mettre en place les outils nécessaires pour rendre cela possible et accompagner si besoin les équipes sur ces bonnes pratiques. Bref, on voit que de nombreuses choses liées à l’infrastructures doivent être compréhensibles pour les développeurs. J’aurai également pu parler de pipelines de CI où là aussi une certaine autonomie est attendue pour définir les étapes de tests, lint, build et pour investiguer des jobs en echec. Une histoire de niveau Bien sûr, un dev junior ne peut pas maitrîser tout ça. Mais au bout de plusieurs années de dev maîtriser ces sujets devient essentiel. Au délà de la partie métier (compréhension du besoin du client, organisation…) et technique pure dev (architecture logicielle), les profils senior et plus doivent élargir leurs horizons et comprendre comment les applications s’intègrent dans le SI au sens large. Travailler sur des architectures orientées service ou des systèmes distribués que l’on retrouve de plus en plus (message bus, base de données NoSQL, ou même sur les communications inter services) demandent d’avoir des compétences transverses. J’aurai également pu citer une maitrîse basique du réseau (HTTP/gRPC, TCP, TLS, UDP, DNS, base du routage, load balancing…) comme autre compétences importantes, voir des compétences systèmes ou hardware sur des applications demandant de très hautes performances (pattern d’accès au disque, epoll…). Je pense que ce sont les équipes qui ont intégrées ces éléments dans les compétences des développeurs qui travaillent le plus efficacement aujourd’hui. Mais je le répète, les dev ne remplacent pas les ops, on ne demande pas aux dev ici de déployer des clusters Kubernetes ou de configurer des machines virtuelles, mais d’avoir la maîtrise totale de leurs applications. Références J’ai déjà produit pas mal de contenu sur le sujet que je repartage ici: Mon talk "Rendez vos développeurs autonomes sur la production" Kubernetes et manifests YAML: trop bas niveau pour les dev ? L’important n’est pas la technologie mais la plateforme 2022: bash n’est toujours pas une bonne idée pour l’administration système Conclusion Avoir certaines compétences infra est non seulement utile mais indispensable. Pas besoin d’être un expert de Linux, du cloud ou de l’orchestration de conteneurs pour être développeur, mais des bases sont attendues et si des gens veulent aller plus loin c’est très bien aussi: l’industrie a besoin de ces profils hybrides ayants des expertises variées.

🔧Quel est l'impact du DevOps et du Cloud dans le métier d'administrateur système ? 💬Rejoins les Compagnons du DevOps : https://www.compagnons-devops.fr Dans l'inconscient collectif, le métier de développeur est le métier numérique par excellence. En effet, c'est le métier le plus facile à reconnaître. Pourtant il existe des tas d'autres métiers. Aujourd'hui je suis avec Rahma Sinien et ensemble on va parler de son rôle d'Administrateur Système. Et on va voir comment le DevOps et le Cloud sont impactant pour son métier. 00:00 Introduction 01:58 Qui est-ce ? 03:30 Sa définition du DevOps 05:52 Sa rencontre avec le DevOps, ce que ça a changer 10:59 Le DevOps, mouvement ou métier ? 18:22 Son quotidien, les tâches récurrentes de son métier 30:39 La place de la veille dans son métier 37:53 Son gros projet du moment 50:03 Quelles études a-t-il fait ? 01:04:18 Pourquoi aime-t-il autant la supervision et le monitoring ? 01:12:09 Les ressources Podcast : - Serverless - Humble : the blackhat playbook python : https://www.amazon.fr/Black-Hat-Python-2nd-Programming-ebook/dp/B08CTGR1XC 01:15:02 Conclusion 💬Rejoins les Compagnons du DevOps https://www.compagnons-devops.fr 💖 Soutien mon travail et la communauté https://soutenir.compagnons-devops.fr Mon Jobboard 💼 Trouve ton job de rêve : https://vu.fr/jobboard-DevOps 👔 Recrute avec moi : https://vu.fr/jobboard-DevOps-recrute Mes antisèches 👨‍💻 Ansible : (à venir) 🎁 Git : https://bref.lydra.fr/antisechegit 🐳 Docker : https://bref.lydra.fr/antisechedocker 🎓 Forge toi un état d'esprit DevOps : https://vu.fr/devops-mindset 🔀 Ma RoadMap DevOps : https://vu.fr/RoadmapDevOps Les rézos de Rahma Sinien : - LinkedIn : https://www.linkedin.com/in/jonathansinien/ - YouTube : https://www.youtube.com/c/SynesiosAventuresTV --- Bienvenue, chez les compagnons sur **Radio DevOps**. La Baladodiffusion des **Compagnons du DevOps**. Le podcast en français dédié à notre mouvement. Nos émissions : - **🗞 Actus Devops :** est une émission animée par des membres de la communauté des Compagnons du DevOps. Dans chaque épisode nous étudierons l'actualité Cloud et DevOps. - **📻 Radio DevOps :** est l'émission phare animée par des membres de la communauté des Compagnons du DevOps. Dans chaque épisode nous débattrons sur un sujet de fond. - **🛋 En aparté :** est une émission où je m'entretiendrai avec un invité sur le mouvement DevOps en entreprise. - **🎙️ En Solo :** est une émission où je serai seul pour vous parler de DevOps ou de Cloud. 📩 Si tu n'es pas déjà abonné, alors **abonne-toi** pour ne pas rater ces émissions. 🎁 Rejoins la communauté Froggit et télécharge mon antisèche git : http://froggit.fr Crédits Christophe Chaudier : consultant indépendant au sein du collectif Lydra. Animateur du podcast de la communauté des Compagnons du DevOps. professeur vacataire à Télécom Saint-Étienne et au CFAI Loire. Découvre le : https://lydra.fr/ea-3-le-podcasteur-christophe | LinkedIn : https://www.linkedin.com/in/cchaudier | Froggit : https://froggit.fr/ L'intro et la fin sont de : - Baptiste Gaillet : FullStack développeur avec une tendance DevOps au Centre Scientifique et Technique du Bâtiment, Fondateur de l'association [Bed Food Coffee](https://www.bedfoodcoffee.com/) et développeur de l'application BedFoodCoffee pour aider les personnes en difficultés. Après des études dans le son et différents métiers, il a effectué une reconversion professionnelle en 2015 pour devenir développeur (Formation diplômante dans le cadre d'un CIF). LinkedIn : https://www.linkedin.com/in/baptiste-gaillet-223832b4 | Twitter : https://twitter.com/bat79a - La musique d'intro est *"Tupac Lives"* de John Bartmann : https://pixabay.com/fr/music - La musique de fin est *"Passport"* de Purple planet : https://www.purple-planet.com/passport Le montage est de : - Louna Ho : https://www.linkedin.com/in/louna-ho-0656801b1/ 📜 Ce contenu est sous licence libre : CC BY-SA : https://creativecommons.org/licenses/by-sa/4.0/deed.fr Si tu utilises ces contenus dans une publication, merci de nous le notifier dans les commentaires. L'image est de tonodiaz : https://www.freepik.com/free-photo/two-business-people-standing-server-room-with-laptop-discussing_27998766.htm 🔗 Tous mes liens : https://i.mtr.bio/compagnons-devops 🌐 Les Compagnons du DevOps est une initiative de Lydra : https://www.lydra.fr #Podcast #DevOps #metiers #Cloud #admin Vidéos similaires : https://youtu.be/PlXf0d9CLhg https://youtu.be/bqAjWf_aqEw https://youtu.be/6haRNTST3gw https://youtu.be/b4BXVipiviA Chaînes similaires : https://www.youtube.com/channel/UCs_AZuYXi6NA9tkdbhjItHQ https://www.youtube.com/channel/UCVRJ6D343dX-x730MRP8tNw https://www.youtube.com/channel/UCM0mnsNbecIi_IAPXtHb-TA

💼 Une vague historique de suppression d'emploi dans la tech ➡️ Extrait d'Actus DevOps de Juin 2023 L'épisode complet : https://youtu.be/akltCRy0XwE * [https://www.lemonde.fr/economie/article/2023/06/09/high-tech-les-lecons-d-une-vague-historique-de-suppressions-d-emplois\_6176826\_3234.html](https://www.lemonde.fr/economie/article/2023/06/09/high-tech-les-lecons-d-une-vague-historique-de-suppressions-d-emplois_6176826_3234.html) * https://www.toolinux.com/?un-plan-de-licenciements-annonce-chez-red-hat * https://www.latribune.fr/technos-medias/internet/hecatombe-dans-la-tech-plus-de-130-000-licenciements-en-2022-940762.html * https://layoffs.fyi/ * https://www.boursorama.com/bourse/indices/cours/%24NDX.X/ * https://www.igen.fr/app-store/2023/02/zenly-cest-fini-le-reseau-social-rachete-par-snap-ferme-ses-portes-135329 📩 Si tu n'es pas déjà abonné, alors **abonne-toi** pour ne pas rater les prochaines vidéos. 💬 Rejoins la communauté : https://www.compagnons-devops.fr 💖 Tu peux soutenir mon travail et la communauté sur : https://soutenir.compagnons-devops.fr 🔗 Tous mes liens : https://i.mtr.bio/compagnons-devops Mon Jobboard 💼 Trouve ton job de rêve : https://vu.fr/jobboard-DevOps 👔 Recrute avec moi : https://vu.fr/jobboard-DevOps-recrute Mes antisèches 🎁 git : https://bref.lydra.fr/antisechegit 🐳 Docker : https://bref.lydra.fr/antisechedocker 🔀 Ma RoadMap DevOps : https://vu.fr/RoadmapDevOps Mes formations 🎓 Forge toi un état d'esprit DevOps : https://vu.fr/devops-mindset Crédits - Christophe Chaudier : consultant indépendant au sein du collectif Lydra. Animateur du podcast de la communauté des Compagnons du DevOps. professeur vacataire à Télécom Saint-Étienne et au CFAI Loire. Découvre le : https://lydra.fr/ea-3-le-podcasteur-christophe | LinkedIn : https://www.linkedin.com/in/cchaudier | Froggit : https://froggit.fr/ L'intro et la fin sont de : - Baptiste Gaillet : FullStack développeur avec une tendance DevOps au Centre Scientifique et Technique du Bâtiment, Fondateur et développeur de l'application BedFoodCoffee pour aider les personnes en difficultés. Après des études dans le son et différents métiers, il a effectué une reconversion professionnelle en 2015 pour devenir développeur (Formation diplômante dans le cadre d'un CIF). LinkedIn : https://www.linkedin.com/in/baptiste-gaillet-223832b4 | Twitter : https://twitter.com/bat79a - La musique d'intro est *"Tupac Lives"* de John Bartmann : https://pixabay.com/fr/music - La musique de fin est *"Passport"* de Purple planet : https://www.purple-planet.com/passport L'image est de Drazen Zigic : https://www.freepik.com/free-photo/view-unrecognizable-businessman-leaving-office-after-losing-his-job_26346316.htm Le montage est de Louna HO : https://www.linkedin.com/in/louna-ho-0656801b1/ 📜 Ce contenu est sous licence libre : CC BY-SA : https://creativecommons.org/licenses/by-sa/4.0/deed.fr Si tu utilises ces contenus dans une publication, merci de nous le notifier dans les commentaires. 🌐 Les Compagnons du DevOps est une initiative de Lydra : https://www.lydra.fr #DevOps #Actualités #licenciement #processeurs #cloud #azure #outils

Je présenterai dans cet article "techno-agnostic" (aucune techno citée) les différents types de métriques que vous pouvez retrouver dans une application, et expliquerai comment les utiliser. Cet article est le premier d’une j’espère longue série sur l’observability qui traitera en profondeur du sujet. Attendez vous prochainement à d’autres articles sur les logs, les traces, les SLO/error budget/burn rate, l’alerting, le monitoring "blackbox" et toutes les bonnes pratiques associées. Retrouvez l’article sur Opentelemetry et le tracing ici. Qu’est ce qu’une métrique ? Une métrique est une mesure et des informations associés à une date précise (un timestamp). Prenons l’exemple d’une métrique représentant le nombre de requêtes HTTP reçu par un serveur web. Je l’appellerai http_requests_total. Cette métrique sera donc incrémentée à chaque fois que le serveur HTTP reçoit une nouvelle requête. Imaginons maintenant que nous puissons regarder et noter de manière régulière la valeur de cette métrique. Cela donnerait peut être (Pour plus de simplicité, je ferai toujours commencer le temps à la valeur 0 dans mes exemples) : Table 1. Valeurs de http_requests_total timestamp valeur 1 10 11 70 21 90 Au temps 1, la valeur de la métrique est 10. Au temps 11, elle est de 70 et au temps 21 elle est de 90. On en déduit donc que notre serveur HTTP a reçu 60 requêtes (70 - 10) entre les temps 1 et 11, et 20 requêtes (90 - 70) entre les temps 11 et 21. Prenons un autre exemple: une métrique pourrait par exemple remonter la consommation mémoire (RAM) d’un serveur. Elle s’appellera ici memory_used et sa valeur sera en mégabyte: Table 2. Valeurs de memory_used timestamp valeur 1 1500 11 3000 21 2900 Notre serveur utilisait donc 1500 MB de mémoire au temps 1, 30000 MB au temps 11, et 2900 au temps 21. Nos métriques peuvent donc représenter plusieurs choses mais l’idée est toujours la même: une mesure associée à un temps. Labels Tout cela est bien pratique, mais il est très souvent nécessaires d’avoir plus de détails sur les métriques. Reprenons notre métrique http_requests_total : comment faire si je souhaite compter le nombre de requêtes par url cible ou par méthode HTTP par exemple ? Si mon serveur web héberge un blog, j’aimerai bien avoir le nombre de de requêtes par article de blog dans le but de connaître mes articles les plus populaires. Cela est possible en rajoutant des labels à la métrique. Les labels sont des dimensions supplémentaires attachées à une métrique. Je vais ici en ajouter trois: url : l’adresse de la page demandée à mon serveur web method : la méthode HTTP de la requête Voici à quoi pourraient ressembler des observations de cette métrique pour par exemple un blog culinaire présentant des recettes de pâtisseries: Table 3. Valeurs de http_requests_total avec des labels timestamp url method valeur 1 /paris-brest GET 40 3 /eclair GET 10 11 /paris-brest GET 60 13 /eclair GET 15 Ces valeurs nous montrent qu’au temps 1, la page paris-brest avait eu 40 visites, puis 60 au temps 11. La page eclair avait elle 10 visites au temps 3, puis 15 au temps 13. La méthode HTTP ici est toujours GET. Nous verrons des exemples plus complexes dans la suite de cet article. On appelle généralement série une combinaison possible des valeurs des labels pour une métrique donnée. Nous avons dans cet exemple deux séries pour la métrique http_requests_total: url="/paris-brest", method="GET" url="/eclair", method="GET" Cela nous amène à la notion de cardinalité et du choix des labels. Cardinalité On appelle cardinalité le nombre de série pour une métrique. La cardinalité était donc de deux dans notre exemple précédent. Imaginons le même site web mais avec ce coup ci 50 recettes différentes, et que l’on autorise en plus les utilisateurs à voter pour une recette (dans le but de pouvoir classer les recettes par popularité par exemple) en exécutant une requête de type POST sur l’url de la page. GET /paris-brest permettrait par exemple aux utilisateurs de récupérer la recette du Paris Brest, et POST /paris-brest de voter pour cette recette. On a donc 50 pages (50 recettes), et 2 méthodes (GET et POST) par recette. Notre cardinalité est donc de 50 * 2 soit égale à 100. Rajoutons un label à notre métrique: le nom de la machine (host) hébergeant le serveur web. Il est en effet courant d’avoir une application hébergée sur plusieurs serveurs pour par exemple avoir de la tolérance aux pannes. Voici par exemple deux séries ayant les mêmes labels à part celui nommé host: Table 4. Exemples de séries timestamp url method host ̀ valeur 1 /paris-brest GET server_1 40 1 /paris-brest GET server_2 10 Quelle serait la cardinalité de la métrique si l’on hébergeait le blog culinaire sur 4 serveurs différents ? Elle serait de 50 * 2 * 4 soit 400 (50 pages, méthodes HTTP GET ou POST, et les 4 serveurs). choix des labels et explosion de la cardinalité Il est important de choisir correctement les labels d’une métrique: Les labels doivent être pertinents et avoir du sens pour la métrique. Comme nous le verrons plus loin dans cet article la majorité des bases de données pour stocker des séries temporelles permettent de requêter les métriques en fonction de leurs labels. Avoir un label url sur une métrique HTTP est donc logique car il sera très utile de pouvoir filter les métriques sur ce label. Il faut éviter d’avoir une cardinalité trop importante. Une erreur classique faite par de nombreux développeurs est de stocker l’ID aléatoire (uuid généralement) généralement associé à une requête HTTP dans un label: cela veut dire que chaque requêtes HTTP sur le serveur web créera une nouvelle série. Cette série n’aura qu’une mesure, car une nouvelle requête en créera une nouvelle. Il y a d’autres pièges à éviter sur les labels. Reprenons notre label url sur notre serveur HTTP. Certaines URL peuvent être variables, par exemple une API web pourrait contenir un ID d’utilisateur comme par exemple /user/:id, la partie :id étant variable et contenant un ID associé à chaque utilisateur. Il est important dans ce cas d’utiliser comme label pour url la valeur /user/:id sans remplacer l’ID à chaque requête, et non par exemple /user/1, /user/2… ce qui créerait une série pour chaque utilisateur de la plateforme. Utiliser l’url avec la variable non remplacée ne créera qu’une série quel que soit la valeur de la variable. Certains labels peuvent être identiques à de nombreuses séries. Les organisations ont très souvent plusieurs environnements: production, pré-production (staging), développement… Il est très intéressant d’ajouter ce label aux métriques pour pouvoir facilement les distinguer, comme pour par exemple avoir des politiques d’alertes différentes entre un environnement de production et de développement. Toutes les métriques de production pourraient par exemple avoir un label environment=production. D’autres labels génériques de ce type peuvent aider à classifier les séries. Il est également important d’avoir une cohérence sur le nommage des labels. Il serait dommage d’avoir la moitié des métriques avec env=production et l’autre moitié avec environment=production par exemple. Certains outils permettent de faire du relabeling (renommer les labels de certaines métriques) mais se poser ce genre de questions dès la mise en place du monitoring reste important. Types de métriques Il existe différents types de métriques. Il vous faudra choisir le bon type selon ce que vous voulez mesurer et calculer. Compteurs Un compteur (counter) est tout simplement une métrique comptant quelque chose. C’était par exemple le cas de la métrique http_requests_total présentée précédemment. Cela veut dire dans le cas de cette métrique que mon serveur web va incrémenter la série correspondante (en fonction des labels) à chaque requête HTTP reçue. Ces compteurs par série vont donc seulement s’incrémenter en permanence. Compter des choses est utile mais il est souvent plus intéressant de calculer un taux (rate) par seconde. Voici par exemples 3 valeurs pour une même série avec le calcul du rate pour chaque valeur. Table 5. Calcul du rate http_requests_total timestamp url method compteur rate (req/sec) 1 /paris-brest GET 40 11 /paris-brest GET 80 (80-40)/10 = 4 21 /paris-brest GET 180 (180-100)/10 = 8 31 /paris-brest GET 210 (210-180)/10 = 3 On voit que le rate est calculé en soustrayant la valeur actuelle du compteur par sa valeur précédente, le tout divisé par l’interval de temps. En effet, entre ma métrique au temps 1 et celle au temps 11, 10 secondes se sont écoulées. La valeur de la métrique au temps 1 était de 40, et celle au temps 11 était de 80. Il y a donc eu 40 requêtes (80 - 40) entre ces deux valeurs. On en déduit donc que l’application a reçue en moyenne 4 requêtes par seconde pendant cet interval de temps. Appliquer cette méthode à chaque nouvelle valeur reçue permet de calculer le rate au fil du temps. Réinitialisation du compteur Les applications gardent généralement leurs métriques en mémoire. Cela veut dire que les métriques sont réinitialisées en cas de redémarrage de l’application par exemple. Il est possible dans ce cas d’obtenir un rate négatif. Table 6. Calcul du rate http_requests_total timestamp url method compteur rate (req/sec) 1 /paris-brest GET 40 11 /paris-brest GET 80 (80-40)/10 = 4 21 /paris-brest GET 10 (10-80)/10 = -7 On voit dans cet exemple que la valeur de la métrique est de 80 au temps 11, et -7 au temps 21. En effet, la valeur de la métrique est passée de 80 à 10, ce qui peut arriver si l’application a redémarrée pendant cet interval de temps. Une solution peut être par exemple de filtrer les valeurs négatives, ces dernières étant de toute façon incorrectes. Jauge Un autre type de métrique est la Jauge (Gauge). Cette métrique représente tout simplement une valeur arbitraire. On peut s’en servir pour compter le nombre d’éléments dans une queue de message par exemple. Notre programme pourrait générer une métrique toutes les 10 secondes contenant le nombre d’éléments dans la liste à cet instant. Table 7. Valeur de ma jauge timestamp valeur 1 10 11 8 21 15 C’est sur ce genre de besoins (nombre d’éléments dans une liste, une queue, une table d’une base de données…) que l’on rencontrera le plus souvent ce type de métriques. Quantiles et histogrammes Les quantiles (souvent appelés également percentiles) sont très courants dans le monde du monitoring lorsqu’on souhaite monitorer les performances d’une application. Reprenons notre exemple de blog culinaire. Nous pourrions avoir envie de mesurer le temps de chargement des pages de notre site. Nous allons donc devoir mesurer le temps des requêtes côté serveur et utiliser ces mesures pour avoir une aperçu des performances de notre serveur HTTP. C’est ici que les quantiles entrent en jeux. Les quantiles vont s’appliquer sur nos mesures et servent à découper en deux partie cet ensemble de mesures, par exemple: q50 (quantile 50, souvent appelé 50 également): ceci est la médiane. Ici, 50 % des requêtes HTTP ont un temps d’exécution inférieur à la valeur associée à mon quantile, et 50 % ont un temps d’exécution supérieur. q75: 75 % des requêtes HTTP on un temps d’exécution inférieur à la valeur associée à mon quantile, et 25 % ont un temps d’exécution supérieur. q99: 99 % des requêtes HTTP on un temps d’exécution inférieur à la valeur associée à mon quantile, et 1 % ont un temps d’exécution supérieur. q1: ceci sera tout simplement la valeur maximale (la requête la plus lente) de mon serveur HTTP. Prenons par exemple ce jeu de données représentant les durées d’exécution des requêtes sur mon serveur HTTP en millisecondes: 550, 300, 1000, 2000, 450, 1300, 1400, 200, 300, 400, 900, 1200, 800, 350, 500 Nous n’avons dans cet exemple que 15 valeurs pour faciliter l’exemple mais en réalité vous pourriez réaliser ce calcul sur plusieurs milliers si nécessaire. Une des premières choses que l’on pourrait faire est de trier ces valeurs: 200, 300, 300, 350, 400, 450, 500, 550, 800, 900, 1000, 1200, 1300, 1400, 2000 Calculons maintenant le q50 sur ces valeurs (la médiane): nous voulons donc trouver la valeur au centre de notre distribution et donc avant le même nombre de valeurs avant et après cette valeur. Ceci est assez simple dans notre cas: nous avons 15 valeurs, donc la médiane sera la 7eme valeur de notre liste triée. Nous aurons en effet 6 valeurs inférieures, et 6 valeurs supérieures. La valeur du q50 est donc de 500. De la même façon, nous voulons pour le q75 trouver la valeur ayant 75 % de valeurs inférieures (soit 15 * 75/100 = 11,25 que l’on arrondira à 11), et 25 % supérieures (donc 4) La 11eme valeur de notre liste est 1000, et donc notre q75 sera égal à cette valeur. Notre jeu de données est petit donc la même procédure appliquée au q99 nous donnera la valeur 2000 qui est aussi la valeur maximale. Les quantiles sont donc bien utiles car ils permettant d’avoir rapidement une information pertinente sur par exemple des performances d’applications. Cela permet également d’énoncer des objectifs de performances clairs, comme par exemple 99 % de mes requêtes doivent s’exécuter dans un temps inférieur à une seconde. Dans des cas réels avec de grands jeux de données (des milliers de requêtes par exemple) on peut même aller jusqu’à calculer le q99.9 ou q99,99 si besoin. Histogrammes La méthode précédente pour calculer des quantiles est intéressante car elle permet de calculer exactement la valeur du quantile. Elle a également un défault: l’ensemble des valeurs doivent être disponibles pour réaliser le calcul. Cela peut être problématique lorsqu’on veut calculer des quantiles sur un grand nombre de valeurs qui devront donc être stockées de façon unitaire. Une autre solution pour calculer les quantiles est d’utiliser un histogramme dans le but de calculer une valeur approchée du quantile mais sans avoir à stocker l’ensemble des données. La première chose à faire est de choisir les intervalles (aussi appelés bucket) de notre histogramme. Nous reprendrons comme exemple ici le temps de traitement de requêtes par un serveur HTTP, avec ce temps en millisecondes. Une pratique courante dans le monde du monitoring serait d’utiliser des intervalles démarrant tous à 0 et de compter le nombre de requêtes ayant un temps d’exécution inférieur à une valeur donnée. La liste de nos mesures est dans cet exemple la même que précédemment: 200, 300, 300, 350, 400, 450, 500, 550, 800, 900, 1000, 1200, 1300, 1400, 2000 Comptons maintenant le nombre de valeurs dans différents intervalles, par exemple combien de requêtes ont un temps d’exécution dans l’intervalle 0-100, 0-200, 0-400… Table 8. Intervalles de l’histogramme Minimum (toujours 0) Maximum (inclus) Total (nombre) 0 100 0 0 200 1 0 400 5 0 600 8 0 1000 11 0 1400 14 0 2200 15 0 Infini 15 On a donc 0 requête ayant un temps d’exécution entre 0 et 100 millisecondes, 1 entre 0 et 200 millisecondes, 5 entre 0 et 400 millisecondes etc. On remarque que cette manière de faire permet de ne pas avoir à garder l’ensemble des mesures: il suffit lorsqu’une nouvelle mesure est réalisée d’incrémenter tous les intervalles nécessaires. On remarque également que le nombre de valeur dans chaque intervalle est en augmentation constante, ce qui est logique car les valeurs précédentes sont inclus dans chaque intervalle vu que l’on recompte à chaque fois le nombre de valeurs dans l’intervalle depuis 0. Le dernier intervalle est intéressant: il compte le nombre de valeurs de 0 à Infini, et contiendra donc toujours le total des valeurs. Ces informations permettent de calculer simplement une valeur approximative d’un quantile, comme par exemple le q50: Il y a 8 intervalles différents, et 15 mesures dans ces intervalles. Nous savons que nous recherchons la métrique au centre de notre distribution, et que nous voulons calculer la médiane: Nous commençons donc par réaliser le calcul suivant: 0.5 * 15 = 7.5. Nous recherchons donc où se trouve cette valeur (7.5) dans notre histogramme. On recherche l’intervalle juste après cette valeur: dans notre cas, c’est dans l’intervalle [0, 600] car sa valeur est de 8. La valeur de l’intervalle précédent étant de 5 nous pouvons en déduire que le quantile se trouve dans cet intervalle (car 5 < 7.5 < 8). Nous calculons maintenant le nombre de valeurs présentes entre cette intervalle ([0, 600]) et le précédent ([0, 400]. Nous souhaitons donc répondre à la question combien de mesures ayant une valeur entre 400 et 600 avons nous ? Le résultat est 8 - 5 et est donc égal à 3. Comme dit au début de cet article, nous allons calculer une valeur approximative pour notre quantile. Nous savons que notre quantile se trouve quelque part dans l’intervalle [400, 600] (qui couvre une durée d’exécution de 200 millisecondes), et que nous avons 3 valeurs dans cet intervalle. Rappelez vous que l’on recherche la durée théorique pour la valeur 7.5 calculée précédemment. Nous réalisons l’opération (7.5 - 5) / 3 = 0.833. Nous soustrayons ici la valeur recherchée à la valeur associée à la borne inférieure (400) de notre intervalle, que nous divisons ensuite par le nombre de valeurs dans l’intervalle (3). Nous multiplions le résultat précédent par la durée de l’intervalle: 200 * 0.833 = 166.6. Nous pouvons décrire ce calcul de la façon suivante: j’ai un intervalle de taille 200 le point recherché se trouve au pourcentage 0.833. Nous ajoutons la borne inférieure de notre intervalle à ce résultat: 400 + 166.6 = 566.6. Ceci est le résultat final et la valeur approximative de notre quantile (et la médiane dans cet exemple). Ce calcul peut aussi se résumer au fait de tracer une droite entre les coordonnées [400, 5] et [600, 8] et de rechercher la valeur associée à 7.5 sur cette droite. Notre résultat approximatif est différent du résultat réel (qui est de 500). Il faut garder en tête que ce type de calculs fonctionne mieux sur de plus gros jeux de données. Mais ce résultat nous donne dans tous les cas une idée de la performance de notre application, et c’est ce qui est le plus important. Connaître la performance de notre application à la milliseconde près n’est pas utile dans de nombreux contextes. Il vaut mieux pouvoir obtenir rapidement et simplement (en utilisant peu de capacités de stockage et de calcul) une valeur approximative mais proche de la réalité que de toujours vouloir une valeur exacte mais qui peut se révéler difficile à calculer. Pull vs Push et stockage Nos systèmes émettent donc des métriques. Pour les exploirer, il faut pouvoir les requêter et donc les stocker. Il existe deux mondes lorsqu’il s’agit pour une application de diffuser ses métriques dans le but de les stocker: le mode push et le mode pull. Le push Dans ce mode, l’application pousse les métriques vers une base de données temporelle (ou vers tout autre système de stream processing pouvant éventuellement servir à filtrer, modifier, enrichir la métrique, ou faire backpressure). Ce mode a un certain nombre d’avantages: Un endpoint unique à connaître pour les applications pour pousser les métriques: cela permet une énorme facilité en terme de configuration applicative et réseau (règles de firewalling en sortie seulement vers une destination unique). Possibilité d’ajouter facilement des composants intermédiaires comme dit précédemment pour faire du stream processing ou absorber des pics de charge en ayant un composant "buffer" entre l’application et la base de données temporelle. Haute disponibilité et scaling très facile (load balancing, déduplication du traffic entre plusieurs base de données/services cloud par exemple) Le push est plus facile à scale et beaucoup plus flexible en ajoutant un système intermédiaire de type "message broker" entre l’application et les systèmes externes. N’importe qui peut comme ça consommer les métriques sans impacter les autres. Bref, le push, c’est bon, mangez en, malheureusement c’est plus forcément "à la mode" pour la gestion de métriques. Le pull Une technologie apparue il y a quelques années a proposé une approche différente et été vite adoptée pour différentes raisons: le pull. Dans ce mode, c’est l’outil stockant les métriques qui va aller chercher (pull) les métriques en envoyant directement des requêtes à l’application. Cela veut dire que l’application doit les exposer, via HTTP dans notre cas. Une application pourrait par exemple exposer un endpoint HTTP /metrics retournant dnas cet exemple la valeur associée à l’instant T de la requête aux différentes métriques configurées (ici des compteurs): healthcheck_total{id="f7b4dba8-9626-436e-a0d2-670e862c650a", name="appclacks-website", status="failure", zone="fr-par-1"} 1 healthcheck_total{id="f7b4dba8-9626-436e-a0d2-670e862c650a", name="appclacks-website", status="success", zone="fr-par-1"} 2789 healthcheck_total{id="f7b4dba8-9626-436e-a0d2-670e862c650a", name="appclacks-website", status="failure", zone="pl-waw-1"} 1 healthcheck_total{id="f7b4dba8-9626-436e-a0d2-670e862c650a", name="appclacks-website", status="success", zone="pl-waw-1"} 2789 La base de données temporelle fera périodiquement (toutes les 30 secondes par exemple) une requête, associera à la valeur des métriques le timestamp de la requête, et stockera ça dans sa base. L’approche pull demande une énorme logique en service discovery et a une plus grosse complexité réseau que le push. Cela force également toutes vos applications à exposer un endpoint HTTP servant les métriques. Au final, les deux approches fonctionnent. Je vous recommande un autre de mes articles sur le sujet si vous voulez avoir plus de retours sur le pull vs push. Calculs côté client ou côté serveur Dernière partie de cette article, le calcul côté client ou côté serveur. J’ai expliqué précédemment comment calculer par exemple des rate, quantiles… à partir de métriques brutes. Il faut savoir que parfois, certaines librairies applicatives de gestion de métriques calculent ces valeurs pour vous. Cela veut dire que votre application ne va pas exposer à la base de données temporelle les données brutes (par exemple, la valeur d’un compteur ou les buckets d’un histogramme) mais directement un nombre de requête par seconde, es quantiles (p99, p75…). Cela peut sembler intéressant de prime abord car il n’y a aucun calcul à réaliser côté base de données temporelle, mais il y a beaucoup d’inconvénients à ne pas avoir accès aux métriques brutes: Si les données sont pré-calculées côté application, il n’est plus possible d’aggréger ensemble les métriques de plusieurs instances (replicas) d’une même application. Il est en effet commun de calculer des quantiles pour une instance d’une application, mais aussi pour toutes les instances d’une application ensemble. Cela permet de visualiser la latence par instance de l’application (utile pour voir si une instance a des caractéristiques de performances étranges par rapport aux autres) mais aussi de voir la latence globale pour toutes les instances de l’application. Ce dernier calcul ne peut se faire que en ayant accès aux métriques brutes et en faisant la somme de chaque bucket de chaque instance de l’application. Je n’ai présenté dans cet article que quelques exemples de calculs à réaliser sur les métriques. En réalité, il y en a de nombreux autres que vous retrouverez dans vos base de données temporelles et qui sont également indispensables pour monitorer vos applications. Si vous n’avez pas accès aux données brutes, ces calculs seront irréalisables. Conclusion Les métriques sont indispensables pour monitorer correctement des composants applicatifs ou d’infrastructure. Bien choisir ses métriques (type, labels…) est important et est la clé pour construire une solide plateforme d’observability.

🗞 Actus DevOps est ton #podcast de veille #DevOps et #Cloud mensuel. 💬 Inscris toi au forum : https://www.compagnons-devops.fr 00:00 Intro 00:59 Vos messages ❓ Pose-nous une question : http://question.compagnons-devops.fr 03:41 Dépressage dans la tech https://www.lemonde.fr/economie/article/2023/06/09/high-tech-les-lecons-d-une-vague-historique-de-suppressions-d-emplois\_6176826\_3234.html https://www.toolinux.com/?un-plan-de-licenciements-annonce-chez-red-hat https://www.latribune.fr/technos-medias/internet/hecatombe-dans-la-tech-plus-de-130-000-licenciements-en-2022-940762.html https://layoffs.fyi/ https://www.boursorama.com/bourse/indices/cours/%24NDX.X/ https://www.igen.fr/app-store/2023/02/zenly-cest-fini-le-reseau-social-rachete-par-snap-ferme-ses-portes-135329 15:40 Va checker mon jobboard ! https://vu.fr/jobboard-DevOps 15:51 Des CPU x86 plus simple ? https://www.theregister.com/2023/05/25/intel_proposes_dropping_16_bit_mode/ 23:44 💖 Tu peux soutenir mon travail et la communauté sur : https://soutenir.compagnons-devops.fr 24:19 La typo qui a cassé Azure au Brésil https://www.lemondeinformatique.fr/actualites/lire-une-erreur-de-typo-bloque-azure-devops-pendant-plusieurs-heures-90613.html https://status.dev.azure.com/_event/392143683/post-mortem 37:10 Un panorama des outils Cloud https://www.linkedin.com/posts/clément-david-59048944\_voici-la-carte-pour-vous-y-retrouver-activity-7070059592595951618-tm8N?utm\_source=share&utm\_medium=member\_desktop https://www.padok.fr/tech-radar 43:27 Nos outils topgrade : https://github.com/topgrade-rs/topgrade snips.sh : https://github.com/robherley/snips.sh exa : https://the.exa.website/ alternative : https://github.com/lsd-rs/lsd dark snoopy : https://www.instagram.com/darksnooopy/?hl=fr 57: Clôture 🔗 Tous mes liens : https://i.mtr.bio/compagnons-devops Mon Jobboard 💼 Trouve ton job de rêve : https://vu.fr/jobboard-DevOps 👔 Recrute avec moi : https://vu.fr/jobboard-DevOps-recrute Mes antisèches 🎁 git : https://bref.lydra.fr/antisechegit 🐳 Docker : https://bref.lydra.fr/antisechedocker 🔀 Ma RoadMap DevOps : https://vu.fr/RoadmapDevOps Mes formations 🎓 Forge toi un état d'esprit DevOps : https://vu.fr/devops-mindset Crédits Les podcasteurs : - Christophe Chaudier : consultant indépendant au sein du collectif Lydra. Animateur du podcast de la communauté des Compagnons du DevOps. professeur vacataire à Télécom Saint-Étienne et au CFAI Loire. Découvre le : https://lydra.fr/ea-3-le-podcasteur-christophe | LinkedIn : https://www.linkedin.com/in/cchaudier | Froggit : https://froggit.fr/ - René Ribaud : Software Engineer chez RedHat. J'aime apprendre et transmettre des connaissances sur le logiciel libre et le DevOps. Découvre le : https://lydra.fr/ea-6-le-podcasteur-rene/ | Linkedin : https://www.linkedin.com/in/ren%C3%A9-ribaud-44145137/ | Twitter : https://twitter.com/Uggla_ | Github : https://github.com/uggla | Sa présentation : https://forum.compagnons-devops.fr/t/uggla-floss-addict-architecte-si/ - Erwan Ben Soudien : DevOps chez Toucan Toco (ex Deezer, Antelink, Weborama - ex sysadmin ) - professeur vacataire à Paris XIII / IUT Creteil. Découvre le : https://lydra.fr/ea-2-le-podcasteur-erwan/ | Linkedin : https://www.linkedin.com/in/erwan-ben-souiden-8b8084152 📩 Si tu n'es pas déjà abonné, alors abonnes-toi pour ne pas rater les prochaines vidéos. L'intro et la fin sont de : - Baptiste Gaillet : FullStack développeur avec une tendance DevOps au Centre Scientifique et Technique du Bâtiment, Fondateur et développeur de l'application BedFoodCoffee pour aider les personnes en difficultés. Après des études dans le son et différents métiers, il a effectué une reconversion professionnelle en 2015 pour devenir développeur (Formation diplômante dans le cadre d'un CIF). LinkedIn : https://www.linkedin.com/in/baptiste-gaillet-223832b4 | Twitter : https://twitter.com/bat79a - La musique d'intro est "Tupac Lives" de John Bartmann : https://pixabay.com/fr/music - La musique de fin est "Passport" de Purple planet : https://www.purple-planet.com/passport L'image est de pressfoto : https://www.freepik.com/free-photo/business-trouble_5403447.htm Le montage est de Louna HO : https://www.linkedin.com/in/louna-ho-0656801b1/ 📜 Ce contenu est sous licence libre : CC BY-SA : https://creativecommons.org/licenses/by-sa/4.0/deed.fr Si tu utilises ces contenus dans une publication, merci de nous le notifier dans les commentaires. 🌐 Les Compagnons du DevOps est une initiative de Lydra : https://www.lydra.fr #DevOps #Actualités #licenciement #processeurs #cloud #azure #outils Vidéos similaires : https://youtu.be/f70nHY7kEQY https://youtu.be/Rp8hNqgGdl0 https://youtu.be/4BibQ69MD8c Chaînes similaires : https://www.youtube.com/channel/UCs_AZuYXi6NA9tkdbhjItHQ https://www.youtube.com/channel/UCVRJ6D343dX-x730MRP8tNw https://www.youtube.com/channel/UCM0mnsNbecIi_IAPXtHb-TA

A propos de Spider DevOps

Contact

Toute l'actualité devOps