01 - Introduzione a Platform Engineering: Cos'è una IDP e Perché Serve

Che cos'è una piattaforma interna e quale problema risolve

Il Platform Engineering è la disciplina che costruisce e gestisce una Internal Developer Platform (IDP): un insieme di capacità offerte in self-service ai team di prodotto, in modo che nessuno debba rifare da solo la pipeline di build, il deploy, la gestione dei segreti e il monitoraggio. Il rapporto DORA 2024 la descrive come una disciplina sociotecnica: riguarda sia le interazioni fra i team sia l'automazione, il self-service e la ripetibilità dei processi.

Il problema nasce dall'autonomia. Il documento del CNCF sulle piattaforme spiega che dare ai team la libertà di scegliere strumenti e servizi ha spostato su di loro sempre più responsabilità di supporto, e quindi tempo ed energia mentale sottratti al lavoro che l'organizzazione si aspetta da loro. La piattaforma è la risposta organizzativa: pochi esperti dedicati servono molti team, e ciò che è comune si fa una volta sola.

Questo articolo apre una serie di quattordici. Qui trovi le definizioni, i numeri della ricerca (compresi quelli che non fanno comodo a chi vende piattaforme) e due piccoli script per misurare, sui tuoi dati, se il problema esiste davvero da te.

Quando ogni team si costruisce il proprio stack

Il sintomo più visibile è la frammentazione. Prima di discutere di piattaforme conviene contarla: quanti strumenti diversi fanno la stessa cosa in azienda? Lo script qui sotto legge un inventario in YAML, con una riga per team e una colonna per categoria, e stampa quanti strumenti distinti compaiono in ogni categoria e quante combinazioni di stack esistono. I quattro team sono inventati per l'esempio: i numeri che escono non descrivono nessuna azienda reale.

# Inventario di un'organizzazione di esempio: quattro team, cinque scelte ciascuno.
# I dati sono inventati per l'esempio, non misurati su un'azienda reale.
teams:
  checkout:   {ci: jenkins,        cd: argocd, monitoring: datadog,    infra: terraform,      secrets: aws-secrets-manager}
  search:     {ci: github-actions, cd: flux,   monitoring: prometheus, infra: cloudformation, secrets: vault}
  catalog:    {ci: github-actions, cd: argocd, monitoring: prometheus, infra: terraform,      secrets: vault}
  notifiche:  {ci: gitlab-ci,      cd: argocd, monitoring: prometheus, infra: pulumi,         secrets: vault}

L'inventario è volutamente banale: ogni team ha messo il proprio nome, e accanto le cinque scelte che ha fatto. Nessuno ha sbagliato, e questo è il punto: ogni scelta, presa da sola, è difendibile.

import sys
from collections import Counter
import yaml

with open(sys.argv[1], encoding="utf-8") as f:
    teams = yaml.safe_load(f)["teams"]

categorie = ["ci", "cd", "monitoring", "infra", "secrets"]
for cat in categorie:
    scelte = Counter(t[cat] for t in teams.values())
    # ordine stabile: prima le più usate, a parità l'ordine alfabetico
    ordinate = sorted(scelte.items(), key=lambda kv: (-kv[1], kv[0]))
    dettaglio = ", ".join(f"{nome} x{n}" for nome, n in ordinate)
    print(f"{cat:<11} {len(scelte)} strumenti distinti  ({dettaglio})")

stack = {tuple(t[c] for c in categorie) for t in teams.values()}
print(f"stack complessivi diversi: {len(stack)} su {len(teams)} team")
print(f"competenze distinte da avere in organizzazione: "
      f"{len({t[c] for t in teams.values() for c in categorie})}")

# Output (python3 sprawl.py stack_per_team.yaml):
# ci          3 strumenti distinti  (github-actions x2, gitlab-ci x1, jenkins x1)
# cd          2 strumenti distinti  (argocd x3, flux x1)
# monitoring  2 strumenti distinti  (prometheus x3, datadog x1)
# infra       3 strumenti distinti  (terraform x2, cloudformation x1, pulumi x1)
# secrets     2 strumenti distinti  (vault x3, aws-secrets-manager x1)
# stack complessivi diversi: 4 su 4 team
# competenze distinte da avere in organizzazione: 12

