Platform Engineering dall'Inizio alla Fine

La maggior parte degli ingegneri con cui parlo pensa che il platform engineering sia "DevOps con un portale" o "il team che possiede il cluster Kubernetes". Nessuna delle due è sbagliata, ma nessuna delle due è giusta nemmeno. Dopo aver letto Platform Engineering: A Guide for Technical, Product, and People Leaders di Camille Fournier e Ian Nowland, e dopo qualche anno a costruire e supportare queste cose su GCP, penso che la disciplina si capisca meglio con una frase semplice: un platform team costruisce e gestisce un prodotto interno i cui utenti sono altri ingegneri. Sembra semplice. Non lo è.

Questo post percorre l'intero arco del libro con parole mie, così puoi decidere se il platform engineering è qualcosa di cui hai davvero bisogno, e come appare quando funziona. Assume che tu sappia già come portare sistemi in produzione. Non spiegherò in modo eccessivo le basi, ma farò in modo che ogni idea risponda alla domanda "perché questa cosa esiste".

Per contesto, il DORA Report 2025 ha rilevato che il 90% delle organizzazioni ha adottato almeno una piattaforma interna, e la qualità della piattaforma è ora un predittore diretto del fatto che gli strumenti AI producano valore o caos. Non è più un argomento di nicchia.

Perché Esiste il Platform Engineering

La Palude del Troppo Generico

Cloud e OSS ci hanno dato primitivi infiniti. Hai bisogno di una coda? Ne hai dodici. Hai bisogno di un object store, un database, un CI runner, una service mesh? Scegli un gusto. Ogni application team sceglie in modo diverso, e un anno dopo la tua "infrastruttura" è una palude di codice collante dove ogni servizio ha la propria pipeline di deploy, la propria logica di retry, le proprie convenzioni di monitoraggio, i propri binding IAM leggermente sbagliati.

Il libro chiama questo la palude del troppo generico. Due cambiamenti ci hanno spinti in essa: l'esplosione delle scelte (ogni primitivo su ogni cloud) e aspettative operative più elevate (uptime 24/7, sicurezza, compliance, controllo dei costi). Ogni app team gestisce tutto questo da solo, male, in parallelo.

L'ho visto in prima persona su progetti di landing zone dove ogni product team stava reinventando gli stessi moduli Terraform per VPC, IAM e alert di budget. Venti team, venti implementazioni quasi identiche, ognuna con i propri bug. Tristezza.

Cosa Fa Davvero il Platform Engineering

Il platform engineering bonifica la palude facendo quattro cose:

Limita i primitivi che i developer vedono. Non ottieni GCS grezzo più Pub/Sub grezzo più Cloud Run grezzo; ottieni un modo curato e opinionato di usarli.
Riduce il codice collante per applicazione assorbendo i plumbing ripetitivi in servizi condivisi.
Centralizza il costo delle migrazioni. Quando il primitivo sottostante cambia, il platform team lo gestisce una volta, non ogni app team lo gestisce 50 volte.
Lascia che i developer gestiscano quello che costruiscono senza costringerli a diventare esperti del kernel Linux.

Questo è anche il motivo per cui il platform engineering non è solo DevOps rinominato. DevOps diceva "developer, prendetevi la responsabilità delle operazioni". Il platform engineering dice "bene, ma vi daremo buoni strumenti per farlo, e tratteremo questi strumenti come un prodotto reale". La pagina sulle capability DORA 2025 lo dice bene: è una disciplina sociotecnica, non una categoria di strumenti.

I Pilastri

Cinque cose fanno di un platform team un platform team e non solo un infra team con una board Jira.

Approccio al Prodotto Curato

Decidi, con intenzione, cosa supporta la tua piattaforma e cosa no. Se un team vuole Kafka invece di Pub/Sub, la risposta non è "certo, ecco il link alla documentazione". La risposta è "ecco cosa supportiamo, ecco perché, ecco la via d'uscita se il tuo caso davvero non si adatta". Dire no fa parte del lavoro.

Astrazioni Software-Based

La piattaforma è software, non un wiki. L'interfaccia verso di essa è API, CLI e SDK. I tuoi developer dovrebbero essere in grado di eseguire il provisioning di un servizio pronto per la produzione scrivendo un piccolo file dichiarativo, non cliccando attraverso una console o scrivendo su Slack.

