Présentation du talk de Fabien Arcellier- OCTO Technology
Avant 10 JVMs, maintenant 300 microservices avec des runtimes
transients. Le nombre de service à assembler pour construire
nos applications augmente.
Le SI se modernise, le monitoring peine à suivre. Que faut-il
repenser ?
Bonjour,
Je suis devant vous aujourd’hui pour vous parler d’observabilité. Ce sujet fait couler beaucoup d’encre depuis 2 ans. Emergence d’initiatives, développement d’outils.
Pourquoi cette question est intéressante ? Illustrer avec les projets
A l’origine de cette réflexion, il y’a un constat. Au cours des dernières années, le nombre de services que nous assemblons pour construire une application augmente.
Une application regroupe des moyens d’interactions exposés à un utilisateur, humain par l’intermédiaire d’IHM ou machine par l’intermédiaire d’API.
Nous pensons que notre industrie suit une voie similaire à ce qu’a suivi l’industrie.
Retour dans le passé. Dans les années 1890, le moteur électrique remplace progressivement le moteur à vapeur dans l’industrie. Cette révolution silencieuse conduit d’un modèle où il y’avait 10 personnes pour gérer un moteur au modèle aujourd’hui où l’on compte plusieurs centaines de moteurs pour un technicien de maintenance.
Qu’est ce qu’un service ? Le concept de service en architecture permet de nommer de manière unique une relation client fournisseur, donc de la décrire.
un service regroupe plusieurs unités d’exécution qui expose des capacités par l’intermédiaire d’un contrat de service
Des modalités d’exposition : Le contrat de service définit au mieux les modalités d’exposition tel que les protocoles d’échanges, les ressources et opérations exposés, ainsi que leurs attributs non fonctionnels comme la performance, résilience, … que respecte le service
Des prérequis client : Le contrat de service définit un ensemble de prérequis que le client doit fournir pour respecter la qualité défini dans le contrat de service
Je m’appelle Fabien Arcellier. Je fais partie de la tribu ARCHI chez octo.
Notre rôle en tant que tribu est de travailler avec des équipes pour que leurs applications tirent partie et enrichissent votre système d’information. Pour cela, nous accompagnons métiers, développeurs et ops pour penser des architectures collaboratives et évolutives qui s’intègrent dans des cycles itératifs de plus en plus court.
C’est pourquoi je me tiens devant vous pour parler d’observabilité.
Nous vous proposons une grille de lecture pour expliquer pourquoi l’augmentation du nombre de service est un mouvement de fond
Clarifier le fait qu’un développeur puisse initier et amener des services plus rapidement en production.
standardisation des unités de déploiement
scaffolding natif avec une intégration CI
image autoportante et transférable cross-runtime
building-block sur étagère pour le développement
100% des projets de delivery chez octo sont faits sur un runtime qui offre un gestionnaire de dépendances
Docker est présent dans plus de 60% de nos projets
image autoportante et transférable cross-runtime
Un cout d’activation de zéro
libre-service à la demande
activation instantanée qui autorise des runtimes transients
Des ressources virtuellement illimitée
Management avancé d’accès et d’identité
Try-and-learn
Avec ces 3 facteurs, nous constatons que 3 populations convergent vers une volonté de construire des services autonomes
Titre à revoir
Peut être expliquer ce que j’entend par flexible et fragile
Le périmètre de chaque service est identifiable. La collaboration d’unité d’exécution autonome complique l’investigation lors des défaillances et dilue les responsabilités aux interfaces.
La relation entre usage, fonction et ressources s’étiole à cause des mécanismes de scalabilité
Quelques modes de défaillance propres aux architectures distribuées
interfaces permissives
défaillance invisible
défaillances réseaux
régime transitoire
….
Un système collaboratif est capable d’évoluer et d’offrir des mécanismes de résilience grâce à l’autonomie des services qu’il offre.
L’impact de la modification d’un service mutualisé est difficile à mesurer.
La collaboration d’unité d’exécution autonome complique l’investigation en cas d’incidents
auditabilité : capacités à lire l’histoire d’un service, exemple les logs d’accès permettent d’auditer l’usage d’un endpoint web
télémétrie : capacités à mesurer l’usage d’un service, exemple les IO Read permettent de mesurer le volume chargé du disque vers la mémoire
trace : capacités à retracer les interactions entre composants dans le temps sur une opération dans un système fermé
l’absence de cartographie d’exécution bout en bout complique la navigation entre les dépendances
L’absence de time-machine élaborée pour explorer les métriques avec leur contexte complique l’investigation dans le passé
l’absence de logs centralisés complique le drill down au niveau d’un service
Le log management est une démarche pour capturer des événements du SI, souvent en provenance des logs pour pouvoir visualiser une activité, analyser des tendances, voir prédire des comportements anormaux.
Exemple
Ajouter une phrase pour l’exception management
Les endpoints de télémétrie offre un instantannée de l’état d’un système sous la forme de compteur ou de gauge. Ce modèle d’exposition offre l’avantage de découpler la production de métrique et leurs historisations. Un instantannée se présente sous la forme d’une page avec une liste de métriques.