Il punto di partenza.
La piattaforma riuniva più componenti per elaborare documenti e sostenere workflow assistiti dall’AI. Gli ambienti non condividevano un unico percorso di configurazione affidabile. Un deploy corretto in un ambiente poteva essere difficile da riprodurre nel successivo.
Definirla soltanto una migrazione cloud avrebbe descritto la destinazione, non il lavoro. Il punto era sostituire infrastruttura e passaggi una tantum con un modello leggibile, verificabile e ripetibile.
Cosa doveva risolvere il nuovo modello.
Il disegno della piattaforma doveva rendere espliciti quattro aspetti:
- Più componenti applicativi dovevano seguire la stessa logica di delivery.
- Le differenze tra ambienti dovevano diventare configurazione, non lavoro manuale non documentato.
- Le modifiche infrastrutturali dovevano essere visibili prima di arrivare su un ambiente attivo.
- Workload applicativi e servizi cloud gestiti avevano bisogno di un confine operativo chiaro.
La diagnosi.
La parte fragile non era un singolo servizio. Era il percorso dal codice sorgente a un ambiente funzionante. Quando quel percorso cambia da un ambiente all’altro, ogni modifica porta con sé ipotesi nascoste.
Ho trattato la riproducibilità come requisito centrale. Definizioni infrastrutturali, workload del cluster e valori d’ambiente dovevano avere responsabilità separate, pur passando dallo stesso percorso di delivery.
Il modello di piattaforma risultante.
GitLab CI/CD fornisce il percorso di delivery. Terraform definisce la base Google Cloud, GKE ospita i workload e i servizi gestiti coprono le responsabilità di piattaforma che non appartengono ai container applicativi.
Le decisioni importanti.
La migrazione è diventata affidabile grazie a confini intenzionali.
Riutilizzare i moduli, variare gli input
Terraform riutilizzabile mantiene coerente la base. I valori specifici restano input visibili, invece di trasformarsi in copie dell’infrastruttura.
Questo richiede contratti più rigidi tra i moduli. È esattamente dove serve disciplina.
Un solo modello runtime per i workload
GKE offre ai componenti un obiettivo di deploy coerente e permette di ragionare insieme sulla configurazione runtime.
Un modello condiviso richiede comunque responsabilità chiare per namespace, configurazione e rollout.
Usare i servizi gestiti con criterio
I servizi gestiti di Google Cloud sottraggono ai workload responsabilità di piattaforma quando il confine è utile.
La maggiore operabilità introduce scelte legate al provider, che devono restare esplicite nell’architettura.
Delivery e verifica.
Il modello mette modifiche infrastrutturali e workload su un percorso ispezionabile in GitLab CI/CD. Terraform rende verificabile lo stato cloud desiderato; il modello GKE offre ai componenti un obiettivo comune.
La verifica segue lo stesso confine: prima la definizione infrastrutturale, poi le risorse di piattaforma, infine i workload. Questa sequenza rende più semplice localizzare un errore rispetto a uno script diverso per ogni ambiente.
Il risultato qualitativo.
Infrastruttura e delivery seguono ora un unico percorso ripetibile e verificabile. La piattaforma può essere trattata come un sistema, non come una raccolta di eccezioni ambientali.
Il risultato più utile non è soltanto l’esecuzione su Google Cloud. È il fatto che il percorso verso un ambiente funzionante sia codificato, revisionabile e coerente.