Cloud Azure e DevOps
Infrastruttura come codice, pipeline che distribuiscono più volte al giorno, una base di sicurezza deny-by-default e un conto che resta prevedibile. È così che costruiamo un ambiente cloud, ed è così che gestiamo il nostro.
Il lavoro DevOps in concreto
- Pipeline. Build, test, scansione di sicurezza e deploy in GitHub Actions, con credenziali federate al posto di segreti memorizzati e ogni action bloccata tramite hash.
- Infrastruttura come codice. Terraform per tutto, rivisto come piano prima di essere applicato, con rilevamento pianificato del drift che segnala ciò che qualcuno ha modificato a mano.
- Rilascio del database. Modifiche dello schema come migrazioni versionate eseguite nella pipeline, così che non possa verificarsi un deploy che rilascia il codice senza il suo schema.
- Monitoraggio e avvisi. Log, metriche e trace in un unico workspace, con avvisi che raggiungono una persona solo quando uno sviluppatore potrebbe intervenire.
- Controllo dei costi. Livelli dimensionati correttamente, prezzi a consumo dove il carico è a picchi e un conto mensile che qualcuno legge davvero.
Con che cosa costruiamo
Ogni risorsa è dichiarata in Terraform e distribuita da GitHub Actions con credenziali federate. Nulla viene configurato a colpi di clic in un portale, né sui nostri ambienti né sui Suoi.
Calcolo
Azure Functions su .NET 10 con isolated worker per l’API e 40 job pianificati; i Container Apps Jobs eseguono i deploy del database e le migrazioni EF Core.
Dati
Azure SQL con row-level security e colonne Always Encrypted sotto chiavi gestite dal cliente in Key Vault; Blob Storage per documenti e PDF firmati.
Front end
Due Static Web Apps, il portale e questo sito, entrambe servite con una Content Security Policy rigorosa e pre-renderizzate dove i crawler hanno bisogno di HTML.
Identità
Entra ID per persone e gruppi, identità gestite assegnate dall’utente per ogni workload, OIDC da GitHub Actions. Nessuna credenziale di lunga durata nella pipeline.
Osservabilità
Application Insights e Log Analytics con regole di avviso che raggiungono il team come messaggi Teams. Diventano avvisi solo i segnali su cui uno sviluppatore può intervenire.
Governance
Policy dei gruppi di risorse, blocchi di gestione, protezione dall’eliminazione definitiva e impostazioni di diagnostica, tutti dichiarati in Terraform con il motivo accanto a ciascuna regola.
Disciplina dei costi
I nostri principi di ingegneria ordinano le priorità in un ordine fisso: prima i costi, poi la sicurezza, poi la modernità, poi le prestazioni. Un tetto di spesa viene fissato prima di disegnare l’architettura, e ogni decisione di progettazione viene verificata rispetto ad esso. In pratica significa prezzi a consumo anziché server sempre attivi dove il carico è a picchi, un livello di database dimensionato correttamente anziché quello consigliato dal fornitore, e avvisi costruiti con servizi già presenti nella sottoscrizione anziché con un prodotto di reperibilità a pagamento.
Base di sicurezza
- I firewall negano per impostazione predefinita; SQL è raggiungibile solo dalla subnet delle Functions.
- I segreti esistono solo in Key Vault e vengono letti tramite identità gestite.
- Le colonne con dati personali e finanziari sono Always Encrypted, quindi nemmeno un amministratore del database può leggerle.
- Action e immagini dei container sono bloccate tramite hash; gli aggiornamenti delle dipendenze arrivano come pull request revisionate e un avviso di sicurezza comporta un aggiornamento incondizionato.
- CodeQL gira a ogni push, i piani Terraform vengono validati prima dell’applicazione e il drift viene rilevato a intervalli pianificati.
Il nostro storico sul cloud
Più di 20 pipeline CI/CD realizzate, release ogni due settimane trasformate in deploy giornalieri, tempo di rilascio ridotto da quattro ore a 25 minuti, spesa Azure ridotta del 30% su una piattaforma. Dati tratti dal nostro storico di realizzazioni.
Selezione mirata, non improvvisata
Il DevOps è un ruolo per cui selezioniamo in modo mirato: il nostro storico di posizioni aperte comprende un DevOps engineer e un intervistatore tecnico dedicato al DevOps, così i candidati sono valutati da chi svolge il lavoro e non da un generalista che legge una checklist.
Vuole il Suo ambiente Azure gestito come codice, con un conto più leggero?
Ci invii un accesso in sola lettura alla Sua sottoscrizione o una descrizione di ciò che gira dove. Riceve una valutazione scritta e un piano entro un giorno lavorativo.