Platform engineering: guida pratica per team e squad

Sono le 22:10 e un new hire sta cercando di allestire un ambiente di staging da due giorni. Ha aperto tre ticket, ha copiato lo stesso errore Terraform in Slack almeno due volte, e ancora non sa quale dei quattro template CI è quello vero. Questa scena è la risposta completa a "cos'è il platform engineering": è il lavoro di costruire la strada asfaltata interna affinché nessuno debba hackerare da solo nella giungla, e di trattare quella strada come un prodotto con degli utenti.

cos'è il platform engineering, senza i buzzword

La definizione più pulita che conosco viene dalla community di platformengineering.org: progettare e costruire piattaforme che danno ai team la capacità self-service per le parti ricorrenti del loro lavoro. Togli i paroloni e rimangono tre componenti fondamentali.

Primo: una internal developer platform (IDP). Non è un unico prodotto che compri. È uno strato sottile di template, pipeline, API e documentazione che si siede sopra gli strumenti che usi già (cloud account, Kubernetes, CI, secret management, monitoring) e nasconde gli angoli acuti.

Secondo: un team di platform. Un piccolo gruppo di ingegneri i cui clienti sono altri ingegneri. Il loro output non sono feature per gli utenti finali. Il loro output è la velocità con cui tutti gli altri riescono a rilasciare.

Terzo: una mentalità da prodotto. La piattaforma ha utenti, un backlog, metriche di adozione e un turno on-call. Se nessuno la usa, ha fallito, non importa quanto elegante sia l'architettura.

Gartner ha predetto che entro il 2026 l'80% delle grandi organizzazioni di software engineering avrebbe avuto dei team di platform, in salita dal 45% nel 2022. Trattalo come un indicatore di trend, non come una promessa. Lo stesso chiacchiericcio industria dice che una grande fetta di quei team fa fatica a dimostrare il suo impatto:ed è esattamente per questo che il resto di questo articolo passa tempo su quello che va storto.

Come si differenzia da DevOps e SRE

Versione breve: DevOps è una cultura, SRE è una disciplina di affidabilità, platform engineering è una forma di team che prodottizza entrambi.

DevOps ha detto che developer e operazioni dovrebbero condividere la responsabilità di far girare il software. Buona idea. In un'azienda di 15 persone funziona perché tutti vedono tutto. In un'azienda di 300 persone si trasforma piano piano in "ogni squad deve anche diventare un esperto di Kubernetes", che non è quello che nessuno ha firmato.

SRE si concentra su target di affidabilità: error budget, incident response, capacity planning. Un team di platform se ne importa di affidabilità, ma la sua metrica principale è diversa. Misura quanto a lungo un dev aspetta tra "ho un'idea per un service" e "sta girando in produzione con log e alert".

Platform engineering è la risposta al carico cognitivo che DevOps ha lasciato dietro. Invece di chiedere a ogni dev di imparare la toolchain intera, gli dai un default supportato e tieni la conoscenza esperta dentro la piattaforma. Tre ragioni per farlo, una per non farlo: paga solo una volta che il numero di team o servizi è abbastanza grande che la duplicazione fa male. Arriviamo a quella soglia sotto.

Che cosa shipper veramente un team di platform

Dimentica i diagrammi d'architettura. Ecco com'è il backlog di un vero team di platform in una martedì normale.

Un service template. Un comando, o un pulsante in un portale, crea un repository con una pipeline funzionante, un Dockerfile, health check, un logging setup e una dashboard base. Il dev cambia la business logic, non l'impianto idraulico.

Un deployment path. Push a main, test girare, l'artifact viene buildato e promosso attraverso gli ambienti con gli stessi step ogni volta. Niente snowflake per-team.

Ambiente on demand. Un ambiente di preview per ogni pull request, smontato automaticamente. Questa è la feature per cui i developer ti dicono grazie davvero.

Secret e accesso. Credential di breve durata, un posto per richiederli, audit trail. Noioso, e la cosa che ti salva in una security review.

Observability by default. Ogni service creato dal template esce con metriche, log e trace senza che nessuno li colleghi a mano. Uno stack tipo Grafana solitamente si siede dietro questo strato, e la sua free tier e opzione open-source vanno bene per un team piccolo.

Nota quello che manca da quella lista: un portale custom-buildato con un roadmap di tre mesi. Il portale è l'ultima cosa che aggiungi, non la prima.

Golden path: l'idea che fa funzionare il resto

Un golden path è il modo supportato, opinioned di fare un compito comune. È più veloce che farlo a mano e più sicuro che improvvisare, e crucialmente è opzionale. I developer possono uscire dal path quando hanno una vera ragione. Portano solo la responsabilità che ne viene.

C'è una distinzione utile nel write-up di Octopus su paved versus golden path: una paved road è la superficie larga, ben mantenuta, mentre un golden path è la rotta specifica consigliata per un certo lavoro. Nella mia esperienza la differenza conta meno del principio dietro. Vinci rendendo il modo giusto il modo facile, non vietando gli altri modi.

Ecco com'è il golden path più piccolo possibile. È un singolo comando di scaffold che un dev fa girare una volta:

platform new service payments-api \
  --template node-api \
  --env preview,staging,prod \
  --owner team-checkout

Dietro quella una linea stanno una repo, una pipeline, DNS, uno stub database, alert e un record di ownership. Il comando è banale. La parte dura è i sei mesi di accordarsi su cosa significa "node-api", e tenerlo aggiornato quando Node, la tua base image o il tuo cloud provider cambia.

