Si has diseñado y planificado las cosas correctamente, la migración de tus aplicaciones a una nube pública como AWS debería ser una experiencia liberadora. Verás cómo tu patrimonio informático se traslada a un entorno de primera clase, seguro, fiable y eficiente, y podrás empezar a prescindir del hardware heredado que te ha estado costando dinero y electricidad durante tanto tiempo. En este artículo, analizaremos los diferentes trayectos que la mayoría de tus aplicaciones recorrerán para llegar a AWS.
Los tres métodos más modernos y sostenibles
En Claranet, nuestro equipo tiene siete opciones sobre qué hacer con una aplicación determinada al planificar una migración: las "siete erres". Sin embargo, en este artículo sólo hablaremos de tres de ellas: replatforming, repurchasing y refactoring. Las otras cuatro opciones -retirar, retener, reubicar y realojar- no aportarán a tu organización los mismos beneficios de modernización y sostenibilidad, por lo que siempre que podamos debemos centrarnos en estas tres. En nuestro próximo artículo encontrarás una definición de las otras cuatro R.
Entonces, ¿qué implican las tres R que nos interesan?
Replatforming: pasar a PaaS en AWS
AWS proporciona una gran cantidad de servicios PaaS que puedes aprovechar, los cuales tienen la garantía de ser modernos y ecológicos. Algunos ejemplos son AWS Relational Database o Amazon DynamoDB para bases de datos NoSQL. Trasladar una aplicación tal cual de una máquina virtual que se ejecuta en tus servidores a un contenedor que se ejecuta en AWS también es un tipo de replatforming.
El replatforming mantiene gran parte de tu aplicación tal cual, lo que significa que no obtendrás los mejores beneficios de la modernización y la sostenibilidad. Sin embargo, sí obtendrás gran parte de ellos incluidas las copias de seguridad, la replicación, la conmutación por error automática entre regiones, las actualizaciones de versiones, etcétera. Y, por supuesto, seguirás obteniendo las ventajas de rendimiento, escalabilidad, tolerancia a fallos, disponibilidad y eficiencia energética derivadas de trasladar elementos de tu infraestructura a la nube.
Normalmente, el replatforming es más adecuado para aplicaciones que no son de vital importancia estratégica, o cuando no hay presupuesto para investigar la recompra o la refactorización, pero donde todavía hay una oportunidad de disfrutar de los beneficios de la arquitectura en nube.
Recompra: pasar a un servicio preconstruido
La recompra consiste en sustituir la aplicación existente por un servicio proporcionado por un socio que ejecuta su propia solución en AWS. Un buen ejemplo sería sustituir un sistema de tickets existente por ServiceNow.
- Tienen un valor estratégico para el negocio; por ejemplo, generan ingresos o son vitales para su funcionamiento.
- Se basan en código o arquitectura heredados, por lo que sería complejo trasladarlas a la nube sin un trabajo significativo.
- Un proveedor puede ofrecerte un servicio más rápido o de mayor calidad (o ambas cosas) que el que tú mismo podrías gestionar.
La recompra es ideal para aplicaciones que:
La recompra puede proporcionar una aplicación mucho más moderna al instante, con la seguridad de saber que funcionará en el nuevo entorno. AWS gestiona un gran mercado de proveedores de servicios con los que puedes comenzar a trabajar fácilmente y, dado que también se ejecutan en su mismo entorno, tienes garantizado que utilizando sus servicios no volverás a aumentar inesperadamente tu huella de carbono.
Refactorización: reconstruir tu aplicación en la nube
Si no hay un proveedor al que puedas o quieras recomprar tu aplicación, entonces el procedimiento habitual es reconstruir su aplicación para aprovechar las capacidades nativas de la nube de AWS. La refactorización puede ser tan sencilla como utilizar un servicio como el de Apps2Container para contenerizar tus aplicaciones, o puede implicar una revisión completa del código y del funcionamiento de la aplicación.
La refactorización te ofrece la mejor oportunidad de modernizar e impulsar la sostenibilidad de tus aplicaciones. Además de los beneficios de la infraestructura de soporte de AWS, tu aplicación puede utilizar características nativas de la nube para comportarse de nuevas maneras, incluido el uso de informática sin servidor. Si estás considerando la refactorización, entonces es absolutamente esencial que encuentres y utilices experiencia en las tecnologías involucradas, como Fargate y Lambda.
Caso práctico de migración a AWS
Al igual que la nube necesita hardware físico para funcionar, los conceptos e ideas de los que hablamos necesitan una base real. Y eso nos lleva a nuestro ejemplo, basado en una empresa especializada en el seguimiento de animales migratorios. Su viaje de migración cloud con Claranet nos muestra cómo puede ser la migración a AWS.
El director de tecnología decide con su equipo dar prioridad a la migración de la aplicación de software personalizada de la empresa. Los servidores que alojan la aplicación son los más costosos y menos eficientes de la empresa, por lo que cuanto antes se migren las aplicaciones, antes podrán apagar los servidores para mejorar su huella de carbono.
El Centro de Excelencia en la Nube (CCOE), que incluye a expertos de la empresa cliente y Claranet, revisa la aplicación y decide que, debido a su criticidad y a su naturaleza personalizada, la refactorización de la aplicación es el camino a seguir. Con la refactorización, esperan desacoplar las distintas funciones de la aplicación y reconstruirla utilizando una arquitectura de microservicios. Algunos de los elementos de la aplicación podrían beneficiarse de la computación serverless a través de AWS Lambda, ya que no se ejecutan 24 horas al día, 7 días a la semana: su función es ejecutar flujos de trabajo específicos realizando llamadas a otros servicios, que se activan cada vez que la empresa recibe datos de los rastreadores montados en los animales que migran. Un enfoque serverless significará que la aplicación sólo utiliza recursos -y por tanto genera emisiones- cuando es necesario, lo que reduce en gran medida el coste y la huella de carbono de la aplicación. Debido a la complejidad de esta actividad, como primer paso, la aplicación se vuelve a alojar en EC2, con el plan de volver y refactorizarla una vez finalizado el trabajo de migración inicial.
La empresa cliente revisa su base de datos que contiene todos los datos recopilados de los dispositivos IoT de seguimiento de animales. Dado que se trata de una base de datos NoSQL, el equipo decide que la mejor opción es hacer el replatforming de la base de datos para utilizar Amazon DynamoDB. AWS se encarga de todo el trabajo pesado, incluidos los backups y la conmutación por error, y el equipo puede estar tranquilo sabiendo que a medida que crece el volumen de datos que recopilan, AWS puede escalar para igualar sin incurrir en la misma huella de carbono que generarían de otro modo.
La empresa cliente decide recomprar algunas de sus aplicaciones a un socio de Claranet, SAP Concur. Dado que SAP Concur también se ejecuta en AWS, la compatibilidad con la nueva infraestructura está garantizada y la empresa cliente sabe que las credenciales ecológicas de SAP Concur coinciden con las suyas.
Para otras aplicaciones, decide utilizar Apps2Container para trasladar las aplicaciones de sus máquinas virtuales existentes a contenedores ejecutados en AWS Fargate. El equipo considera que podrían refactorizar aún más estas aplicaciones o volver a comprarlas en el futuro para que sean aún más eficientes y consuman menos energía, pero el esfuerzo de hacerlo durante la migración inicial superaría los beneficios.
Esperamos que este caso práctico te haya sido útil para imaginar una posible migración de tu infraestructura a AWS. Si quieres aplicar el replatforming, repurchasing o refactoring con tus aplicaciones, podemos ayudarte. Contacta con nuestros expertos para que te ayudemos a elegir qué hacer con cada aplicación basándonos en nuestras experiencias.