Qui è dove il progetto Score, ora sotto CNCF, diventa interessante. Una spec di workload come:

yaml

apiVersion: score.dev/v1b1
metadata:
  name: orders-api
containers:
  api:
    image: ghcr.io/acme/orders-api:1.4.2
resources:
  db:
    type: postgres
  events:
    type: topic

è sufficiente perché una piattaforma esegua il provisioning del database giusto, del topic giusto, del service account giusto e del deployment giusto. Al developer non importa che sotto il cofano ci siano Cloud SQL, Pub/Sub e Cloud Run. Questo è il punto.

Personalizzazioni OSS e Registri di Metadata

Due cose fanno sembrare le piattaforme reali invece che fragili.

La prima è la personalizzazione OSS: non esegui Argo CD o Backstage vanilla. Li esegui con i plugin, le policy predefinite e le integrazioni che si adattano alla tua org. La seconda è un registro di metadata, di solito un service catalog. Senza di esso, non sai chi possiede cosa, cosa dipende da cosa, o cosa sta effettivamente girando.

Backstage è il framework OSS de facto per questo layer. Più di 270 organizzazioni lo eseguono in produzione, e CNCF ha lanciato sia il Certified Backstage Associate che il Certified Cloud Native Platform Engineering Associate. Che tu usi Backstage, Port, Cortex, o costruisca il tuo, hai bisogno di un'unica fonte di verità per "quali servizi esistono, chi li possiede, da cosa dipendono".

Servire una Base Ampia, Non Solo i Clienti Più Rumorosi

Le piattaforme interne hanno un piccolo numero di clienti molto rumorosi. Il team senior che gestisce il servizio con più traffico richiederà funzionalità esotiche. Resisti. La piattaforma esiste per servire bene il developer mediano che fa il compito mediano. Se costruisci solo per gli utenti d'élite, la lunga coda dei team ti aggirerà, ed è così che nascono le shadow platform.

Operare Come Fondamenta

Se la tua piattaforma è giù, l'azienda è giù. Questo cambia molto: on-call 24/7, SLO reali, change management reale, onere di supporto. Non sei "uno strumento"; sei il pavimento. Tutto ciò che è costruito sopra assume che il pavimento regga.

Quando e Come Iniziare

Non Formare un Platform Team Troppo Presto

Con 10 ingegneri, non hai bisogno di un platform team. Hai bisogno di cooperazione. Una persona possiede gli script di deploy, un'altra possiede il Terraform, vi accordate tutti sulle convenzioni, e questo è sufficiente. Formare un "platform team" di una o due persone troppo presto trasforma quelle persone in una coda di ticket e rende passiva il resto dell'org.

Il libro è esplicito: su piccola scala, favorisci la cooperazione. Forma il team solo quando il modello di cooperazione sta visibilmente cedendo, di solito oltre i 50 ingegneri, quando inizi ad avere più target di deployment e nessuno conosce la risposta canonica a "come lancio un nuovo servizio".

Trasformare un'Org Infra Tradizionale

Se hai già un team infra o SRE e vuoi trasformarlo in un'org di piattaforma, la parte più difficile non è la tecnologia. È la cultura. Le persone dell'infra sono abituate a essere i guardiani del "no". Le persone della piattaforma devono diventare i fornitori del "sì facile". Questo significa:

Parlare con i clienti, molto. Più di quanto siano abituati.
Assumere o far crescere software engineer a cui piace costruire strumenti, non solo operatori.
Aggiornare il riconoscimento e i premi in modo che "ho reso 200 team il 5% più veloci" batta "ho deployato un nuovo cluster".

Non basta spruzzare product manager sopra e chiamarlo fatto. Questo è il modo di fallire più comune e produce teatro, non piattaforme.

Costruire i Platform Team

I Quattro Ruoli

Il libro divide gli ingegneri di piattaforma in quattro categorie, e la divisione è utile:

Software engineer: costruiscono la superficie prodotto della piattaforma (API, SDK, portali).
Systems engineer: conoscono a fondo i primitivi sottostanti (Kubernetes, Linux, networking, il cloud control plane).
Reliability engineer: si concentrano sulla qualità operativa, on-call, SLO, observability.
Systems specialist: sono gli esperti di dominio profondo (database, sicurezza, networking).