Lo script usa un Counter per categoria e ordina le voci prima per frequenza e poi alfabeticamente, così l'uscita è identica a ogni esecuzione (l'ho lanciato due volte e ho confrontato i risultati). Il dato che pesa è l'ultimo: quattro team, quattro stack diversi, dodici strumenti da saper usare. Chi cambia team deve reimparare tutto; chi gestisce un incidente notturno non sa come si legge il monitoraggio degli altri. Dove invece compare un solo strumento per categoria, come i segreti nel caso di tre team su quattro, sta già emergendo una piattaforma di fatto, anche se nessuno l'ha chiamata così.

Che cosa deve avere una piattaforma, secondo il CNCF

Il documento CNCF Platforms White Paper, scritto dal gruppo TAG App Delivery, indica alcune caratteristiche che distinguono una piattaforma di successo da un cumulo di strumenti:

• Piattaforma come prodotto: si progetta e si fa evolvere in base ai requisiti dei suoi utenti, dando priorità ai casi d'uso comuni a più team rispetto a quelli di uno solo.
• Esperienza d'uso: le capacità si offrono con interfacce coerenti, e se serve in più forme (portale, riga di comando, API, IDE).
• Documentazione e onboarding: esempi e strumenti per avviare un nuovo progetto, come un template iniziale con la sua documentazione, che il documento chiama golden path.
• Self-service: chiedere un database e ricevere indirizzo e credenziali senza aprire un ticket.
• Meno carico cognitivo: i team non devono gestire il server del database, ma poterlo configurare e osservare.
• Opzionale e componibile: se la piattaforma non offre un database a grafo, il team deve poterlo gestire per conto proprio.
• Sicura per impostazione predefinita: conformità e validazione secondo le regole dell'organizzazione.

L'elenco non è una scala di priorità, ma tre voci portano il peso della scelta. «Prodotto» spiega perché una piattaforma costruita senza ascoltare chi la usa fallisce. «Self-service» è ciò che permette a pochi esperti di servire molti team. «Opzionale e componibile» è la voce che i progetti trascurano più spesso, e che nel resto della serie ritroverai come requisito di progetto: una piattaforma obbligatoria e rigida diventa un ostacolo.

Platform Engineering e DevOps

Non è una sostituzione. Il rapporto DORA 2024 osserva che spostare una capacità dentro un sistema condiviso («shifting down») può sembrare in contrasto con il principio «you build it, you run it», ma lo legge come un modo di estendere quelle pratiche a tutta l'organizzazione: una volta che una capacità è nella piattaforma, i team la ottengono adottandola. Un esempio concreto è l'esecuzione dei test unitari: se la piattaforma li esegue e restituisce i risultati, il team scrive test migliori senza costruire né mantenere l'ambiente che li esegue.

La differenza pratica sta in chi si fa carico di cosa. Con il solo DevOps, ogni team presidia tutto il proprio stack, come nell'inventario di prima. Con una piattaforma, un team dedicato presidia le capacità comuni e i team di prodotto continuano a essere responsabili dei propri servizi in esercizio.

Team Topologies: chi costruisce la piattaforma e per chi

Il libro Team Topologies di Matthew Skelton e Manuel Pais descrive quattro tipi di team: il team allineato al flusso (stream-aligned), che possiede una fetta di dominio dall'inizio alla fine; il team abilitante (enabling), che aiuta gli altri a superare ostacoli e rileva le capacità mancanti; il team di sottosistema complicato (complicated subsystem), dove serve competenza matematica o tecnica elevata; e il team di piattaforma, che offre un prodotto interno per accelerare i team allineati al flusso. Lo dice il sito del progetto, nella pagina dei concetti chiave, che sostiene anche che la maggior parte delle piattaforme interne diventa ingombrante e rallenta i team, e propone come rimedio la «piattaforma minima praticabile» (Thinnest Viable Platform): solo la capacità che serve, senza altre dipendenze da gestire.

