Benvenuti a un altro episodio delle pillole di conoscenza Microsoft su M365FM, sono il vostro conduttore Mirko P. L'argomento di oggi è qualcosa di cui quasi tutti hanno sentito parlare, ma che pochi comprendono davvero, la platform engineering. Avrete probabilmente sentito parlare di DevOps, l'idea che sviluppatori e team operativi lavorino insieme senza problemi, ma lungo il percorso quella promessa è diventata complicata. Gli sviluppatori hanno finito per fare lavoro operativo e qui il sistema si è robo. Alla fine di questo episodio capirete cosa è andato storto con DevOps, cos'è effettivamente una piattaforma per sviluppatori interna, come i Golden Path offrano i team una strada chiara da seguire perché i team di ingegneria più brillanti ne stiano già costruendo una. Il caos è lasciato da DevOps. Torniamo a dove tutto è iniziato. DevOps era un'ottima idea con un obiettivo semplice, abbattere i muri tra sviluppatori e operazioni.

Basta lanciare il codice oltre il muro, sperando che tutto vada bene. Shift-Left, spostare i test, la sicurezza e le operazioni all'inizio del processo. Consegni più rapide, meno passaggi di consegni, maggiore responsabilità. Sulla carta sembrava perfetto. Nella pratica qualcosa è andato storto. Lo Shift-Left non ha solo spostato le responsabilità, le ha accumulate. Lo sviluppatore che prima scriveva codice apriva un ticket e ora gestisce infrastruttura, sicurezza, monitoraggio, Kubernetes, pipeline CI, CCD, gestione dei segreti e circa 15 servizi cloud di cui non aveva mai sentito parlare prima. Una sola persona gestisce tutto questo mentre continua a sviluppare il prodotto. Ecco come appare nella vita reale. Un team vuole attivare un nuovo ambiente per testare una funzionalità. Prima di DevOps apriva un ticket e aspettavano. Dopo DevOps se ne occupano da soli, che in teoria suona bene.

Ma ora devono scrivere moduli Terraform, configurare un cluster Kubernetes, impostare regole di rete, collegare il monitoraggio, capire la gestione dei segreti e assicurarsi che le politiche di sicurezza siano applicate. Ciò che prima era un ticket che richiedeva, ora qualcun altro, richiede tre giorni del tempo di uno sviluppatore. Tre giorni in cui non scrivono codice per i prodotti. Lottano con file YAML e cercano di capire perché il bilanciatore del carico non in strada correttamente trova. Il carico mentale qui è enorme. Ogni team finisce per costruire le proprie pipeline, script di distribuzione e dashboard di monitoraggio. E siccome tutti sono al limite si prendono delle scorciatoie. La sicurezza viene tralasciata perché la scadenza è venerdì. Le fatture del cloud raddoppiano senza che nessuno se ne accorga perché nessuno si è ricordato di spegnere l'ambiente di test. Quando qualcosa si rompe alle 2 del mattino, lo sviluppatore che l'ha costruito è l'unico che può ripararlo.

Questo non è sostenibile ed ecco perché è più importante che mai. La complicità del cloud continua a crescere. Ogni anno ci sono più servizi, più strumenti, più decisioni da prendere. Oggi gli strumenti di programmazione basati su AI permettono agli sviluppatori di rilasciare codice più velocemente che mai. 10, 20, persino 30 volte più codice aggiungono. Ma tutto quel codice necessita comunque di infrastruttura, sicurezza e monitoraggio. Più codice senza un sistema migliore significa solo un caos più rapido. Se ti senti soffocare tra YAML e Terraform, non sei il solo. Non è un fallimento personale, è sistemico. Modello ha stravolto il vero significato di platform engineering. Quindi qual è la soluzione? Si chiama platform engineering ed ecco il modo più semplice per pensarci. Questa disciplina crea uno strato interno che assorbe la complessità per gli sviluppatori. Immagina di entrare in un grande edificio per uffici.

