Sulla scia della recente crisi di CrowdStrike, il dibattito storico tra agent e agent-less è tornato d'attualità. Un po' come la questione dell'ananas sulla pizza: tutti hanno un'opinione netta, ma la risposta giusta dipende dai gusti (o, in questo caso, dalle esigenze).
Chi mi conosce sa che non aderisco alla logica del "è tutto buono" o "è tutto cattivo". La vita è fatta di compromessi e spesso non conta soltanto COSA si fa, ma COME lo si fa.
Questo vale in modo particolare per il dibattito agent vs agent-less. Se pensa che scegliere l'agent-less sia sempre la soluzione migliore, sta rinunciando a moltissimi vantaggi, soprattutto sul fronte monitoring, observability e FinOps. Vediamo alcune delle chicche a cui si rinuncia:
- Metriche d'uso approfondite e granulari: gli agent offrono insight dettagliati su performance di sistema, applicazioni e processi.
- Capacità in tempo reale: con gli agent si ottengono monitoring in tempo reale e insight immediati, decisivi per rilevare e risolvere i problemi senza ritardi.
- Sicurezza rafforzata: gli agent possono applicare la crittografia alla fonte, garantendo una trasmissione sicura dei dati.
- Efficienza: gli agent filtrano ed elaborano i dati in locale, inviando al backend soltanto le informazioni rilevanti.
- Affidabilità: eliminando dipendenze critiche da rete e connessioni remote, gli agent continuano a raccogliere dati anche in caso di caduta della rete.
Questo è il "COSA". Ora, non sono tipo da rinunciare facilmente a vantaggi del genere. Con questo in mente, concentriamoci sul "COME" ed esaminiamo alcune best practice per lavorare con gli agent ed evitare il prossimo caso in stile CrowdStrike.
Capire cosa fa l'agent e come funziona
Non tutti gli agent sono uguali. Alcuni risultano più invasivi, sia in termini di consumo di risorse (con impatti su capacità complessiva, performance e costi) sia per le azioni che compiono. Vale la pena dedicare un momento a comprendere la tecnologia sottostante e il comportamento dell'agent.
Ad esempio, gli agent basati su eBPF sono considerati più sicuri perché, tra le altre tutele, girano in un ambiente sandbox all'interno del kernel, superano controlli di verifier prima del caricamento e dispongono di un set di istruzioni limitato e ben definito. A questo si aggiunge una community solida e viva, che mantiene e verifica attivamente questa tecnologia.
Strategia di deployment
- Approccio a fasi: effettui il deployment degli agent in più fasi, partendo dai sistemi non critici per arrivare gradualmente alla copertura completa. Vale sia per i deployment iniziali sia per gli aggiornamenti di versione.
- Timing: sia lei a controllare il processo di deployment, non il contrario. Eviti gli aggiornamenti automatici: gli imprevisti tendono a manifestarsi nei momenti peggiori (per esempio durante quella demo cruciale che sta preparando da settimane).
Mantenere i guardrail attivi
- Limitazione delle risorse: imposti dei tetti alla quantità di risorse che un agent può consumare e ne definisca la priorità di esecuzione. In questo modo evita che l'agent sottragga risorse ai servizi critici.
In conclusione, per quanto le soluzioni agent-less abbiano il loro spazio, non possono garantire la profondità, la reattività in tempo reale, la sicurezza, l'efficienza e l'affidabilità che offrono gli agent. Comprendendo cosa fanno gli agent, distribuendoli in modo strategico e adottando guardrail adeguati, può sfruttarne appieno il potenziale senza cadere vittima di problemi imprevisti.
Ricordi: non si tratta solo di scegliere tra agent e agent-less, ma di come si implementa la propria scelta. Con l'approccio giusto, può godersi il meglio di entrambi i mondi senza drammi. A proposito: adoro sia la pizza al pepperoni sia quella con l'ananas!