Per evitarlo la domanda di partenza è sempre la stessa: che cosa chiedono i team, e la piattaforma lo offre? Lo script seguente confronta il catalogo della piattaforma con le richieste dei team e stampa ciò che resta scoperto. Anche qui i dati sono di esempio.

# Che cosa la piattaforma offre oggi e che cosa chiedono i team (dati di esempio).
platform:
  offers:
    - ci-cd-pipeline
    - kubernetes-namespace
    - monitoring-dashboard
    - secrets-management
teams:
  checkout:
    consumes: [ci-cd-pipeline, kubernetes-namespace, monitoring-dashboard, secrets-management]
  search:
    consumes: [ci-cd-pipeline, elasticsearch-cluster, monitoring-dashboard]
  catalog:
    consumes: [ci-cd-pipeline, kubernetes-namespace, postgres-database]
  notifiche:
    consumes: [ci-cd-pipeline, message-queue, postgres-database]

Nel file, offers è il catalogo attuale e consumes è ciò che ogni team usa o vorrebbe usare. Il caso interessante è quello dei team che chiedono un database o una coda che la piattaforma non offre.

import sys
from collections import Counter
import yaml

with open(sys.argv[1], encoding="utf-8") as f:
    dati = yaml.safe_load(f)

offerte = set(dati["platform"]["offers"])
richieste = Counter(
    voce for team in dati["teams"].values() for voce in team["consumes"]
)

print("Coperte dalla piattaforma:")
for voce in sorted(offerte):
    print(f"  {voce}: usata da {richieste.get(voce, 0)} team")

print("Richieste senza risposta:")
mancanti = sorted(
    ((voce, n) for voce, n in richieste.items() if voce not in offerte),
    key=lambda vn: (-vn[1], vn[0]),
)
for voce, n in mancanti:
    print(f"  {voce}: chiesta da {n} team")

totale = sum(richieste.values())
coperte = sum(n for voce, n in richieste.items() if voce in offerte)
print(f"Richieste coperte: {coperte} su {totale}")

# Output (python3 domanda_offerta.py domanda_offerta.yaml):
# Coperte dalla piattaforma:
#   ci-cd-pipeline: usata da 4 team
#   kubernetes-namespace: usata da 2 team
#   monitoring-dashboard: usata da 2 team
#   secrets-management: usata da 1 team
# Richieste senza risposta:
#   postgres-database: chiesta da 2 team
#   elasticsearch-cluster: chiesta da 1 team
#   message-queue: chiesta da 1 team
# Richieste coperte: 9 su 13

Il risultato è una lista di priorità che nessuno ha dovuto inventare: il database PostgreSQL è richiesto da due team su quattro e non è nel catalogo, quindi è il prossimo candidato; il cluster di ricerca lo chiede un solo team, e conviene lasciarglielo gestire (la regola «opzionale e componibile» del CNCF). Il 9 su 13 finale non è un punteggio da ottimizzare, ma il modo di accorgersi che il catalogo ha lasciato scoperto circa un terzo della domanda. Un team di piattaforma che non misura la distanza fra ciò che offre e ciò che i team usano finisce a costruire ciò che gli piace costruire.

Che cosa dicono i dati: il rapporto DORA 2024

La fonte più solida sull'effetto delle piattaforme è il rapporto Accelerate State of DevOps 2024 di DORA (Google Cloud), che dedica un capitolo al tema. Sono risultati di un sondaggio, quindi correlazioni e non prove di causa, e la definizione di piattaforma era lasciata volutamente ampia: l'89% dei rispondenti dichiara di usarne una. Chi usa una IDP risulta:

• più produttivo come individuo, con un +8% rispetto a chi non la usa, e più efficace come team, con un +10%;
• in un'organizzazione con prestazioni complessive migliori, con un +6%;
• con una produttività più alta del 5% quando riesce a completare i compiti senza l'intervento di un team abilitante (l'indipendenza degli sviluppatori);
• con un throughput di consegna inferiore dell'8% e una stabilità dei cambiamenti inferiore del 14%.

