Qual è la differenza tra scaling orizzontale e verticale?
Lo scaling verticale ingrandisce una singola istanza aggiungendo CPU, memoria o storage più veloce, mentre lo scaling orizzontale aggiunge più istanze e distribuisce il carico tra di esse dietro un load balancer. Lo scaling verticale è semplice e non richiede modifiche al codice ma incontra un tetto hardware e lascia un single point of failure; lo scaling orizzontale non ha di fatto un tetto e tollera la perdita di istanze, ma richiede che il carico sia stateless o conservi lo stato in un archivio esterno. I design cloud-native preferiscono lo scaling orizzontale e trattano quello verticale come un rapido passo iniziale.
Quando dovrei usare i container invece delle macchine virtuali?
Usa i container quando vuoi avvio rapido, alta densità e impacchettamento applicativo portabile e immutabile, soprattutto per microservizi e servizi stateless scalati orizzontalmente che condividono il kernel host. Usa le macchine virtuali quando ti serve un isolamento forte, un sistema operativo diverso o completo, controllo a livello di kernel, o per far girare software legacy che assume un OS intero. Molte architetture reali combinano entrambi, facendo girare container su nodi worker basati su VM.
Qual è la differenza tra IaaS, PaaS e serverless?
L'IaaS ti dà macchine virtuali, storage e rete grezzi, lasciando OS, runtime e applicazione come tua responsabilità, il che massimizza controllo e portabilità. La PaaS fornisce una piattaforma gestita che costruisce, distribuisce, scala e instrada il tuo codice così da saltare la gestione dei server, al costo di seguire le convenzioni della piattaforma. Il serverless va ancora oltre: il provider esegue il tuo codice per ogni evento, lo scala a zero quando inattivo e verso l'esterno sotto carico, e fattura per invocazione e tempo di esecuzione, spostando al provider tutta la pianificazione della capacità e le patch.
Come scelgo una regione cloud?
Scegli una regione pesando la latenza verso i tuoi utenti, i requisiti di residenza dei dati e conformità, il costo di calcolo ed egress in quella regione, e quali servizi sono effettivamente disponibili lì, poiché i cataloghi differiscono per regione. Per la maggior parte delle applicazioni dominano la latenza verso la base utenti principale e la residenza legale. Se servi un pubblico globale, combina una regione primaria con una CDN e considera il multi-regione solo quando gli obiettivi di latenza o disponibilità lo richiedono davvero.
Cos'è l'Infrastructure as Code e perché conta?
L'Infrastructure as Code definisce le tue risorse cloud in file di definizione sotto controllo di versione e le fa il provisioning automaticamente, invece di cliccare in una console. Conta perché rende gli ambienti riproducibili, revisionabili nelle pull request e auditabili, e ti permette di replicare ambienti di staging e produzione identici e di recuperarli dopo un disastro. Gli strumenti dichiarativi come Terraform fanno convergere le risorse a uno stato desiderato, così ri-eseguire la stessa definizione è sicuro e idempotente.
Come posso controllare e ridurre la mia bolletta cloud?
Comincia dalla visibilità: tagga ogni risorsa e attribuisci la spesa a team o prodotti così che il costo diventi una metrica di ingegneria anziché una fattura a sorpresa. Poi ottimizza - ridimensiona le istanze sovra-provisionate, elimina le risorse inattive, impegnati in reserved instance o savings plan per il carico di base costante, usa spot instance per il lavoro interrompibile e tieni d'occhio i costi di egress, che spesso dominano. Questa pratica continua di responsabilità sui costi tra ingegneria e finanza è nota come FinOps.
Qual è la differenza tra alta disponibilità e disaster recovery?
L'alta disponibilità riguarda il sopravvivere ai guasti ordinari di componenti all'interno di una regione tramite ridondanza e failover automatico, così che i guasti di singoli server, zone o repliche causino poco o nessun downtime. Il disaster recovery riguarda il ripristino del servizio dopo un evento su larga scala, come un'intera regione che diventa indisponibile, ed è definito da un recovery time objective e un recovery point objective. L'HA riduce la frequenza del downtime; il DR limita l'impatto quando qualcosa di grave accade comunque nonostante l'HA.
Come tengo le mie risorse di backend fuori dall'internet pubblico?
Colloca i servizi di backend e i database in subnet private all'interno di un VPC, dove le istanze non hanno IP pubblico né rotta in entrata da internet, ed esponi solo un load balancer o un API gateway in una subnet pubblica. L'accesso in uscita per aggiornamenti e API di terzi passa per un NAT gateway, che permette alle istanze private di iniziare connessioni senza essere raggiungibili dall'esterno. Combina questo con security group stretti, IAM a privilegio minimo e un web application firewall all'edge.
Cosa sono le availability zone e come dovrei usarle?
Le availability zone sono data center isolati all'interno di una regione, ciascuno con alimentazione, raffreddamento e rete indipendenti, collegati da link a bassa latenza. Le usi distribuendo istanze, repliche e standby di database su almeno due zone così che la perdita di una zona non abbatta il tuo carico. Il deployment multi-AZ è la base per l'alta disponibilità e di solito è molto più economico e semplice del passare al multi-regione.
Qual è la differenza tra deployment blue-green e canary?
Il deployment blue-green mantiene due ambienti di produzione completi e sposta tutto il traffico dalla vecchia alla nuova versione in una volta dopo la verifica, dando rollback istantaneo tornando indietro. Il deployment canary invece sposta una piccola fetta di traffico verso la nuova versione, osserva tasso di errore e latenza e aumenta gradualmente solo se le metriche restano sane. Il blue-green ottimizza per un passaggio istantaneo tutto-o-niente; il canary ottimizza per limitare il raggio d'impatto e cogliere i problemi prima della piena esposizione.
Perché la mia bolletta di egress cloud è così alta?
L'egress - i dati che lasciano la rete del provider verso internet o un'altra regione - è fatturato al gigabyte, mentre il traffico in entrata di solito è gratuito, quindi i design con molti dati o chiacchieroni e cross-region accumulano costi rapidamente. I colpevoli comuni sono la replica cross-region, i cache miss della CDN che fanno ripetuti pull dall'origine e le API che restituiscono payload grandi a molti utenti. Lo riduci servendo contenuti memorizzabili in cache tramite una CDN, mantenendo il traffico dentro una regione, comprimendo le risposte ed evitando movimenti di dati cross-region inutili.
Quando ho davvero bisogno di Kubernetes?
Hai bisogno di Kubernetes quando fai girare molti servizi containerizzati che richiedono scheduling automatico, self-healing, aggiornamenti rolling, service discovery e autoscaling orizzontale su un cluster, e hai la maturità operativa per gestirlo. Per un piccolo numero di servizi, una piattaforma di container gestita o una PaaS spesso ottiene lo stesso risultato con molta meno complessità. Adotta Kubernetes quando le sue astrazioni risolvono problemi reali che hai, non preventivamente, e preferisci un control plane gestito per non dover esercire tu stesso il cervello del cluster.
Qual è la differenza tra RTO e RPO?
Il recovery time objective (RTO) è quanto in fretta devi ripristinare il servizio dopo un'interruzione, e il recovery point objective (RPO) è quanta perdita di dati, misurata nel tempo, puoi tollerare. Un RTO stretto ti spinge verso architetture warm-standby o active-active sempre pronte, mentre un RPO stretto richiede replica frequente o sincrona. Entrambi sono decisioni di business: li imposti pesando il costo dell'architettura contro il costo di downtime e perdita di dati.
Dovrei usare le spot instance in produzione?
Le spot instance sono capacità in eccesso con uno sconto elevato che il provider può riprendersi con poco preavviso, quindi appartengono a carichi tolleranti ai guasti e interrompibili come job batch, runner di CI e tier web stateless fronteggiati da una coda o un load balancer. Non sono adatte a servizi stateful o critici per la latenza che non tollerano un'eviction improvvisa. Puoi far girare una grande quota di carichi idonei su spot per ridurre drasticamente i costi, purché diversifichi i tipi di istanza e gestisca con grazia le interruzioni.
Cos'è una service mesh e mi serve?
Una service mesh è un layer infrastrutturale, di solito implementato come proxy sidecar, che gestisce la rete servizio-a-servizio - bilanciamento del carico, retry, mutual TLS e telemetria - in modo trasparente al codice applicativo. Offre sicurezza e observability uniformi tra molti microservizi senza che ogni team le re-implementi. Ti serve quando hai abbastanza servizi da rendere gestione del traffico, cifratura e tracing coerenti un onere reale; per una manciata di servizi la latenza aggiuntiva e l'overhead operativo raramente ripagano.
Come dovrei gestire i segreti nell'infrastruttura cloud?
Non inserire mai segreti in codice, immagini o file di Infrastructure as Code; conservali in un secrets manager dedicato e iniettali a runtime tramite variabili d'ambiente o volumi montati con accesso strettamente limitato. Usa credenziali a vita breve e ruotate automaticamente e identità di carico (come i ruoli delle istanze o i service account) invece di chiavi statiche a lunga vita dove possibile. Audita gli accessi, cifra i segreti a riposo e in transito, e tieni lo state di Terraform - che può contenere segreti - in un backend protetto e con controllo degli accessi.
Cos'è lo zero trust in un contesto cloud?
Lo zero trust è un modello di sicurezza che non concede alcuna fiducia implicita basata sulla posizione di rete e invece verifica identità, dispositivo e contesto di ogni richiesta prima di concedere un accesso a privilegio minimo. Nel cloud sostituisce il vecchio perimetro della "rete interna fidata" con identità forte, mutual TLS tra servizi e policy imposta per ogni richiesta. Limita il movimento laterale: anche un attaccante che viola un componente non può raggiungere liberamente gli altri, perché ogni interazione è autenticata e autorizzata in modo indipendente.