Consulenza cloud

Quando serve un consulente cloud

Le aziende mi contattano di solito per uno di questi tre motivi:

• Costi fuori controllo, e nessuno sa dire con precisione dove finiscono i soldi.
• Bisogna scegliere un provider, o decidere se restare su quello attuale, e la scelta peserà per anni.
• C'è una migrazione da fare: verso il cloud, da un provider all'altro, o in parte fuori dal cloud.

Spesso il punto di partenza è una revisione dell'infrastruttura che c'è: cosa costa, dove sono i rischi, cosa conviene cambiare prima.

Architettura e infrastruttura cloud

La mia esperienza in datacenter e sul cloud mi permette di affrontare migrazioni di ogni tipo: da on-premise verso il cloud, da un cloud provider a un altro, verso configurazioni ibride o multi-cloud, oppure nella direzione opposta, dal cloud al bare metal. La direzione cambia, il modo di lavorare resta lo stesso.

Nelle configurazioni ibride e multi-cloud, prima di tutto il resto servono due cose: un piano di networking completo, che spieghi come i diversi ambienti parlano tra loro, e piani di alta affidabilità e disaster recovery, che dicano cosa succede quando un pezzo viene a mancare. Senza questi due elementi si aggiunge complessità senza ottenere i benefici che ci si aspettava.

Buone pratiche, Infrastructure as Code e Kubernetes permettono di progettare con il giusto grado di indipendenza dal cloud provider: non un'astrazione totale, costosa e spesso inutile, ma abbastanza libertà da poter adottare configurazioni ibride e migrare quando serve.

È un tema sempre meno teorico. In un momento in cui la capacità di calcolo scarseggia, a cominciare dalle GPU, poter spostare un carico di lavoro dove la capacità c'è, o dove costa meno, è un vantaggio concreto.

Su ibrido e multi-cloud la mia regola è una sola: tenere sotto controllo la complessità. Si aggiunge un secondo provider, o un pezzo on-premise, quando c'è un motivo concreto (costi, capacità, vincoli sui dati), non per principio.

Sicurezza e conformità fanno parte del progetto fin dall'inizio: gestione delle identità e dei permessi, segmentazione della rete, gestione dei segreti, backup e disaster recovery, residenza dei dati (scelta delle region e percorsi dei dati entro l'Unione Europea, dove il GDPR o il settore lo richiedono). Ho seguito la parte tecnica di percorsi di certificazione ISO 27001, e so cosa significa tradurre i requisiti in configurazioni verificabili.

Migrazione cloud

Quando una migrazione fallisce, raramente è colpa della tecnologia. Più spesso è il modo in cui viene gestita: tutto il rischio concentrato nel cutover, poca visibilità sui dettagli operativi, e un team che si ritrova a mettere le mani su sistemi che non ha costruito.

La migrazione la progettiamo e la realizziamo insieme, in Infrastructure as Code: ogni passaggio è automatizzato, tracciabile e reversibile.

1. Analisi. Cosa c'è oggi, come funziona davvero, dove stanno le dipendenze e i rischi.
2. Strategia. Cosa migrare, in che ordine, verso dove, e cosa invece conviene lasciare dov'è.
3. Implementazione incrementale. I servizi si spostano un passo alla volta, ciascuno con il suo piano di rollback, invece di concentrare tutto il rischio in un unico cutover.
4. Accompagnamento. A migrazione conclusa resto sul progetto finché la nuova infrastruttura non è stabile e il team non la gestisce da solo.

Il team al centro della migrazione

Il team interno sta al centro della migrazione. Deve fare suo il cambiamento ed esserne protagonista, non spettatore: una migrazione decisa e realizzata solo dall'esterno non dura, non resta stabile e col tempo diventa difficile da gestire.

Per questo il team partecipa alle scelte, lavora all'implementazione insieme a me e, alla fine, la nuova infrastruttura è sua.

Cloud repatriation: quando ha senso tornare indietro

Non tutto deve per forza stare nel cloud pubblico. Riportare alcuni carichi di lavoro on-premise o su bare metal ha senso quando sono stabili e prevedibili, quando i costi del cloud crescono più del valore che portano, o quando servono risorse, come le GPU, che il cloud fatica a garantire. Ne ha meno per carichi molto variabili, o quando il team non ha le competenze per gestire l'hardware.

Spesso la soluzione migliore è ibrida: ogni carico di lavoro dove rende meglio. E l'approccio in Infrastructure as Code fa sì che anche questa scelta resti reversibile.

Costi cloud sotto controllo

Ridurre la spesa cloud è spesso il primo risultato concreto di una collaborazione. Nei casi che ho seguito il risparmio è stato tra il 20 e il 40 per cento, e l'intervento si è ripagato in pochi mesi.

Il grosso viene da tre cose: il dimensionamento corretto delle risorse (rightsizing), che quasi sempre sono più grandi del necessario; l'eliminazione di quello che non serve più, come ambienti dimenticati, volumi orfani e servizi mai spenti; l'ottimizzazione del traffico di rete, che sul cloud può incidere in maniera rilevante.

AWS e Google Cloud

Ho un'ampia esperienza su AWS e Google Cloud, su container e Kubernetes, sia nelle versioni gestite (EKS, GKE) sia installati e gestiti in proprio, e su infrastrutture on-premise basate su macchine virtuali. Tra i lavori recenti: una piattaforma multi-cloud ed edge su AWS, Google Cloud e Proxmox per una startup deep-tech, con accesso alle GPU e costi sotto controllo, e una piattaforma di observability open source distribuita tra datacenter di proprietà e cloud provider.

Consulenza AWS

Su AWS lavoro soprattutto su networking, organizzazione degli account con AWS Organizations, multi-tenancy e isolamento tra ambienti e clienti, container con EKS ed ECS, infrastruttura per i carichi di lavoro AI, e Infrastructure as Code con Terraform.

Il ruolo dell'AI

L'AI ha ormai un ruolo centrale nella gestione dell'infrastruttura: i modelli linguistici conoscono bene l'Infrastructure as Code e nel debugging sono efficaci. Un'analisi assistita dall'AI aiuta a far emergere il drift infrastrutturale, le dipendenze nascoste e i rischi prima ancora di cominciare a migrare.

Funziona però a una condizione: gli agenti devono lavorare dentro un harness completo, cioè con il contesto, gli strumenti e il modo di lavorare giusti (il repository dell'infrastruttura, la documentazione, la possibilità di lanciare un terraform plan e i test, di proporre modifiche tramite pull request), con dei guardrail che delimitano cosa possono fare e con procedure operative chiare su come si procede e chi approva.

Come lavoro

Si parte sempre da una revisione di quello che c'è: architettura, costi, rischi, dipendenze. Da lì la forma della collaborazione dipende dal problema.

• Sessione singola. Una revisione dell'architettura, una seconda opinione sulla scelta del provider, un piano di riduzione dei costi.
• Progetto. Una migrazione, una riorganizzazione degli account e della rete, un intervento sui costi con obiettivi misurabili.
• Collaborazione fractional. Lavoro continuativo accanto al team che gestisce l'infrastruttura cloud, quando serve esperienza senior ma non una figura a tempo pieno.

In ogni caso il team interno partecipa alle scelte e all'implementazione: l'infrastruttura, alla fine, è sua.