Estuve charlando con un amigo consultor hace un par de semanas. Su función principal en este momento es trabajar en proyectos que mueven bases de datos de SQL Server a la nube (AWS y Azure) y en masa. Su historia me recuerda los proyectos de hace años en proyectos P2V en los que la memoria física y los núcleos podrían asignarse a memoria virtual y núcleos virtuales y luego darle al administrador de VMWare la tarea de revisar esto en función del consumo; de lo contrario, los beneficios de la virtualización serían negados.
Bueno, con las migraciones a la nube, la misma metodología todavía se aplica con demasiada frecuencia por simplicidad y velocidad, pero el impacto llega cuando llegan las facturas de suscripción a la nube. Nuevamente, puede ser una pérdida de dinero evitable, en este caso, gastos operativos en lugar de gastos de capital. .
Por alguna razón, a menudo los propietarios del proyecto se muestran reacios a revisar el uso, el consumo y el rendimiento actuales de antemano y predecir con precisión el tamaño que se requiere para la migración a la nube. El problema de abordar el problema después de la migración es que hay más riesgos involucrados, más extinción de incendios y qué tan rápido puede hacerlo mientras las facturas siguen llegando cada mes.
Así que estoy ansioso por escuchar lo que Denis O'Sullivan y Peter O'Connell tienen que decir el 14 de abril con su webcast en vivo:Dimensionamiento y escalado precisos de su base de datos en la nube.