Non devi preoccuparti di chi ha accesso a quale piano, quale badge funziona o dove siano le uscite di sicurezza. La reception gestisce tutto questo per te, tu entri e inizi a lavorare. È esattamente ciò che platform engineering fa per i tuoi sviluppatori. Invece di costringere ogni singolo sviluppatore a diventare un esperto di Kubernetes, Terraform, networking e sicurezza, un team di piattaforma centrale crea uno strato che gestisce tutta quella complessità. Lo sviluppatore ha un'interfaccia semplice. Clicca un pulsante, esegue un comando, compila un modulo. La piattaforma si occupa di tutto il resto. Attenzione, questo non è la stessa cosa del DevOps. Il DevOps diceva a ogni team di gestire la propria infrastruttura, ma il platform engineering sostiene che sia la ricetta per i brand. Invece il team di piattaforma fornisce strade asfaltate, modi standard, testati e sicuri per gestire le attività comuni.

Loro costruiscono e mantengono la strada, mentre i team di prodotto ci guidano su. Il risultato principale del platform engineering, chiamato internal developer platform, o IDP in breve, pensalo come un sistema self-service che automatizza tutto quel lavoro ripetitivo. Provisioning dell'infrastruttura, pipeline, chase, CD, controlli di sicurezza, monitoraggio, tutto integrato e standardizzato. Un esempio concreto. Quando uno sviluppatore vuole distribuire un nuovo servizio senza una piattaforma, passerebbe giorni a configurare l'infrastruttura, scrivere pipeline e impostare il monitoraggio. Con un IDP basta cliccare su deploy in un'interfaccia o eseguire un singolo comando. La piattaforma gestisce tutto, provisioning, test, monitoraggio e rilascio, tutto in pochi minuti invece di giorni. Quindi cosa significa questo? Smetti di essere un tuttofare dell'infrastruttura e torni a essere uno specialista del tuo prodotto.

Il tuo lavoro può essere costruire funzionalità importanti per i clienti, invece di cercare di capire perché il tuo file di stato di Terraform sia corovo. Questo è un punto fondamentale. La piattaforma interna per sviluppatori, spiegatemi l'uso. Quindi analizziamo cosa sia effettivamente una internal developer. È il motore che combina tutto in un unico sistema. Le tue pipeline CI, CD, template e infrastruttura, le policy di sicurezza, il monitoraggio e logging. Invece di sei strumenti separati che devi collegare tra loro. Ecco un'analogia. Pensala come cucinare da zero rispetto allo zero di un distributore automatico. Cucinare da zero significa comprare ingredienti, tagliare verdure, dosare spezie, controllare il fornello. Molte decisioni, molti passaggi, molti modi per sbagliare. Un distributore automatico ti dà un risultato premendo solo più se meno decisioni, risultati più rapidi, qualità costante.

E quel distributore automatico? Lo sviluppatore non ha bisogno di sapere come viene fornita l'infrastruttura o dove sono archiviati i segreti. Deve solo premere il pulsante. Cosa c'è dentro quel distributore automatico? I componenti principali sono piuttosto stanti. Template CI, CD per build coerenti, provisioning dell'infrastruttura per la creazione automatica di ambienti, gestione dei segreti affinché le credenziali non circolinano i file di configurazione, e logging con osservabilità integrata per risolvere i problemi senza andare nel panico. Tutto preconfigurato, testato e mantenuto dal team di piattaforma. Ecco un esempio concreto. Uno sviluppatore digita crea nuovo servizio nella riga di comando, clicca un pulsante nel portale. Dietro le quinte l'IDP crea un nuovo repository con la struttura corretta, imposta una pipeline di build che esegue test automaticamente, distribuisce il servizio in un ambiente di sviluppo e aggiunge endpoint di health check con logging.

