Cos'è il platform engineering: guida pratica per i team dev
Riassunto
Il platform engineering costruisce una piattaforma interna self-service che permette agli sviluppatori di ottenere ambienti, pipeline e servizi senza aspettare altre persone. Funziona come un prodotto, con gli sviluppatori come clienti, e si fonda sui golden path, cioè percorsi supportati per i compiti comuni. Non è DevOps con un nome nuovo: DevOps è una cultura, la SRE definisce l'affidabilità, il platform engineering fornisce la strada. Sotto circa 30 ingegneri di solito non vale la pena creare un team dedicato.
Il platform engineering è la pratica di costruire e gestire una piattaforma interna che dà agli sviluppatori accesso self-service a ciò che serve per rilasciare software: ambienti, pipeline, servizi, documentazione e regole di sicurezza. Quindi, cos'è il platform engineering in pratica? Un piccolo team tratta il percorso tra «ho un'idea» e «gira in produzione» come un prodotto, e gli sviluppatori ne sono i clienti. L'obiettivo è meno attesa, meno ticket e meno strumenti da imparare.
Probabilmente hai già vissuto il problema. Un nuovo servizio richiede un repo, una pipeline, un database, dei segreti, delle dashboard e una rotazione di reperibilità, e ciascuno di questi elementi sta dietro una pagina wiki diversa o una persona diversa su Slack.
Perché il platform engineering è nato?
«Chi lo costruisce, lo gestisce» funzionava bene quando un team possedeva un solo servizio e pochi strumenti. Ha smesso di reggere quando la toolchain è cresciuta fino a Kubernetes, Terraform, tre sistemi di CI, un secret manager, un service mesh e uno stack di osservabilità. Ogni sviluppatore di prodotto doveva diventare, a tempo parziale, un ingegnere dell'infrastruttura.
Il costo non compare in una riga di budget, ma nel carico cognitivo. Chi impiega 90 minuti per capire quale chart Helm sia quella «giusta» non è rallentato da una mancanza di competenze. È rallentato da una mancanza di default.
Il platform engineering è la correzione. Invece di chiedere a ogni team di assemblare da zero lo stesso stack, un team dedicato lo assembla una volta, lo rende l'opzione più semplice e lo mantiene in salute. Anche gli analisti vedono questa spinta: Gartner prevede che l'80% delle grandi organizzazioni di ingegneria del software avrà team di platform engineering entro il 2026, contro il 45% del 2022.
Cosa costruisce davvero un platform team?
Mettiamo da parte per un momento i diagrammi dei vendor. In molte aziende un platform team rilascia quattro cose.
Una internal developer platform (IDP). L'insieme di strumenti e flussi self-service sopra il tuo cloud e la tua CI. Può essere un portale Backstage, un prodotto di un vendor o un repo ben curato di template con una CLI.
Golden path. Percorsi opinionati e supportati per compiti comuni, come «crea un nuovo servizio API» o «aggiungi una coda».
Guardrail. Policy, scansioni e limiti di costo applicati di default, in modo che l'opzione sicura sia anche quella più comoda.
Documentazione e discovery. Un catalogo che risponde a «chi possiede questo servizio, dove si trova il suo runbook e da cosa dipende?»
Nessuna di queste cose richiede una nuova categoria di prodotto. Parecchie buone piattaforme sono nate come un template cookiecutter e un README che qualcuno teneva aggiornato.
Cos'è un golden path e perché i team lo ignorano?
La CNCF descrive un golden path come una «composizione templata di codice e capacità ben integrate per lo sviluppo rapido dei progetti», una definizione che Google Cloud illustra con un esempio Spring Boot. In parole semplici è un template che dà a un nuovo servizio, fin dal primo giorno, un repo, una pipeline, il logging e la configurazione di deploy.
Il modo in cui fallisce è altrettanto semplice. Un percorso che nessuno ha chiesto, costruito senza parlare con i team che dovranno usarlo, resta a un'adozione di una sola cifra, mentre il platform team si chiede perché gli sviluppatori continuino ad aprire ticket. Il percorso deve essere più corto della scorciatoia, altrimenti le persone prendono la scorciatoia.
Due regole tengono in vita i golden path:
Asfaltati, non recintati. Gli sviluppatori possono uscire dal percorso, ma si assumono il carico di supporto per ciò che costruiscono fuori.
Gestiti come un prodotto. Qualcuno legge i feedback, misura l'adozione ed elimina i percorsi che nessuno usa.
Il platform engineering è solo DevOps con un nome nuovo?
In parte sì, e la risposta onesta è più utile di quella del marketing. DevOps è una cultura: responsabilità condivisa tra sviluppo e operations, cicli di feedback brevi. Il platform engineering è un modo per rendere sostenibile quella cultura su larga scala, trasformando il lavoro operativo ripetuto in un prodotto.
SRE è un'altra disciplina ancora. Gli SRE definiscono obiettivi di affidabilità, li misurano e decidono quando smettere di rilasciare per proteggerli. Il platform team fornisce la strada asfaltata, il team SRE ti dice quanto rischio puoi permetterti percorrendola.
DevOps è una cultura e un insieme di pratiche. Il suo output sono proprietà condivisa e automazione, e di solito fallisce diventando un titolo di lavoro e una coda di ticket.
SRE è una disciplina di affidabilità. Il suo output sono SLO, error budget e un processo per gli incidenti, e di solito fallisce diventando una rotazione di reperibilità senza autorità.
Platform engineering è un team di prodotto interno. Il suo output sono una piattaforma self-service e i golden path, e di solito fallisce diventando una piattaforma che nessuno usa.
Le modalità di fallimento sono la parte da leggere due volte. Un platform team che raccoglie ticket e costruisce qualunque cosa gli venga chiesta è un team operations con un nome nuovo, e si porta dietro tutti i vecchi problemi delle code.
Quando un platform team vale il costo in persone?
Lascia perdere se hai meno di circa 30 ingegneri e uno o due servizi. A quella dimensione bastano un buon repo di template e un modulo Terraform condiviso, e un platform team a tempo pieno è solo overhead. Un paio di persone in un team di dieci finiranno in silenzio per diventare la piattaforma, e va bene così.
Comincia a ripagarsi quando vedi ripetersi gli stessi segnali:
I nuovi servizi impiegano settimane per arrivare in produzione, soprattutto in attesa di altre persone.
Tre team hanno risolto lo stesso problema di deploy in tre modi diversi.
Inserire un nuovo ingegnere significa un mucchio di conoscenza tacita e parecchi «chiedi a Priya, lei lo sa».
Le revisioni di sicurezza e compliance arrivano alla fine, per ogni team, a mano.
La versione minima utile è quella che Team Topologies chiama thinnest viable platform: quanto basta per rimuovere il dolore ripetuto più grande, documentato bene, e niente di più. Parti dal flusso che costa più ore tra i team, di solito «crea un nuovo servizio» o «ottieni un ambiente di preview».
Il feature management è un buon esempio di capacità più economica come servizio condiviso che come dieci versioni private.
Un servizio di flag che ogni team può chiamare, con lo stesso audit trail e le stesse regole di pulizia, evita a ogni team di scrivere il proprio sistema di toggle a metà. Che lo compri o lo costruisca, deve stare sulla piattaforma e non in ogni repo.
Cosa c'entra la piattaforma con la lettura del codice?
Più di quanto i diagrammi ammettano. Una piattaforma è utile solo quanto la conoscenza che la circonda. Quando uno sviluppatore chiede «come si autentica il servizio A verso il servizio B?», la risposta sta nel codice, nella configurazione e in un runbook che potrebbe avere sei mesi.
È qui che i platform team bruciano tempo in silenzio. Sono loro a ricevere la domanda su Slack che inizia con «dove è configurato X?» e a rispondere a memoria, ancora, per la quinta volta in settimana. L'effetto si vede quando un repo supera le 80K righe e il platform team diventa un indice di ricerca umano.
Alcuni strumenti aiutano, e risolvono metà del problema ciascuno. Gli strumenti docs-as-code tengono la parte scritta vicina al sorgente.
Gli assistenti consapevoli del codice rispondono a domande sul codice stesso. Quello di Sourcegraph, Cody, è pensato per organizzazioni grandi e multi-repo ed è venduto alle aziende su preventivo, quindi si adatta ai platform team di grandi estate più che a un team di quindici persone.
Per il lavoro quotidiano dentro l'editor, un assistente generico copre parecchio terreno, con la riserva che conosce solo il contesto che gli dai.
Lo schema che copieremmo: metti i template dei golden path, il catalogo di ownership e un indice ricercabile del codice nello stesso posto, e lascia che i nuovi ingegneri facciano domande lì prima di chiederle a una persona. È misurabile in ore: se dopo averlo fatto il platform team riceve meno di dieci domande «dove è configurato questo» a settimana, ha funzionato.
Come iniziare senza costruire una cattedrale?
La maggior parte degli sforzi di platform che falliscono parte dallo strumento. L'ordine migliore è persone, poi percorsi, poi strumenti.
Intervista dieci sviluppatori. Chiedi dove perdono tempo tra una PR unita e una funzionalità in esecuzione. Sentirai le stesse tre risposte.
Scegli un percorso e rilascialo in un mese. Un singolo template «nuovo servizio» che funziona dall'inizio alla fine batte un portale con 40 riquadri vuoti.
Misura prima e dopo. Monitora il tempo al primo deploy di un nuovo servizio e il tempo alla prima PR unita per un nuovo assunto. Questi due numeri ti diranno più di qualunque sondaggio di soddisfazione.
Pubblica una roadmap e un changelog. Il lavoro di piattaforma è invisibile se non lo rendi visibile.
Elimina cose. Ritira percorsi e strumenti che nessuno usa. Una piattaforma più piccola di cui le persone si fidano batte una più grande che aggirano.
Resisti alla tentazione di comprare prima un portale. Un portale sopra un insieme disordinato di flussi ti dà un disordine dall'aspetto migliore, e un catalogo con 247 voci, metà delle quali obsolete, è peggio di nessun catalogo.
Cosa va storto, e come lo riconosci in anticipo?
Tre schemi di fallimento tornano sempre.
La piattaforma helpdesk. Le richieste arrivano via ticket, il team le evade a mano e chiama tutto questo self-service. Test: uno sviluppatore può completare il compito comune senza parlare con nessuno?
La piattaforma imposta. La leadership obbliga ogni team a passare alla piattaforma prima che sia buona. I numeri di adozione sembrano ottimi e il sentiment crolla. Lascia che l'uso si guadagni nei primi sei mesi.
La piattaforma tuttofare. Ogni richiesta diventa una funzionalità, la superficie esplode e la qualità cala. Dì di no, per iscritto, con le motivazioni.
Un segnale precoce utile è il rapporto tra domande su Slack e risposte documentate. Se la stessa domanda compare tre volte in un mese e non esistono doc, template o automazione, quella è la prossima voce del backlog.
Se dovessi fare una sola cosa lunedì, sceglierei il lavoro che fa perdere più tempo tra i team e lo renderei noioso. Per la maggior parte delle aziende è creare un nuovo servizio o ottenere un ambiente di test. Scrivi il percorso, mettilo dove le persone lo troveranno, conta le ore che fa risparmiare, e solo allora decidi se ti serve un team più grande.
Il platform engineering non è una toolchain da installare. È la decisione di trattare gli sviluppatori interni come clienti, e la prova che l'hai presa è una distanza più corta tra il primo giorno di un nuovo assunto e la sua prima modifica unita.