Testato, non ottimale, e qui è il perché lo facciamo comunque: un golden path mediocre che l'80% dei team usa batte uno perfetto che il 10% adotta, perché il primo ti dà la leva per migliorare tutto in una volta.

Quando vale la pena, e quando è una distrazione

Questa è la sezione che molti post saltano. Platform engineering non è gratis, e per molti team è la mossa sbagliata.

L'overview di platformengineering.org suggerisce che le organizzazioni tipicamente cominciano a beneficiare una volta superati gli ~20-30 platform user. Leggi questo come un pavimento ruvido, non come una regola. Sotto, un buon README condiviso, un template CI solido e una persona che se ne importa faranno più di un formal platform team.

Vale la pena quando:

• Hai più di un manipolo di team, e ognuno ha buildato la sua deploy pipeline.

• I nuovi dev mettono settimane, non giorni, a shippare il primo cambiamento.

• Lo stesso tipo di incident si ripete perché ogni service ha hardwired i suoi alert.

• Security o compliance chiede consistenza che non puoi fornire con una richiesta gentile.

Saltalo quando:

• Sei un team di cinque. Scrivi uno script, non una piattaforma.

• Non sai ancora che forma hanno i tuoi service. Standardizzare troppo presto congela le decisioni sbagliate.

• La proposta è "buildare un portale" senza una lista di pain point che toglie.

Per i builder solo e i piccoli side-project crew, l'informazione onesta è più semplice. Non hai bisogno di un platform team, ma hai bisogno delle abitudini: un deploy script ripetibile, un template per i nuovi progetti, un dashboard che controlli. Questo è un platform di uno, e ti farà risparmiare un weekend ogni mese.

Gli strumenti che i team assembla veramente

Non c'è un singolo "prodotto di platform engineering". I team montano uno stack, e i pezzi cadono in alcuni bucket.

Per il portale e il catalogo, molti team usano Backstage o un'alternativa hosted, che dà una lista cercabile di service, owner e doc. Per il provisioning, Terraform o OpenTofu più uno strumento GitOps come Argo CD o Flux. Per CI e delivery, quello che usi già, avvolto in template condivisi.

Due bucket meritano uno sguardo più vicino, perché decidono se la piattaforma sembra affidabile.

Observability. Se i developer non possono vedere cosa sta facendo il loro service, non si fidano della piattaforma che l'ha deployato. Datadog ti dà un single pane elegante attraverso infra, APM e log, a un prezzo per-host che cresce veloce. Lo stack open-source di Grafana ti costa tempo operativo invece che licenze. Scegli basato su se la tua risorsa scarsa è soldi o attenzione.

Doc e qualità. Una piattaforma senza buone doc è una coda di ticket in disguise. Strumenti docs-as-code tengono guide accanto alla repo che descrivono, e code-quality gate in CI mantengono i template onesti.

Nessuno di questi è obbligatorio. Sono esempi dello strato dove un team di platform spende il suo tempo: scegliere un default, collegarlo al template, e possedere il path di upgrade.

Come cominciar senza buildare la cosa sbagliata

La maggior parte degli sforzi di platform che falliscono condividono lo stesso pattern. Cominciano troppo grandi, buildano per mesi prima che un singolo team lo tocchi, e ottimizzano per la slide del roadmap invece che per l'adozione. La fix è poco glamour.

Scegli un compito doloroso, frequente. "Creare un nuovo service" e "ottenere un ambiente di preview" sono i soliti vincitori. Intervista tre developer e guarda loro farlo. Conta gli step e i minuti.

Buildare la versione più sottile che toglie la maggior parte del dolore. Una template repo e un file di pipeline condiviso contano. Daigli a un team amico e siedi accanto a loro mentre lo usano. Aggiusta quello che si rompe, poi offrilo a un secondo team.

Traccia due numeri: quanto a lungo da "nuovo service" a "girando in produzione", e quanti team usano il path volontariamente. Se il secondo numero è piatto, la piattaforma è un mandato, e i mandati marciscono.

Staffalo come un team di prodotto. I platform engineer non sono DevOps con un nuovo titolo. Il materiale di platformengineering.org nota che i platform engineer guadagnano circa il 27% più dei professionali DevOps, che ti dice che il mercato vede il mix product-and-engineering come un lavoro distinto, più difficile.

Una ragione in più di farlo adesso: il nuovo twist è che l'"utente" di una piattaforma non è più solo un umano. Ai agent aprono pull request, fanno girare test e chiedono ambienti. Una piattaforma con template puliti, permessi chiari e doc leggibili-da-macchina è un posto molto più sicuro per un agent per lavorare che una pila di snowflake repo.

Credential di breve durata, ambienti di preview e una pipeline consistente sono quello che mantiene gli errori di un agent contenuti in un branch throwaway. Se la tua piattaforma non può dire un deploy umano da uno automatizzato, aggiungi quello prima che aggiungi qualsiasi cosa.

Cosa dovrebbe buildare il tuo team dopo?

Se guidi un team di 30 dev e ogni squad ha la sua pipeline, un piccolo team di platform con un golden path è probabilmente il tuo hire a leva più alta. Se sei un solo dev con tre side project, copia la pipeline del tuo miglior progetto in una template repo questo weekend e chiamalo fatto.

In ogni caso, la domanda che vale la pena portare alla tua prossima planning session è concreta: quale singolo compito i tuoi developer ripetono più, e cosa ci vorrebbe per renderlo un job da un comando?