Tutto questo accade in pochi minuti. Lo sviluppatore non ha mai toccato un file terraform e ne ha configurato un manifesto Kubernetes. Ha solo digitato un comando e ottenuto un servizio on-send. Perché è importante? La coerenza è la ragione principale. Quando ogni team costruisce le proprie pipeline e scrive i propri script di deployment, si finisce con configurazioni uniche e ingestibili. 50 servizi diversi, 50 modi diversi di fare le cose. Quando qualcosa si rompe, nessuno può fare debug, se non la persona che l'ha creato. E se quella persona ha lasciato l'azienda, buona fortuna. Un IDP elimina questo problema facendo sì che ogni servizio segue gli stessi pattern, ogni deployment, usi la stessa pipeline e ogni team ottenga le stesse impostazioni predefinite. Quando qualcosa si rompe, i pattern sono familiari e la soluzione è documentata. Quindi ecco cosa significa per te. Se la tua organizzazione ha 50 team che effettuano deployment in 50 modi diversi, un IDP è la soluzione.

Non significa che i team perdano l'autonomia. Significa che le parti noiose, ripetitive e soggette errori vengono standardizzate, così il lavoro creativo e interessante può variare. È un compromesso che vale la pena fare. Golden Paths la via non una gabbia. Parliamo di Golden Paths. Probabilmente ne avrei sentito parlare, ma di desse no. Un Golden Path è un flusso di lavoro consigliato e precostruito che rende la cosa giusta la più facile da fare. Il tuo team di piattaforma dice ecco come vi suggeriamo di procedere. L'abbiamo testato, funziona e vi sosterremo se qualcosa dovesse rompersi. Nota la parola suggeriamo. I percorsi ideali non sono obbligatori. Gli sviluppatori possono abbandonare il percorso se necessario, ma è l'opzione predefinita rapida e sicuramente. È già attivo, supportato e documentato. Non devi capire tutto partendo da zero. Pensalo come binari ferroviari anziché guardrail.

I guardali ti proteggono quando vai a sbattare. Reagiscono e ti impediscono di finire fuori strada, ma non ti aiutano a guidare. I binari ti guidano dolcemente lungo il percorso così non devi decidere dove svoltare. I percorsi ideali sono i binari. Ti fanno avanzare e non si limitano a salvarti quando fallisci. Ecco dove molti team sbagliano. Costruiscono percorsi ideali per il team di piattaforma, non per gli sviluppatori. Ottimizzano per la purezza architetturale, la conformità, la sicurezza, qualche regola interna che nessuno al di fuori del team di piattaforma capisce. Il risultato sembra ottimo su una lavagna, ma è terribile da usare. Gli sviluppatori trovano soluzioni alternative, l'adozione cala e il team di piattaforma si chiede perché nessuno apprezzi tutto quello sforzo. La soluzione è semplice ma difficile attuare. Servono via d'uscita. Se il percorso non si adatta al caso d'uso di uno sviluppatore, serve una via d'uscita.

Un modo per sovrascrivere un'impostazione predefinita, portare la propria pipeline o uscire completamente dalla piattaforma. Qui viene la parte importante. Quando deviano non è un fallimento, è un feedback. Ogni volta che uno sviluppatore abbandona il percorso ideale ti dice cosa di concreta. O al percorso manca una funzionalità necessaria, o il caso d'uso non vi appartiene affatto, entrambi i segnali sono preziosi. Un buon percorso ideale nella pratica si presenta così. Un team vuole distribuire un nuovo servizio backend. Usano il percorso. Offre loro un repository modello con la struttura corretta, una pipeline CIS-CD standard già testata, logging e monitoraggio integrati, e un rollback con un click in caso di problemi. Il tutto richiede minuti invece di giorni, poiché il team di piattaforma mantiene il percorso se qualcosa si rompe ci pensano loro. Lo sviluppatore non deve diventare un esperto di debug delle pipeline.

