Idealmente, en cualquier migración cloud en la que la modernización sea un objetivo clave, se debería realizar la mayor parte posible de esa modernización durante la migración. Pero, por supuesto, eso no siempre es posible. Algunas aplicaciones son demasiado complejas para modernizarlas por completo de una sola vez, y otras no son lo suficientemente importantes como para abordarlas en los plazos del proyecto. Esto significa que, una vez completada la migración propiamente dicha, tendrás más oportunidades de modernizar tus aplicaciones y así avanzar aún más en tus objetivos de sostenibilidad.
En este artículo, identificamos y explicamos algunas de las tecnologías clave que puedes aprovechar una vez que tu infraestructura esté en la nube. También compartimos un caso para ejemplificar cómo funciona este proceso en la práctica.
¿Qué significa modernizar aplicaciones?
En pocas palabras, ejecutar una aplicación en AWS significa que puedes hacerlo de maneras diferentes en comparación con cómo lo harías en un servidor local, o incluso cómo lo harías en una nube privada. Con AWS, tienes acceso a nuevos servicios y tecnologías preconstruidas que puedes incorporar a sus aplicaciones, con lo que puedes conseguir:
- Más rapidez, ofreciendo a los usuarios una mejor experiencia (ya sean tus empleados, clientes o socios).
- Más resistencia a cortes u otros problemas, manteniendo tu negocio en marcha cuando antes las cosas podrían haberse detenido.
- Más eficiencia, utilizando los recursos informáticos solo cuando sea necesario.
Aunque este último punto es el que hace que la modernización de las aplicaciones sea tan importante para un plan de sostenibilidad, solo por estar en AWS ya habrás reducido tu huella de carbono; modernizando tus aplicaciones, puedes asegurarte de que no estás utilizando recursos (y por tanto energía) que no necesitas, haciendo que tus TI sea aún más sostenibles. Y, por supuesto, la reducción del consumo de energía debido a la creación de aplicaciones modernas que son más rápidas y utilizan menos recursos conllevan también una reducción de tus costes.
¿Qué opciones tienes para modernizar las aplicaciones y en qué te benefician?
Autoescalado
Esta es posiblemente la tecnología de cloud más importante y, como tal, dependiendo de cómo se hayan migrado sus aplicaciones, es probable que ya esté activada. Es la tecnología que permite a AWS aumentar o disminuir automáticamente la cantidad de recursos informáticos que utilizan sus aplicaciones en función de sus necesidades. El autoescalado garantiza que no se utilicen ni se pague por recursos que no se necesitan, por lo que es ideal para el control de costes y la sostenibilidad.
El autoescalado es adecuado para cualquier aplicación que se ejecute en la nube, ya sea en EC2, Fargate, Aurora o EKS, siempre que la aplicación se haya creado para permitir el autoescalado (si estás migrando una aplicación muy antigua o personalizada, asegúrate de comprobar esto de antemano). Además, su implementación es gratuita, por lo que no hay razón para no incluirla en el mayor número posible de aplicaciones, aunque, por supuesto, habrá que pagar por los recursos informáticos adicionales que se utilicen al escalar.
SNS y SQS
Simple Notification Service (SNS) y Simple Queue Service (SQS) son otras de las tecnologías fundamentales que impulsan muchas ventajas en las aplicaciones en la nube. SNS permite que las aplicaciones se envíen mensajes entre sí, o a personas como usuarios o clientes a través de correo electrónico, SNS o notificaciones push. Por otro lado, SQS es un servicio de colas de mensajes totalmente gestionado para esos mensajes.
SNS y SQS trabajan juntos para que las aplicaciones se comuniquen, ya sea entre sus propias aplicaciones, sus aplicaciones y la plataforma de AWS, o incluso los diferentes microservicios que componen una aplicación (monolitos o microservicios, como veremos más abajo). Sin ellas se pierde la capacidad de acoplar aplicaciones de forma fácil y flexible, que es lo que impulsa gran parte de la resiliencia, la automatización y la inteligencia en la nube.
La refactorización de una aplicación para utilizar SNS y SQS hace posibles muchas de las innovaciones y, por tanto, también aportan múltiples beneficios, como la sostenibilidad. Al igual que con todos los servicios de AWS también se puede autoescalar, lo que significa que no utiliza recursos o energía que no se necesite, al mismo tiempo que garantiza que sus aplicaciones puedan realizar su trabajo las 24 horas del día, los 7 días de la semana, y comunicarse entre sí de forma segura.
Instancias de subasta
Las instancias de subasta son esencialmente recursos informáticos sobrantes que AWS subasta a bajo precio. Es específico de las instancias EC2 de AWS, por lo que es ideal para cualquier aplicación o servicio que se ejecute en EC2, cuyo uso puntual puede ahorrar hasta un 90% del coste. En relación a la sostenibilidad, las instancias spot disminuyen su huella de carbono al utilizar recursos que ya han sido provisionados (como hacer que un lavavajillas funcione de manera más eficiente asegurándonos de que está completamente lleno antes de iniciar un ciclo).
Sin embargo, debemos tener cuidado con las instancias de subasta; se utilizan recursos sobrantes, por lo que existe el riesgo de que se apaguen o se retiren si AWS los necesita en otro lugar. Por lo tanto, no son adecuadas para actividades que requieren que los recursos estén disponibles 24 horas al día, 7 días a la semana, como el almacenamiento de datos.
Sin embargo, el procesamiento por lotes de datos almacenados en otra instancia es un buen ejemplo de actividad adecuada para el uso de instancias de subasta, ya que el proceso puede detenerse sin perder los datos y reanudarse cuando haya otra instancia de subasta disponible.
De monolitos a microservicios
En el pasado, las aplicaciones solían construirse como monolitos, es decir, todo lo que la aplicación necesitaba para funcionar existía como una sola unidad. En cambio, en la nube se pueden crear aplicaciones que son colecciones de microservicios (básicamente, aplicaciones más pequeñas que gestionan funciones específicas de la aplicación más grande) que trabajan juntas para ofrecer la función de la aplicación al usuario final. De hecho, SQS, SNS y Lambda son ejemplos de microservicios disponibles en AWS.
Las aplicaciones de microservicios tienen el potencial de ser mucho más sostenibles que las aplicaciones monolíticas, y son mucho más modernas:
- Si quieres escalar una aplicación monolítica, tienes que escalarla entera, incluso si es solo una sección de la aplicación la que está ocupada, como una pasarela de pago. Esto es costoso y consume muchos más recursos de los necesarios. Si tu aplicación utiliza microservicios, cada uno de ellos puede ampliarse o reducirse según sea necesario, lo que te permite utilizar los recursos de forma mucho más eficiente.
- Si deseas actualizar una parte de una aplicación monolítica, debes desconectarla por completo para actualizarla. Con los microservicios, puedes actualizar componentes individuales mientras el resto de la aplicación sigue funcionando.
- Si una parte de una aplicación monolítica se rompe, toda la aplicación se cae. Si falla un microservicio, el resto de la aplicación sigue funcionando, ofreciendo a los usuarios un mejor servicio y permitiéndole hacer un mejor uso de sus recursos (ya que no está alojando una aplicación que no hace nada).
Reestructurar una aplicación de un monolito a microservicios no es tarea fácil, por lo que deberías evaluar detenidamente tu conjunto de habilidades internas y buscar un socio de confianza que te ayude. Una aplicación de RRHH sería un buen ejemplo de ello, ya que gestiona funciones como la gestión de vacaciones, nóminas, hojas de horas, etc. Todas ellas podrían desacoplarse entre sí y ser gestionadas por microservicios que se unan para hacer que la aplicación funcione. Las aplicaciones que son buenas candidatas para una arquitectura de microservicios probablemente se volvieron a hospedar en la migración inicial, lo que significa que se ejecutan en AWS pero funcionan exactamente igual que antes, o no se migraron en absoluto debido a su tamaño y complejidad.
Informática serverless (AWS Lambda)
La informática serverless es la siguiente capa de abstracción por encima de la nube. En la nube, no tienes que operar la infraestructura en la que se ejecutan sus recursos informáticos, pero debes seguir aprovisionándola, con un mayor o menor grado de automatización. En la computación serverless, ni siquiera se aprovisionan los recursos. Especificas el código que desea ejecutar y AWS aprovisiona automáticamente los recursos para ejecutar ese código como y cuando sea necesario mediante Lambda, su servicio de informática serverless.
El uso de Lambda te hace subir otro peldaño en la escalera de la sostenibilidad al ofrecer otro nivel de escalabilidad. Solo pagas por los recursos que utilizas, hasta el milisegundo, y eso significa, por supuesto, que puedes utilizar los recursos que aumentan tu huella de carbono de forma aún más eficiente. Al dar a AWS el control sobre qué recursos utiliza para ejecutar su código y cómo lo hace, la forma en que su código utiliza los recursos también puede ser más eficiente.
Lambda es ideal para actividades basadas en eventos, en las que no se ejecuta código 24 horas al día, 7 días a la semana, y por lo tanto solo se necesitan recursos listos para cuando se produzca el evento. Por ejemplo, un usuario que sube una foto a una aplicación que ejecutas, donde la subida desencadena un evento en Lambda que redimensiona automáticamente la foto para el usuario.
Revisiones bien diseñadas
AWS quiere asegurarse de que todos los usuarios de su nube la aprovechan al máximo. Para ello, ha creado el marco Well-Architected, que le permite revisar cómo están configuradas tus operaciones en la nube y qué puedes hacer para mejorarlas. Como era de esperar, la sostenibilidad es uno de los pilares de este marco, por lo que la revisión de tus operaciones utilizando el marco es una gran manera de descubrir más oportunidades para modernizar e impulsar la sostenibilidad.
Una revisión bien diseñada puede realizarse para una sola aplicación o para todo el conjunto, pero la mejor forma de llevarla a cabo es a través de un socio acreditado como Geko Cloud. Esto garantiza que el marco y su herramienta asociada se utilicen de forma óptima y, por tanto, que se les saque el máximo partido.
Caso práctico
Existen otros servicios y productos que AWS ofrece para ayudarte a modernizar tus aplicaciones: son tecnologías clave que debes tener en cuenta y que te proporcionarán beneficios con mayor rapidez. Ahora que las hemos cubierto con un poco de detalle, es hora de ver cómo funcionan en la vida real. Para ello, simularemos un caso práctico a través de la empresa ficticia Charlie Loud Migrations, una empresa que se asocia con Geko Cloud para migrar su parque informático a AWS. CLM se dedica a seguir las migraciones de animales en todo el mundo utilizando las últimas tecnologías y nos unimos a ellos ahora que entran en la fase final de su migración.
CLM ha completado su migración inicial y ya disfruta de una huella de carbono considerablemente menor una vez que ha podido desactivar la mayor parte de su arquitectura local. La modernización de sus aplicaciones no solo les proporcionará los mejores beneficios de sostenibilidad ahora, sino que también les ayudará a crecer de forma más sostenible en el futuro.
El primer punto es la aplicación central de la empresa, que gestiona todos los datos que recibe sobre los animales que rastrea y los convierte en información sobre migración. Durante la migración inicial, la aplicación se volvió a alojar en EC2, pero sin cambios en su funcionamiento. La aplicación es un monolito, por lo que el Centro de Excelencia en la Nube que CLM creó al inicio de la migración recomienda que el equipo dedique tiempo a refactorizar la aplicación para utilizar una arquitectura de microservicios. Geko Cloud realiza la mayor parte del trabajo en este proyecto, ya que es quien tiene más conocimientos técnicos, pero también participa un pequeño equipo de desarrolladores de CLM, con el objetivo de incorporar esas habilidades internamente para el futuro.
A continuación, el equipo examina la aplicación que gestiona las cargas de fotos y NFC. Una de las formas en que CLM rastrea los movimientos de los animales es proporcionando etiquetas con NFC a los grupos conservacionistas. Una vez que los animales han sido etiquetados, cuando otro grupo de conservación se encuentra con el animal, puede hacerle una foto y escanear su etiqueta NFC; estos datos se envían a CLM, junto con la ubicación del dispositivo del usuario, son procesados por la aplicación y, a continuación, se pasan a la aplicación personalizada para su análisis. Durante la migración, la aplicación se replanteó para ejecutarse con Amazon DynamoDB como repositorio de datos; ahora el equipo decide reconstruir esta aplicación para incluir AWS Lambda. En lugar de ejecutarse permanentemente en una instancia EC2, la aplicación ahora se basa en eventos, solo ejecuta código y utiliza recursos cuando se carga un nuevo conjunto de datos. Lambda se encarga del procesamiento de los datos de imagen y NFC, los envía a DynamoDB y llama a la aplicación central para comenzar el análisis de los nuevos datos.
CLM también examina su entorno de recuperación ante desastres (DR). Antes de la migración, la recuperación consistía en copias de seguridad en cinta magnética y una instancia local de Zerto para la recuperación instantánea. Durante la migración, las cintas magnéticas se copiaron en Amazon S3 Glacier mediante AWS Snowball con Tape Gateway; se decidió cambiar de Zerto a AWS Elastic Disaster Recovery (EDR). Las capacidades de DR de CLM se dejaron inicialmente como estaban en Zerto, que mantenía un entorno multisite completo que era costoso y consumía mucha energía. Ahora, el CCOE recomienda que AWS EDR se reconfigure de manera que la conmutación por error multisite solo esté disponible para la aplicación principal de la empresa; todo lo demás utiliza un sistema piloto en su lugar, lo que significa que la región en espera se mantiene en funcionamiento a una escala muy pequeña, lista para escalar rápidamente si la región principal se cae. Como resultado, la RD de CLM consume mucha menos energía sin dejar de ofrecer el nivel de servicio que necesita para mantenerse operativa.
CLM también decide alojar su sistema de nóminas y aplicaciones similares en instancias puntuales. Dado que estas aplicaciones se ejecutan con poca frecuencia y tienden a procesar lotes de datos, se adaptan bien a las instancias puntuales y permiten a CLM ahorrar una media del 70% en el coste de sus instancias EC2.
Al final del proceso, el equipo examina sus objetivos iniciales y los compara con los resultados obtenidos. El objetivo era reducir el consumo energético de su parque informático en un 85%. La migración inicial redujo el consumo de energía en un 40%; una vez finalizada la modernización de las aplicaciones, el equipo calcula que el consumo de energía de la empresa se ha reducido en un 87%. Además, las aplicaciones de CLM funcionan ahora más rápido que antes, requieren menos mantenimiento por parte del equipo informático interno y, con la nueva experiencia que han adquirido.
¿Y ahora qué?
Los proyectos de migración de este tipo son complejos y requieren conocimientos especializados para sacarles el máximo partido.
A lo largo de nuestra trayectoria, desde Geko hemos ayudado a organizaciones a trasladar sus aplicaciones y bases de datos a AWS para obtener un conjunto moderno de aplicaciones y herramientas, y para impulsar su agenda de sostenibilidad.
Si quieres saber si podemos ayudarte a cumplir tus objetivos de sostenibilidad y sacar el máximo partido de sus aplicaciones mediante la migración a AWS, puedes contactar con nuestros expertos.
