Di recente ho avuto l'opportunità di confrontarmi con Miha Kralj, IBM Global Senior Partner, Microsoft Practice, per discutere della rapida evoluzione dell'informatica. La nostra conversazione ha riguardato una serie di argomenti, tra cui il data storage, l'infrastruttura IT, gli integratori di sistemi e la crescita della tecnologia cloud. Un tema emerso durante la nostra discussione è stato il cambiamento dei ruoli degli sviluppatori di software e dei professionisti delle infrastrutture e la fine dei silo tradizionali nell'IT. Di seguito sono riportati i punti salienti di questa parte della nostra conversazione.
Matthew Finio: Come sta cambiando il rapporto tra sviluppatori e professionisti dell'infrastruttura?
Miha Kralj: Il lavoro nel campo dello sviluppo è cambiato con l'avvento del "software-defined everything", come software-defined networking, software-defined storage e software-defined computing.
In passato, c'erano gli addetti alle infrastrutture da una parte e gli addetti allo sviluppo software dall'altra, e i due gruppi si parlavano a malapena. Uno si occupava di tutti gli asset e impianti sottostanti, l'altro della codifica e di trasformare i sogni in realtà.
Ora, tutto questo sta crollando. Nessuna delle due parti è preparata per l'era in cui viviamo. E nessuna delle due ha una vera comprensione della sicurezza, che è un ulteriore elemento da considerare. Devono iniziare a imparare l'una dall'altra, e questo è difficile per entrambe.
È un po' come nel libro Chi ha spostato il mio formaggio?: nessuna delle due parti si sente a proprio agio se proviene dal vecchio mondo tradizionale. Le giovani generazioni che sono cresciute con Gmail e YouTube vivono in quel nuovo mondo combinato. Ma chi proviene dall'infrastruttura tradizionale o dallo sviluppo software fatica, perché non ha avuto modo di imparare "l'altro lato" nelle prime fasi della propria carriera.
MF: Quindi, sia gli sviluppatori sia i professionisti dell'infrastruttura dovrebbero rivalutare le proprie mansioni e responsabilità?
MK: Esattamente. Gli sviluppatori non dovrebbero più pensare di essere solo sviluppatori di applicazioni. Chi si occupa di infrastrutture non dovrebbe più pensare di essere solo addetto alle operazioni. Oggi valgono i modelli di collaborazione dei team di ingegneria di prodotto, dove ognuno può intervenire, all'occorrenza, anche nelle attività degli altri. Ci sono ancora specializzazioni, ma uno sviluppatore, quando necessario, deve essere in grado di intervenire e scrivere alcuni script Terraform, che tradizionalmente sarebbero un'attività molto incentrata sull'infrastruttura.
Quindi, quando chiedi a qualcuno che lavoro fa, non dovrebbe rispondere "Sono uno sviluppatore di software" o "Mi occupo di infrastrutture/operazioni". Queste persone costruiscono un prodotto o aiutano a creare un servizio che non verrà mai lanciato senza tutti quei pezzi messi insieme correttamente. Tutti devono comprendere l'intera catena, l'intero ciclo di vita, dall'inizio alla fine.
MF: Hai menzionato Terraform. Quali sono gli altri concetti relativi all'infrastruttura che gli sviluppatori devono apprendere?
MK: Gli sviluppatori spesso non capiscono bene come funziona davvero l'infrastruttura sottostante e cosa può essere durevole o effimero.
Se, ad esempio, si apporta una qualunque modifica all'host, al container o al componente serverless che esegue qualcosa, quella modifica persisterà quando quel componente, quella macchina virtuale passerà a qualcos'altro? Quindi, il concetto di sistemi che memorizzano i loro stati altrove, di sistemi senza stato, è uno dei capisaldi che gli sviluppatori possono iniziare a capire. Come si fa a rendere un sistema scalabile all'infinito? Come si creano sistemi molto durevoli ed elastici? Tutti questi concetti architettonici sono implementati nel software, ma di fatto si basano sui modelli di infrastruttura.
Inoltre, è importante comprendere tutti i modelli di sicurezza utili a creare una superficie minima di attacco nel codice, riducendo al massimo le possibilità di vulnerabilità. E come comunicare correttamente con un servizio remoto. Vuoi scrivere un microservizio "loquace" che invia centinaia di piccole richieste al secondo? Oppure preferisci raggruppare le richieste in pacchetti più grandi da inviare meno frequentemente?
Sono decisioni molto importanti che ogni sviluppatore di software deve prendere, ma non capiranno perché le stanno prendendo se non capiscono cosa sta succedendo dietro le quinte: come funzionano i sistemi effettivi. Questa comprensione del sistema dal basso verso l'alto è fondamentale. Lo sviluppatore deve scrivere codice pulito e ben strutturato, che non sovraccarichi il sistema, non blocchi il database e non generi comportamenti indesiderati.
Se torniamo a 20 o 30 anni fa, avevamo una professione dedicata all'ottimizzazione delle query al database per il numero minimo di cicli richiesto dalla CPU, la quantità minima di blocco dei dati. Gran parte di quella conoscenza arcana è andata perduta. Ma è comunque molto importante capire come creare un sistema ad alte prestazioni e come creare un sistema ottimizzato in termini di costi. Tutte queste lezioni non dovrebbero essere dimenticate.
Potresti pensare: "Eh, ma siamo nel 2025, vecchio mio! Il mondo moderno è totalmente diverso. Non hai idea!" Ebbene, siamo stati noi a costruire questo mondo moderno, e ora siamo qui per aiutare i nuovi sviluppatori e professionisti dell'infrastruttura a usarlo nel modo più efficiente possibile.
MF: Puoi descrivere alcuni dei modi in cui gli sviluppatori possono utilizzare strumenti Infrastructure as Code per migliorare il loro workflow?
MK: Sì. Un buon esempio è che uno sviluppatore può creare un workflow adeguato per il proprio codice facendo in modo che venga automaticamente testato, compilato e impacchettato ogni volta che crea un pezzo di codice e ne esegue il commit in un repository. Gli sviluppatori non dovrebbero aver bisogno di un addetto alle infrastrutture che lo faccia per loro. Creare un buon script YAML su GitHub è un'attività Infrastructure as Code che ogni sviluppatore può ottimizzare per rendere quel processo il più efficiente possibile.
Ad esempio, uno sviluppatore non ha bisogno di eseguire il packaging completo, la validazione completa e i test completi se sta lavorando solo sul ramo di sviluppo. Quel sviluppatore può dire: "Ehi, sono sul ramo di sviluppo, posso ignorare tutte quelle 20 attività che sono pensate solo per il ramo di produzione".
Ma se sei in produzione, devi attivare tutta una serie di automazioni, avviare la macchina che effettuerà la verifica completa di sicurezza e la validazione del codice, e così via. Tutte queste piccole decisioni influenzano la velocità con cui si completa la compilazione e si vedono i risultati dopo aver inviato il codice: ogni sviluppatore dovrebbe essere in grado di modificare gli script di infrastruttura come codice, adattandoli al proprio workflow.
È come quando quegli stessi sviluppatori mettono a punto il proprio ambiente di sviluppo integrato. Preferiscono i propri font, colori, scorciatoie da tastiera e tutto il resto. Allo stesso modo, dovrebbero poter configurare i propri workflow, ovvero cosa succede dopo il commit del codice. Tutto questo è conoscenza che deriva dall'Infrastructure as Code (IaC).
MF: Quali cose specifiche dovrebbero capire i professionisti dell'infrastruttura sullo sviluppo di app oggi?
MK: L'Infrastructure as Code (IaC) comporta il fatto che gli addetti alle infrastrutture diventino dei programmatori. L'infrastruttura è composta da script, da dati, da codice, il che significa che lo script o il codice dell'infrastruttura deve seguire lo stesso ciclo di vita dello sviluppo software di qualsiasi codice scritto da sviluppatori:
Deve essere trattato esattamente nello stesso modo. I classici addetti alle infrastrutture non capivano questo aspetto o non erano in grado di farlo. Gli addetti alle infrastrutture sanno configurare cose, fare clic con il mouse e forse sanno scrivere alcuni script Bash o qualcosa del genere.
Ma oggi ci si aspetta che loro siano dei veri e propri programmatori delle infrastrutture. Devono conoscere Git. Devono capire come eseguire la scansione di sicurezza dei loro asset Infrastructure as Code. I loro asset devono essere sottoposti a un adeguato controllo delle versioni e saranno sottoposti a revisione paritaria. Gli addetti alle infrastrutture devono sapere cosa sia una richiesta pull. Questi sono i termini e le attività standard che ogni sviluppatore di software conosce.
Gli addetti alle infrastrutture devono diventare degli ingegneri full stack. E gli ingegneri full stack sono difficili da formare e difficili da trovare. C'è una carenza di persone che conoscono il processo dall'inizio (come scorrono i pacchetti, come funziona la rete e come funziona il kernel del sistema operativo) alla fine. Ad esempio, come faccio a scrivere più dipendenze software? A utilizzare pacchetti open source o proprietari? Come si scrive codice asincrono? Queste sono tutte domande che hanno a che fare con lo sviluppo software puro e semplice. Due settori enormi compressi in uno. Ma mancano la gestione del cambiamento, la riqualificazione e il miglioramento delle competenze dei talenti.
MF: Se la riqualificazione e il miglioramento delle competenze sono una tale sfida, come possono i professionisti delle infrastrutture rimanere aggiornati sulle tecnologie e sulle tendenze nel campo dello sviluppo?
MK: Ormai non esistono più figure specifiche per l'infrastruttura o per lo sviluppo; tutto si è fuso in un unico ambito. Tutti stanno imparando queste nuove tendenze, i cambiamenti nel ciclo di vita dello sviluppo software e, soprattutto, le novità introdotte dall'AI.
Man mano che lo sviluppo diventa nativo dell'AI, sia gli addetti alle infrastrutture che gli sviluppatori di applicazioni devono impararlo. Tutti soffrono l'effetto della FOMO e pensano di essere già rimasti indietro. Hanno appena imparato a fare prompt engineering e ora gli viene detto che devono imparare a scrivere agenti con Semantic Kernel o qualcosa del genere.
Le persone devono aiutarsi a vicenda, devono trovare il giusto equilibrio. Quanto tempo occorre dedicare per rimanere aggiornati e sapere di avere ancora un certo vantaggio? Prima era il 5%, ora è il 10%. L'AI generativa è utile in questo senso. Ma il rapporto tra il tempo necessario per imparare questi concetti e il tempo impiegato per applicarli e creare qualcosa che offra valore all'azienda o in termini di IT tende sempre di più verso l'apprendimento.
MF: E prima di concludere, quali sono alcuni aspetti chiave che gli sviluppatori e i professionisti dell'infrastruttura dovrebbero tenere a mente sulle applicazioni moderne?
MK: Non ci sono più attività suddivise. Le applicazioni moderne hanno un'infrastruttura quasi integrata. Per esempio, uno sviluppatore moderno scrive il codice e richiede la creazione di un container. Non c'è più una persona dedicata all'infrastruttura che crea il container per lui. Alcuni lavori richiedono maggiormente competenze infrastrutturali ma anche sviluppo, mentre altri richiedono più sviluppo software ma anche conoscenze e accesso all'infrastruttura.
Quindi, ciò che i professionisti dell'infrastruttura devono considerare è diventare sviluppatori di software. E lo stesso vale per gli sviluppatori di software, che devono diventare professionisti dell'infrastruttura.
Quei ruoli non sono distinti, si fondono. È come dieci anni fa o più, quando ogni centro di sviluppo software professionale aveva sviluppatori e tester. Nessuno parla più dei tester perché questi due ruoli si sono fusi. Lo stesso tipo di compressione e fusione dei ruoli sta accadendo ora, ma questa volta tra sviluppatori e addetti alle infrastrutture.
Reinventa la modalità di lavoro grazie al collegamento tra trasformazione aziendale e tecnologica per sbloccare l'agilità aziendale.
Reinventa e modernizza le risorse umane con l'AI al centro per ottenere risultati aziendali migliori e sbloccare il potenziale dei dipendenti.
Migliora le prestazioni finanziarie e sblocca il valore aziendale con servizi end-to-end che integrano analisi dei dati, AI e automazione in tutti i processi fondamentali.