Cosa significa per te meno sorpresa? Pubblichi più velocemente perché il percorso è testato. Pubblichi in modo più sicuro perché sicurezza e monitoraggio sono integrati. Pubblichi con sicurezza perché il rollback avviene con un click. Il percorso esiste per aiutarti, non per ostacolarti. Usalo. Ridurre il carico cognitivo. Ecco dove si vede il vero vantaggio. Quando una piattaforma gestisce il lavoro pesante, gli sviluppatori possono finalmente concentrarsi sul codice. Non hanno bisogno di sapere quale versione di Kubernetes in esecuzione. Non devono aggiornare i moduli terraforma ogni volta che un provider cloud cambia una API. Si limitano a scrivere funzionali. Ingegneri di piattaforma assorbano talestità. Decidono cosa gli sviluppatori debbano vedere, cosa debba restare nascosta. Questa è una vera scelta di design, non solo tecnico. Si tratta di capire quali dettagli importino a chi usa la piattaforma e quali siano solo rumore.

Ecco un esempio concreto. Uno sviluppatore che distribuisce un nuovo servizio non si preoccupa di dimensioni dei nodi dei cluster, tipi distanze o soglie di autoscaling. Si preoccupa che il suo servizio funzioni di quanto velocemente risponda. Quindi la piattaforma preconfigura tutto in base all'applicazione. Servizio piccolo ecco la configurazione giusta. Servizio ad alto traffico ecco una configurazione diversa. Lo sviluppatore non fa queste scelte perché non ne ha bisogno. Perché questo è importante? Perché il burnout diminuisce quando gli sviluppatori non devono gestire 15 preoccupazioni diverse contemporaneamente. Alcuni team di piattaforma maturi hanno ridotto il carico cognitivo di quasi la metà. Dal 40 al 50% meno di sovraccarico mentale. È un cambiamento enorme. È la differenza tra uscire dal lavoro con ancora energia e fissare un terminale alle 22 chiedendosi perché la pipeline abbia fallito.

Ecco un avvertimento. Non create illusioni. Alcuni team di piattaforma cadono a trap. Nascondono le impostazioni senza dare agli sviluppatori in modo di capire cosa accada sotto il cofano. Questa non è astrazione. È inganno. E si ritorce contro non appena qualcosa la storta. Gli sviluppatori sbattono contro un muro che non possono vedere improvvisamente la piattaforma sembra una scatola nera che lavora contro l'uomo. Il termine per questo è la strazione perfetta. Nascondi la complessità ma alla fine quella complessità emerge. Un database rallenta. Un deployment fallisce. Una policy di sicurezza blocca qualcosa di imprevisto. E lo sviluppatore non ha un modello mentale di ciò che sta accadendo perché la piattaforma non gliel'ha mai fornito. La trasparenza è importante. Mostrate agli sviluppatori ciò che devono sapere quando ne hanno bisogno. Non nascondete tutto sperando che vada bene. Cosa significa questo per voi?

Meno cambi di contesto e più stato di flusso. Non iniziate la mattina chiedendovi se il cluster Kubernetes necessiti di un aggiornamento. Iniziate lavorando la funzionalità in scadenza la prossima settimana. Il vostro lavoro torna a essere il vostro vero. Trattare la piattaforma come un prodotto. Oggi parliamo di qualcosa che cambia il modo in cui gli strumenti interni funzionano davvero. Molti pensano che un team di piattaforma sia solo un team fra su... E lo è. È un team di prodotto e gli sviluppatori che usano quella piattaforma sono i loro clienti, non persone che aprono il ticket. Questo cambia tutto. Un team di prodotto parla con i propri clienti, scopre cosa causa davvero problemi, dà priorità alle funzionalità in base a bisogni reali, misura l'adozione, non costruisce qualcosa per poi abbandonarlo o continua a iterare. Quindi come è fatto un team di prodotto nella pratica? Non opera come un help desk.

