Platform engineering

Quando serve una piattaforma

La piattaforma su cui gira un prodotto nasce quasi sempre in modo disordinato, un pezzo alla volta. Quando il prodotto cresce, va resa robusta, scalabile e modificabile in sicurezza da tutto il team. Finché questo passaggio non avviene, codice e infrastruttura restano in uno stato in cui né le persone né gli agenti riescono a intervenire con efficacia.

Cos'è il platform engineering

Il platform engineering è la disciplina che costruisce e mantiene la piattaforma interna su cui i team sviluppano, rilasciano e gestiscono il software. Il white paper sulle piattaforme della CNCF la definisce così: un insieme integrato di funzionalità, definite e presentate in base alle esigenze di chi le usa.

Il concetto chiave è il self-service: chi sviluppa può creare da solo un nuovo servizio, un ambiente o una pipeline di rilascio, seguendo un percorso già pronto e supportato (la cosiddetta golden path), senza aprire un ticket e senza dover conoscere ogni dettaglio dell'infrastruttura sottostante. Lo scopo è alleggerire il carico cognitivo dei team di prodotto.

Platform engineering e DevOps

Il platform engineering nasce dalle pratiche DevOps e le porta un passo oltre, spostando l'accento sul self-service: invece di pretendere che ogni sviluppatore diventi esperto di Kubernetes, Terraform e pipeline, si mettono a disposizione strumenti e percorsi in cui quelle competenze sono già incorporate.

In pratica la piattaforma diventa un prodotto interno: ha degli utenti (i team di sviluppo), una documentazione, interfacce coerenti, e migliora in base a come viene usata davvero.

Cosa c'è in una piattaforma

Ogni piattaforma è diversa, ma alcune funzionalità tornano quasi sempre:

• Infrastructure as Code e GitOps. L'intero ambiente è descritto in modo dichiarativo, con Terraform e strumenti come Argo CD, versionato e riproducibile.
• Un solo percorso di rilascio. Pipeline di CI/CD che costruiscono, testano e rilasciano ogni servizio allo stesso modo.
• Template e golden path. Un nuovo servizio o un nuovo ambiente nasce da un modello che porta già con sé pipeline, configurazione e strumentazione.
• Ambienti. Sviluppo, test e produzione coerenti tra loro, creati e distrutti in automatico.
• Observability. Metriche, log e tracce raccolti in modo uniforme, per esempio con OpenTelemetry, fin dal primo giorno.
• Identità, segreti e sicurezza di default. Permessi, gestione dei segreti e controlli fanno parte della piattaforma, non arrivano dopo.
• Ownership e runbook. È chiaro chi risponde di cosa e come si interviene quando qualcosa si rompe.

Serve davvero un developer portal?

Un'internal developer platform completa, con un portale come Backstage, non è adatta a tutte le aziende. Ha senso quando molti team gestiscono molti servizi; in una startup o in una PMI rischia di diventare un progetto a parte, che si finisce per mantenere più che per usare.

Nella maggior parte dei casi conviene partire da qualcosa di più semplice: template automatizzati, un solo modo di rilasciare, convenzioni scritte. È quello che l'approccio Team Topologies chiama thinnest viable platform: il minimo di funzionalità che basta a rendere veloci i team di prodotto. La piattaforma cresce quando cresce l'organizzazione, non prima.

Una piattaforma agent-ready

L'AI rende più veloce modificare codice e infrastruttura. Ma se la piattaforma è fragile, poco documentata o piena di eccezioni, accelera anche il rischio. Aiuto il team a costruire una piattaforma dichiarativa, osservabile e comprensibile, in modo che persone e strumenti AI possano intervenire con più fiducia.

Una piattaforma agent-ready poggia sugli stessi principi del platform engineering e del DevOps: infrastruttura dichiarativa, un solo modo di fare le cose, convenzioni esplicite. A questi aggiunge tre elementi:

• Un harness: l'ambiente di lavoro dell'agente, cioè il contesto che legge, gli strumenti che può usare e il modo in cui propone le modifiche.
• Dei guardrail: i limiti che impediscono a un agente, o a una persona, di fare danni, come permessi minimi, pull request obbligatorie, test automatici e approvazione umana prima di andare in produzione.
• Observability: per capire l'effetto di ogni modifica servono metriche, log e tracce che si possano interrogare, dalle persone come dagli agenti.

Ne parlo più a fondo nella pagina sulla consulenza DevOps.