1~
2Man mano che i sistemi software diventano più complessi  -  microservizi, Kubernetes, multi-cloud, pipeline CI/CD, stack di osservabilità  -  gli sviluppatori dedicano sempre più tempo all'infrastruttura e sempre meno alla costruzione dei prodotti. Il **Platform Engineering** risolve questo problema creando una piattaforma interna che astrae la complessità e fornisce agli sviluppatori strumenti self-service per rilasciare più velocemente.
3~
4Gartner prevede che entro il 2027, l'**80% delle organizzazioni di ingegneria del software** costituirà team di piattaforma. In questa guida esploreremo cos'è il Platform Engineering, perché è importante e come costruire una Internal Developer Platform da zero.
5~
6## Cos'è il Platform Engineering?
7~
8Il Platform Engineering è la disciplina di progettazione e costruzione di toolchain e workflow che abilitano capacità self-service per le organizzazioni di ingegneria del software. Il risultato è una **Internal Developer Platform (IDP)**  -  un livello che si pone tra gli sviluppatori e l'infrastruttura.
9~
10```mermaid
11graph TD
12    subgraph "Developers"
13        D1[Frontend Team]
14        D2[Backend Team]
15        D3[Data Team]
16    end
17~
18    subgraph "Internal Developer Platform"
19        Portal[Developer Portal]
20        Templates[Service Templates]
21        CICD[CI/CD Pipelines]
22        Infra[Infrastructure Abstraction]
23    end
24~
25    subgraph "Infrastructure"
26        K8s[Kubernetes]
27        Cloud[Cloud Services]
28        DB[Databases]
29        Monitor[Monitoring]
30    end
31~
32    D1 --> Portal
33    D2 --> Portal
34    D3 --> Portal
35    Portal --> Templates
36    Portal --> CICD
37    Portal --> Infra
38    Infra --> K8s
39    Infra --> Cloud
40    Infra --> DB
41    CICD --> Monitor
42```
43~
44### Platform Engineering vs DevOps
45~
46Il Platform Engineering non è un sostituto del DevOps  -  è la sua evoluzione naturale. Il DevOps diceva "lo costruisci, lo gestisci." Il Platform Engineering dice "renderemo la costruzione e la gestione senza sforzo."
47~
48| Aspetto | DevOps | Platform Engineering |
49|---------|--------|---------------------|
50| **Focus** | Cultura e pratiche | Prodotti e self-service |
51| **Approccio** | Ogni team gestisce l'infrastruttura | Il team di piattaforma astrae l'infrastruttura |
52| **Carico Cognitivo** | Alto (ogni team impara tutto) | Basso (golden path forniti) |
53| **Output** | Pipeline CI/CD, script IaC | Internal Developer Platform |
54| **Utenti** | Tutto l'engineering | Il team di piattaforma serve l'engineering |
55~
56## Perché il Platform Engineering è Importante
57~
58### Il Problema del Carico Cognitivo
59~
60In una tipica organizzazione moderna, uno sviluppatore deve comprendere:
61~
62- Workflow Git e strategie di branching
63- Configurazione delle pipeline CI/CD
64- Costruzione di container e gestione dei registry
65- Manifest Kubernetes e Helm chart
66- Servizi del cloud provider (AWS/GCP/Azure)
67- Networking, DNS, certificati TLS
68- Configurazione di monitoring, logging e alerting
69- Provisioning e migrazioni dei database
70- Policy di sicurezza e conformità
71~
72È un enorme carico cognitivo che distoglie l'attenzione dal prodotto reale.
73~
74### Il Golden Path
75~
76Il Platform Engineering introduce il concetto di **golden path**  -  percorsi opinionati, ben supportati e documentati per le attività comuni. Un golden path non è un obbligo; gli sviluppatori *possono* deviare, ma la piattaforma rende la cosa giusta anche la cosa facile.
77~
78```mermaid
79flowchart LR
80    Dev[Developer] -- "Create new service" --> Portal[Portal]
81    Portal -- "Select template" --> Template[Service Template]
82    Template -- "Auto-provision" --> Repo[Git Repository]
83    Template --> Pipeline[CI/CD Pipeline]
84    Template --> Infra[Kubernetes Namespace]
85    Template --> Monitor[Dashboards + Alerts]
86    Repo --> Ready[Ready to Code!]
87```
88~
89**Esempio di golden path per la creazione di un nuovo microservizio:**
901. Lo sviluppatore seleziona "Nuovo Servizio Backend" nel portale
912. Sceglie linguaggio/framework (Node.js, Go, Python)
923. La piattaforma crea automaticamente: repository Git, pipeline CI/CD, namespace Kubernetes, dashboard di monitoraggio e regole di alerting
934. Lo sviluppatore clona il repository e inizia a programmare immediatamente
94~
95## Costruire una Internal Developer Platform
96~
97### Livello 1: Developer Portal
98~
99Il portale è il punto di ingresso unico per gli sviluppatori. L'opzione open-source più popolare è **Backstage** (creato da Spotify, ora progetto CNCF).
100~
101Funzionalità chiave:
102- **Catalogo dei servizi**: Ogni servizio, il suo proprietario, la documentazione e le dipendenze
103- **Template software**: Scaffolding per nuovi servizi con le best practice integrate
104- **Documentazione tecnica**: Documentazione come codice, renderizzata e ricercabile
105- **Ecosistema di plugin**: Estendibile con funzionalità personalizzate
106~
107```yaml
108# backstage/catalog-info.yaml
109apiVersion: backstage.io/v1alpha1
110kind: Component
111metadata:
112  name: user-service
113  description: Manages user accounts and authentication
114  annotations:
115    github.com/project-slug: myorg/user-service
116    backstage.io/techdocs-ref: dir:.
117spec:
118  type: service
119  lifecycle: production
120  owner: team-auth
121  system: identity-platform
122  dependsOn:
123    - resource:postgresql-main
124  providesApis:
125    - user-api
126```
127~
128### Livello 2: Astrazione dell'Infrastruttura
129~
130Gli sviluppatori non dovrebbero scrivere direttamente Terraform o YAML Kubernetes. La piattaforma dovrebbe fornire astrazioni.
131~
132**Strumenti:**
133- **Crossplane**: Provisioning dell'infrastruttura nativo per Kubernetes
134- **Terraform con moduli**: Moduli di infrastruttura pre-costruiti e testati
135- **Pulumi**: Infrastruttura come codice reale (TypeScript, Python, Go)
136~
137```yaml
138# Example: Crossplane composition for a database
139apiVersion: database.example.com/v1
140kind: PostgreSQLInstance
141metadata:
142  name: user-db
143spec:
144  size: small        # Abstraction: small = 2 vCPU, 4GB RAM
145  version: "16"
146  backup: daily
147  team: auth-team
148```
149~
150Invece di configurare parametri RDS, subnet VPC, security group e policy di backup, lo sviluppatore specifica semplicemente `size: small` e `backup: daily`. La piattaforma gestisce il resto.
151~
152### Livello 3: Standardizzazione CI/CD
153~
154Standardizza la CI/CD affinché i team non costruiscano ciascuno le proprie pipeline.
155~
156```yaml
157# .github/workflows/platform-ci.yml
158# Teams just include the shared workflow
159name: Build and Deploy
160on:
161  push:
162    branches: [main]
163~
164jobs:
165  pipeline:
166    uses: myorg/platform-workflows/.github/workflows/standard-pipeline.yml@v2
167    with:
168      language: node
169      deploy-target: production
170    secrets: inherit
171```
172~
173**Pratiche chiave:**
174- Template CI/CD condivisi che i team includono (non copiano)
175- Scansione di sicurezza automatica (SAST, audit delle dipendenze)
176- Strategie di deployment standardizzate (canary, blue/green)
177- Rollback automatico in caso di health check falliti
178~
179### Livello 4: Osservabilità
180~
181Monitoraggio pre-configurato affinché gli sviluppatori ottengano dashboard e alert pronti all'uso.
182~
183- **Metriche**: Prometheus + Grafana con dashboard standard per servizio
184- **Logging**: Logging strutturato con raccolta centralizzata (Loki, ELK)
185- **Tracing**: Tracing distribuito con OpenTelemetry
186- **Alerting**: Integrazione con PagerDuty/Opsgenie con default sensati
187~
188```mermaid
189graph LR
190    Service[Your Service] -- "OpenTelemetry SDK" --> Collector[OTel Collector]
191    Collector --> Prometheus[Prometheus]
192    Collector --> Loki[Loki]
193    Collector --> Tempo[Tempo]
194    Prometheus --> Grafana[Grafana Dashboards]
195    Loki --> Grafana
196    Tempo --> Grafana
197    Grafana --> PagerDuty[PagerDuty Alerts]
198```
199~
200## Misurare il Successo
201~
202Come fai a sapere se la tua piattaforma funziona? Monitora queste metriche:
203~
204### Metriche DORA
205- **Frequenza di deployment**: Quanto spesso il codice raggiunge la produzione
206- **Lead time per i cambiamenti**: Tempo dal commit alla produzione
207- **Tasso di fallimento dei cambiamenti**: Percentuale di deployment che causano errori
208- **Tempo medio di ripristino**: Tempo per ripristinare il servizio dopo un incidente
209~
210### Metriche Specifiche della Piattaforma
211- **Tempo al primo deploy**: Quanto tempo dal "nuovo servizio" al primo deploy in produzione
212- **Soddisfazione degli sviluppatori (NPS)**: Fai sondaggi regolari ai tuoi utenti
213- **Rapporto self-service**: % di richieste di infrastruttura gestite senza ticket
214- **Adozione del golden path**: % di servizi che seguono il percorso raccomandato
215~
216## Errori Comuni
217~
218### 1. Costruire Troppo, Troppo Presto
219Inizia dal problema più doloroso, non da una grande visione. Se i deployment sono dolorosi, inizia da lì. Se il provisioning richiede settimane, inizia da lì.
220~
221### 2. Non Trattare la Piattaforma come un Prodotto
222Il team di piattaforma ha bisogno di un product manager, ricerca sugli utenti e cicli di feedback. Gli sviluppatori sono i tuoi clienti  -  comprendi le loro esigenze.
223~
224### 3. Imporre Invece di Attrarre
225Le migliori piattaforme vengono adottate volontariamente perché rendono la vita degli sviluppatori più facile. Se devi imporre l'utilizzo, la tua piattaforma non è abbastanza buona.
226~
227### 4. Ignorare la Developer Experience
228Una piattaforma con una UX terribile non verrà utilizzata. Investi in documentazione chiara, messaggi di errore utili e cicli di feedback rapidi.
229~
230## Come Iniziare
231~
232Una roadmap pratica per costruire la tua prima IDP:
233~
234```mermaid
235flowchart TD
236    A[Month 1-2: Discovery] --> B[Month 3-4: MVP]
237    B --> C[Month 5-6: Iterate]
238    C --> D[Month 7+: Scale]
239~
240    A --> A1[Interview developers]
241    A --> A2[Map pain points]
242    A --> A3[Choose first golden path]
243~
244    B --> B1[Deploy Backstage]
245    B --> B2[First service template]
246    B --> B3[Standardized CI/CD]
247~
248    C --> C1[Gather feedback]
249    C --> C2[Add infrastructure abstraction]
250    C --> C3[Improve docs and onboarding]
251~
252    D --> D1[More templates and golden paths]
253    D --> D2[Self-service infrastructure]
254    D --> D3[Advanced observability]
255```
256~
257### Piattaforma Minima Funzionante
258~
2591. **Catalogo dei servizi** (Backstage)  -  sapere cosa esiste e chi ne è responsabile
2602. **Un template di servizio**  -  golden path per il tipo di servizio più comune
2613. **CI/CD standardizzata**  -  pipeline condivisa che i team includono
2624. **Documentazione di base**  -  come usare la piattaforma, dove trovare aiuto
263~
264Puoi costruire questo MVP in 2-3 mesi con un team di 2-3 ingegneri.
265~
266## Conclusione
267~
268Il Platform Engineering non consiste nel costruire la piattaforma perfetta dal primo giorno. Si tratta di ridurre incrementalmente il carico cognitivo sugli sviluppatori affinché possano concentrarsi sulla costruzione dei prodotti. Inizia in piccolo, misura l'impatto e itera basandoti sul feedback degli sviluppatori.
269~
270Le organizzazioni che investono nel Platform Engineering avranno un vantaggio competitivo significativo: delivery più rapida, sviluppatori più soddisfatti e sistemi più affidabili.
271~
272**Risorse:**
273- [Team Topologies](https://teamtopologies.com/)  -  il libro che ha reso popolari i team di piattaforma
274- [Backstage](https://backstage.io/)  -  il portale per sviluppatori open-source di Spotify
275- [CNCF Platforms White Paper](https://tag-app-delivery.cncf.io/whitepapers/platforms/)  -  definizione della community e best practice
276- [platformengineering.org](https://platformengineering.org/)  -  community, eventi e risorse
277~