Eu estava conversando com um amigo consultor algumas semanas atrás. Sua principal função no momento é trabalhar em projetos que movem bancos de dados SQL Server para a nuvem (AWS e Azure) e em massa. Sua história me lembra dos projetos de anos atrás em projetos P2V onde a memória física e os núcleos podem ser mapeados para memória virtual e núcleos virtuais e, em seguida, dar ao administrador do VMWare a tarefa de revisar isso com base no consumo, caso contrário, os benefícios da virtualização seriam negados.

Bem, com as migrações para a nuvem, a mesma metodologia ainda é aplicada com muita frequência para simplicidade e velocidade, mas o choque vem quando as contas de assinatura da nuvem chegam. Pode ser novamente um desperdício de dinheiro evitável, neste caso, opex em oposição ao capex .

Por alguma razão, muitas vezes há uma relutância dos proprietários do projeto em revisar o uso, consumo e desempenho atuais com antecedência e prever com precisão o dimensionamento necessário para a migração para a nuvem. O problema de lidar com o problema pós-migração é que há mais risco envolvido, mais combate a incêndios e com que rapidez você pode fazer isso enquanto as contas ainda estão chegando a cada mês.

Então, ansioso para ouvir o que Denis O'Sullivan e Peter O'Connell têm a dizer no dia 14 de abril com seu webcast ao vivo:Dimensionar e dimensionar com precisão seu banco de dados em nuvem.