Cosa protegge davvero TLS su una connessione HTTPS Carica una pagina in http:// puro su una rete che non controlli, un aeroporto o il router di un bar, e tutto quello che invii viaggia come testo leggibile. Il percorso dell’URL, i cookie, i campi del form, la password in un POST di login: chiunque su quella rete con uno sniffer di pacchetti li legge mentre passano. TLS, Transport Layer Security, è il protocollo che blocca questo scenario. Si inserisce tra TCP e il protocollo applicativo, quindi quando HTTP inizia a parlare la connessione è già cifrata e legata a un’identità server verificata. HTTPS è semplicemente HTTP eseguito su quella connessione invece che su una in chiaro. ...

Ogni chiamata a un’API LLM ospitata manda il tuo prompt sul server di qualcun altro e ti fattura per token. Se perdi la connessione di rete, smette di rispondere. Ollama toglie di mezzo entrambi i problemi: scarica un modello open-weight sulla tua macchina e lo serve tramite un’API REST su localhost:11434. Un solo binario fa da gestore dei modelli, client di chat e server. Cosa fa davvero Ollama Ollama avvolge llama.cpp e motori di inferenza simili, così non devi mai toccare un flag del compilatore o un percorso di libreria CUDA. ollama pull llama3.2 scarica un file di modello quantizzato (formato GGUF) dal registro di Ollama invece che da Hugging Face, anche se può importare file GGUF anche da lì. Quando esegui il modello, quei pesi passano a un server in background: li carica in RAM (o in VRAM, se trova una GPU compatibile), li tiene residenti per qualche minuto dopo l’ultima richiesta così la successiva è veloce, e li scarica non appena smetti di fare domande. ...

Un endpoint di checkout che ridimensiona l’immagine di un prodotto, invia un’email di conferma e aggiorna un motore di raccomandazione prima di rispondere con 200 OK è veloce quanto il suo passaggio più lento. Se anche uno solo va in timeout, l’intera richiesta fallisce. Una coda di messaggi permette all’endpoint di passare quel lavoro come messaggi e rispondere subito, mentre worker separati lo prendono in carico con i propri tempi. ...

Ogni risorsa cloud che hai mai creato cliccando in una console web (una VM, un load balancer, un record DNS) si può descrivere anche in un file di testo e creare con un solo comando. Il file vive nel repository git, passa da una pull request, e riproduce lo stesso setup su un secondo account senza che nessuno debba ricordare quali nove impostazioni ha cambiato a mano. È questo che fa Terraform. ...

Cosa fa davvero una CDN a una richiesta Un utente a Tokyo che carica una pagina ospitata su un server in Virginia paga quella distanza due volte: una per far arrivare la richiesta, una per far tornare la risposta. La fibra ottica viaggia a una frazione fissa della velocità della luce, e quel solo tragitto costa già 150-200 ms di andata e ritorno prima che l’origine abbia fatto qualsiasi lavoro. Aggiungi una query al database e un salto di rete lento, e una pagina che sembra istantanea per chi sta vicino al server diventa lenta dall’altra parte del pianeta. ...

Una query che impiega 200ms sul tuo database impiega 200ms anche alla milionesima esecuzione, e ogni esecuzione compete per le stesse connessioni, lo stesso I/O su disco e la stessa CPU. Redis tiene la risposta in memoria, su un server che non fa altro, così la milionesima lettura costa un round trip di rete invece di un piano di query. Cosa fa davvero Redis come cache Redis è un key-value store in memoria. I valori vivono in RAM, quindi letture e scritture si misurano in tempi sotto il millisecondo invece delle decine o centinaia di millisecondi che costa una query relazionale una volta che entrano in gioco join, indici sotto pressione o un connection pool occupato. Si affianca al tuo database, non lo sostituisce: la tua applicazione interroga prima Redis e va al database solo quando Redis non ha la risposta. ...

Cosa c’è tra il browser e la tua app Punta il browser su example.com e la richiesta non tocca mai il processo che esegue il tuo codice. Incontra prima qualcos’altro: un server che legge la richiesta, decide quale backend deve rispondere, la inoltra lì e rimanda indietro la risposta come se l’avesse prodotta lui stesso. Quel server è un reverse proxy. Nginx, Caddy, Traefik e HAProxy fanno tutti questo lavoro, così come il load balancer davanti a un cluster Kubernetes. La disposizione non cambia mai: i client parlano con il proxy e con nient’altro. I server reali restano dietro, in qualunque numero e ovunque girino. ...

Fai il pull dell’ultimo main e Git si blocca con CONFLICT (content): Merge conflict in checkout.js. Risolvi il conflitto e nel log compare un commit chiamato Merge branch 'main' into feature/checkout, appoggiato sopra i tre commit che avevi effettivamente scritto tu. Quattro commit, una sola modifica reale. Un collega che legge quella storia il mese prossimo non riesce più a distinguerli. git merge e git rebase rispondono alla stessa domanda: come allineo il mio branch alle modifiche fatte altrove. Lasciano tracce molto diverse, e scegliere quello sbagliato su un branch condiviso causa danni reali. ...

Chiedi a un LLM generico qual è la politica di reso della tua azienda o cosa dicono i ticket di supporto della settimana scorsa, e otterrai o un “non lo so” o una risposta inventata ma plausibile. La sua conoscenza si ferma a quello che c’era nei dati di addestramento. Non ha mai visto i tuoi documenti e non può andare a cercarli a metà conversazione. La retrieval-augmented generation (RAG) risolve proprio questo: prima che il modello risponda, un passaggio separato trova il testo rilevante nei tuoi dati e lo passa al modello come parte del prompt. ...

docker build && docker push dal tuo portatile funziona finché qualcun altro non deve pubblicare la stessa immagine, oppure finché non deve succedere a ogni merge senza che tu sia davanti alla tastiera. GitHub Actions esegue quella build sui runner di GitHub, tagga l’immagine in base a cosa ha scatenato il workflow e la pubblica su un registry da cui il tuo step di deploy può fare il pull. Niente gira in locale. ...