Platform Engineering — la piattaforma interna che restituisce tempo agli sviluppatori

C'è un costo che quasi nessuno mette a bilancio, eppure lo pagano tutte le aziende che sviluppano software: il tempo che gli sviluppatori spendono non a scrivere codice, ma a farlo arrivare in produzione. Configurare una pipeline, provisionare un ambiente, capire quale segreto va in quale variabile, ricordarsi come si fa il deploy di quel servizio che tocca una volta ogni tre mesi. Preso singolarmente sembra lavoro di routine; sommato su decine di persone e centinaia di rilasci diventa una tassa silenziosa che rallenta tutto. La platform engineering nasce esattamente per abbattere quella tassa: non aggiungendo strumenti, ma trasformando l'infrastruttura in un prodotto che il team usa senza doverla capire ogni volta da capo.

Il problema non è la mancanza di strumenti, è il carico cognitivo

Negli ultimi dieci anni il movimento DevOps ha dato agli sviluppatori un potere enorme: «you build it, you run it». È stato un progresso reale, ma ha avuto un effetto collaterale poco discusso — ha caricato su ogni team la responsabilità di conoscere Kubernetes, Terraform, la rete cloud, le policy di sicurezza, l'osservabilità e mezza dozzina di altri domini, oltre al dominio applicativo per cui erano stati assunti. Il risultato, in molte organizzazioni, è che ogni squadra reinventa la propria pipeline, con soluzioni leggermente diverse, leggermente incompatibili e leggermente sbagliate.

Il punto chiave della platform engineering è riconoscere che questo carico cognitivo non è un dettaglio, ma il vero collo di bottiglia. Uno sviluppatore produttivo non è quello che sa configurare tutto da solo: è quello che può concentrarsi sul problema di business perché il resto è già risolto in modo affidabile. La piattaforma interna serve a spostare la complessità fuori dalla testa di chi scrive le feature, senza toglierle il controllo quando gli serve davvero.

Che cos'è un'Internal Developer Platform

Un'Internal Developer Platform (IDP) non è un nuovo strumento da aggiungere allo stack: è il livello che tiene insieme gli strumenti che già ci sono e li espone al team come un servizio coerente. Concretamente, una IDP ben fatta offre poche cose, ma solide:

• Self-service, ovvero la possibilità di creare un nuovo servizio, un ambiente o un database senza aprire un ticket e aspettare due giorni. Chi ha bisogno di una risorsa la richiede e la ottiene, entro regole già definite.
• Golden path, cioè un percorso preconfezionato e raccomandato per fare la cosa giusta: un template di servizio che arriva con CI/CD, logging, metriche, security scanning e deploy già cablati. Non è un obbligo, è la strada in discesa — quella che conviene prendere.
• Astrazione con via di fuga: la piattaforma nasconde la complessità di default, ma non la mura. Quando un caso particolare richiede di scendere sotto l'astrazione, dev'essere possibile farlo, senza combattere contro lo strumento.

La differenza rispetto al «facciamo un po' di script condivisi» è di natura, non di grado: una IDP è trattata come un prodotto, con utenti (gli sviluppatori interni), un ciclo di vita, una roadmap e metriche di successo. Chi la costruisce non consegna infrastruttura e sparisce: la mantiene, la migliora, ascolta chi la usa.

La platform engineering riesce quando la strada giusta diventa anche la più comoda. Se per fare la cosa corretta bisogna faticare più che per farla male, prima o poi vince la scorciatoia.

Platform-as-a-Product: la piattaforma ha dei clienti

L'errore più comune è costruire una piattaforma interna come si costruisce un impianto: la si progetta secondo ciò che il team infrastrutturale ritiene elegante, la si «rilascia» e ci si aspetta che tutti la adottino perché è obbligatorio. Quasi sempre fallisce. Gli sviluppatori la aggirano, tornano ai loro script, e la piattaforma diventa un ulteriore livello da attraversare invece che una scorciatoia.

L'approccio che funziona è opposto: trattare la piattaforma come un prodotto e gli sviluppatori interni come clienti che possono scegliere di non usarla. Questo cambia tutto. Si parte dai loro problemi reali — «quanto ci metto oggi a mettere online un servizio nuovo?» — non dall'architettura ideale. Si misura l'adozione, non la conformità. Se un team non usa la piattaforma, non è un problema di disciplina: è un segnale che la piattaforma non gli sta ancora restituendo abbastanza tempo. La domanda giusta non è «come li obblighiamo?», ma «perché la strada che offriamo non è la più conveniente?».

Quali metriche contano davvero

Una piattaforma interna si giustifica solo se sposta numeri concreti. I più onesti sono anche i più semplici da spiegare a chi non è tecnico:

• Time-to-first-deploy: quanto tempo passa da «nuovo servizio» al primo rilascio in produzione. Su una base sana scende da settimane a ore.
• Lead time for change: quanto ci vuole perché una modifica arrivi in produzione. È la misura più diretta della velocità reale del team, e le ricerche del programma DORA la collegano in modo robusto alle performance di business.
• Frequenza di deploy e change failure rate: quanto spesso si rilascia e quanto spesso un rilascio provoca un problema. Una buona piattaforma li migliora insieme — si rilascia più spesso e si rompe di meno, perché i controlli sono incorporati nel golden path invece di essere lasciati alla memoria delle persone.

Sono le stesse metriche con cui si misura la salute dell'ingegneria in generale, e non è un caso: la platform engineering non è un fine in sé, è una leva su quei numeri. Se non li muove, non serve.

Come lo affrontiamo in MAST

In MAST non partiamo dallo strumento di moda, ma dal collo di bottiglia reale del team. Prima osserviamo dove si perde tempo — di solito nei passaggi manuali tra «codice pronto» e «codice in produzione» — e costruiamo il primo golden path proprio lì, dove il ritorno è immediato e visibile. Preferiamo una piattaforma piccola e davvero usata a una grande e ignorata: partiamo da un template di servizio che porta con sé CI/CD, osservabilità e controlli di sicurezza già collegati, e lo allarghiamo solo quando il team lo chiede.

Manteniamo un principio fermo: la piattaforma astrae, non imprigiona. L'astrazione di default copre il 90% dei casi con un percorso semplice; per il restante 10% deve sempre esserci una via di fuga documentata, perché una piattaforma che costringe a combatterla viene abbandonata. E la trattiamo come un prodotto vivo, con qualcuno che ne è responsabile, la misura sulle metriche giuste e la migliora ascoltando chi la usa ogni giorno.

Il segno che sta funzionando non è un dashboard pieno di verde. È molto più semplice: uno sviluppatore che, per mettere online una cosa nuova, non deve più chiedere il permesso a nessuno né ricordarsi dodici passaggi — e può tornare a fare la cosa per cui l'avete assunto, cioè risolvere il problema del cliente.