Come costruire una Internal Developer Platform capace di evolvere nel tempo, senza dipendere dalle tecnologie adottate? È il tema che ho affrontato nel mio intervento al devsecopsday 2026 (Highway to cloud: come progettare una IDP evolvibile e senza lock-in), dove ho messo a confronto diversi modelli di provisioning e ho presentato l’approccio che abbiamo adottato in un progetto reale. 

Dal DevOps al Platform Engineering 

La filosofia DevOps nasce con l’obiettivo di dare ai team di sviluppo maggiore autonomia, attraverso automazione e collaborazione. Tuttavia, la complessità crescente delle infrastrutture cloud-native e la diffusione di più cloud provider hanno reso sempre più difficile distribuire tra gli sviluppatori tutte le competenze necessarie. 

Il Platform Engineering rappresenta un’evoluzione di questo modello: un team dedicato realizza e mantiene una Internal Developer Platform (IDP), concepita come un prodotto interno che offre servizi standard, risorse on-demand e processi self-service.
L’obiettivo è migliorare la developer experience e, allo stesso tempo, garantire controllo e compliance. 

La scelta delle tecnologie e i modelli operativi 

Uno degli aspetti più complessi nella progettazione di una IDP è la scelta degli strumenti, perché ogni tecnologia risponde a esigenze diverse e porta con sé un proprio modello operativo. 

Mettiamo a confronto tre strumenti per il provisioning dell’infrastruttura cloud: 

• Terraform: dal 2023 è distribuito con licenza HashiCorp non open source (il fork open source è OpenTofu). È multicloud e permette di descrivere l’infrastruttura come codice (Infrastructure as Code), applicandola con un comando esplicito (apply). È lo strumento più diffuso.  

• Crossplane: progetto CNCF graduated, multicloud. Permette di descrivere le risorse infrastrutturali come oggetti Kubernetes e le mantiene allineate con un modello a convergenza continua, sfruttando il reconciliation loop. Ha però un’adozione più limitata e richiede un cluster che faccia da control plane.  

• Cloud provider operator: distribuiti con la licenza del singolo cloud provider e specifici per quel cloud. Anche loro riconciliano continuamente le risorse e, pur avendo un’adozione limitata, offrono il supporto ufficiale del provider.  

Ogni soluzione presenta vantaggi e criticità in termini di maturità, complessità operativa e flessibilità, e nessuna vince su tutto. Inoltre, lo strumento migliore oggi potrebbe non esserlo domani: una IDP non è un progetto a scadenza, ma un prodotto che deve sopravvivere ai cambi tecnologici.
Da qui nasce l’esigenza di basare la platform su astrazioni, che la rendano indipendente dalla scelta degli strumenti. 

Una piattaforma evolvibile 

Per raggiungere questo scopo, siamo partiti dalle entità tipicamente coinvolte in una platform: 

• Building block: componente riutilizzabile che racchiude le funzionalità previste per un tipo di risorsa infrastrutturale ed espone un’interfaccia ben definita. Per esempio, il building block per i bucket S3 su AWS o per i cluster AKS su Azure.  

• Template: archetipo di una risorsa che usa i building block. Può essere istanziato più volte con parametri diversi, per rispondere a richieste diverse degli utenti.  

Siamo così arrivati alla definizione di un processo di provisioning semplice: a valle di una richiesta, si materializza il template che risponde a quella richiesta e si effettua il provisioning tramite un processo di deploy. 

Come gestire tecnologie diverse? 

La prima risposta che ci siamo dati è stata un processo di deploy capace di riconoscere la tecnologia con cui è implementata una risorsa e di lanciare il comando giusto (per esempio terraform apply nel caso di Terraform). 

Ci siamo però scontrati con un problema reale: per le risorse complesse, come un cluster Kubernetes, non basta creare la risorsa. Bisogna anche configurarla con gli strumenti e i servizi che vivono al suo interno, come cert-manager, Istio o Argo CD. 

Per rispondere a questo problema abbiamo introdotto una nuova entità: 

• Scaffolding plan: sequenza ordinata di template che, insieme, realizzano il provisioning di una risorsa.  

Con uno Scaffolding plan possiamo definire non solo il template del cluster, ma anche N template a cascata per i servizi che vogliamo rilasciare al suo interno a valle di una richiesta. Ogni template renderizzato viene poi rilasciato con il processo di deploy specifico per la sua tecnologia (per esempio Helm, kubectl o Argo CD).
Ogni componente ha così il proprio ciclo di vita, il proprio strumento e, se serve, il proprio responsabile. 

Chi decide i parametri di una risorsa? 

Dall’analisi dei requisiti di un servizio offerto dalla platform si stabilisce quali funzionalità del building block sono in carico all’utente e quali no. Quelle che non sono in carico all’utente, a loro volta, possono avere proprietari diversi: per esempio, il team platform sceglie la regione e la dimensione dei dischi, il team security la cifratura e la retention dei dati. 

Per gestire queste ownership abbiamo introdotto una seconda entità: 

• Interfaccia: sorgente di configurazioni in carico a un ufficio o a un utente.  

Il processo che materializza i template, che abbiamo chiamato templater, raccoglie quindi, oltre ai parametri forniti dall’utente, quelli di tutte le interfacce necessarie per completare il provisioning della risorsa. Resta compito del template stabilire come aggregarli. 

In questo modo ogni ufficio gestisce le proprie decisioni in un unico punto, e il template le applica in automatico a ogni richiesta. La sicurezza, in particolare, non è più un controllo a valle: le sue regole fanno parte di ogni risorsa fin dalla creazione. 

Il valore della flessibilità: come estendere la IDP 

Con queste entità abbiamo realizzato una platform che può essere estesa in più direzioni, ognuna con un percorso già previsto: 

• nuovi strumenti: si aggiunge un processo di deploy dedicato;  

• nuove risorse e nuove operazioni: si definiscono nuovi template;  

• nuovi componenti per una risorsa: si crea o si modifica uno scaffolding plan;  

• nuovi parametri e nuove ownership: si definiscono nuove interfacce.  

Progettare una IDP in questo modo richiede un investimento iniziale di analisi e di disegno. In cambio, non essendo legata agli strumenti, permette di ridurre il rischio di dover ripensare l’intera soluzione se o quando cambiano strumenti o requisiti.
L’obiettivo ruota intorno della capacità della piattaforma di mantenere il proprio valore nel tempo. E continuare a offrire autonomia a sviluppatori e flessibilità all’organizzazione.