Ingegneria cloud e DevOps, dalla migrazione al FinOps

Una singola applicazione con un’architettura pulita si sposta in poche settimane. Un ambiente completo è un programma che si misura in trimestri, e la risposta onesta dipende da quanti carichi di lavoro ci sono, da quanto la base di codice dà per scontato l’ambiente attuale e da quanto si può spostare così com’è invece di essere rifatto. Partiamo da un assessment che classifica ogni carico di lavoro e vi consegna un piano sequenziato con un modello di costo.

Nell’ordine: rendere la spesa visibile e attribuita, eliminare ciò che nessuno usa, ridimensionare ciò che è sovradimensionato, poi impegnarsi su capacità riservata o savings plan per la base stabile. Le modifiche architetturali — tiering dello storage, autoscaling, spostamento dei batch su capacità spot — vengono per ultime, perché portano il rischio più alto rispetto al ritorno. La maggior parte degli ambienti trova risparmi a doppia cifra percentuale prima di arrivare a quel passaggio.

Spesso no. Se gestite una manciata di servizi, una piattaforma a container gestita o serverless costerà meno da gestire e richiederà molta meno competenza per essere usata in sicurezza. Kubernetes ripaga quando avete molti team che rilasciano molti servizi e vi serve una piattaforma coerente sotto di loro. Vi diremo da che parte di quella linea vi trovate, anche quando la risposta ci toglie lavoro.

Di solito quello che il vostro team già conosce, a meno che un requisito specifico non lo escluda — residenza dei dati in una determinata giurisdizione, un servizio gestito che non ha equivalenti altrove o accordi enterprise già in essere. Il multi-cloud per impostazione predefinita è costoso e raramente ripaga la propria complessità; il multi-cloud per una ragione dichiarata va bene.