Hai bisogno di un mix. Troppo focus sul software e consegni un portale bellissimo che crolla sotto carico reale. Troppo focus sui sistemi e hai un cluster solidissimo che nessuno riesce a usare senza aprire ticket.

Assumere per Tutto Questo

Assumi per l'empatia verso i clienti. Non posso sottolinearlo abbastanza. Un ingegnere di piattaforma che non riesce a stare in una chiamata con un app dev frustrato e uscirne con una comprensione chiara del suo problema è nel posto sbagliato. La brillantezza tecnica senza empatia produce piattaforme corrette e inutilizzate.

Permetti titoli specifici per ruolo. Usa la stessa matrice di livelli per i ruoli software, ma sii flessibile per gli specialisti di sistemi, dove il valore di mercato e le competenze non sempre si mappano pulitamente su una scala di software engineer.

Manager e Altri Ruoli

I grandi manager di platform engineering tendono a condividere tre caratteristiche: hanno effettivamente operato piattaforme (non solo costruite), hanno consegnato progetti a lungo termine multi-trimestre, e sono ossessivi sui dettagli. Le piattaforme premiano l'attenzione ai dettagli. L'1% dei casi che hai saltato perché sembravano rari mangerà l'80% del tuo tempo di supporto.

Product manager, technical writer, developer advocate e support engineer contano tutti. Ma assumili solo quando il team di engineering è abbastanza maturo da usarli. Un PM prematuro in un platform team di 4 persone diventa una sedia a forma di roadmap.

Piattaforma come Prodotto

Questo è il capitolo che la maggior parte dei non-credenti dovrebbe leggere. Trattare la piattaforma come un prodotto non è branding. È una postura di lavoro!

I Clienti Sono Interni e Questo Lo Rende Più Difficile

I clienti interni sono strani. Sono captive (non possono fare churn facilmente). Hanno opinioni forti e istinti di prodotto deboli. Ti diranno quello che vogliono, che spesso non è quello di cui hanno bisogno. Chiederanno alla piattaforma di fare il loro lavoro, non di dargli strumenti per fare il loro lavoro.

L'empatia vince ancora. Siediti con loro, guardali lavorare, conta quante volte devono fare context-switch per consegnare una singola modifica. Questo è il tuo vero backlog.

Discovery, Roadmap, Modi di Fallire

Il discovery di piattaforma è più caotico del discovery di prodotti consumer. Non esegui test A/B, esegui pilota. Valida i nuovi investimenti distribuendo effettivamente con un team amico e misurando se il loro lead time diminuisce, non se sorridono nelle interviste.

Una roadmap funzionante ha quattro orizzonti temporali:

Visione (pluriennale): dove sta andando questa piattaforma.
Strategia (annuale): le scommesse che stai facendo quest'anno.
Obiettivi e metriche (trimestrale-annuale): come appare il successo.
Milestone (trimestrale): cosa spedirai effettivamente.

Modi comuni di fallire dal libro che ho visto distruggere team:

Sottostimare il costo della migrazione (sempre 2-3x quello che pensi).
Sovrastimare il budget per i cambiamenti che i tuoi utenti hanno per le nuove funzionalità.
Aggiungere funzionalità quando la stabilità è il vero problema.
Troppi product manager rispetto alla dimensione del team di engineering.

Se il tuo team di engineering ha 5 ingegneri e 2 PM, sei nei guai.

Operare le Piattaforme

L'On-Call Non È Opzionale

Le piattaforme operano come fondamenta, quindi la copertura 24/7 non è negoziabile. Il mantra DevOps "you build it, you run it" vive qui. Il team che costruisce il sistema di deploy è anche il team che viene svegliato quando si rompe alle 2 di notte. Questo non è una punizione, è il feedback loop.

Consiglio pratico che vale sempre: mantieni l'on-call sostenibile. Se un singolo ingegnere viene allertato più di qualche volta a settimana, aggiusta il sistema, non il calendario. Gli ingegneri di piattaforma esauriti consegnano piattaforme scadenti.

