Ciao, sono Valerio Barbera, founder e CTO di Inspector.dev, partner di CTO Mastermind.

In questo articolo voglio condividere con te la mia esperienza sul perché dovresti sempre preferire strumenti di monitoraggio code-driven a quelli infrastructure-driven.

Comprendere questa differenza ti aiuta a organizzare meglio il tuo team, aumentare la velocità di rilascio e scoprire i problemi prima ancora che siano i tuoi clienti ad accorgersene.

In quanto CTO di un prodotto SaaS che fornisce un servizio di Code Execution Monitoring, ho l’opportunità di discutere questo argomento ogni settimana, con aziende e reparti IT di tutte le dimensioni: a causa di problemi tecnici nei sistemi software, ho visto dispute clienti arrabbiati, addirittura contratti cancellati, cause legali e molti altri disastri.

Nella maggior parte dei casi il team di sviluppo semplicemente non era nella condizione di svolgere il proprio lavoro correttamente, nei costi e tempi definiti per portare a termine il progetto.

In questo articolo ti descrivo la causa principale che ho individuato grazie alla mia esperienza sul campo, in modo che tu possa individuare questi problemi anche nella tua organizzazione e metterti al sicuro il prima possibile.

Perché il monitoraggio è indispensabile

Il momento in cui gli sviluppatori software sentono il bisogno di monitorare le loro applicazioni coincide spesso con l’inizio di un progetto di medie/grandi dimensioni.

La ragione è semplice: quando il software diventa complesso o è utilizzato da clienti ad alto valore per l’azienda, i bug e le interruzioni di servizio diventano costosi.

Il monitoraggio è una parte del lavoro quotidiano degli sviluppatori: serve a evitare problemi tecnici inaspettati e quindi a mantenere i clienti soddisfatti del servizio ricevuto il più a lungo possibile. Il che naturalmente significa un flusso di revenue costante per il tuo business.

Strumenti di monitoraggio infrastructure-driven

Le piattaforme di monitoraggio più conosciute (come DataDog, Dynatrace, New Relic, AppDynamics e altre) richiedono di essere installate e configurate a livello di server o sull’infrastruttura IT in generale, con cui gli sviluppatori odiano avere a che fare.

Gli sviluppatori, invece, amano concentrarsi sul codice.

Le piattaforme menzionate qui sopra richiedono molta assistenza tecnica o addirittura delle figure ingegneristiche dedicate alla loro configurazione e mantenimento.

Per questo tendono ad essere troppo complesse e costose per team di sviluppo di piccole e medie dimensioni che hanno necessità di rimanere agili e focalizzati sulla parte di sviluppo applicativo.

Avere a che fare con le infrastrutture è un problema per gli sviluppatori per due motivi:

1) Work Overload

Gestire le infrastrutture IT è una professione a sé. Richiede molte competenze verticali sull’ambiente server, networking e security, e coinvolge tecnologie complesse (es. Kubernetes).

Per esigenze semplici gli sviluppatori tendono ad affidarsi a piattaforme per automatizzare il provisioning dei server, come dashboard di cloud hosting, PaaS o simili, per evitare questa preoccupazione.

Ma in organizzazioni medio-grandi o quando l’azienda inizia a scalare potrebbe essere necessario avere un team dedicato principalmente alla gestione dell’infrastruttura in modo da dare agli sviluppatori software più tempo libero per lavorare al codice ed alle features dell’applicazione.

2) Scarso controllo

Sia che tu stia usando piattaforme di automazione per i server o tu abbia un team esterno che se ne prende cura, tutto quello che configuri a livello server è fuori dal ciclo di vita dello sviluppo del software: per gli sviluppatori è l’inizio della perdita della loro autonomia rispetto ad altri team.

All’interno della tua organizzazione ogni area ha i propri strumenti di monitoraggio specifici:

• IT Operation;
• Software development;
• Cyber Security;
• Sales & Marketing;
• Administration.

Tool che funzionano in un contesto potrebbero dimostrarsi un collo di bottiglia in un altro!

L’errore che spesso si fa è di accorpare “IT Operation” e “Software development” cercando strumenti che vadano bene per tutto il reparto tecnico, a discapito degli sviluppatori in questo caso.

E quindi, poiché gli agenti di monitoraggio sono installati sulle infrastrutture e la condivisione dei tool tra team diversi non è mai facile, invece di continuare a dipendere dal team infrastrutture per qualsiasi configurazione, gli sviluppatori continuano a fare affidamento sui log per monitorare le proprie applicazioni manualmente.

E non c’è niente di peggio di un processo così critico come quello di monitoraggio portato avanti con abitudini e processi manuali.

Molte segnalazioni di guasti e malfunzionamenti arriveranno inevitabilmente dai clienti prima che gli sviluppatori ne siano a conoscenza, impiegando ore o giorni per risolvere.

Strumenti di monitoraggio code-driven

Gli strumenti di monitoraggio code-driven, invece, forniscono una libreria software che puoi installare come dipendenza dell’applicazione e usarla come ogni altra libreria da strumento a supporto dello sviluppo.

L’idea alla base degli strumenti code-driven è di creare un ambiente di monitoraggio appositamente pensato per lo sviluppatore, evitando ogni installazione e configurazione a livello server.

Questa differenza tecnica (fare affidamento su una libreria software anziché su un agente a livello di server) ha molte implicazioni sulla capacità degli sviluppatori di identificare rapidamente bug e colli di bottiglia all’interno delle applicazioni, molto prima che diventino disservizi.

Grazie a uno strumento che può essere installato, configurato e personalizzato liberamente, senza dipendere da alcun team esterno, gli sviluppatori saranno in grado di identificare e risolvere i problemi nelle applicazioni più velocemente:

• Senza doversi interfacciare con altri team;
• Senza infiniti scambi di email o tickets;
• Senza ritardi per i clienti.

I clienti pagano per “non avere problemi”: per questo assicurarsi che il team di sviluppo software sia in grado di lavorare in modo rapido e indipendente è fondamentale. Il risultato?

• Meno segnalazioni di bug;
• Fix più veloci;
• Clienti più felici.

Per diversi mesi ho condiviso la nostra idea su Inspector come strumento di monitoraggio code-driven, tenendo conferenze in occasione di eventi della community italiana di PHP e discutendo con altri CTO. In questa pagina ho raccolto le recensioni degli sviluppatori che utilizzano Inspector nel loro lavoro quotidiano: https://www.inspector.dev/testimonials

Inspector è partner di Axelerant: richiedi una prova gratuita.

Inspector è partner di CTO Mastermind e fa parte della rete di aziende innovative scelte dal CTO Mastermind e consigliate dalla community.

Per la community e per chi ha letto questo post, è stato creato un link di referral specifico che ti permetterà di avere una prova gratuita e 80.000 transazioni mensili incluse.

Per ottenerle, clicca qui sotto e registra il tuo account su Inspector!