Il problema del flusso di lavoro degli sviluppatori di cui nessuno parla

Lo sviluppo software moderno non è mai stato così potente.

Oggi uno sviluppatore che lavora da casa ha a disposizione una potenza di calcolo, un numero di framework, servizi cloud, database e livelli di automazione superiori a quelli di cui disponevano interi reparti di ingegneria vent'anni fa. L'ecosistema degli strumenti si è espanso a dismisura, l'intelligenza artificiale è entrata a far parte dei flussi di lavoro quotidiani e la creazione di infrastrutture globali richiede ormai pochi minuti anziché mesi.

Eppure, nonostante tutti questi progressi, molti team di ingegneri dedicano ancora una quantità sorprendente di tempo a lottare con i propri strumenti.

Non perché gli strumenti siano scadenti. La maggior parte di essi è eccellente nel risolvere singoli problemi. La sfida sta nel fatto che i moderni flussi di lavoro di sviluppo raramente riguardano un unico problema.

Uno sviluppatore che indaga su un problema in produzione potrebbe iniziare esaminando i log dell’applicazione su un server remoto. Ciò porta a una query sul database. La query rivela dati inaspettati. Lo sviluppatore deve quindi ispezionare la risposta di un’API, convalidare i payload, tracciare una chiamata di servizio, esaminare una migrazione, confrontare gli schemi tra gli ambienti e, forse, implementare una correzione.

Ogni attività, presa singolarmente, è semplice.

L’attrito si manifesta nelle transizioni.

Un’applicazione per SSH. Un’altra per i database. Un’altra ancora per il test delle API. Un’altra per il trasferimento dei file. Un’altra per i tunnel. Un’altra per la documentazione. Un’altra per la visibilità della distribuzione.

Alla fine della giornata, gli ingegneri hanno dedicato tanto tempo a passare da uno strumento all’altro quanto a risolvere il problema vero e proprio.

Nel settore si parla spesso di ridurre la complessità all’interno dei sistemi. Molta meno attenzione viene invece dedicata alla riduzione della complessità tra i sistemi.

Questa distinzione è importante.

Il costo del cambio di contesto

Il cambio di contesto è diventato uno dei fattori che più sottovalutati che riducono la produttività nell’ingegneria del software.

Il problema non è semplicemente l’apertura di più applicazioni. Ogni strumento introduce la propria interfaccia, il proprio modello di autenticazione, le proprie convenzioni di flusso di lavoro, la propria terminologia, le proprie scorciatoie e i propri presupposti operativi.

Un ingegnere che sta indagando su un problema relativo a un database potrebbe passare da una console cloud a un client SSH, poi a un client di database, quindi a una piattaforma di test delle API, prima di tornare infine a un IDE. Ogni transizione costringe il cervello a ricaricare il contesto.

Il costo si accumula nel tempo.

Diventa particolarmente evidente durante la risposta agli incidenti, quando i team sono sotto pressione e ogni minuto è fondamentale. Un problema di produzione raramente si presenta ben circoscritto entro i confini di un singolo sistema. Più spesso coinvolge contemporaneamente database, infrastruttura, API, servizi di autenticazione, livelli di archiviazione e ambienti di distribuzione.

Purtroppo, l’ecosistema degli strumenti tende ancora a trattare questi ambiti come mondi separati.

Gli sviluppatori, invece, no.

Infrastruttura, dati e API non sono più discipline separate

C’era un tempo in cui i team di infrastruttura gestivano i server, gli amministratori di database gestivano i database e gli sviluppatori si concentravano principalmente sul codice delle applicazioni.

Quei confini sono in gran parte scomparsi.

Oggi ci si aspetta spesso che uno sviluppatore comprenda l’infrastruttura cloud, le reti, i database, i controlli di sicurezza, l’automazione della distribuzione, l’orchestrazione dei container, l’osservabilità e i flussi di lavoro assistiti dall’intelligenza artificiale.

L’ascesa dell’ingegneria delle piattaforme e del DevOps ha accelerato questa convergenza.

Di conseguenza, gli sviluppatori si muovono ogni giorno sempre più spesso tra tre ambiti operativi:

Infrastruttura. Dati. Connettività.

L’infrastruttura fornisce l’accesso agli ambienti. I dati offrono una visione di ciò che sta realmente accadendo. Le API collegano i servizi tra loro.

Quando qualcosa va storto, gli sviluppatori raramente indagano su una sola di queste aree in modo isolato. Indagano su tutte e tre.

Un esempio concreto

Immaginiamo che un cliente segnali che gli ordini falliscono in modo intermittente all’interno di una piattaforma di e-commerce.

Il primo istinto potrebbe essere quello di esaminare i log dell’applicazione. Un ingegnere apre una sessione SSH sul server di produzione e inizia a esaminare l’attività del sistema.

Non emerge nulla di evidente.

L’attenzione si sposta sul database. L’interrogazione della tabella degli ordini rivela diverse transazioni incomplete. Ulteriori indagini mostrano che i record vengono creati ma non elaborati completamente.

A questo punto l’attenzione si sposta nuovamente.

Lo sviluppatore deve esaminare l’API responsabile dell’invio di tali ordini. Le richieste vengono riprodotte. Le risposte vengono convalidate. Le intestazioni vengono controllate. Vengono esaminati i token di autenticazione. Vengono generati e confrontati dei payload di test.

