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.
Dans le domaine de l'observabilité d'applications distribuées ou de services distribués pour être plus exacts, Google a souvent eu une longueur d'avance. Notamment parce que Google a rapidement été confronté à une considérable mise à l'échelle de ses services (conteneurisés), mais aussi par souci d'optimisation des ressources et de la réduction de leurs coûts. Rien d'étonnant donc à ce qu'il soit à l'origine de concepts tels que les traces distribuées et le continuous profiling. Et si vous n'avez pas encore entendu parler du continuous profiling, alors cette introduction devrait vous mettre l'eau à la bouche, car c'est un outil qui permet de réduire la latence de vos applications, tout en en optimisant leurs coûts !
1. L'histoire du continuous profiler
Le profiling ne date pas d'hier. C'est un concept qui nous vient du début des années 1970 quand les applications tournaient encore sur des mainframes. Son évolution au travers d'outils comme gprof ou...
- Accédez à tous les contenus de Connect en illimité
- Découvrez des listes de lecture et des contenus Premium
- Consultez les nouveaux articles en avant-première