Dans le sillage de la récente crise CrowdStrike, le vieux débat entre agent et sans-agent refait surface. Un peu comme celui de l'ananas sur la pizza : chacun a un avis tranché, mais la bonne réponse dépend de vos goûts (ou, en l'occurrence, de vos besoins).
Ceux qui me connaissent le savent : je n'adhère pas à la logique du tout est bon ou tout est mauvais. La vie est faite de compromis, et souvent il ne s'agit pas seulement de CE QUE vous faites, mais de COMMENT vous le faites.
C'est particulièrement vrai pour le débat agent contre sans-agent. Si vous pensez qu'il vaut toujours mieux opter pour le sans-agent, vous passez à côté de nombreux bénéfices, notamment en matière de monitoring, d'observabilité et de FinOps. Voici quelques atouts auxquels vous renonceriez :
- Des métriques d'usage détaillées et granulaires : les agents offrent une vision fine des performances système, des applications et des processus.
- Des capacités en temps réel : avec un agent, vous bénéficiez d'un monitoring en temps réel et d'informations instantanées, indispensables pour détecter et résoudre rapidement les incidents.
- Une sécurité renforcée : les agents peuvent chiffrer les données à la source, garantissant une transmission sécurisée.
- De l'efficacité : les agents filtrent et traitent les données localement, et n'envoient au backend que les informations pertinentes.
- De la fiabilité : en supprimant les dépendances critiques au réseau et aux connexions distantes, les agents continuent de collecter des données même en cas de coupure réseau.
Voilà pour le QUOI. Or, je ne suis pas du genre à renoncer facilement à ces bénéfices. Concentrons-nous donc sur le COMMENT et explorons quelques bonnes pratiques pour travailler avec des agents et éviter le prochain incident façon CrowdStrike.
Comprendre ce que fait l'agent et comment il fonctionne
Tous les agents ne se valent pas. Certains sont plus intrusifs, tant par leur consommation de ressources (qui peut peser sur la capacité globale, les performances et les coûts) que par les actions qu'ils exécutent. Prenez le temps de comprendre la technologie sous-jacente et le comportement de l'agent.
Par exemple, les agents basés sur eBPF sont réputés plus sûrs : entre autres garde-fous, ils s'exécutent dans un environnement sandboxé au sein du noyau, passent par un vérificateur avant d'être chargés et disposent d'un jeu d'instructions restreint et bien défini. À cela s'ajoute une communauté solide et active qui maintient et audite cette technologie en permanence.
Stratégie de déploiement
- Approche progressive : déployez les agents par phases, en commençant par les systèmes non critiques et en étendant progressivement la couverture. Cette stratégie vaut aussi bien pour les déploiements initiaux que pour les mises à jour de version.
- Timing : pilotez le processus de déploiement plutôt que de le subir. Évitez les mises à jour automatiques : les imprévus surviennent souvent au pire moment (comme pendant cette démo cruciale que vous préparez depuis des semaines).
Gardez des garde-fous en place
- Limitation des ressources : plafonnez la quantité de ressources qu'un agent peut consommer et hiérarchisez son exécution. Vous éviterez ainsi qu'il n'accapare les ressources au détriment de vos services critiques.
En conclusion, si les solutions sans-agent ont leur utilité, elles ne peuvent égaler la profondeur, les capacités en temps réel, la sécurité, l'efficacité et la fiabilité qu'apportent les agents. En comprenant ce que font les agents, en les déployant de manière réfléchie et en posant les bons garde-fous, vous pouvez exploiter pleinement leur potentiel sans en subir les mauvaises surprises.
N'oubliez pas : la vraie question n'est pas seulement de choisir entre agent et sans-agent, mais de savoir comment vous mettez ce choix en œuvre. Avec la bonne approche, vous profitez du meilleur des deux mondes, sans drame. D'ailleurs, personnellement, j'adore autant la pizza pepperoni que la pizza ananas !