I was chatting with a consultant friend a couple of weeks ago. His main role at the moment is working on projects moving SQL Server databases to the cloud (AWS and Azure) and on mass. His story reminds me of the projects years ago on P2V projects where the physical memory and cores might just be mapped to virtual memory and virtual cores and then giving the VMWare admin the task of reviewing this based on consumption otherwise the benefits of virtualization were negated.
Well with cloud migrations, the same methodology is all too often still applied for simplicity and speed but the shock comes when the cloud subscription bills come rolling in. It can again be an avoidable waste of money, in this case, opex as opposed to capex.
For some reason there is often a reluctance for the project owners to review current usage, consumption and performance beforehand and accurately predict the sizing that is required for cloud migration. The problem with tackling the issue post-migration is there is more risk involved, more firefighting and how quickly can you do this while the bills are still coming in each month.
So looking forward to hearing what Denis O’Sullivan and Peter O'Connell have to say on the 14th April with their live webcast: Accurately Sizing and Scaling Your Cloud Database.