Il platform engineering è passato da buzzword di Gartner a realtà operativa. Entro il 2026, l'80% delle grandi organizzazioni di software engineering avrà team dedicati alla piattaforma che forniscono servizi, componenti e strumenti riutilizzabili per la distribuzione delle applicazioni. Quelli che hanno successo non stanno semplicemente costruendo infrastruttura — stanno costruendo prodotti che i loro stessi sviluppatori vogliono effettivamente utilizzare.
La differenza tra una Internal Developer Platform di successo e un costoso progetto destinato a prendere polvere si riduce a una cosa: trattare la piattaforma come un prodotto con gli sviluppatori come clienti. Questo significa misurare l'adozione (non solo l'utilizzo), guadagnare l'adozione volontaria tra i team e ridurre incessantemente l'attrito nel workflow degli sviluppatori.
Questa guida copre l'architettura pratica del platform engineering moderno — cosa costruire, quali strumenti utilizzare, come strutturare il team e come misurare se la piattaforma funziona davvero.
Perché esiste il Platform Engineering
Il problema che il platform engineering risolve è semplice: man mano che le organizzazioni scalano, il divario tra ciò che gli sviluppatori devono fare (rilasciare funzionalità) e ciò con cui devono confrontarsi (infrastruttura, sicurezza, conformità, osservabilità) cresce fino a quando la produttività crolla sotto il peso della complessità operativa.
Senza una piattaforma, un tipico workflow di sviluppatore per il deploy di un nuovo servizio appare così:
- Scegliere un runtime (container? serverless? VM?)
- Scrivere un Dockerfile (sperando che sia sicuro)
- Configurare CI/CD (pipeline, secret, ambienti)
- Provisionare l'infrastruttura (Terraform? CloudFormation? Cliccare in una console?)
- Configurare il networking (ingress, load balancer, DNS, certificati TLS)
- Configurare il monitoraggio (quale strumento? dove vanno i log? quali alert?)
- Gestire i secret (Vault? variabili d'ambiente? sperare per il meglio?)
- Soddisfare i requisiti di sicurezza (scanning, policy, controlli di conformità)
- Scrivere la documentazione (forse)
- Superare un processo di revisione delle modifiche (eventualmente)
Ogni passaggio comporta decisioni che la maggior parte degli sviluppatori applicativi non dovrebbe dover prendere. Il compito del team della piattaforma è codificare queste decisioni in capacità self-service che permettano agli sviluppatori di saltare da "ho del codice" a "è in esecuzione in produzione" con guardrail che garantiscono che sicurezza, conformità e standard operativi siano rispettati automaticamente.
Con una piattaforma, lo stesso workflow diventa:
- Scegliere un template dal catalogo dei servizi
- Compilare i campi (nome del servizio, team, tier)
- Pushare il codice
- È deployato con CI/CD, monitoraggio, networking e sicurezza integrati
Questa è la proposta di valore: un'esperienza curata e self-service che riduce il carico cognitivo applicando al contempo gli standard organizzativi.
Architettura di una Internal Developer Platform
Una IDP ben strutturata ha cinque livelli, ognuno con uno scopo distinto:
Livello 1: Portale per Sviluppatori (L'Interfaccia)
Il portale per sviluppatori è la vetrina della piattaforma. È dove gli sviluppatori scoprono servizi, leggono la documentazione, creano nuovi progetti e visualizzano lo stato dei loro deployment. Backstage, costruito originariamente da Spotify e ora progetto in incubazione CNCF, detiene circa l'89% della quota di mercato tra le organizzazioni che hanno adottato una IDP.
Il portale fornisce:
- Catalogo software: Un registro di tutti i servizi, API, librerie e componenti infrastrutturali di proprietà di ogni team.
- Template (Golden Path): Scaffold di progetto preconfigurati che codificano le best practice dell'organizzazione.
- TechDocs: Documentazione-come-codice renderizzata direttamente nel portale.
- Ecosistema di plugin: Integrazioni estensibili con CI/CD, monitoraggio, cloud provider e strumenti di sicurezza.
# catalog-info.yaml — Registrare un servizio in Backstage
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
name: payment-service
description: Handles payment processing and billing
annotations:
github.com/project-slug: myorg/payment-service
backstage.io/techdocs-ref: dir:.
pagerduty.com/service-id: P1A2B3C
tags:
- python
- payments
- tier-1
links:
- url: https://grafana.internal/d/payments
title: Grafana Dashboard
icon: dashboard
spec:
type: service
lifecycle: production
owner: team-payments
system: billing
providesApis:
- payments-api
dependsOn:
- component:user-service
- resource:payments-db
Livello 2: Golden Path (Strade Lastricate)
I Golden Path sono la funzionalità più impattante di una piattaforma. Sono percorsi opinati e preconfigurati attraverso la vostra infrastruttura che codificano decisioni affinché gli sviluppatori non debbano prenderle. La parola chiave è "opinato" — un Golden Path dice "ecco come costruiamo un servizio API Python in questa azienda" e fornisce tutto il necessario per passare da zero alla produzione.
Un buon Golden Path include:
- Scaffold del progetto con la struttura di directory standard
- Pipeline CI/CD preconfigurata
- Dockerfile costruito secondo i vostri standard di sicurezza
- Manifest Kubernetes o configurazione di deployment
- Dashboard di monitoraggio e regole di alert
- Scansione di sicurezza integrata nella pipeline
- Template di documentazione
# template.yaml — Backstage Software Template per una API Python
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
name: python-api-service
title: Python API Service
description: |
Create a production-ready Python API service with FastAPI,
Docker, CI/CD, monitoring, and security scanning pre-configured.
tags:
- python
- fastapi
- recommended
spec:
owner: team-platform
type: service
parameters:
- title: Service Information
required:
- name
- owner
- description
properties:
name:
title: Service Name
type: string
pattern: '^[a-z][a-z0-9-]*$'
description: Lowercase alphanumeric with hyphens
description:
title: Description
type: string
maxLength: 200
owner:
title: Owner Team
type: string
ui:field: OwnerPicker
ui:options:
allowedKinds: [Group]
- title: Infrastructure
properties:
tier:
title: Service Tier
type: string
enum: [tier-1, tier-2, tier-3]
enumNames:
- "Tier 1 — Business critical (99.9% SLA)"
- "Tier 2 — Important (99.5% SLA)"
- "Tier 3 — Internal tooling (best effort)"
default: tier-2
database:
title: Database
type: string
enum: [none, postgresql, redis, both]
default: none
steps:
- id: scaffold
name: Generate Project
action: fetch:template
input:
url: ./skeleton
values:
name: ${{ parameters.name }}
owner: ${{ parameters.owner }}
description: ${{ parameters.description }}
tier: ${{ parameters.tier }}
database: ${{ parameters.database }}
- id: publish
name: Create Repository
action: publish:github
input:
repoUrl: github.com?owner=myorg&repo=${{ parameters.name }}
description: ${{ parameters.description }}
defaultBranch: main
protectDefaultBranch: true
requireCodeOwnerReviews: true
- id: register
name: Register in Catalog
action: catalog:register
input:
repoContentsUrl: ${{ steps.publish.output.repoContentsUrl }}
catalogInfoPath: /catalog-info.yaml
- id: create-argocd-app
name: Setup Deployment
action: argocd:create-application
input:
appName: ${{ parameters.name }}
repoUrl: ${{ steps.publish.output.remoteUrl }}
path: k8s/overlays/production
Livello 3: Orchestrazione dell'Infrastruttura
Dietro il portale e i template, serve un livello che effettivamente provisiona e gestisce l'infrastruttura. Nel 2026, lo stack di base è:
- Kubernetes per l'orchestrazione dei container (EKS, GKE, AKS o self-managed)
- Terraform o OpenTofu per il provisioning dell'infrastruttura
- ArgoCD o Flux per il deployment basato su GitOps
- Crossplane per la gestione dell'infrastruttura nativa Kubernetes
Crossplane merita un'attenzione particolare perché permette ai team della piattaforma di esporre l'infrastruttura come custom resource Kubernetes. Invece di scrivere Terraform, gli sviluppatori inviano un manifest YAML che richiede un database, e Crossplane lo provisiona tramite l'API del cloud provider.
# Richiedere un database PostgreSQL tramite Crossplane
apiVersion: database.platform.example.com/v1alpha1
kind: PostgreSQLInstance
metadata:
name: payment-service-db
namespace: team-payments
spec:
parameters:
storageGB: 50
version: "16"
tier: production # mappa sulla classe di istanza appropriata
backup:
enabled: true
retentionDays: 30
compositionRef:
name: aws-postgresql # Il team della piattaforma gestisce questa composition
writeConnectionSecretToRef:
name: payment-db-credentials
namespace: team-payments
Lo sviluppatore richiede un database descrivendo ciò di cui ha bisogno. La Crossplane Composition del team della piattaforma gestisce il come — quale cloud provider, quale tipo di istanza, quale configurazione di rete, quale policy di backup. Se l'organizzazione migra da AWS a GCP, il team della piattaforma aggiorna la Composition e gli sviluppatori non cambiano una sola riga.
Livello 4: CI/CD e Distribuzione
Il livello di distribuzione automatizza il percorso dal commit del codice al deployment in produzione. Una piattaforma moderna fornisce pipeline standardizzate che i team ereditano anziché costruire da zero.
# .github/workflows/platform-pipeline.yaml
# Ereditato dal template Golden Path — i team personalizzano tramite configurazione, non codice pipeline
name: Platform Standard Pipeline
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
quality-gates:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Security Scan (SAST)
uses: platform/security-scan@v3
with:
severity-threshold: high
fail-on-vulnerability: true
- name: Dependency Audit
uses: platform/dependency-audit@v2
with:
policy: organizational-standards
- name: Unit Tests
run: make test
- name: Container Build & Scan
uses: platform/container-build@v4
with:
registry: registry.internal
scan-policy: strict
deploy-staging:
needs: quality-gates
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
steps:
- name: Deploy to Staging
uses: platform/gitops-deploy@v3
with:
environment: staging
auto-promote: false # Richiede promozione manuale alla produzione
deploy-production:
needs: deploy-staging
runs-on: ubuntu-latest
environment: production # Richiede approvazione
steps:
- name: Deploy to Production
uses: platform/gitops-deploy@v3
with:
environment: production
strategy: canary
canary-percentage: 10
promotion-criteria:
error-rate-threshold: 0.1%
latency-p99-threshold: 500ms
Livello 5: Osservabilità e Feedback
L'ultimo livello chiude il ciclo di feedback. Ogni servizio deployato attraverso la piattaforma riceve automaticamente monitoraggio, logging e alerting configurati secondo gli standard organizzativi.
# Generato automaticamente dal template Golden Path
# monitoring/alerts.yaml
groups:
- name: payment-service-slo
rules:
- alert: HighErrorRate
expr: |
sum(rate(http_requests_total{service="payment-service",status=~"5.."}[5m]))
/
sum(rate(http_requests_total{service="payment-service"}[5m]))
> 0.001
for: 5m
labels:
severity: critical
tier: "1"
team: payments
annotations:
summary: "Il tasso di errore del payment service supera lo 0,1%"
runbook: "https://portal.internal/docs/runbooks/payment-service/high-error-rate"
- alert: HighLatency
expr: |
histogram_quantile(0.99,
sum(rate(http_request_duration_seconds_bucket{service="payment-service"}[5m])) by (le)
) > 0.5
for: 5m
labels:
severity: warning
tier: "1"
team: payments
Misurare il Successo della Piattaforma
Il cambiamento critico nella maturità del platform engineering è passare dalla misurazione dell'utilizzo alla misurazione dell'adozione. L'utilizzo vi dice che le persone interagiscono con la piattaforma; l'adozione vi dice che scelgono di usarla quando hanno alternative.
Metriche Chiave
Tasso di adozione: Quale percentuale di nuovi servizi viene creata attraverso i Golden Path della piattaforma rispetto a manualmente? Obiettivo: >80% entro 12 mesi.
Tempo al primo deployment: Quanto tempo impiega un nuovo sviluppatore per deployare la sua prima modifica in produzione? Con una piattaforma matura, dovrebbe essere meno di 1 giorno (incluso l'onboarding).
Tasso di aggiramento della piattaforma: Quanto spesso i team lavorano aggirando la piattaforma? Ogni aggiramento è un segnale che la piattaforma non soddisfa un'esigenza reale. Tracciate le richieste di eccezione.
Riduzione del carico cognitivo: Intervistate gli sviluppatori trimestralmente. Chiedete: "Quanto del vostro tempo viene speso sull'infrastruttura rispetto al lavoro sulle funzionalità?" Il trend conta più del numero assoluto.
Tempo medio di ripristino (MTTR): I servizi costruiti sulla piattaforma dovrebbero riprendersi più velocemente dagli incidenti perché hanno monitoraggio standardizzato, runbook e meccanismi di rollback del deployment.
# platform_metrics.py — Tracciare e reportare le metriche di salute della piattaforma
from dataclasses import dataclass
from datetime import datetime, timedelta
@dataclass
class PlatformMetrics:
total_services: int
platform_services: int # Creati attraverso i Golden Path
manual_services: int # Creati al di fuori della piattaforma
bypass_requests: int # Eccezioni richieste questo trimestre
avg_first_deploy_hours: float
developer_satisfaction: float # Scala 1-10 dal sondaggio
@property
def adoption_rate(self) -> float:
"""Percentuale di servizi che utilizzano la piattaforma."""
if self.total_services == 0:
return 0.0
return (self.platform_services / self.total_services) * 100
@property
def bypass_rate(self) -> float:
"""Quanto spesso i team aggirano la piattaforma."""
if self.total_services == 0:
return 0.0
return (self.bypass_requests / self.total_services) * 100
def health_report(self) -> str:
"""Generare un riepilogo della salute della piattaforma."""
status = "healthy" if self.adoption_rate > 80 else "needs attention"
return (
f"Platform Health: {status}\n"
f" Adoption Rate: {self.adoption_rate:.1f}%\n"
f" Bypass Rate: {self.bypass_rate:.1f}%\n"
f" Avg First Deploy: {self.avg_first_deploy_hours:.1f} hours\n"
f" Developer Satisfaction: {self.developer_satisfaction:.1f}/10\n"
f" Total Services: {self.total_services} "
f"({self.platform_services} platform, "
f"{self.manual_services} manual)"
)
Strutturare il Team della Piattaforma
Un team della piattaforma non è un team infrastruttura con un nuovo nome. La distinzione è importante perché modella tutto, dall'assunzione alla priorizzazione.
I team infrastruttura costruiscono e mantengono sistemi. I loro clienti sono macchine. La loro metrica di successo è l'uptime.
I team della piattaforma costruiscono prodotti per gli sviluppatori. I loro clienti sono esseri umani. La loro metrica di successo è l'adozione. Questo significa che i platform engineer hanno bisogno di pensiero prodotto, competenze di user research e la capacità di dire "no" a funzionalità che aggiungono complessità senza valore proporzionale.
Una struttura tipica del team della piattaforma per un'organizzazione di medie dimensioni (200-500 sviluppatori):
- Platform Product Manager (1): Gestisce la roadmap, priorizza basandosi sul feedback degli sviluppatori, traccia le metriche di adozione.
- Platform Engineer (3-5): Costruiscono e mantengono i componenti della piattaforma — plugin Backstage, template Golden Path, composition Crossplane, template di pipeline CI/CD.
- Developer Advocate (1-2): Onboardano i team, scrivono documentazione, conducono workshop interni, raccolgono feedback.
- SRE/Reliability (1-2): Garantiscono che la piattaforma stessa sia affidabile, gestiscono i cluster Kubernetes, gestiscono l'incident response per l'infrastruttura della piattaforma.
Errori Comuni
Costruire senza parlare con gli sviluppatori. La ragione numero uno per cui le piattaforme falliscono è che il team della piattaforma costruisce ciò che pensa gli sviluppatori abbiano bisogno invece di ciò di cui hanno effettivamente bisogno. Intervistate i vostri utenti. Osservateli lavorare. Misurate dove perdono tempo.
Imporre invece di guadagnare l'adozione. Se dovete forzare i team sulla vostra piattaforma, la vostra piattaforma non è abbastanza buona. Le migliori piattaforme vincono attraverso l'esperienza sviluppatore — sono più veloci, più facili e più affidabili dell'alternativa.
Astrarre troppo presto. Iniziate con un Golden Path per il vostro tipo di servizio più comune. Fatelo bene. Poi espandete. Le piattaforme che cercano di supportare ogni possibile caso d'uso dal primo giorno finiscono per non supportarne nessuno bene.
Ignorare la via di fuga. Gli sviluppatori hanno bisogno della possibilità di personalizzare quando il Golden Path non si adatta. Se la vostra piattaforma è un giardino recintato senza uscite, i team la abbandoneranno del tutto piuttosto che aggirare singole limitazioni.
Trattarla come un progetto una tantum. Una piattaforma è un prodotto. Ha bisogno di investimento continuo, cicli di feedback e iterazione. Il team che ha lanciato la piattaforma dovrebbe continuare a migliorarla un anno dopo.
Per Iniziare
Se partite da zero, ecco una sequenza pratica:
Mese 1-2: Intervistate 10 team di sviluppo. Mappate il loro workflow di deployment dall'inizio alla fine. Identificate i tre maggiori punti di attrito. Configurate Backstage con un catalogo software di base.
Mese 3-4: Costruite il vostro primo Golden Path per il tipo di servizio più comune nella vostra organizzazione (probabilmente una REST API). Includete CI/CD, container build, deployment Kubernetes e monitoraggio di base. Deployatelo con un team volontario.
Mese 5-6: Iterate basandovi sul feedback del team pilota. Aggiungete l'integrazione TechDocs. Costruite il vostro secondo Golden Path per il secondo tipo di servizio più comune. Onboardate 3-5 team in più.
Mese 7-12: Scalate l'adozione. Aggiungete Crossplane per l'infrastruttura self-service. Costruite dashboard per le metriche della piattaforma. Stabilite una community interna di sviluppatori attorno alla piattaforma. Puntate al 50% di adozione dei Golden Path per i nuovi servizi.
Le organizzazioni che nel 2026 traggono il massimo valore dal platform engineering condividono un tratto comune: trattano la loro piattaforma come il prodotto più importante che costruiscono — perché ogni altro prodotto dipende da essa.