Rehosting es sinónimo de cambiar de lugar. También es, de alguna manera, sinónimo de modernización. Y, por supuesto, hacerlo no es trivial.
Podemos buscar una analogía no tecnológica, por ejemplo: mudarnos, cambiar de casa. Podríamos decir que no es lo mismo cambiar a un barrio que a otro. Tampoco es igual cambiar llevando los viejos muebles con nosotros que adquiriendo nuevos. Ni hablar de poner sobre la mesa la variable familiar, ¿se mudan todos los integrantes? o los niños ya han crecido y aprovechan para independizarse y abandonar el hogar donde crecieron.
Bromas aparte, hay que evaluar muchas variables, seleccionar tácticas y estratégicas y, como siempre, las distintas realidades de cada instalación lo condicionan todo.
Hoy existen infinidad de empresas y soluciones. Incluso se han patentados metodologías sobre la forma correcta de hacer un rehosting de aplicaciones. Porque los tiempos cambian y modernizar es, a veces, el único camino posible.
El caso es que debemos tomar decisiones pronto. Y no se puede hacer sin información, pero de la buena y rápido, porque si seguimos esperando, llegará el momento en que no hacer nada habrá dejado de ser una opción.
Y entonces será tarde.
Estrategia de rehosting
La elección de la estrategia adecuada para acometer cualquier proyecto es el paso fundamental para evitar cometer errores. Pero me atrevo a decir que es mucho más crucial cuando estamos hablando de rehosting y modernización.
La estrategia nos remite a construir un plan. El plan está compuesto por acciones bien definidas que se suceden ordenadamente y nos guían antes de llegar al objetivo buscado.
En resumen y, de alguna forma, la estrategia define una pauta de actuación.
¿Qué es el Rehosting?
Podemos ensayar una definición (¿otra?) El rehosting es una forma de preservar las costosas inversiones en lógica empresarial y datos corporativos atrapados en hardware y software propietarios, al mismo tiempo que abre caminos hacia una futura modernización al pasar a una arquitectura abierta y más extensible.
Productos automatizados
Existen diversas herramientas que forman parte de una estrategia determinada para enfocar un proyecto de rehosting (o modernización).
Los productos automatizados son una parte importante de estas estrategias.
Estos productos están constituidos por paquetes de software que proporcionan todo un conjunto de herramientas automáticas de migración para volver a montar ficheros RPG, COBOL o JLC, así como sus conexiones habituales con las bases de datos.
Parece necesario señalar que el automatismo nunca es total y que siempre habrá personal operando y supervisando las diferentes etapas que se suceden en el proceso.
¿Estrategia de rehosting?
Ya sea que estemos hablando de mainframes o servidores AS400, la estrategia de rehosting debe aplicarse en cualquier entorno siguiendo ciertos lineamientos específicos de cada uno.
El conocimiento de la plataforma de origen es prioritario.
Es muy importante contar con una guía y listas de verificación rápida que nos den una idea de conjunto y de la marcha del proyecto.
El primer paso es revisar la planificación que establece los requisitos generales de la arquitectura de destino.
Inventarios de aplicaciones y procesos batch o la preparación de los ficheros a trasladar, por ejemplo, deben ser los primeros ítems de la lista a identificar.
Y no podemos olvidar que la creación de entornos específicos de pruebas, de integración y de producción son otros de los renglones que no deben faltar en nuestra lista.
Es necesario organizar el proceso dentro de una serie de fases y pasos.
Por ejemplo:
- Definición de la estrategia del proyecto.
- Estudio de evaluación.
- Proyecto piloto.
- Implementación.
A su vez, cada ítem se dividirá en sucesivos pasos que pueden tener una determinada cantidad de iteraciones.
Pero en el comienzo de la implementación, deberemos estudiar y analizar cada entregables que produzca el proceso.
De forma paralela, a los pasos que producen entregables, aparecerán oportunamente la secuencia de pruebas que determinarán la validez de cada uno de los entregables.
Por otra parte, es imposible separar al proceso de rehosting del entorno en el cual se inscribe. Habrá personas de diferentes responsabilidades, donde deberán estar claramente asignados los roles a ocupar.
El entorno de la estrategia de rehosting
Podríamos señalar entornos necesarios y bien diferenciados para encarrilar nuestra estrategia de rehosting o modenización.
Además, para más claridad, podemos dividirlos en entornos de origen y de destino.
Cabe aclarar que cuando hablamos de «entornos de origen» estamos referenciando al entornos y condiciones previas a la migración y, en el otro extremo, al hablar de «entorno de destino» estaremos hablando de condiciones posteriores a la migración.
- El entorno de origen «fuentes en producción actual» para los ficheros que se convertirán.
- Un entorno de origen «de prueba» para almacenar y aislar las operaciones extraídas del entorno de producción y para crear una base de datos de prueba.
Y además,
- Un entorno de destino «de prueba» para ejecutar, ajustar y probar los activos convertidos.
- Un entorno de destino «de integración», que se utiliza para albergar todas las actividades, como la integración, la migración de operaciones o el procesamiento previo al cambio.
- Un entorno de destino «de producción» para los activos convertidos y probados.
¿Qué es Lift and Shift?
Si bien la traducción literal es: levantar y cambiar, «lift and shift» hace referencia a un enfoque muy particular a la hora de migrar aplicaciones informáticas.
El caso es mover la aplicación y los datos asociados a la misma a otra plataforma sin hacer cambios de reingeniería en el código original.
¿Esto es posible acaso?
Además la llamamos…
También es común referirse a esta estrategia como «migración tal cual» o «migración como está». Y, sin dudas, es otro sinónimo del concepto de rehosting
De alguna manera, lift and shift describe de forma genérica al mecanismo involucrado.
El proceso toma las aplicaciones de misión crítica (las levanta) y las migra a un nuevo hardware (las cambia).
Es por ello que a veces verán referido a este enfoque como «estrategia de reemplazo».
Independientemente del nombre que le demos, el objetivo siempre es proteger la inversión que se realizó oportunamente en la lógica y los datos que hoy residen en el servidor local.
Desventajas del enfoque lift and shift
Como cualquier estrategia de migración, el «levantar y cambiar» no es una decisión trivial.
Si pudiéramos señalar un condicionamiento habría que mirar en la plataforma de destino y evaluar cuan preparada está para recibir el código «tal cual».
Por ejemplo, ¿Podemos garantizar que, si el destino es la nube, será posible ejecutar el código sin cambios? Si y no.
Es casi seguro que no habrá aplicación nativa en la nueva plataforma que sea capaz de ejecutar el código original, tal y como está corriendo un un mainframe.
Es evidente que también debemos estar muy seguros de la herramienta elegida para la migración y si se incorporará un interprete entre la aplicación nativa y la nueva plataforma de destino.
¿Cuándo es mas adecuado el enfoque lift and shift?
Podemos centrarnos en los costos , por ejemplo.
Evaluar cuanto de la plataforma de destino estamos realmente aprovechando con el enfoque lift and shift.
Si la migración tal cual de la aplicación de origen implica que no estaremos usando al 100% la potencia de la plataforma de destino, debemos replantearnos esta estrategia.
Si la herramienta que posibilita la migración como está de la aplicación de origen, afecta al rendimiento de nuestra lógica empresarial, es otro punto de atención que no debemos perder de vista.
Por otra parte, si los fondos disponibles para una operación de migración de sistemas son limitados, no lo dude, el enfoque «lift and shift» es el más económico.
También es la elección correcta si los tiempos le apremian, un enfoque de «levantar y cambiar» es el más adecuado en estos casos, ya que ha demostrado con creces que es capaz de implementar proyectos de migración en tiempos récord, comparados con los de una reingeniería total.
¿Es hora de un mainframe rehosting?
Mejor en afirmativo: ¡Es hora de hacer un mainframe rehosting!
Mantener en funcionamiento un mainframe es tomar la decisión de aceptar desafíos costosos y de alto riesgo. No parece ser una decisión inteligente.
Si dejamos por un momento de lado el tema del mantenimiento de una plataforma antigua y cara, también vemos que el mercado demanda más agilidad tanto en aplicaciones como en procesos . En pocas palabras: innovación y rentabilidad.
¿Qué es el mainframe rehosting?
Como ya dijimos, el rehosting es una de las tantas formas que existen de prolongar la vida útil de software valioso que fue desarrollado para hardware propietario.
El rehosting es una de las estrategias que se contrapone a a realizar modernizaciones y actualizaciones en el mismo mainframe.
También podemos decir que el mainframe rehosting es uno de los métodos más rentables de abordar la problemática a la que nos referimos: abandonar el mainframe.
Ya dijimos que una forma de rehosting es trasladar el software «como está» de una plataforma a otra. REvisa el apartado anterior si no te ha quedad claro.
También podemos abordar el tema desde el punto de vista de una de las medidas estándar que usamos para referirnos al consumo de los recursos son los MIPS, esto es, el acrónimo en inglés de «millones de instrucciones por segundo».
Es evidente que el objetivo es reducir el número de MIPS que identificamos como la carga de trabajo en el mainframe para trasladarlo a entornos más modernos y menos costosos. Hay una amplia variedad de herramientas automáticas que se encargan de esta tarea dependiendo de cual sea el destino que hayamos elegido.
¿Por qué hacer un mainframe rehosting?
Es una estrategia de bajo riesgo. La lógica del negocio no se ve afectada y la interfaz de usuario apenas cambia o no lo hace en absoluto con lo que los requerimientos de formación son mínimos reduciendo al máximo el impacto del cambio.
Es una estrategia de rápida implementación.
Dependiendo de la complejidad de la base instalada un proyecto de mainframe rehosting puede afrontarse en un lapso de 6 a12 meses.
Reutilización del personal.
Dependiendo del lenguaje de programación de la plataforma de origen es muy posible que con una formación mínima pueda mantener a sus recursos de personal de sistemas.
Actualización y modernización.
Las nuevas plataformas están mejor preparadas para responder con mayor rapidez a los cambios del mercado.
Independencia de propietario.
Los destinos del mainframe rehosting son mayormente sistemas de fuente abierta sin licenciamiento de propietario.
Rendimiento y escalabilidad.
Las nuevas plataformas son fácilmente escalables permitiendo mejores rendimientos generales y aumentando la velocidad de respuesta y adaptación frente a nuevas demandas del mercado.
Costos.
Hay una clara reducción de costos en las nuevas plataformas, tanto en mantenimiento, menos gastos de licenciamientos propietarios y acceso a personal bien preparado y en mayor oferta.
Conclusión
No es fácil tomar decisiones (¿cuándo lo fue?) en esta situación, pero hay suficientes variables sobre la balanza que nos invitan a reflexionar.
Por otro lado, debemos ser conscientes que los tiempos se precipitan. y las preguntas se acumulan.
¿Reemplazamos nuestro mainframe por uno nuevo? ¿Reescribimos todo el código? ¿Solo una parte? ¿Cambiamos solo los front-ends? ¿Rehosting?
Es evidente que hay que tomar alguna decisión. Ha llegado el momento.