El pasado fin de semana estuvimos trabajando en la migración de datos y el paso a producción de los sistemas que Belike ha estado desarrollando durante varios meses para uno de nuestros principales clientes, AECOC. En especial estuvimos trabajando en la migración de datos de los diferentes sistemas antiguos y que no iban a continuar utilizándose al nuevo sistema en producción.
La Asociación Española de Codificación Comercial (AECOC), con cerca de 40 años de actividad, es una de las mayores asociaciones empresariales españolas. Cuenta con más de 27.000 empresas de diferentes sectores y volumen, sumando todos ellos el 20% del PIB nacional. La misión de AECOC consiste en mejorar la competitividad de toda la cadena de valor, compartiendo soluciones, estándares y conocimiento para hacerla más eficiente y sostenible, aportando mayor valor al consumidor.
El proyecto ha consistido en el desarrollo de la Web pública de AECOC, desde donde se exponen contenidos públicos y además se ofrece una plataforma de servicios, e-commerce y área privada para los asociados. También hemos desarrollado un backoffice Web donde se llevan a cabo los procesos de negocio desde y hacia la Web, este backoffice integra además el ERP y CRM de la asociación e incluye un módulo de marketing automation y newsletters.
Después de contaros qué hemos hecho y quién es AECOC, en este post os voy a hablar de las diferentes estrategias de migración de datos que pueden llevarse a cabo y muy especialmente os voy a contar cómo hemos migrado los datos de producción del antiguo sistema al nuevo que hemos desarrollado para AECOC.
Estrategias de migración de Sistemas
Ya sean Sistemas software, hardware o una combinación de ambos, existen tres visiones o estrategias de migración de un Sistema:
Estrategia de implantación BigBang
Esta estrategia consiste en un apagado del sistema antiguo y un encendido del nuevo. En una migración a un entorno de producción siguiendo una estrategia de este tipo, los sistemas (antiguo y nuevo) no co-existirán, los usuarios comenzarán a utilizar el nuevo aplicativo el mismo día en el que dejarán de tener acceso al antiguo. Podemos decir que se trata de una estrategia “absoluta” que supondrá un esfuerzo considerable de trabajo previo al día del apagado.
Estrategia de interoperabilidad
En este caso, el objetivo final será el mismo que en una estrategia BigBang pero el paso de los sistemas a producción se hará de manera gradual, en fases. Cada fase representará un paso incremental hacia el nuevo aplicativo, desconectando sistemas viejos y conectando sistemas nuevos gradualmente.
Estrategia de implantación en paralelo
La última estrategia de migración de un sistema a un entorno productivo consiste en mantener el sistema viejo y el nuevo funcionando simultáneamente durante un tiempo. Este tiempo servirá para verificar y certificar la conformidad del nuevo sistema antes de proceder al apagado del antiguo.
Por las características y circunstancias del cliente, por la situación de los sistemas “legados” y por la naturaleza propia del servicio que ofrece AECOC, el paso a producción en entorno productivo y la migración de datos se realizó siguiendo una estrategia de implantación BigBang, es decir se hizo un “apagado del sistema antiguo” y “encendido del sistema nuevo”.
Aunque a priori, una estrategia Bigbang podría parecer la solución menos problemática, más simple o incluso más cómoda, esta afirmación ignora por completo la complejidad que implica la migración de los datos, más si cabe teniendo en cuenta que tras ejecutarse la migración, el sistema antiguo quedará desconectado, complicando o incluso imposibilitando una posible marcha atrás. En nuestro caso además, el cliente tenía 40 años de datos por migrar al nuevo sistema, os podéis imaginar que el trabajo no fue sencillo.
El trabajo que hemos llevado a cabo desde Belike para llevar a cabo con éxito la migración se ha basado en una serie de etapas y “highlights” que describo a continuación.
Ejecutar el proceso de migración completo sobre un entorno de Test
Aunque pueda parecer evidente, se trata del punto más importante antes de afrontar un proceso de migración de este calibre. Debemos disponer de un entorno de pruebas lo más fiel posible al entorno de producción final. Sobre él iremos programando, probando y optimizando todas las herramientas y scripts de migración que posteriormente deberemos ejecutar. En este aspecto, es vital disponer con un set de datos de prueba de igual volumen al que posteriormente deberemos llevar a cabo. En este sentido es altamente recomendable hacer una carga de datos de producción al entorno real, para llevarnos el menor número de sorpresas posibles en el paso a producción. Eso no significa que debamos trabajar con los datos reales, podemos incluir un proceso de “anonimizado” en la carga de datos desde producción a pruebas.
Desarrollar programas ad-hoc para ejecutar la migración de datos
En este punto podemos encontrar dos vertientes distintas. Podríamos utilizar herramientas de tipo ETL (Extract Transform and Load) como kettle, o podemos desarrollar nuestras propias herramientas.
En nuestro caso decidimos la segunda opción, principalmente porque queríamos asegurarnos que todos los datos cargados cumplieran las restricciones de negocio que habíamos desarrollado, de esta forma evitamos hacer migraciones de “base de datos a base de datos”. Lo que hacían los programas que desarrollamos ad-hoc eran conectarse a las fuentes de datos antiguas para leer los datos y llamar a nuestra API de servicios para insertarlos, en definitiva, como si los estuviéramos escribiendo por el Frontend de las aplicaciones.
Optimizar los procesos de migración de los datos
En nuestro caso, este proceso fue vital para el éxito de la migración. Como decía con anterioridad, 40 años de datos son muchos datos a migrar. En las primeras versiones de migración en pruebas, nuestros cálculos nos decían que debíamos de estar ejecutando scripts de migración durante más de 10 días, cuando el resultado final fue que la carga de datos desde las bases de datos antiguas al nuevo entorno de producción se realizó en unas 9 horas.
La clave de este punto no fue ni más ni menos que aplicar técnicas de computación paralela al proceso. Conociendo el número de cores que disponían los servidores, se ejecutaban hilos de trabajo en paralelo con distintos sets de datos, con el objetivo de ocupar el mayor porcentaje de máquina posible durante el mayor tiempo.
Planificación de la implantación
Para minimizar los riesgos al máximo, se planificó y probó todo el proceso para saber qué hacer, en qué momento y cuánto debía durar el proceso. En nuestro caso, se hicieron pruebas previas en el entorno de pruebas con “cronómetro”, de aquí obtuvimos cuál era la secuencia de ejecución de scripts más óptima. Esto se llevó a una pizarra en nuestra oficina con una línea de tiempo diciendo, desde las 6 de la tarde del viernes hasta las 6:30 de la madrugada del sábado, qué proceso estaría en ejecución y cual debería de ser el resultado esperado. De esta manera, en estrecha colaboración con el cliente, podíamos ir avanzando pasos de ejecución y validación.
Ejecución de la migración de datos
Para finalizar, hay que ejecutar todo lo ensayado sobre el entorno real de producción. Ni que decir tiene que este proceso debe de realizarse en un horario de no actividad del cliente, en nuestro caso fue el fin de semana. En este punto, es vital que el equipo de programación esté en el proceso de la migración, puesto que aunque todo haya sido ensayado previamente, siempre existen incidencias que hay que solventar en el momento, como por supuesto nos ocurrió a nosotros.
Para concluir, quería enfatizar la importancia que tiene, en un contexto de proyecto de desarrollo de software nuevo, tener en cuenta aquellos sistemas que vamos a sustituir (si es el caso) y en especial el volumen y calidad de los datos que posteriormente vamos a tener que migrar. En principio, la fase de migración no debería de afectar al modelado del sistema que vamos a desarrollar, pero sí habrá que tener muy en cuenta esta fase, tanto en nuestra planificación, como en el esfuerzo necesario que deberemos llevar a cabo. Hay que tener en cuenta que, tras la migración, los usuarios van a disponer de nuevas herramientas, pero en ningún momento deberán de encontrar ni menos funcionalidad de la que tenían, ni problemas en los datos que se han migrado.
Deja una respuesta