Nel panorama tecnologico attuale, il Platform engineer è la figura che sta ridefinendo il processo attraverso cui il software raggiunge gli utenti finali. Se dovessimo dare una definizione, potremmo dire che è l’ingegnere che progetta e costruisce un Internal Developer Platform (IDP): un ecosistema interno automatizzato che permette agli sviluppatori di gestire l’intero ciclo di vita di un’applicazione in totale autonomia.
Ma per capire davvero chi è, dobbiamo guardarlo accanto al DevOps engineer. Per rendere il concetto comprensibile a tutti, usiamo una metafora sportiva riguardante la Formula 1:
- Il DevOps engineer è come il capo meccanico ai box: interviene durante la gara, in modo reattivo su più fronti per cambiare le gomme, risolve i guasti improvvisi e aiuta il pilota (lo sviluppatore) a finire la corsa senza incorrere in errori critici. È una figura di supporto vitale, ma spesso sovraccarica.
- Il Platform engineer, invece, è l’ingegnere che ha progettato l’intera officina automatizzata e i sistemi di telemetria dell’auto. Non aspetta che il pilota chieda aiuto; costruisce un’auto con controlli così intuitivi e sistemi di sicurezza così avanzati che il pilota può gestire quasi ogni imprevisto da solo, premendo un tasto sul volante.
Il cambio di mentalità: dal “Ticket” al “Self-service”
La differenza fondamentale sta nell’approccio. Mentre il DevOps engineer spesso finisce per gestire una marea di richieste manuali (i famigerati “ticket” per aprire un database o configurare un server), il Platform engineer lavora per eliminare quei ticket alla radice.
Il suo obiettivo non è “fare il lavoro per lo sviluppatore”, ma fornire allo sviluppatore gli strumenti per farlo da solo in modo sicuro, standardizzato e veloce. In questo senso, il Platform engineer non gestisce solo infrastruttura: crea un vero e proprio prodotto interno i cui clienti sono i suoi stessi colleghi programmatori.
Il punto di rottura: perché il DevOps engineer non basta più?
Per anni il grido di battaglia è stato: “You build it, you run it” (lo implementi, lo mantieni). Il DevOps engineer avrebbe dovuto insegnare agli sviluppatori a gestire la propria infrastruttura. Ma la realtà si è scontrata con una rapida espansione del panorama tecnologico.
L’era della “complessità infinita”
Oggi, per mettere online una semplice applicazione, uno sviluppatore non deve solo scrivere codice, deve conoscere Kubernetes per l’orchestrazione, Terraform per l’infrastruttura, le policy di sicurezza del Cloud (AWS, Azure o Google), i sistemi di monitoraggio e le logiche di rete.
Questo ha creato quello che gli esperti chiamano sovraccarico cognitivo: lo sviluppatore passa il 30-40% del suo tempo a gestire configurazioni YAML e permessi di accesso, invece di concentrarsi sulle funzionalità che portano valore al business.
Il DevOps engineer come punto di congestione
In molte aziende, il DevOps engineer è diventato un punto di congestione:
- Lo sviluppatore ha bisogno di un database? Apre un ticket al DevOps.
- C’è da aggiornare un certificato? Aspetta il DevOps.
- Bisogna scalare un server? Chiama il DevOps.
In uno scenario con decine di microservizi e centinaia di rilasci al giorno, un singolo team di DevOps engineer non può più gestire ogni richiesta manuale. È qui che l’approccio manuale e non scalabile (artigianale) del DevOps inizia a evidenziare limitazioni operative.
La soluzione: dalla gestione alla delega intelligente
Il Platform engineer nasce per risolvere questo stallo operativo. Capisce che non si può chiedere a ogni sviluppatore di essere un esperto di infrastruttura. Invece di risolvere il problema per lo sviluppatore (come farebbe un DevOps engineer), il Platform engineer costruisce la soluzione nello strumento che lo sviluppatore usa.
I pilastri della piattaforma: cos’è l’Internal Developer Platform (IDP)?
Se il DevOps engineer si concentra sui flussi di lavoro (le pipeline), il Platform engineer si concentra sul prodotto che abilita quei flussi: la Internal Developer Platform (IDP).
Non è solo un insieme di strumenti, ma uno strato software che si interpone tra lo sviluppatore e l’infrastruttura complessa (Cloud, Kubernetes, database). Ecco i tre pilastri che la rendono rivoluzionaria:
I “Golden Paths”
È forse il concetto più importante del Platform engineering. Un Golden Path è un percorso pre-configurato, testato e sicuro per svolgere un’operazione comune.
- Esempio: uno sviluppatore deve creare un nuovo microservizio. Invece di scrivere da zero file di configurazione complessi, segue il Golden Path: compila un modulo o lancia un comando, e la piattaforma crea automaticamente il database, imposta i permessi di sicurezza e configura il monitoraggio.
- Il vantaggio: lo sviluppatore è libero di uscire dal sentiero se ha esigenze particolari, ma il 90% delle volte sceglierà la via facile e sicura già tracciata dal Platform engineer.
Self-service: l’addio ai ticket
In un modello gestito da un Platform engineer, lo sviluppatore non deve più chiedere il permesso o aspettare che qualcuno sia libero. Attraverso un portale web o una riga di comando (CLI), può “ordinare” ciò di cui ha bisogno. È la democratizzazione dell’infrastruttura: l’autonomia operativa viene trasferita ai team di sviluppo, ma senza i rischi di fare danni.
Standardizzazione e “Policy as Code”
Mentre il DevOps engineer spesso deve spegnere incendi causati da configurazioni diverse tra un progetto e l’altro, il Platform engineer impone uno standard a monte. Le regole di sicurezza, i limiti di costo e le best practice sono scritte direttamente nel codice della piattaforma. Se un’operazione non è sicura, la piattaforma semplicemente non permette di eseguirla.
Platform engineer vs DevOps engineer: evoluzione o sostituzione?
Molti si chiedono: “Quindi il DevOps engineer è destinato a scomparire?”. La risposta breve è: no, ma il suo ruolo sta cambiando pelle. Se il DevOps è la filosofia (la cultura della collaborazione), il Platform engineering è il metodo pratico per farla funzionare su larga scala senza generare un elevato livello di stress operativo. Mentre il DevOps engineer si concentra sul “come” far fluire il lavoro, il Platform engineer si concentra sul “cosa” dare in mano ai team per renderli autonomi.
La sfida tra DevOps engineer e Platform engineer: artigianato contro industria
Ecco le differenze chiave riassunte in questa tabella di confronto:
| Caratteristica | DevOps egineer | Platform engineer |
| Focus Principale | Flusso di lavoro e Pipeline (CI/CD) | Prodotto Interno (IDP) |
| Interazione | Collabora direttamente al rilascio | Fornisce un portale self-service |
| Metodo di Lavoro | Risolve problemi specifici (“Artigianale”) | Crea sistemi scalabili (“Industriale”) |
| Relazione con i Dev | Supporto tecnico e operativo | Abilitatore di autonomia |
| Obiettivo Finale | “Tu lo scrivi, tu lo gestisci” | “Tu lo scrivi, la piattaforma lo gestisce” |
Il “passaggio di testimone” da DevOps a Platform engineer
In un’azienda piccola, un DevOps engineer può ancora gestire tutto manualmente. Ma quando l’azienda cresce, quel modello fallisce.
Il Platform engineer interviene proprio qui: prende le “best practice” del DevOps e le trasforma in un software interno. Non si tratta di una contrapposizione tra ruoli, è più una transizione di responsabilità necessaria per sopravvivere alla complessità del Cloud moderno.
Il Platform engineer non sostituisce la cultura DevOps, la rende possibile anche quando i team diventano centinaia.
Perché le aziende ne hanno un disperato bisogno
Investire in un Platform engineer non è solo una scelta tecnologica, ma una decisione strategica che impatta direttamente sui profitti e sulla competitività dell’azienda. Mentre il DevOps engineer cerca di sostenere l’infrastruttura aziendale giorno dopo giorno, il Platform engineer la trasforma in un vantaggio competitivo.
Velocità reale (Time-to-Market)
In un mondo dove vince chi arriva prima sul mercato, non ci si può permettere che un’idea resti ferma per giorni in attesa che un DevOps engineer configuri un ambiente di test. Con una piattaforma self-service, il tempo che intercorre tra “ho scritto il codice” e “il codice è online” passa da giorni a minuti.
Sicurezza “di serie” (compliance by design)
Uno dei rischi maggiori del modello DevOps classico è l’errore umano: uno sviluppatore stanco potrebbe dimenticare di chiudere una porta di accesso o configurare male un database. Il Platform engineer integra la sicurezza direttamente nei “Golden Paths”. Se lo sviluppatore usa la piattaforma, è garantito che rispetti le policy aziendali. La sicurezza non è più un controllo fatto “dopo”, ma un componente integrato fin dall’inizio.
Ritenzione dei talenti (developer happiness)
Oggi gli sviluppatori senior rappresentano una risorsa altamente qualificata e difficile da reperire. Farli lavorare su compiti ripetitivi, noiosi o frustranti (come affrontare file di configurazione articolati) rappresenta un forte fattore di demotivazione e turnover. Il Platform engineer elimina le complessità operative non necessarie, permettendo ai programmatori di fare ciò che amano: risolvere problemi logici e creare nuove funzionalità. Un team che lavora senza attriti è un team con un’elevata retention.
Verso il futuro del software con il Platform engineer
In definitiva, il passaggio dal DevOps engineer al Platform engineer non è una semplice questione di etichette o di “nuove mode” tecnologiche. È la risposta necessaria a un mondo digitale che è diventato troppo vasto e frammentato per essere gestito con i vecchi metodi manuali.
Mentre il DevOps ha gettato le basi culturali per la collaborazione tra chi scrive il codice e chi lo mette online, il Platform engineer è colui che rende quella collaborazione sostenibile e scalabile. Non si tratta di eliminare la figura del DevOps, ma di elevarla: passare dal “risolvere l’emergenza” al “costruire il sistema” che impedisce l’emergenza stessa.
In un mercato dove la velocità di rilascio e la sicurezza non sono più opzionali, il Platform engineer emerge come il vero architetto dell’efficienza moderna. È la figura che permette agli sviluppatori di tornare a fare ciò che sanno fare meglio: creare software straordinario, lasciando che sia la piattaforma a occuparsi di tutto il resto.
