Beuret Stéphane

Trop complexe à mettre en œuvre, trop chère également, ralentissant le cycle de développement logiciel (ou Software Development Life Cycle, SDLC), depuis plus de 40 ans l'industrie dans son ensemble (ou tout du moins dans la majorité des cas) fait souvent l'impasse sur la sécurité. Pourtant entre le coût d'une cyberattaque pour une entreprise, ses obligations de protéger les données personnelles, et son e-réputation, les jours où on fermait désinvoltement les yeux sur la sécurité semblent toucher à leur fin. Alors autant prendre le sujet à bras le corps et se familiariser un peu plus avec ce domaine qui est tout sauf ennuyeux !

L'arrivée de Docker, de Kubernetes et plus généralement de ce que l'on nomme le cloud natif a bousculé nos habitudes : de la manière dont nous écrivons notre code, dont nous le déployons, mais aussi de la manière dont nous l'observons ! Peu d'entre nous se préoccupaient de l'Application Performance Monitoring (APM) avant 2014, et je suis sûr que beaucoup ignorent encore ce qu'est une trace distribuée. Pourtant, avec nos applications dynamiques découpées en microservices et hébergées dans le cloud, il est de plus en plus difficile de faire l'impasse sur ce genre d'outils. Et le continuous profiler est justement l'un de ces précieux outils.

Les métriques sont de loin, à mon humble avis, le signal le plus fascinant. Je vous l'accorde, elles sont aussi vieilles que l'informatique elle-même et pour cause : « ce qui ne se mesure pas ne s'améliore pas » [1]. Mais mesurer une chose est parfois un art, et dans les technologies de l'informatique, c'est un art qui a fondamentalement évolué ces dernières années. Non pas qu'on ne mesure plus les mêmes choses qu'il y a 20 ans, la charge d'un CPU et les IOPS ont toujours leur importance, mais on ne les aborde simplement plus de la même manière, surtout quand on vient à parler de systèmes distribués.

N'importe qui ayant travaillé dans l'informatique depuis plus de cinq ans vous le dira : on n'a pas attendu Google et son livre sur les SRE [1] pour « monitorer » nos systèmes. Au passage, excusez-moi pour l'affreux barbarisme alors que j'aurais pu utiliser le mot surveiller tout simplement, mais alerte de « divulgâchage » : il y en aura malheureusement bien d'autres dans cet article, parce que soit je ne trouve pas la traduction française satisfaisante, soit la traduction française n'a pas exactement le même sens. Alors pourquoi depuis cinq ans ne parle-t-on plus que d'observabilité et non plus de monitoring ?

Après avoir survolé ce qu'était une trace distribuée dans l'article sur les 3 piliers de l'observabilité, et donné une description des différents éléments qui la composaient, nous allons entrer un peu plus dans les détails de l'instrumentation proprement dite. Car si collecter des traces pour mieux comprendre une application en microservices change totalement la donne, pour autant, cela demande un peu de travail. Et c'est justement ce qui explique la montée en puissance d'OpenTelementry aujourd'hui. Vous allez découvrir pourquoi.

Parmi les trois piliers de l'observabilité, s'il y en a bien un qui n'a pas besoin d'être présenté, ce sont bien les logs. Qui n'a pas son anecdote sur un print initialement utilisé par un développeur pour s'assurer du bon déroulement de son code qui finit par se retrouver dans le code en production ? Le log est réellement l'instrument qui nous permet de répondre à cette question rudimentaire, mais essentielle : que se passe-t-il dans mon code à l'instant t. Mais parce qu'il est simple à utiliser et flexible à souhait, le log pose souvent un réel problème lorsqu'une application passe en production. Et c'est encore plus vrai dans les systèmes distribués.

Être en mesure de surveiller la consommation énergétique de nos applications est une idée attrayante, qui n'est que trop souvent mise à la marge aujourd'hui. C'est d'ailleurs paradoxal, quand on pense que de plus en plus de voitures permettent de connaître la consommation instantanée et la consommation moyenne du véhicule, mais que nos chers ordinateurs, fleurons de la technologie, ne le permettent pas pour nos applications... Mais c'est aussi une tendance qui s'affirme petit à petit et à laquelle à terme, il devrait être difficile d'échapper. Car même si ce n'est qu'un effet de bord, elle nous amène à créer des programmes plus efficaces, qui sont également moins chers à exécuter.

Avoir des informations précises et détaillées sur ce qu’il se passe dans une infrastructure, et sur les applications qu'elle héberge est un enjeu critique pour votre business. Cependant, ça demande du temps, temps qu'on préfère parfois se réserver pour d'autres tâches jugées plus prioritaires. Mais qu'un système plante, qu'une application perde les pédales ou qu'une faille de sécurité soit découverte et c'est la panique à bord ! Alors je vous le demande, qui voudrait rester aveugle quand l'observabilité a tout à vous offrir ?

L'une des forces de Linux est sans conteste son gestionnaire de paquets ; imaginez-vous disposer d'un outil aussi puissant pour déployer vos applications dans Kubernetes...