Existen modelos cloud native a medida. Como bien sabrás, por más recomendaciones que se puedan oír sobre la migración a nubes privadas y luego públicas, lo cierto es que no existe una metodología unívoca. No se ha creado aún la plantilla estándar para generar modelos de migración Cloud-Native.
Cada organización deberá afrontar sus propios desafíos y modelos cloud native a medida. Deberá ser capaz de elaborar presupuestos que comulguen con su demanda. Que porten la viabilidad de operación en entornos amplios. Que tengan la capacidad de asegurar que no haya interrupción entre las aplicaciones. O que sean capaz de poseer las skills de los equipos que han de hacer realidad este proceso.
De esta manera, en pro de intentar aglutinar posibles modernizaciones de aplicaciones Cloud Native a medida, desde atmira proponemos una serie de modelos que se adecúan a las diferentes naturalezas y estadios de negocio de las organicaciones:
MODELO 1: “RENCAPSULATE”
La inteligencia en el proceso de migración al Cloud-Native Ecosystem radica en saber comprender que es posible que algunos elementos no tenga sentido migrarlos. Resulta de vital importancia saber identificar en el inicio de una migración completa a la nube pública si esto es realmente necesario y productivo para la naturaleza del negocio.
El modelo de migración “Rencapsulate” trabaja en la implementación de un Cloud híbrido con el objetivo de evolucionar hacia el Cloud pero respetando las arquitecturas heredadas On Premise en pro de conservar su valor comercial.
MODELO 2: “REHOST”
En la actualidad, el 80% de las cargas de trabajo todavía están en arquitecturas On Premise. Unas arquitecturas que a día de hoy no permiten mucho margen de maniobra si hablamos de procesos de escalabilidad y flexibilidad. El modelo de “Rehost” permite disponer de aplicaciones nativas que se ejecutan en el Cloud. Este modelo de “Rehost” también conocido como “Lift & Shift”, evita la necesidad de reescribir las aplicaciones. En estadio de urgencia que plantea la realidad del mercado, podría ser a menudo el enfoque más pragmático.
“Rehost” es un modelo de migración que funciona sobre todo en aplicaciones donde no se pretende hacer cambios masivos sino un pequeño paso adelante en la modernización de las arquitecturas. Un ejemplo claro de una estrategia bajo el modelo “Rehost” es cuando en lugar de simplemente mover MySQL a una VM en GCP se decide que es hora de moverlo a Cloud SQL y transformarlo en un “servicio administrado”. Esto permite dejar de gestionar el ciclo de vida de la base de datos sin la necesidad de cambiar las aplicaciones en sí mismas.
MODELO 3: “REPLATFORM”
“Replatform” es esencialmente una versión más robusta e implicada de “Rehost”. En este modelo de migración, nuestros equipos recogen los componentes de las aplicaciones existentes para transformarlas en servicios Cloud-Native. El proceso radica en la introducción de pequeñas modificaciones y actualizaciones de código que aportarán a la aplicación capacidades Cloud más avanzadas y con mayor recorrido como escalado, un rendimiento mejorado, o una mayor tolerancia a los fallos.
La primera pregunta que debe hacerse es simple: ¿Qué se está utilizando y qué no? Esta pregunta nos permite ver si tiene o no tiene sentido migrar una aplicación no utilizada a un entorno Cloud. Esto generaría un coste innecesario, donde no habría un ROI tangible del proceso ya que esta continuaría sin otorgar valor. De esta manera, “Replatform” representa una gran oportunidad para identificar y desmantelar herramientas heredadas que ocupan recursos innecesariamente. Una buena oportunidad para descubrir que estamos ejecutando múltiples aplicaciones que duplican capacidades, pudiendo quitar así lo innecesario como parte del proceso mismo de migración.
Algunos ejemplos comunes del modelo “Replatform” los podemos ver, bien en la transición de una base de datos heredada a un servicio de base de datos nativo compatible con la nube, o también al pasar de un balanceador de carga de máquina virtual a un balanceador de carga nativo de la nube. Es importante comprender que cada vez más, los proveedores de servicios en la nube ofrecen una variedad de herramientas útiles para facilitar las migraciones comunes, desbloqueando un valor incremental más allá de una simple reubicación.
MODELO 4: “REFACTOR”
Otro modelo que proponemos desde atmira es el modelo “Refactor. Este consiste en un análisis pormenorizado de todas aquellas aplicaciones heredadas que han sido creadas sobre la base de lenguajes y plataformas legacy ( PowerBuilder, Delphi, VB, C++, COBOL) o bajo tecnologías anticuadas (versiones Java y.NET obsoletas), y prepararlas para un nuevo uso de lenguajes de programación, frameworks y bases de datos modernos aplicables al ecosistema Cloud-Native.
Durante este proceso es importante tomar decisiones de arquitectura que eficienten los recursos sobre los que se ejecutan las aplicaciones y responder a las necesidades del tiempo de ejecución. Nos estamos refiriendo a la implementación de Integración continua (CI) y Entrega Continua (CD) junto a otras prácticas Devops como la creación de servicios API para capacitar el uso multi-cloud, la misma introducción de nuevas funcionalidades orientadas a Cloud-Native, o la comprensión de las aplicaciones con el objetivo de simplificar el mantenimiento o su sustitución en el futuro.
Es importante remarcar que la evolución a través del modelo “Refactor” incrementa de manera exponencial el rendimiento a la vez que se reduce el coste de mantenimiento y la dependencia de personal especializado.
MODELO 5: “REARCHITECT”
El mayor desafío de la migración al Cloud implica a su vez el mayor beneficio potencial de la misma. En el modelo evolutivo Cloud-Native conocido como “Rearchitect” significa que, desde el código en adelante, se cambia absolutamente todo para aprovechar las capacidades y beneficios de la nube en su máxima potencia. Esto incluye los componentes principales, la relación de la aplicación con las bases de datos, e inclusive la infraestructura.
Puede resultar confuso que una refactorización o reestructuración de aplicaciones sea el primer paso. En cualquier caso, es importante destacar que una arquitectura bien diseñada que de vida a una aplicación verdaderamente Cloud, puede proporcionar un ROI masivo en el corto plazo al tiempo que proporciona un nuevo panorama de oportunidades y flexibilidad para el futuro.
El ejemplo “Rearchitect” más visible lo podemos apreciar cuando dividimos las aplicaciones en servicios / microservicios web para que de esta manera se aproveche al máximo las posibilidades Cloud-Native. Siguiendo este modelo, las nuevas aplicaciones Cloud se adaptan perfectamente a los requisitos de carga dinámica y rendimiento, lo que habilita actualizaciones parciales, la mezcla de tecnologías y el uso compartido de la plataforma.
MODELO 6: “REBUILD”
Este modelo de evolución plantea una cuestión importante… ¿Qué deben hacer las organizaciones? ¿Deben modernizar primero o empezar la ecuación por el final? Llegados a esta instancia, esta toma de decisiones se basará en el análisis pormenorizado de diferentes restricciones y factores que presenten estas aplicaciones. A medida que las organizaciones avancen en esta estrategia tendrán que preguntarse: ¿Qué tan complejo es? ¿Qué tan crítico puede resultar para el negocio? ¿Cómo se verá esta nueva arquitectura? ¿Qué tiempo tenemos para ello? ¿Tenemos el presupuesto, el personal, la experiencia?
La experiencia de atmira en diversos procesos de transformación nos sirve de precedente para entender que esta Big Bang en aplicaciones grandes empresariales a veces no representan una opción viable, y aunque parezca atractivo, probablemente el proceso terminará en fracaso ya que el coste y el esfuerzo o la complejidad de obtener una aplicación Cloud-Native es demasiado grande y arriesgado.
«Lo único que garantiza una reescritura Big Bang es un Big Bang…» (Martin Fowler)
La respuesta que dan los proveedores de Cloud Públicas a este tipo de preguntas es que las organizaciones deben realizar un análisis de su situación tecnológica y enfocarse en su catálogo de aplicaciones disponibles y como estas pueden ayudarles a escalar sus necesidades. Los caminos son múltiples y las respuestas totalmente ad-hoc a cada situación particular.
Desde atmira, en lugar de llevar a cabo una reescritura de esta envergadura, trabajamos para refactorizar gradualmente las aplicaciones. Esto lo hacemos reescribiendo funcionalidades como la integración con servicios de terceros como SaaS (Software as a Service) y cambiando la forma en que se paga por ellas. Un claro ejemplo lo vemos en muchos de los sistemas CRM. Estos utilizan herramientas de productividad como Microsoft Office, sistemas ERP y otras aplicaciones comunes que fácilmente se pueden migrar a la nube cambiando la forma en que se licencia el software.
Fuente: Atmira