Il Supporto: La Metà Nascosta del Lavoro

Il lavoro di supporto è la brutta metà del platform engineering di cui nessuno parla nelle talk di conferenza. Il libro delinea quattro fasi:

Formalizza i livelli di supporto (P0 vs P3, tempi di risposta, ecc.)
Separa il supporto non critico dall'on-call in modo che "come aggiungo un CronJob?" non svegli nessuno.
Assumi uno specialista di supporto dedicato quando il volume lo giustifica.
Su scala, costruisci un'org di supporto tecnico reale.

Se salti la fase 1, i tuoi ingegneri passano metà del tempo a rispondere ai DM su Slack e l'altra metà a lamentarsene.

Feedback Operativo

SLO e SLA sono necessari; gli error budget sono utili ma opzionali. Il monitoraggio sintetico intercetta i modi di fallire che i tuoi utenti incontrano prima che aprano un ticket. Le revisioni operative costringono il team a guardare effettivamente i dati e non solo a dare un'occhiata a una dashboard verde. I dati DORA 2025 hanno rilevato che la capability di piattaforma più correlata a un'esperienza utente positiva è il feedback chiaro sui risultati delle attività, che è solo un modo sofisticato per dire: quando qualcosa fallisce, l'utente dovrebbe sapere esattamente cosa è andato storto e cosa fare al riguardo.

Pianificazione e Consegna

I Progetti a Lungo Termine Necessitano di un Documento di Proposta

I progetti di piattaforma sono grandi. Migrazioni, rearchitetture, nuovi control plane. Richiedono trimestri. Saltare il passaggio della proposta è pericoloso.

Una buona proposta risponde a: quale problema stiamo risolvendo, chi ne beneficia, cosa è in scope, cosa è esplicitamente fuori scope, come appare il successo. Scrivila prima di scrivere qualsiasi codice. Falla revisionare. Poi trasformala in un piano d'azione con milestone concrete. Il modo di fallire del "lungo calvario" (il progetto trascina per anni, nessuno ricorda perché) è quasi sempre tracciabile all'omissione di questo passaggio.

Pianificazione della Roadmap Bottom-Up

Le roadmap di piattaforma sono strane perché includono quattro tipi di lavoro: keep-the-lights-on, mandati dalla leadership, miglioramenti di sistema che decidi tu, e richieste dirette dei clienti. Non puoi semplicemente classificare per domanda dei clienti. Il KTLO viene prima, i mandati vengono dopo, e il resto è una lotta che devi affrontare onestamente con gli stakeholder.

Report Quindicinali di Vittorie e Sfide

Questa è una delle pratiche più sottovalutate del libro. Ogni due settimane, il team scrive un breve documento: ecco cosa abbiamo consegnato (vittorie), ecco dove siamo bloccati (sfide). Breve, pubblico, senza fronzoli. Fa tre cose insieme: costringe il team ad articolare i progressi, dice agli stakeholder cosa sta effettivamente succedendo, e porta alla luce le sfide in anticipo in modo che la leadership possa aiutare. Non saltare le sfide. Un documento con sole vittorie è un documento di cui nessuno si fida.

Rearchitetture e Migrazioni

Rearchitetta, Non Costruire una v2

L'istinto quando una piattaforma diventa obsoleta è "costruiamo la v2". Quasi sempre sbagliato. I progetti v2 falliscono perché congelano l'investimento nella v1, richiedono più tempo del previsto, e la migrazione alla v2 costa più della rearchitettura che hai evitato.

Rearchitetta all'interno della piattaforma esistente. Mantieni la compatibilità il più a lungo possibile. Usa ambienti inferiori, rollout lenti, migrazione basata su tranche. Rimani una versione indietro in produzione mentre stabilizzi il nuovo percorso di codice in staging.

I quattro passaggi di pianificazione del libro sono validi:

Pensa in grande agli obiettivi dell'architettura finale.
Considera i costi di migrazione (sempre 2-3x, l'ho già detto?).
Identifica le principali vittorie a 12 mesi che giustificano l'investimento continuato.
Ottieni il buy-in della leadership, e sii pronto ad aspettare.

La Sicurezza È Architettonica

Non puoi aggiungere la sicurezza a una piattaforma dopo che è stata costruita. L'architettura deve imporre least privilege, isolamento e tracciabilità per design. Se la tua piattaforma richiede a ogni team di ricordarsi di impostare i binding IAM giusti, il bug è nella piattaforma, non nel team.

Le Migrazioni: Il Problema Difficile Sottovalutato

Le migrazioni sono il punto in cui le piattaforme provano il loro valore o espongono le loro menzogne. Gli antipattern più comuni:

Chiedere a ogni team di fare la migrazione da soli con una checklist e una scadenza.
Dare mandati senza fornire on-ramp e off-ramp chiari.
Sottostimare la lunga coda di casi d'uso strani.

Ingegnerizza migrazioni più semplici:

Traccia i metadata di utilizzo in modo da sapere effettivamente chi è sulla vecchia versione.
Costruisci automazione, non checklist. Se 200 team devono migrare, il platform team scrive lo script, non gli app team.
Architetta per migrazioni trasparenti (il nuovo sistema parla la vecchia API mentre si cambia il backend).
Documenta gli on-ramp in modo abbastanza chiaro che un nuovo team possa fare self-service.

Usa i mandati con parsimonia. I mandati funzionano una o due volte, poi diventano rumore. La maggior parte delle volte, rendi il nuovo percorso così migliore che il vecchio percorso si estingua.

Dismissione

Non aver paura di eliminare prodotti. Una piattaforma con sette sistemi di deploy semi-supportati è peggio di una con un solo sistema di deploy solido. La dismissione è difficile ma è quello che fanno i team maturi.

Relazioni con gli Stakeholder

I platform team hanno una mappa degli stakeholder particolarmente impegnativa. Ogni team di engineering è un cliente. La maggior parte dei VP ha un'opinione. Le finanze si preoccupano della spesa cloud. La sicurezza si preoccupa di tutto.

La Griglia Potere-Interesse

Mappa i tuoi stakeholder su due assi: quanta potere hanno e quanto sono interessati a quello che fai. Le persone con alto potere e alto interesse ricevono aggiornamenti regolari e consultazione. Le persone con basso potere e basso interesse ricevono una status page. Non sprecare il tempo del tuo team a tenere informato un VP con scarso interesse sugli upgrade di Kubernetes.

Comunicare Senza Condividere Tutto

Sii trasparente, ma non esaustivamente trasparente. Un leader senior non ha bisogno di sapere che hai dibattuto tre diverse strategie di retry per gRPC. Ha bisogno di sapere se raggiungerai le milestone e quali rischi vedi. Usa i 1:1 con giudizio. Traccia aspettative e impegni da qualche parte visibile.

Dire No Senza Rovinare il Rapporto

Il skill più difficile. Sii chiaro sull'impatto aziendale del dire sì ("se aggiungiamo questa funzionalità, la nostra migrazione slitterà di un trimestre, il che costa all'azienda $X"). A volte dici "sì, con compromessi". A volte dici no ma offri una via. A volte tolleri una shadow platform perché il costo di combatterla è più alto del costo di lasciarla funzionare.

Gestire il budget conta anche. Quando arriva la stagione dei budget, non andare persona per persona. Raggruppa per team e per capability. Vieni con opinioni forti su cosa tagliare e cosa mantenere. Se non lo fai, le finanze sceglieranno per te e sceglieranno male.

Come Appare il Successo

Gli ultimi quattro capitoli del libro descrivono le piattaforme di successo con quattro proprietà: aligned, trusted, manage complexity e loved. Questa è la parte che la maggior parte dei post sul platform engineering salta, ed è la più importante.

Piattaforme Aligned

Un'org di piattaforma di successo ha più team che tirano tutti nella stessa direzione. Allineamento di scopo (tutti sanno perché esiste la piattaforma), allineamento di strategia (le scommesse sono coerenti tra i team), allineamento dei piani (le milestone non sono in conflitto).

Sembra ovvio finché non hai un runtime team che vuole che tutti usino Kubernetes e un team di observability che vuole supportare ogni framework sotto il sole. Il disallineamento si manifesta come orientamento conflittuale ai clienti, lavoro duplicato e developer arrabbiati nel mezzo. Risolverlo richiede leadership di principio, non consenso.

Piattaforme Trusted

La fiducia si costruisce lentamente e si perde in una singola migrazione andata male. La fiducia deriva da come operi (comunichi quando le cose vanno storte, mantieni gli impegni), da come investi (consegni le grandi scommesse che hai venduto), e da come prioritizzi la consegna.

Il libro ha un ottimo caso di studio della "piattaforma sovra-accoppiata", dove un team ha integrato così tanta logica personalizzata nella propria piattaforma che qualsiasi cambiamento richiedeva mesi. La soluzione non era più capacità di engineering, ma sfidare le ipotesi sullo scope. A volte il problema di fiducia è che fai troppo, non troppo poco.

Piattaforme che Gestiscono la Complessità

La complessità del software è inevitabile. La complessità accidentale no. Il libro traccia una linea tra la complessità irriducibile del problema e la complessità accidentale che i team aggiungono attraverso coordinazione umana sloppy, shadow platform che risolvono lo stesso problema due volte, e crescita senza limiti.

Tre leve pratiche:

Controlla la crescita. Una piattaforma che supporta tutto non supporta nulla bene. Sii esplicito sullo scope.
Usa il product discovery per capire cosa smettere di fare, non solo cosa aggiungere.
Gestisci le shadow platform. Quando un team costruisce una soluzione parallela, è un segnale: o alla tua piattaforma manca qualcosa di reale, o qualcuno sta costruendo un impero. Entrambe richiedono una risposta.

Piattaforme Loved

L'ultimo capitolo parla, in modo un po' controtipico, del fatto che i developer amino davvero la tua piattaforma. L'amore può sembrare tre cose:

Amore che funziona e basta. La maggior parte degli utenti non noterà la piattaforma per niente. Le cose vengono consegnate, il deploy funziona, la CI passa. Il noioso è il complimento più alto.
Amore che sembra un hack. Una piccola cosa che delizia, come un comando CLI che fa la cosa ovviamente giusta senza cerimonie.
Amore che è ovvio. Punteggi dei sondaggi, retention, adozione organica, persone che raccomandano la piattaforma ad altri team.

Se la tua piattaforma è amata, puoi chiedere un budget e le persone combatteranno per te. Se è tollerata, sei a un brutto incidente dal essere sostituita.

Cosa Significa in Pratica

Se stai partendo da zero o ricostruendo, le priorità sono grosso modo in questo ordine:

Decidi cosa supporti e cosa no. Scrivilo. Difendilo.
Investi in astrazioni software, non in wiki. Score, Crossplane, il tuo SDK, qualunque cosa si adatti, ma software reale con API reali.
Avvia un registro di metadata. Backstage o altro, hai bisogno di sapere cosa gira dove e chi lo possiede.
Costruisci per il team mediano, non per quello più rumoroso.
Tratta le operazioni come una funzionalità di primo livello. SLO, on-call, livelli di supporto, tutto.
Assumi per l'empatia tanto quanto per le competenze di sistemi.
Comunica senza sosta. Report quindicinali di vittorie e sfide, roadmap trasparenti, gestione onesta degli stakeholder.
Taglia quello che non ti serve. Dismetti, consolida, di' no.

I dati DORA sono coerenti: la qualità della piattaforma è ora un moltiplicatore su tutto il resto, inclusa l'adozione dell'AI. Una piattaforma scadente fa sì che gli strumenti AI amplifichino il caos. Una buona piattaforma li fa amplificare il throughput. Costruisci il pavimento prima di costruire il razzo.

Conclusione

Il platform engineering non è glamour. È una delle poche discipline di engineering dove il massimo elogio è "ho dimenticato che esistessi". Se vuoi costruire qualcosa da cui ingegneri reali dipendono ogni giorno, che si accumula di valore nel corso degli anni, e che puoi difendere a un CFO con numeri reali, questo è uno dei posti più vantaggiosi dove spendere una carriera. Non aspettarti solo che qualcuno ti mandi un biglietto di ringraziamento quando il deploy funziona.

Se vuoi approfondire, leggi il libro di Fournier e Nowland. È il trattamento più chiaro della disciplina che ho trovato, e la maggior parte di quello che c'è di buono in questo post deriva da lì. Gli errori sono miei.