Así que todos hemos oído hablar de la nube y al menos hemos escuchado sobre la migración a la nube. ¿Pero qué implica realmente? Actualmente formo parte de un equipo encargado de transferir una base de datos local a la nube. Y esta base de datos local tiene un tamaño total de casi un terabyte. Y así, este artículo es un informe de experiencia sobre algunos de los problemas y soluciones a los que me he enfrentado. Y luego algunos consejos generales que daría a los equipos en el futuro. Y esta experiencia de la que voy a hablar es realmente una pequeña línea de tiempo en comparación con el gran panorama general de todo el proyecto. Pero antes de sumergirnos en eso, primero respondamos «¿Por qué?» ¿Por qué la nube? Bueno, la nube es genial y IBM está apostando todo a la tecnología en la nube. Pero más específicamente, nos gusta mucho la nube por su recuperación ante desastres y por sus características de escalabilidad. Y así, llegamos a la presentación de hoy. En esta experiencia, formé parte de un equipo encargado de realizar pruebas de rendimiento para cada tipo de base de datos, para asegurarnos científicamente de que cambiar a la nube realmente sea mejor para nuestro equipo y nuestro producto. Y así, tuvimos que trabajar en tres problemas principales. Primero, ¿cómo íbamos a probar la nube? Luego, ¿qué tipo de métricas nos ayudaban a demostrar la calidad del rendimiento? Y finalmente, ¿cómo obtenemos estos resultados de métricas y los presentamos adecuadamente?
Índice
Prueba de la nube
Entonces, ¿cómo probamos la nube? Bueno, mi equipo configuró un entorno en la nube y creamos una instancia de prueba de la base de datos copiando una gran cantidad de tablas y llenando esas tablas con datos generados automáticamente. De esta manera, no tenemos que transferir toda la base de datos a la nube, darse cuenta de que no funciona cuando la estamos probando y luego sentirnos tristes por todo el esfuerzo desperdiciado. De esta manera, tenemos dos instancias de la base de datos en ambos entornos y podemos enviar consultas a ambas y emular el rendimiento que obtendremos cuando finalmente traslademos la base de datos a la nube. Así que tenemos nuestra configuración de prueba lista.
Métricas
¿Qué tipo de métricas nos ayudan a demostrar la calidad del rendimiento? Bueno, después de bastante discusión, mi equipo redujo las cosas a cinco aspectos principales: uso de CPU, uso de memoria, E/S de disco, latencia y esperas de bloqueo. Esto nos dará una base general sólida y suficiente información para tomar una decisión racional sobre el cambio.
Resultados y presentación
¿Cómo obtenemos estos resultados de métricas y los presentamos adecuadamente? Bueno, este problema, de los tres, fue el más intenso y específicamente mi trabajo consistía en crear el conjunto de pruebas que se utilizaría para estresar las bases de datos. El conjunto de pruebas que creé tenía miles de consultas y cada una de las cuatro operaciones CRUD diferentes, y luego el resto de mi equipo configuró un sistema de monitoreo y una consulta de métricas para ejecutarse en paralelo con las operaciones CRUD. Entonces, mientras las operaciones CRUD están estresando las bases de datos, estamos obteniendo todas las métricas que necesitamos. Configurar este conjunto de pruebas nos planteó muchos problemas divertidos con los que tuvimos que lidiar. Desde esos molestos errores SQL que no te dan ninguna explicación sobre qué está mal o cómo solucionarlo, hasta descubrir que nuestros archivos de registro se sobrescribían a mitad de la prueba. Afortunadamente, mi equipo está lleno de verdaderos profesionales, así que superamos todos los obstáculos y lo resolvimos. Una vez que terminamos nuestras pruebas de rendimiento y recopilamos las métricas, creamos una serie de scripts en Python para analizar la información, compilar los resultados y generar visualizaciones. De esta manera, fue muy fácil para nuestra dirección y ejecutivos leer los resultados. Y, sorprendentemente, la nube fue más rápida. Y mucho más rápida. Especialmente en cuanto a la CPU, la memoria y la E/S de disco, superó con creces la versión local.
Consejos generales para futuros equipos
Ahora, sé que la migración a la nube es un proceso muy lucrativo con muchas partes móviles, por lo que algunos consejos generales que daría a los equipos en el futuro son comunicarse de manera exhaustiva y planificar tiempo extra. Comenzando por la comunicación. Como desarrollador junior, esta es la primera vez que hago algo relacionado con la migración a la nube, y mucho menos algo de esta escala. Así que muchas veces sentí que no veía realmente el panorama general y me sentía un poco excluido. Por eso tuve que reunirme mucho con mis líderes y el resto de mi equipo para discutir el trabajo que habíamos completado, el trabajo que todavía teníamos que hacer y hacia dónde íbamos. Por lo tanto, para los equipos en el futuro, recomiendo encarecidamente que sean consistentes en asegurarse de que todos estén en la misma página, incluso si puede parecer un poco redundante.
Luego, siempre planifiquen tiempo extra. Siempre habrá esos problemas divertidos que surgen y que simplemente no se pueden planificar. Y así, especialmente si se comprometen con una fecha límite específica, asegúrense de darse margen suficiente para tener el tiempo necesario para resolver esos problemas. Y sé que este consejo es súper genérico y se puede aplicar literalmente a cualquier tipo de proyecto, pero sin embargo, se aplica aquí con la migración a la nube.
Así que si puedes sacar algo de este artículo, ¡sabe que la nube realmente es genial! Y aunque este proceso puede ser desafiante, vale la pena el esfuerzo y deberías considerarlo. Gracias por leer. Si te ha gustado este artículo, asegúrate de dejar un comentario y suscribirte.
| Problemas | Soluciones |
|---|---|
| Problema de prueba de la nube | Utilizar una instancia de prueba de la base de datos en la nube |
| Problema de métricas | Medir CPU, memoria, E/S de disco, latencia y esperas de bloqueo |
| Problema de presentación de resultados | Crear scripts en Python para analizar y visualizar las métricas |
Preguntas frecuentes
1. ¿Cómo se comparó el rendimiento de la nube con la versión local de la base de datos?
La nube superó significativamente en rendimiento a la versión local en términos de CPU, memoria y E/S de disco.
2. ¿Cuáles fueron los problemas más desafiantes encontrados durante las pruebas?
Algunos de los problemas más desafiantes fueron los errores SQL sin explicación y los archivos de registro que se sobrescribían a mitad de las pruebas.
3. ¿Qué consejos se dan para futuros equipos que realicen la migración a la nube?
Se recomienda enfáticamente una comunicación exhaustiva y planificar tiempo extra para resolver posibles problemas imprevistos.
Gracias por leer nuestro artículo sobre la migración a la nube. Esperamos que haya sido útil y te invitamos a consultar nuestros otros artículos relacionados. ¡Hasta pronto!
¿Te ha resultado útil??
0 / 0
Hola, somos Mila Jiménez y César Sánchez. Dos apasionados de la ciberseguridad con muchos años de experiencia. Hemos trabajado en muchas empresas del mundo TI y ahora nos apetece compartir nuestro conocimiento con cualquiera que lo necesite.
¡Si te gusta nuestro contenido puedes invitarnos a un café AQUÍ!