Stavo chattando con un amico consulente un paio di settimane fa. Il suo ruolo principale al momento è lavorare su progetti che spostano i database di SQL Server sul cloud (AWS e Azure) e su massa. La sua storia mi ricorda i progetti di anni fa su progetti P2V in cui la memoria fisica e i core potevano essere semplicemente mappati su memoria virtuale e core virtuali e quindi affidando all'amministratore di VMWare il compito di rivederlo in base al consumo, altrimenti i vantaggi della virtualizzazione sarebbero stati annullati.
Bene, con le migrazioni cloud, la stessa metodologia è ancora troppo spesso applicata per semplicità e velocità, ma lo shock arriva quando arrivano le bollette dell'abbonamento cloud. Può essere ancora una volta uno spreco di denaro evitabile, in questo caso, opex anziché capex .
Per qualche motivo, i proprietari dei progetti sono spesso riluttanti a rivedere in anticipo l'utilizzo, il consumo e le prestazioni attuali e prevedere con precisione il dimensionamento necessario per la migrazione al cloud. Il problema nell'affrontare il problema dopo la migrazione è che ci sono più rischi coinvolti, più antincendio e quanto velocemente puoi farlo mentre le bollette stanno ancora arrivando ogni mese.
Quindi non vedo l'ora di ascoltare ciò che Denis O'Sullivan e Peter O'Connell hanno da dire il 14 aprile con il loro webcast dal vivo:dimensionamento accurato e ridimensionamento del database cloud.
