Gamers ahora disponen en Latam de SSD más fría
¿Cómo sabe cuándo, simplemente, reubicar unas aplicaciones en la nube y cuándo reconstruirlas desde cero? Estas Rs lo ayudan en esa tarea.
Por Isaac Sacolick | Original de IDGN
Cuando alguien dice que quiere modernizar una aplicación para la nube, ¿a qué se refiere exactamente?
Los usuarios tienen una perspectiva:
- Esperan que la modernización brinde experiencias mejoradas
- Mayor confiabilidad
- Rendimiento más rápido
- E, idealmente, implementaciones de funciones más frecuentes
Los arquitectos, los desarrolladores de software y los ingenieros devops tienen diferentes respuestas sobre lo que significa la modernización de aplicaciones.
Esto se debe a que existen varios enfoques técnicos para la modernización de apps y la opción óptima no siempre es obvia.
Por ejemplo, una aplicación de flujo de trabajo utilizada por docenas de usuarios escrita en las últimas versiones de Java y MySQL puede ser fácil de cambiar a una nube pública.
Este enfoque requiere poca reescritura de código pero, probablemente, precise:
- Cambios de configuración
- Actualización del CI/CD
- Y re-ejecutar las automatizaciones de prueba
Por otro lado, si esa misma aplicación está escrita en Cobol y se ejecuta en un mainframe, es muy probable que necesite una revisión antes de ejecutarse en la nube.
Todavía hay varias opciones técnicas entre levantar y cambiar hasta una revisión completa. Tales opciones se conocen como las 7 Rs de la modernización de aplicaciones en la nube.
Hay pequeñas diferencias de una fuente a otra, pero representan bien las opciones de modernización de alto nivel.
Factores a considerar
Las organizaciones tienen cientos o miles de aplicaciones heredadas, así como apps con una deuda técnica significativa y otras que ganan beneficios comerciales o para el usuario en una migración.
Los arquitectos y los líderes técnicos a menudo usan diferentes enfoques de modernización según las necesidades comerciales y los desafíos técnicos.
Los primeros temas a considerar son los impactos en las operaciones comerciales y los usuarios.
Las aplicaciones de mayor uso y de misión crítica requerirán enfoques técnicos diferentes a los de las aplicaciones que se usan de forma esporádica.
Cada modernización requerirá comunicación con los usuarios, pruebas y capacitación de personas sobre cambios en el flujo de trabajo.
Nitha Puthran, vicepresidenta sénior de nube e infraestructura de Persistent Systems, brinda una descripción general de algunos de los factores comerciales en la selección de enfoques y hojas de ruta para la modernización de aplicaciones.
Ella dice:
“Uno de los mayores desafíos que enfrentan las organizaciones es tanto identificar como saber qué aplicaciones deben levantarse y cambiarse, refactorizarse o reescribirse y en qué orden”.
La ejecutiva destacó que la modernización de apps requiere de un equilibrio cuidadoso entre:
- La velocidad de comercialización y la escalabilidad
- La optimización de costos
- La mitigación de la deuda técnica futura
- Y el tiempo de inactividad operativo
Garth Fort, director de productos de Splunk, comparte cómo los equipos de desarrollo se benefician de las modernizaciones de aplicaciones.
“Puede haber muchos beneficios en una migración a la nube, incluida la reducción de costos, la mejora de la seguridad y la resiliencia, así como el facilitar el escalar la prestación de servicios para los clientes”, dice.
Igualmente asegura que, para los equipos de desarrollo, la modernización puede:
“Mejorar la agilidad y la productividad del personal, lo que permite que los equipos se centren en la experiencia del cliente”.
Los equipos y arquitectos de Devops deben revisar los factores comerciales, técnicos, operativos y/o de seguridad de cada aplicación para, luego, considerar estos enfoques en la modernización de la nube de aplicaciones.
Retire las aplicaciones que ya no son valiosas
¿Todavía tiene aplicaciones compatibles con conexiones de acceso telefónico, fax u otras formas heredadas de hacer negocios? Cuando las apps realizan funciones que ya no son necesarias, la estrategia de modernización adecuada es retirarlas.
A veces, la decisión de retirar una aplicación es clara: los usuarios comerciales han decidido cerrarla o retirar la app que no tiene ningún impacto en las operaciones comerciales.
Pero, incluso cuando las aplicaciones tienen poco uso o realizan una función comercial, su valor comercial debe sopesarse frente a los costos de modernización y soporte continuo.
Amit Patel, vicepresidente senior de Consulting Solutions, dice al respecto:
“Para mejorar la experiencia del usuario, las empresas deben considerar la estrategia de retiro. Salir de las aplicaciones heredadas obsoletas crea eficiencias, lo que lleva a una mejor experiencia de usuario para sus clientes. La superficie de ataque reducida también conduce a una mayor seguridad”.
Reemplace apps con opciones SaaS comerciales o de código abierto
Fort explica que el reemplazo puede ser apropiado cuando las soluciones propietarias ya no son necesarias.
El ejecutivo destaca que:
“Reemplazar una aplicación es algo que ocurre cuando una organización deja de depender de sus propias aplicaciones personalizadas y migra hacia apps de terceros: preconstruidas, proporcionadas por un proveedor y alojadas en una nube”.
Los ejemplos incluyen:
- Herramientas de gestión de relaciones con los clientes
- Sistemas de gestión de contenido
- O herramientas de flujo de trabajo personalizadas
- Desarrolladas cuando las soluciones SaaS, comerciales o de código abierto equivalentes
- En ese momento, no satisfacían las necesidades comerciales
Hoy en día, los usuarios comerciales pueden encontrar opciones de terceros mejores y más baratas en comparación con la propia que necesita actualizarse.
Reubicar la aplicación en la nube
Las aplicaciones que satisfacen las necesidades comerciales y se ejecutan en pilas de software compatibles pueden ser candidatas para la reubicación.
En lugar de ejecutarlos en máquinas virtuales o hardware dedicado, el equipo de arquitectura y desarrollo encuentra beneficios técnicos y comerciales al trasladarlos a entornos de nube.
Por ejemplo, puede ser más fácil configurar:
- Entornos de desarrollo y prueba
- Escalar automáticamente la producción
- Y configurar entornos de recuperación ante desastres
- Con la aplicación ejecutándose en una nube pública o privada
Pero Bob Quillin, director de ecosistemas de vFunction, explica que:
“La migración no es igual a la modernización. Se pueden obtener beneficios devops con el método de migración, de elevación y cambio. Casi todas las empresas logran algunas ganancias a corto plazo. Pero, el error que cometen muchos líderes tecnológicos es creer que el trabajo se detiene allí”.
La reubicación puede proporcionar flexibilidad de infraestructura, seguridad mejorada y reducción de costos, pero no aborda los problemas relacionados con el soporte de la aplicación y el código subyacente.
“Esta es la realidad: un monolito en la nube tiene los mismos problemas espinosos que tenía en las instalaciones: velocidad de ingeniería lenta, falta de escalabilidad y mantenimiento difícil”, explica Quillin.
Señla que la fase de descubrir esto se conoce como “arrepentimiento de levantar y cambiar”, ya que los costos aumentan y los beneficios de la nube aún están fuera de alcance.
“Para acabar con este mito, la migración debe verse y planificarse en el contexto de una estrategia de modernización más amplia y estratégica”, explica.
Componentes de la nueva plataforma que tienen ventajas operativas
Muchos interpretan “lift and shift” como una opción de migración que requiere una participación mínima del equipo de desarrollo y no necesitará actualizaciones de código ni cambios de configuración importantes.
La esperanza es obtener algunos beneficios de la migración sin el trabajo adicional y los costos de reingeniería del código.
Pero entre el código y la infraestructura hay plataformas de base de datos, marcos y componentes, así como oportunidades para cambiarlos de plataforma durante la migración.
Aunque una nueva plataforma, generalmente, requiere desarrolladores, es posible que no requiera cambios sustanciales en el código, especialmente cuando se intercambian en la pila plataformas básicas, estandarizadas o casi equivalentes.
Tomer Shiran, cofundador y director de productos de Dremio, comparte un ejemplo.
“En lugar de levantar y cambiar un almacén de datos heredado o un lago de datos a la nube, una migración a la nube presenta oportunidades para adoptar arquitecturas de lago abierto y enfoques de malla de datos para la gestión de datos”.
Los arquitectos de la nube pueden modernizar los almacenes y lagos de datos para implementarlos como servicios de nube pública que ofrecen beneficios operativos y de costos.
Otras opciones de cambio de plataforma incluyen:
- La migración de buses de servicio
- El cambio a las herramientas de CI/CD estándar de una organización
- O el cambio de redes de entrega de contenido.
Reutilice, refactorice o reconstruya aplicaciones que ofrezcan impactos comerciales a largo plazo
Una vez que los equipos de arquitectos y desarrolladores deciden actualizar el código como parte de la modernización de la aplicación, tienen varias opciones:
- Reutilice los modelos de datos, los servicios y las API existentes de la aplicación, pero rediseñe la experiencia del usuario.
- Refactorice el código para mejorar el rendimiento, la seguridad, la capacidad de mantenimiento y otras actualizaciones no funcionales.
- Reconstruya módulos y capacidades para mejorar la funcionalidad, solucionar defectos o reducir la deuda técnica.
Algunos rediseñarán aplicaciones monolíticas en microservicios.
¿Qué enfoque es mejor para su aplicación? Patel comparte su punto de vista:
“La estrategia de refactorización y rediseño, si bien es el enfoque más costoso, debe tenerse en cuenta cuando las empresas desean avanzar hacia un modelo de DevOps más ágil. Esta estrategia también ayuda con la innovación continua y, en última instancia, ayuda a aumentar el rendimiento”.
Los equipos de Devops también pueden considerar enfoques por etapas.
Por ejemplo, primero pueden volver a hospedar aplicaciones que se ejecutan en plataformas compatibles para obtener los beneficios operativos de ejecutarlas en nubes públicas o privadas.
Luego, pueden considerar reutilizar aplicaciones de bajo uso que no se actualizan con frecuencia y rediseñar otras aplicaciones donde existe una necesidad empresarial de mejoras frecuentes.
Las modernizaciones de aplicaciones no están libres de costos o riesgos.
Para las organizaciones con miles de aplicaciones, puede llevar años modernizar completamente la cartera.
Los equipos y arquitectos de Devops deben usar una lente de practicidad y revisar todos los factores antes de seleccionar la estrategia de modernización de una aplicación.
