🔗 Se vuoi curiosare tra i file Terraform e gli script di deploy che ho costruito durante il corso, trovi tutto qui: github.com/Pandagan-85/ai-in-production-week2
Immagina di iniziare lunedì con solo un quaderno digitale e un laptop. Entro venerdì, hai un sistema AI completamente automatizzato, pronto per la produzione e in esecuzione su AWS, con infrastructure as code, supporto multi-ambiente.
Non è fantascienza—è il viaggio che ho fatto costruendo un AI Digital Twin come parte del corso "Generative and Agentic AI in Production" di Ed Donner.
Come qualcuno che esplora l'infrastruttura cloud, volevo capire cosa serve davvero per portare un sistema AI in produzione — non la versione teorica, ma le decisioni reali, i tradeoff, e i principi che emergono quando costruisci qualcosa di reale.
E la parte interessante? Non riguarda davvero il codice. Riguarda le decisioni architetturali, l'evoluzione dell'infrastruttura, e i principi che contano quando costruisci sistemi che funzionano su larga scala.
Questo articolo percorre quel viaggio, spiegando non il "come" ma il "perché"—perché abbiamo preso ogni decisione, quali problemi abbiamo risolto, e quali principi emergono quando effettivamente costruisci qualcosa di reale.
Cosa abbiamo costruito: Un chatbot che ricorda le conversazioni, in esecuzione sul tuo laptop.
Perché funziona:
Insight: prima di scalare qualsiasi cosa, devi capire davvero cosa stai costruendo. Il Giorno 1 non riguarda la velocità o l'efficienza. Riguarda la chiarezza. Scopri:
Principio introdotto: La Legge dell'Ottimizzazione Prematura. Non ottimizzare quello che non capisci ancora.
Leggi anche Il Rasoio di Occam, YAGNI e il concetto di Less is More
Cosa è cambiato: Abbiamo spostato tutto su AWS.
La decisione: Dove dovrebbe vivere ogni pezzo?
Perché queste scelte?
Lambda over EC2: Potresti affittare un server ed eseguire lì il backend. Ma perché dovresti farlo? Lambda significa:
S3 per lo storage: I tuoi file JSON sono ora file cloud. S3 è:
CloudFront come porta d'ingresso: Invece di far scaricare agli utenti da un singolo server in Irlanda, CloudFront copia i tuoi file statici su server in tutto il mondo. Gli utenti scaricano dai server più vicini = caricamento più veloce.
L'insight chiave: Ogni servizio fa UNA cosa bene. Il tuo compito è collegarli correttamente.
Nuova architettura:
Principio introdotto: La Separazione dei Compiti. Ogni pezzo ha una responsabilità. I cambiamenti in un'area non si ripetono ovunque.
Cosa è cambiato: Abbiamo sostituito OpenAI con AWS Bedrock.
Il punto di decisione: Hai un sistema funzionante. Perché cambiarlo?
Perché i tradeoff sono cambiati:
Il Giorno 3 ti insegna che le scelte infrastrutturali non riguardano cosa è meglio—riguardano cosa è meglio per LA TUA situazione.
OpenAI è fantastico. Ma per un sistema di produzione dove controlli l'infrastruttura, hai tutto in un cloud, e vuoi migliore efficienza di costo? Bedrock vince.
E proveremo i foundational models di AWS, la famiglia NOVA:
Questo è il tuo primo incontro con i tradeoff specifici dell'ambiente. Lo sviluppo può essere veloce ed economico. La produzione ha bisogno di affidabilità e qualità. Stesso sistema, configurazioni diverse.
Principio introdotto: Scegliere lo Strumento Giusto. La soluzione migliore non è universale. Il contesto importa.
Cosa è cambiato: Abbiamo smesso di cliccare(e impazzire) intorno alla Console AWS. Tutto è diventato codice. 🤯🚀
cosa stiamo effettivamente costruendo:
Durante questo viaggio, abbiamo usato tre tipi di servizi:
Esempi: OpenAI (Giorno 1-2), Bedrock (Giorno 3) | Modello di costo: Paghi per uso
Nella Settimana 1 (la settimana precedente del corso), abbiamo usato Vercel—un classico PaaS. Fai push del codice → Vercel gestisce tutto. Perfetto se vuoi che l'infrastruttura scompaia.
Puoi vedere quella progressione qui: github.com/Pandagan-85/ai-in-production-week1
Nella Settimana 2, abbiamo fatto una scelta diversa: S3 + CloudFront (IaaS) invece di Vercel (PaaS).
Il tradeoff: La complessità è il prezzo della comprensione. Più cose impari a gestire, più chiaro diventa il sistema.
Il problema che stiamo risolvendo:
Hai costruito infrastruttura manualmente:
Ma questo approccio è fragile. Se qualcuno elimina il bucket S3 sbagliato, come recuperi? Lo ricostruisci manualmente, il che richiede ore.
Infrastructure as Code è un'idea semplice: invece di cliccare intorno a una console, scrivi codice che descrive l'infrastruttura che vuoi.
Terraform è uno strumento che ti permette di farlo. È open source, funziona con AWS (e altri cloud), ed è diventato lo standard dell'industria.
Ecco cosa mi ha sorpreso di più: Terraform sembra come il controllo di versione per il tuo cloud. Proprio come `git diff` mostra quale codice è cambiato, `terraform plan` mostra quale infrastruttura cambierà. Il tuo cloud diventa qualcosa che puoi revisionare, committare e fare rollback.
Scrivi un file (in un linguaggio chiamato HCL) che dice:
"I want:
- Two S3 buckets (frontend and memory)
- One Lambda function
- One API Gateway
- One CloudFront distribution
- IAM roles with specific permissions"Code language: PHP (php)Poi esegui: `terraform apply`
E AWS crea esattamente ciò che hai definito. Ogni. Singola. Volta. Identicamente.
La parte magica: Se lo esegui di nuovo, Terraform controlla "è già qui questa infrastruttura?" Se lo è, non fa nulla. Se qualcosa è cambiato, aggiorna solo quello che è diverso.
Questa è infrastruttura dichiarativa: Dichiara quello che vuoi, Terraform scopre come farlo accadere.
Perché questo importa:
Stesso codice per dev e prod? Come?
Con file di configurazione dell'ambiente (`.tfvars`):
Development (.tfvars):
Model: Nova Micro (fast, cheap)
Timeout: 30 seconds
Bedrock permissions: Full access
Production (prod.tfvars):
Model: Nova Lite (better quality)
Timeout: 60 seconds
Bedrock permissions: Only specific modelCode language: CSS (css)Stesso codice Terraform, valori diversi, risultati diversi.
Questo è profondo perché significa:
Principio introdotto: Sicurezza con Privilegi Minimi
Dai a ogni sistema solo i permessi che assolutamente ha bisogno. Niente di più.
Questo è uno dei concetti più importanti della sicurezza infrastrutturale.
Esempio:
Perché? Perché se il tuo Lambda di produzione viene hackerato o ha un bug, l'attaccante non può:
Può solo fare ciò che il Lambda deve legittimamente fare.
Questo sembra ovvio in retrospettiva, ma è profondo nella pratica. Molti sistemi falliscono gli audit di sicurezza perché danno permessi eccessivamente ampi "nel caso".
Principio introdotto: Automazione Su Processo Manuale
Crei gli script `deploy.sh` e `destroy.sh` che automatizzano tutto:
Un comando. Tutto accade. Consistente, ripetibile, documentabile.
Nuova architettura (ma ora in codice):
Terraform code
├── dev configuration (cheap, fast)
├── prod configuration (reliable, secure)
└── Shared resources definition
Deploy script automates:
├── Lambda build
├── Terraform initialization
├── Infrastructure creation
└── Frontend deploymentCosa cambia:
Nel Giorno 4, abbiamo costruito uno script di deployment (`deploy.sh`) che automatizza l'intero processo. Un comando fa tutto:
Finora: Esegui `./scripts/deploy.sh` a mano quando vuoi deployare.
Giorno 5: Non lo esegui. Lo fa GitHub. Tu solo fai push del codice.
Primo problema: I file di stato Terraform sul tuo laptop non funzionano per i team.
Soluzione: S3 backend con DynamoDB locks
Quando due persone deployano simultaneamente:
Il problema di sicurezza: Non puoi memorizzare le credenziali AWS in GitHub.
La soluzione: OIDC (OpenID Connect)
Invece di credenziali, GitHub genera un token crittografico che dice:
"Sono una GitHub Action legittima dal repository X, branch main, dall'utente Y."
AWS verifica questo token (è firmato crittograficamente). Nessuna credenziale necessaria.
Due workflow:
Workflow di deployment (`.github/workflows/deploy.yml`):
Workflow di distruzione (`.github/workflows/destroy.yml`):
START SIMPLE
Aggiungi complessità solo quando emerge un problema che la richiede
OGNI LAYER DOVREBBE ESSERE SOSTITUIBILE
Sostituisci OpenAI con Bedrock? Scambia un componente.
THE LEAST PRIVILEGE
- Dev ottiene ampi permessi (ambiente a basso rischio)
- Prod ottiene permessi stretti (alto rischio = accesso min)
L'INFRASTRUTTURA DOVREBBE ESSERE USA E GETTA
Se puoi eliminare tutto e ricrearlo con un comando, hai vinto. Non hai paura di sperimentare.
LA VISIBILITÀ BATTE L'INVISIBILITÀ
Quello che abbiamo costruito non è rivoluzionario in termini di tecnologia. Questi servizi esistono. Ma il viaggio è stato fantastico.🚀
I sistemi di produzione non sono magici. Sono intenzionali, documentati e costruiti strato dopo strato.
Questo Digital Twin è intenzionalmente un foglio bianco—costruito per capire l'architettura passo dopo passo.
Ma il valore reale non è in questo progetto. È nell'applicare questi principi a sistemi effettivi e complessi.
Ho un sistema di produzione nel mondo selvaggio: website-agent. E lo trovi live proprio su questo sito! È più sofisticato. Ed è stato costruito nel modo vecchio—infrastruttura manuale, deployment manuale, conoscenza implicita su cosa sta girando dove.
Se vuoi scoprire di più sul mio website agent, leggi qui
Nei prossimi mesi trasformerò website-agent usando esattamente quello che ho imparato questa settimana:
Infrastructure as Code: Ogni risorsa AWS definita in Terraform (non più click sulla Console AWS)
Multi-ambiente: Dev è economico e usa e getta. Prod è sicuro e affidabile. Stesso codice, configurazioni diverse.
Privilegi Minimi: Non "dagli tutti i permessi, nel caso". Invece: "Cosa ha effettivamente bisogno di fare questo servizio? Solo quello."
Deployment Automatici: Fai push del codice → GitHub Actions esegue → l'infrastruttura si aggiorna. Nessun intervento umano nel percorso critico.
Visibilità: Tutto nel controllo di versione. Puoi vedere la storia. Puoi capire le decisioni.
Il Digital Twin è stato il blueprint. Website-agent è dove testerò se il blueprint effettivamente funziona su sistemi reali.
Questo progetto è stato realizzato seguendo il corso "Generative and Agentic AI in Production" di Ed Donner, disponibile su Udemy.
Se sei interessato a questo viaggio, consiglio molto il corso!
Da quando uso Claude Code, il mio modo di sviluppare è cambiato. Non tanto perché scrive codice al posto mio, ma perché è diventato il mio pair programming partner: qualcuno con cui discutere scelte architetturali, validare pattern, ragionare su trade-off. Quando lavoro da sola, è facile restare incastrata nelle mie assunzioni. Avere Claude che fa […]
Oggi è il secondo giorno dal mio rientro. La mia testa continua a correre, a pensare, a tentare di mettere a terra tutte le idee e gli stimoli accumulati in questi giorni. Dall'altro lato continua a rivivere momenti, sorrisi, difficoltà affrontate, sensazioni scaturite dal parlare con altre persone, dal trovarsi davanti degli occhi che si […]