Cloud Computing - Migrando mi base de datos y en el proceso recuperar mi vida personal.

PUBLICADO EL 20 DE AGO 2022 POR VICTOR CORNEJO

Espero haber logrado el impacto deseado con el titulo de este articulo, comparto que el manejo de los centros de datos consumen un gran esfuerzo de los equipos de IT.

No solo los equipos de Infraestructura se quejan de la sobre carga sino también los equipos de desarrollo se ven impactados buscado alternativas para manejar la carga que se generan en nuestras bases de datos.

La decisión de migrar nuestra base de datos a la nube no es fácil porque se deben considerar algunos aspectos que sino tenemos en cuenta podemos "morir" en el intento.

Cuando inicies el análisis para plantearte una migración te recomiendo que consideres los siguientes puntos.

Conoce tu ecosistema de aplicaciones y negocio.

Aunque parezca obvio pero es importante conocer cómo nuestras aplicaciones se comunican con la base de datos, versiones de drivers, volumen de información que se intercambian, etc.

Generalmente las aplicaciones no se diseñan considerando que la base de datos estará fuera de nuestra infraestructura local.

Regulaciones nacionales ó internacionales que debe cumplir la información que almacenas.

Con el tiempo es muy común que áreas gerenciales deseen subirse al tren de la nube e impulsen transformaciones con un entusiasmos desbordado.

Pero nunca debemos ignorar las regulaciones vigentes en nuestro país o en el país del datacenter que deseas utilizar. Hay sectores que son muy regulados como los Bancos, Aseguradoras y Servicios médicos por mencionar algunos; donde hay entes locales que velan por el cumplimiento de políticas con respecto al almacenamiento y disponibilidad de la información.

Consultas lentas por falta de indices y retorno de información innecesaria.

Las aplicaciones tradicionales están llenas de componentes que representan tablas de datos, es muy común que los programadores con poca experiencia realicen consultas abiertas que retornan todas las columnas de las tablas. Esto genera una carga fuerte sobre el motor de la base de datos. Pero el esfuerzo generalmente no compensa con la utilidad que él usuario hace de toda esa masa de datos.

Ademas podemos mencionar los cuellos de botella generados por la falta de mantenimientos sobre los indices de nuestras tablas.

En lo posible no migres a la nube creyendo que allá mejoraran los tiempos de respuesta, seguramente así será pero a cambio tendrás que pagar una alta factura por desperdicio de recursos.

No existe backup si nunca has restaurado uno.

Es fundamental tener una política actualizada sobre la generación y manejo de respaldos. Es de muchos conocidos que si nunca hemos completado el ciclo de restaurar una copia de respaldo, entonces nunca hemos tenido un respaldo.

Cuántas historias hay al rededor de una cinta magnética reutilizada por error o un respaldo que falla porque al momento de generarse faltaron incluirle los parámetros correctos del formato de caracteres.

Es común creer que al estar en la nube ya no será necesario hacer backups, pero esto no es necesariamente correcto. Seguramente nuestras políticas deberán ser ajustadas pero siempre debemos velar por tener un respaldo que nos permita recuperarnos de un incidente.

Los procesos de migración son oportunidades de mejora de nuestros sistemas.

No todo es malo en los procesos de migración de datos, podemos aprovechar este proceso para mejorar el "schema de datos actual haciendo revisiones de campos que se han dejado de utilizar o posiblemente nunca se utilizaron.

Reconstrucción o re-definición de indices que reflejen mejor el estado actual de nuestras soluciones.

La depuración de la data también puede ser considerada; actualizando la política de drenado de datos hacia "schemas" históricos.

Siempre es bueno consolidar lo logrado para prepararnos a evolucionar nuestras soluciones.

Tipos de migraciones que podemos realizar.

Hay veces que no es posible migrar de forma homogénea pero este escenario lo abordaremos luego; enfoquémonos en esos escenarios donde sí es posible.

Motores que podemos considerar para migrar de forma homogénea:

  • MySQL local hacia Amazon RDS MySQL ó Aurora MySQL, Google Cloud SQL for MySQL.

  • PostgreSQL hacia Aurora Postgres ó Amazon RDS Postgres, Google Cloud SQL for Postgres.

  • SQL Server ( diversas versiones ) hacia SQL Server de Amazon, Google Cloud SQL for SQL Server y por supuesto SQL Azure.

Este tipo de migración definitivamente será menos compleja pero siempre es un reto realizarla.

Motores que podemos considerar para migrar de forma heterogénea.

Podríamos asegurar que es posible movernos de un motor a otro pero dependiendo de la complejidad de nuestros sistemas sugiero servicios que parecen razonables evaluarlos.

  • Si localmente trabajamos con Oracle parece natural moverse a un servicio de Postgres o viceversa. Existen herramientas que pueden ayudarnos en este proceso.

  • Si nuestra base es SQL Server también podemos considerar usar Mysql o Postgres. Igualmente hay herramientas que nos pueden apoyar con esta tarea.

Realmente la migración heterogénea es un reto mayor, nos demandara un mayor conocimiento de nuestros sistemas y de los motores de bases de datos a los que deseamos movernos.

No solo hay que considerar la conversión de tipos de datos sino qué tanto será posible reutilizar los procedimientos almacenados o tendremos que re-escribirlo.

Documentar permisos tanto de usuarios finales como de los equipos de tecnología.

Es fundamental documentar todos los permisos de todos los usuarios que son funcionales utilizados en las aplicaciones, como también de la aplicación.

Un porcentaje alto de errores en los sistemas luego de una migración son los permisos al momento de consultar datos o ejecutar procedimientos almacenados.

Estudia el trafico interno y hacia el internet.

He conocido de casos donde en el análisis no se considero el trafico actual que se tiene en la infraestructura; no hablo solo de la red de nuestra oficina sino aquellas redes externas que están en sucursales o puntos remotos de servicio.

Definitivamente al tener fuera de tu infraestructura la base de datos, el trafico hacia internet cambiara. Los tiempos de respuesta pueden variar e impactar a nuestras aplicaciones.

Estos cambios se deben revisar para poder recomendar o en su caso considerar en el costo operativo:

  • Aumentos de ancho de banda en las sucursales o oficinas remotas.

  • Compra de equipos que gestionen VPN o algún otro tipo de infraestructura de seguridad para ese trafico externo que se estaría incorporando.

  • Enlaces redundantes con diferentes proveedores para garantizar el mayor tiempo posible que nuestra red institucional puede salir hacia el proveedor de la nube.

No hay que subestimar el impacto en la red, mas si la migración es heterogénea.

Diseña un plan y ejecútalo al pie de la letra.

Si luego de haber realizado los estudios necesarios para identificar las ventajas y desventajas que tendrás específicamente para tu infraestructura y sistemas; y aun deseas migrar, lo mejor es que tomes conciencia que "la disciplina, tarde o temprano, vencerá a la inteligencia" dicho popular japonés que Yokoi Kenji ha hecho famoso en redes sociales, pero que tiene mucha sabiduría detrás.

Construye un plan lo más real posible, y motiva a todo el equipo a ejecutarlo de la forma mas disciplinada que les sea posible.

Documenta los riesgo y trabaja por reducirlos con planes de contingencia que ayuden a que la organización pueda seguir generando ingresos mientras se completa la migración.

Fuentes:

Última actualización