Alla fine emerge la causa principale.

Una sottile modifica al contratto dell’API ha introdotto un caso limite inaspettato che si è propagato attraverso lo stack dell’applicazione e alla fine si è manifestato sotto forma di record di database incompleti.

Notate un aspetto importante. Il problema non è mai stato puramente un problema di infrastruttura. Non è mai stato puramente un problema di database. Non è mai stato un problema puramente legato alle API. Era un problema di flusso di lavoro operativo. E questo sta diventando sempre più comune.

L’ascesa degli strumenti operativi

La prossima generazione di strumenti per sviluppatori si concentrerà probabilmente meno su funzionalità isolate e più sulla continuità operativa.

Gli sviluppatori non hanno necessariamente bisogno di più strumenti. Hanno bisogno di meno interruzioni del flusso di lavoro.

È qui che le piattaforme operative diventano interessanti. Anziché trattare database, infrastruttura e API come attività indipendenti, gli strumenti moderni possono iniziare a riconoscere che questi sistemi sono parti profondamente interconnesse dello stesso flusso di lavoro.

Questa filosofia è alla base di Datara Studio.

DataraDB: comprendere il livello dei dati

DataraDB è stato sviluppato partendo da una semplice osservazione. Le applicazioni moderne generano più dati che mai, ma comprenderli rimane spesso sorprendentemente difficile.

Gli sviluppatori lavorano abitualmente con PostgreSQL, MySQL, SQL Server, Oracle, SQLite, Redis e MongoDB. Confrontano schemi, esaminano le migrazioni, risolvono problemi di prestazioni, generano documentazione e utilizzano sempre più spesso l’intelligenza artificiale per accelerare lo sviluppo delle query.

DataraDB integra questi flussi di lavoro in un ambiente moderno e ad alte prestazioni che si concentra sul lavoro pratico quotidiano di ingegneria, piuttosto che limitarsi a fungere da browser di database.

L’obiettivo non è semplicemente eseguire query. L’obiettivo è comprendere i sistemi. Perché quando qualcosa si guasta, spesso è il database a rivelarlo per primo.

DataraSSH: Accesso al livello dell’infrastruttura

Naturalmente, i dati raramente esistono in modo isolato. Le applicazioni risiedono su server, container, piattaforme cloud, macchine virtuali e ambienti edge.

Ciò significa che gli sviluppatori hanno ancora bisogno di un accesso affidabile all’infrastruttura. SSH rimane una delle tecnologie più importanti nell’informatica moderna, poiché l’accesso remoto sicuro continua a essere alla base dei flussi di lavoro operativi praticamente in ogni settore.

DataraSSH è stato creato per modernizzare tale esperienza. Anziché considerare SSH come un’utilità autonoma, DataraSSH è progettato come uno spazio di lavoro operativo pratico per sviluppatori e team di infrastruttura che necessitano di connessioni sicure, inoltro delle porte, trasferimento di file, host di passaggio e gestione dell’ambiente senza inutili complessità.

L’infrastruttura dovrebbe essere di facile accesso. Non difficile da navigare.

DataraAPI: il completamento del flusso di lavoro

Prossimamente sulla piattaforma Datara Studio sarà disponibile DataraAPI.

Se DataraDB aiuta gli sviluppatori a comprendere i dati e DataraSSH li aiuta ad accedere all’infrastruttura, DataraAPI è progettata per aiutarli a comprendere la connettività.

Le applicazioni moderne comunicano sempre più spesso tramite API. Queste alimentano integrazioni, servizi interni, ecosistemi di partner, applicazioni mobili, piattaforme SaaS, sistemi di intelligenza artificiale e flussi di lavoro di automazione.

Tuttavia, il collaudo, la convalida, la documentazione e la gestione del ciclo di vita delle API rimangono spesso scollegati dagli ambienti e dai database con cui interagiscono.

DataraAPI mira a avvicinare questi flussi di lavoro. Questo perché gli sviluppatori raramente analizzano le API senza finire per interagire con l’infrastruttura o i dati. E raramente analizzano l’infrastruttura o i dati senza finire per interagire con le API.

La piattaforma per i flussi di lavoro operativi

Presi singolarmente, DataraDB, DataraSSH e DataraAPI risolvono problemi ben noti. Insieme, riflettono un cambiamento più ampio in atto nell’ingegneria del software.

Il settore si sta orientando verso flussi di lavoro operativi piuttosto che verso categorie di strumenti isolate. Gli sviluppatori non si limitano più a scrivere codice. Si muovono all’interno di sistemi interconnessi che abbracciano infrastrutture, database, API, ambienti cloud, confini di sicurezza e flussi di lavoro sempre più assistiti dall’intelligenza artificiale.

Gli strumenti che avranno successo nei prossimi anni saranno probabilmente quelli che riconosceranno queste realtà e ridurranno l’attrito tra di esse. Non perché gli ingegneri abbiano bisogno di più funzionalità, ma perché hanno bisogno di maggiore continuità.

Il futuro della produttività degli sviluppatori potrebbe non consistere nel creare, in modo isolato, client di database migliori, client SSH migliori o strumenti API migliori. Potrebbe invece consistere nel creare un flusso di lavoro operativo migliore che abbracci tutti e tre questi aspetti.