L'ultima voce è quella che le presentazioni commerciali omettono, ed è nel rapporto: le piattaforme aggiungono passaggi fra sistemi, e per chi è obbligato a usarle in esclusiva per tutto il ciclo di vita dell'applicazione il throughput scende del 6%. DORA propone tre ipotesi per l'instabilità (la piattaforma permette di rimediare in fretta, quindi si rischia di più; non filtra abbastanza i cambiamenti difettosi; oppure sono le organizzazioni già instabili a costruire piattaforme) e dichiara di non sapere quale valga. Per i primi anni la produttività segue una curva a J: guadagno iniziale, calo, poi ripresa.

Per chi progetta, la lezione è doppia. Il guadagno dipende da self-service e indipendenza, non dalla sola esistenza di una piattaforma. E la stabilità va misurata fin dall'inizio, con le metriche che trovi nell'articolo Platform Observability: metriche DORA e SPACE: senza, il calo del 14% non lo vedi.

Da dove si parte: il modello di maturità del CNCF

Il CNCF pubblica anche un Platform Engineering Maturity Model con quattro livelli (Provisional, Operationalized, Scalable, Optimizing) e cinque aspetti da valutare in modo indipendente: investimento, adozione, interfacce, operazioni e misurazione. Il documento avverte che non serve classificare un'organizzazione come «livello 2» o «livello 4», perché lo stesso team può essere a livelli diversi su aspetti diversi, e che ogni livello in più richiede più fondi e più tempo delle persone, quindi raggiungere il massimo non è un obiettivo in sé.

Un esempio dal modello, sull'adozione: al livello più basso i team usano strumenti condivisi in modo sporadico e senza una linea comune; al livello «Scalable» sono i team a scegliere la piattaforma perché riduce il loro carico, non perché glielo impone un mandato. È una distinzione utile quando devi decidere se imporre un percorso o renderlo conveniente, e ci tornerai nell'articolo sui golden path.

Una nota mia, non della letteratura: una startup con una decina di sviluppatori raramente ha bisogno di un team di piattaforma. Le serve un percorso scritto per creare un servizio, un template che funzioni e qualcuno che lo tenga aggiornato. Il resto viene quando l'inventario dello script sopra smette di essere un esercizio.

Come leggere la serie

Gli articoli sono pensati in sequenza, dal perché al come e infine alla misura. Sapere che cosa viene dopo serve a decidere dove fermarti:

1. Questo articolo: definizioni, dati e il caso per e contro.
2. Architettura di una IDP moderna: piani, componenti e integrazioni.
3. Golden Paths: flussi standardizzati e template.
4. Backstage: portale, catalogo e template.
5. Infrastructure as Code: Terraform, Pulumi e policy as code.
6. Service Catalog e CMDB: proprietà e dipendenze.
7. Metriche DORA e SPACE: come misurare la piattaforma.
8. Multi-cloud e developer experience: portabilità e ascolto degli utenti.
9. AI nella piattaforma e sicurezza e conformità.
10. Caso di studio, i postmortem di produzione e AI on-prem contro cloud.

Se hai poco tempo, leggi nell'ordine: questo articolo, i golden path e le metriche. Backstage e l'Infrastructure as Code sono strumenti: servono dopo aver deciso che cosa la piattaforma offre, non prima, e gli articoli sulla sicurezza e sull'osservabilità si appoggiano a quelle scelte. Sul blog trovi anche le serie su DevSecOps e sull'Observability, a cui rimando quando gli argomenti si toccano.

Che cosa sai fare adesso

Sai definire una piattaforma interna e distinguerla da un cumulo di strumenti, con le sette caratteristiche del CNCF. Sai misurare la frammentazione di un'organizzazione con un inventario e la distanza fra catalogo e domanda con il secondo script, entrambi riproducibili con i comandi riportati sopra. Sai citare i risultati di DORA 2024 per intero, compresi il calo di throughput e di stabilità, e sai che il guadagno dipende da self-service e indipendenza. Il prossimo passo è l'architettura: da quali parti si compone una piattaforma e dove passa il confine fra ciò che decide e ciò che esegue.