Uno sviluppatore apre un ticket e il team di piattaforma lo gestisce manualmente. Questa non è platform engineering, è solo operation centralizzate con un nome nuovo. Non è scalabile, non riduce il carico cognitivo, sposta solo il collo di bottiglia da un team all'altro. Ecco invece cosa fanno. Misurano le cose giuste. Tempo al primo deploy, velocità di onboarding per i nuovi membri, punteggi di soddisfazione degli sviluppatori. Queste sono le metriche che ti dicono se la piattaforma aiuta davvero le persone o aggiunge solo un altro livello di complessità. Spotify è un buon esempio. Il loro team di piattaforma opera come una vera organizzazione di prodotti. Hanno roadmap, hanno care, parlano con gli sviluppatori di ciò che funziona e ciò che non funziona. Trattano la piattaforma come qualcosa che deve guadagnarsi l'adozione ogni singolo giorno e questa è l'idea principale. Una piattaforma che nessuno usa è solo un progetto che accumula polvere in un angolo.

L'adozione è la convalida definitiva. Se gli sviluppatori scelgono la tua piattaforma invece di costruirsi i propri strumenti, hai fatto centro. Se la evitano nessuna eccellenza tecnica, può rimediare. Cosa significa questo per te? Significa che se stai costruendo una piattaforma, non iniziare con diagrammi di architettura, non iniziare con cluster e Kubernetes o moduli terraforma. Inizia con interviste agli utenti, parla con gli sviluppatori che useranno la tua piattaforma. Scopri cosa causa davvero problemi. Costruisci una cosa che risolva un problema reale, poi itera, e così che costruisci qualcosa che le persone vogliono davvero usare. Perché è proprio ora l'onda dell'IA? Quindi perché ne stiamo parlando proprio ora? Perché non 5 anni fa? La risposta è l'IA. Gli strumenti di codifica IA come GitHub Copilot permettono agli sviluppatori di rilasciare codice a un ritmo mai visto prima. 10 volte, 20 volte più codice al giorno rispetto a quanto fosse possibile solo un paio di anni fa.

Sembra fantastico e lo è. Ma c'è un risvolto. Tu quel codice ha comunque bisogno di infrastrutture. Ha comunque bisogno di sicurezza. Deve comunque essere distribuito, testato e gestito. Più codice senza un sistema migliore non ti rende più veloce. Rende solo il caos più veloce. Se i tuoi sviluppatori stanno già affogando in Yaml e Terraform, l'IA non risolve il problema. Significa solo che affogano più velocemente, producendo più codice che deve essere supportato. Al momento, circa il 55% delle aziende ha già adottato il platform engineering in qualche forma. Gartner prevede che quel numero raggiungerà l'80% alla fine del 2026. Non ha tendenza lenta. È un cambiamento che sta avvenendo proprio. Le aziende stanno rendendo conto di non poter scalare team di ingegneria senza un layer di piattaforma. Il vecchio approccio in cui ogni team fa tutto da solo non funziona quando si rilascia codice alla velocità dell'IA.

Ecco cosa sfugge a molte persone. L'IA non crea solo il bisogno di piattaforma, aiuta anche a costruire. I team di piattaforma usano l'IA per generare moduli Terraform, scrivere documentazione e correggere pipeline. La stessa tecnologia che crea l'urgenza fornisce anche gli strumenti per risolverla. Ora una parola di cautela. L'IA amplifica ciò che hai già. Se le tue basi sono solide, come una piattaforma ben progettata, l'IA ti rende da 2 a 3 volte più produttivo. Ma se le tue fondamenta sono deboli, l'IA ti aiuta solo a fare errori più grandi, più velocemente. Configurazioni errate, falle di sicurezza, infrastrutture rotte, tutto rilasciato in produzione prima che qualcunusene. L'IA non corregge le cattive fondamenta. Le espone. Un esempio reale. Un'azienda con una buona piattaforma per sviluppatore interno può permettere a un non ingegnere di distribuire strumenti A in sicurezza. La piattaforma fornisce linee guida per te, applica le polisi di sicurezza, gestisce l'infrastruttura.

