Consulenza Cloud
Il cloud non è di per sé più economico né più affidabile: lo diventa se l'architettura è disegnata per quello che serve davvero. La maggior parte delle infrastrutture che mi capita di riordinare sono nate copiando uno schema pensato per un carico dieci volte superiore, e pagano ogni mese quella scelta.
Lavoro senza vincoli di fornitore: progetto su AWS, Google Cloud, Aruba Cloud e Linode/Akamai, e la scelta la fa il caso, non un accordo commerciale.
Scegliere il fornitore: cosa cambia davvero fra AWS, Google Cloud, Aruba e Linode
Le differenze che contano sono meno di quante sembrino. Per un'applicazione ordinaria — un backend, un database, dello spazio per i file — tutti e quattro fanno lo stesso lavoro. Le differenze emergono altrove:
- Servizi gestiti. AWS e Google Cloud offrono molti più servizi pronti. Utili quando servono, un vincolo quando ti ci leghi senza motivo.
- Prevedibilità della spesa. Linode e Aruba hanno listini semplici; su AWS e Google Cloud la spesa dipende dal traffico e dall'uso, e va tenuta d'occhio.
- Collocazione dei dati. Per alcune attività il fatto che i dati restino in Italia o nell'Unione Europea non è una preferenza ma un requisito.
- Competenza necessaria. Un'infrastruttura su AWS ben fatta richiede più conoscenza da mantenere di due macchine su Linode che fanno la stessa cosa.
Progetto in modo che il passaggio da un fornitore all'altro resti possibile: componenti standard, configurazione descritta in codice, e uso dei servizi proprietari solo dove danno un vantaggio che vale il vincolo.
Progettare un'architettura scalabile senza sovradimensionare
«Scalabile» non vuol dire grande: vuol dire che può crescere quando serve. Un'architettura sovradimensionata al primo giorno costa da subito e complica la manutenzione per un carico che forse non arriverà mai.
Il criterio che seguo è separare ciò che deve poter crescere da ciò che non ne ha bisogno, e rendere possibile la crescita senza riscrivere. In pratica significa applicazioni che non conservano stato al proprio interno, file su spazio oggetti invece che su disco locale, e configurazione fuori dal codice.
Fatte queste tre cose, passare da una macchina a dieci è una decisione operativa, non un progetto.
Migrazione al cloud: inventario, prove, finestra di passaggio
Una migrazione va male quasi sempre per la stessa ragione: si scopre a metà che qualcosa dipendeva da qualcos'altro che nessuno aveva censito. Per questo la prima fase è un inventario di cosa gira davvero, cosa parla con cosa e quali sono i punti fermi.
Poi si prova. Si ricostruisce l'ambiente di destinazione, ci si sposta un carico non critico, si misura. Solo dopo si concorda la finestra di passaggio per il resto, con una condizione decisa prima: cosa deve funzionare perché il passaggio sia considerato riuscito, e cosa si fa se non funziona.
La strada del ritorno resta aperta finché non è chiaro che tutto regge. Smontare il vecchio ambiente è l'ultimo passo, non il primo.
Sicurezza, backup e ripristino verificato
- Superficie ridotta. Quello che non deve essere raggiungibile da internet non lo è: accesso amministrativo su rete privata, servizi interni non esposti.
- Segreti fuori dal codice. Chiavi e password in un archivio dedicato, con accesso tracciato, non nei file di configurazione.
- Aggiornamenti. Un sistema operativo non aggiornato è la via d'ingresso più comune, e la meno interessante da raccontare dopo.
- Backup provati. Un backup mai ripristinato non è un backup: è un file. Il ripristino va provato periodicamente e cronometrato, perché il tempo di ripristino è un dato che serve conoscere prima di averne bisogno.
Ottimizzazione dei costi ricorrenti: dove si spreca davvero
Nella mia esperienza gli sprechi ricorrenti stanno quasi sempre negli stessi posti: macchine dimensionate per un picco che dura un'ora al giorno, ambienti di collaudo accesi anche di notte e nei fine settimana, dischi e istantanee di cose spente da mesi, traffico in uscita che passa da percorsi più cari del necessario, e servizi gestiti scelti per comodità dove un componente semplice sarebbe bastato.
La revisione parte dalla fattura, non dall'architettura: si guarda cosa costa davvero, in ordine decrescente, e si risale a cosa lo genera. È un lavoro noioso che spesso riduce la spesa mensile senza toccare una riga di codice applicativo.
Gestione continuativa o passaggio di consegne
Alla fine di un progetto ci sono due strade oneste. La prima è che continui a occuparmene io, con monitoraggio e manutenzione. La seconda è che l'infrastruttura passi al team interno: in quel caso il lavoro comprende la documentazione e l'affiancamento necessari perché il passaggio sia reale e non formale.
In entrambi i casi l'infrastruttura resta descritta in codice e leggibile da chiunque: nessun pezzo che funziona solo perché lo conosco io. Se il passo successivo è automatizzare i rilasci, se ne parla nella consulenza DevOps.
Parliamone
Descrivimi in poche righe la situazione e cosa vorresti ottenere: rispondo con una prima valutazione e con le domande che servono a inquadrare il lavoro.
- E-mail: angelo.derrico.itconsultant@gmail.com
- WhatsApp: +39 347 857 6817
- PEC: angelo.derrico@pec.cloud