Ik was een paar weken geleden aan het chatten met een bevriende adviseur. Zijn belangrijkste rol op dit moment is het werken aan projecten die SQL Server-databases naar de cloud (AWS en Azure) en massaal verplaatsen. Zijn verhaal doet me denken aan de projecten van jaren geleden op P2V-projecten waarbij het fysieke geheugen en de kernen misschien gewoon werden toegewezen aan virtueel geheugen en virtuele kernen en de VMWare-beheerder vervolgens de taak gaf om dit te beoordelen op basis van verbruik, anders zouden de voordelen van virtualisatie teniet worden gedaan.
Welnu, bij cloudmigraties wordt dezelfde methode maar al te vaak nog steeds toegepast voor eenvoud en snelheid, maar de schok komt wanneer de rekeningen van het cloudabonnement binnenkomen. Het kan opnieuw een vermijdbare verspilling van geld zijn, in dit geval opex in tegenstelling tot capex .
Om de een of andere reden zijn de projecteigenaren vaak terughoudend om het huidige gebruik, het verbruik en de prestaties vooraf te beoordelen en nauwkeurig de omvang te voorspellen die nodig is voor cloudmigratie. Het probleem met het aanpakken van het probleem na de migratie is dat er meer risico's aan verbonden zijn, meer brandbestrijding en hoe snel kun je dit doen terwijl de rekeningen nog elke maand binnenkomen.
Dus ik kijk ernaar uit om te horen wat Denis O'Sullivan en Peter O'Connell op 14 april te zeggen hebben met hun live webcast:Accurately Sizing and Scaling Your Cloud Database.