Platform Engineering vs DevOps: la differenza che conta in pratica
Stessi obiettivi di delivery, modelli operativi diversi. Come scegliere senza comprare un portale per sviluppatori troppo presto
Non è una guerra di etichette
“Facciamo Platform Engineering” è diventata una frase comoda quanto “facciamo DevOps” dieci anni fa. Spesso significa soltanto che qualcuno ha installato un catalogo servizi, ha rinominato il team infrastrutturale e ha lasciato invariato il modo in cui i prodotti arrivano in produzione.
La distinzione utile non sta nel vocabolario. Sta nel modello operativo: chi porta la complessità, chi la consuma, e come si misura se il sistema funziona.
Cosa risolve DevOps (quando è fatto sul serio)
DevOps, nella forma che interessa ai team che devono rilasciare, è un insieme di pratiche e di automazioni sul percorso commit → produzione: CI affidabile, infrastruttura come codice, ambienti confrontabili, feedback rapido, responsabilità condivisa sugli incidenti.
Funziona molto bene finché il numero di team resta piccolo e ognuno può ancora padroneggiare lo stack. Il costo cognitivo è alto, ma è sostenibile.
Il collasso arriva quando ogni team ricrea leggermente diverso lo stesso pezzo: pipeline, moduli di Infrastructure as Code, policy di rete, osservabilità, gestione dei segreti. Nessuna scelta è sbagliata da sola. L’insieme è ingestibile.
Cosa risolve Platform Engineering
Il Platform Engineering risponde a quel collasso trattando l’infrastruttura interna come un prodotto, con utenti reali: gli sviluppatori dell’azienda.
Invece di chiedere a ogni squadra di assemblare Kubernetes, CI, segreti e osservabilità, la piattaforma offre golden path: percorsi già pronti, sicuri e misurabili per le attività ricorrenti, con una via di uscita quando il caso è davvero speciale.
Non è “un portale”. Il portale è la vetrina. La sostanza è ciò che il portale attiva: template, provisioning, policy applicate per costruzione, ambienti self-service, metriche di adozione.
Una tabella onesta
| DevOps / delivery | Platform Engineering | |
|---|---|---|
| Problema tipico | Rilasci lenti, fragili, legati a una persona. | Troppi team che reinventano lo stesso stack. |
| Utente principale | Il team che consegna un prodotto. | I molti team che consumano la piattaforma. |
| Artefatto chiave | Pipeline, IaC, pratiche operative. | Golden path, self-service, prodotto interno. |
| Metrica utile | Lead time, failure rate, tempo di ripristino. | Adozione volontaria dei percorsi standard. |
| Troppo presto quando… | Quasi mai, se i rilasci non sono ancora ripetibili. | Sotto circa 3–4 team di sviluppo. |
Errori ricorrenti che vedo
Comprare la piattaforma prima della delivery
Se i rilasci fanno ancora paura a un solo team, una Internal Developer Platform aggiunge superficie senza togliere dolore. Sistemate prima CI, ambienti e ownership con una consulenza DevOps.
Confondere il portale con la piattaforma
Installare un portale o un catalogo servizi — open source o commerciale — senza percorsi dietro produce un inventario. Utile, non sufficiente. La domanda da fare è: quale azione ripetitiva oggi richiede un ticket e domani deve essere self-service?
Imporre i golden path
Se i team usano il percorso standard solo perché è obbligatorio, non avete prodotto: avete policy. L’adozione volontaria è l’unico indicatore onesto.
Separare Kubernetes dalla piattaforma
Su stack cloud-native la piattaforma poggia quasi sempre su Kubernetes, multi-tenancy e GitOps. Se il cluster è instabile, il self-service moltiplica il danno.
Come scegliere il prossimo passo
- Un team, delivery fragile → partite da DevOps e CI/CD.
- Più team, stessi ticket infrastrutturali → valutate Platform Engineering.
- Cluster ereditato e day-2 doloroso → sistemate Kubernetes prima di industrializzare i percorsi.
- Serve solo allineare competenze → formazione mirata sulla toolchain reale.
Nella mia esperienza Fintech, Insurtech e industriale, la sequenza corretta è quasi sempre: stabilizzare la delivery, chiarire i confini su Kubernetes, poi estrarre i percorsi ripetuti in una piattaforma. Invertire l’ordine costa mesi.
Se state discutendo se “fare PE” o “rafforzare DevOps”, descrivetemi in poche righe quanti team rilasciano, cosa oggi richiede un ticket al gruppo infrastrutturale, e ne parliamo. Le pagine di dettaglio restano qui: Consulenza DevOps e Consulenza Platform Engineering.