Così un product manager può avviare un prototipo basato su IA senza dover capire Kubernetes o il cloud networking. Questo è potente. È il tipo di cosa che distingue i team pronti per l'era dell'IA da quelli che verranno lasciati indietro. Cosa significa questo per te? La finestra temporale per costruire una piattaforma si sta chiudendo. Non perché la tecnologia stia scomparendo, ma perché il divario tra i team con piattaforma e quelli senza si sta allargando rapidamente. Ogni mese che aspetti, i team che hanno già le piattaforme prendono sempre più vantaggio. Rilasciano più velocemente, soffrono meno di burnout e si adattano più rapidamente ai nuovi strumenti. I team senza piattaforma restano sempre più indietro. A te la scelta. Inizia con un unico percorso di A. Quindi, da dove si inizia da V? Se sei lì a pensare di dover costruire un'intera piattaforma interna per sviluppatori da zero, fermati, è il modo più veloce per uccidere il tuo progetto prima ancora che inizi.

L'erore più grande che fanno i team è cercare di costruire tutto subito. Passano mesi a progettare la piattaforma perfetta, includendo ogni funzionalità che viene loro in mente. Poi la lanciano e non sentono nulla. Nessuno la usa. Perché? Perché risolve problemi che nessuno ha chiesto e solo per iniziare serve leggere un piccolo manuale. Punto è non farlo. Invece inizia in piccolo. Parlate davvero con gli sviluppatori. Non con gli architetti, non con i manager. Non basatevi sulle vostre supposizioni. Trovate le persone che scrivono funzionalità ogni giorno. Chiedete loro dove scontrollano. Individuate il flusso di lavoro che richiede più tempo, frustra più persone o viene saltato più spesso del dovuto. Poi costruite esattamente un percorso ideale dall'inizio alla fine. Magari si tratta di creare e distribuire un nuovo microservizio. Magari configurare un ambiente di sviluppo da zero. Magari rilasciare un hotfix in produzione senza rompere nulla.

Scegliete quello più problematico e create un percorso che faccia sparire quel problema. Costruitelo, testatelo con utenti reali, raccogliete feedback, iterate. Poi aggiungete un altro percorso e un altro ancora dopo. Non cercate di risolvere i miei problemi in una cosa sola. Risolvete un problema davvero bene e lasciate che lo slancio vi porti avanti. Come fate a sapere se sta funzionando? Vi assicurate le cose giuste. Tempo dall'idea al primo deploy, numero di passaggi manuali eliminati e tassi di adozione volontaria. Se gli sviluppatori scelgono il vostro percorso invece di costruire non proprio state vincendo. Se lo evitano ascoltate e cambiate direzione. Ecco la trappola a evitare. Non rendete la piattaforma obbligatoria. Costringete gli sviluppatori sul vostro percorso e ne risentiranno. Troveranno dei modi per la girata. Creeranno i propri script e ve li nasconderanno. Piuttosto rendete il percorso facile.

Rendetelo più veloce dell'alternativa. Rendetelo la scelta ovvia. Ma mai l'unica. Il primo percorso è sempre più difficile. Vi insegna tutto sul product thinking. Imparate a parlare con gli utenti, a dare priorità e che costruire qualcosa che la gente vuole è davvero molto più difficile che costruire qualcosa che funzioni e basta. Ma una volta fatto il secondo percorso diventa più facile e il terzo ancora di più. Non state costruendo la piattaforma in un colpo solo. State costruendo un percorso alla volta. Quindi questo è il sistema. La platform engineering consiste nel costruire una strada asfaltata finché gli sviluppatori possano concentrarsi sulla guida invece di riparare. Se siete stanchi di combattere con l'infrastruttura, iniziate trovando un percorso ideale nel vostro team, solo uno. Condividete questo video con chi ha bisogno di sentirlo e iscrivetevi per altre analisi come questa.