Para el éxito de Lift and Shift hacia la nube, concéntrese en la arquitectura

Han surgido dos modelos distintos de “transición a la nube”. El primero y más obvio es el enfoque nativo. Nativo que significa nuevo, ya sea nuevo o reescrito. El enfoque nativo fomenta un enfoque centrado en la aplicação, con la suposición de que cuando se adapta a la nube, el rendimiento y la seguridad se convierten en una cuestión de aprovisionamiento de los servicios adecuados en la nube. Lo cual no es del todo cierto, pero es lo suficientemente cercano como para que nos quedemos con eso por ahora.

El segundo enfoque es “lift and shift”, que se centra exactamente en lo que parece: levantar una aplicação existente desde su base de centro de datos y trasladarla a la nube, donde se coloca sobre una base nublada. Excepto que en este modelo el foco no puede estar sólo en la aplicação , porque la aplicação también tiene dependencias que deben abordarse. Esto incluye otros componentes arquitectónicos que abarcan aplicação y servicios de infraestructura. 

Esto se destacó recientemente en un informe de Cloud Velox , con el foco puesto en aprovechar la nube como centro de datos secundario. Curiosamente se observó este hallazgo:

Ahora bien, Cloud Velox se centraba en la recuperación ante desastres, pero parece que el problema general tiene una aplicación más amplia. Transferir y trasladar aplicaciones a la nube es mucho más cómodo si también puedes transferir controles (servicios) de red y seguridad junto con ellas.

Básicamente, si mueves una aplicación que ha sido optimizada a lo largo de los años utilizando servicios de aplicaciones alojados en la red sin esos servicios de aplicaciones, pierdes esas optimizaciones. Ah, existe esa creencia errónea de que simplemente estar ahí, en la nube, proporciona un aumento de rendimiento porque está físicamente más cerca de la red troncal de Internet y de los usuarios que interactúan con ella, y eso es algo cierto, pero no del todo. Esto se debe a que gran parte del rendimiento de una aplicação no está determinado por la latencia de la red. La verdad es que muchas de las ineficiencias de una aplicação que conducen a un bajo rendimiento están relacionadas con el tamaño y la composición del contenido, la mala gestión de la conexión y la incapacidad de ajustar adecuadamente la pila de red para que coincida con las necesidades específicas de la aplicación.

Las preocupaciones en materia de seguridad tampoco desaparecen de repente cuando se traslada una aplicación a la nube. Si la aplicación era vulnerable a XSS o SQLi en el centro de datos, puedes apostar que seguirá siendo vulnerable cuando la migres a la nube*.  Si esas inquietudes se abordaran en el centro de datos con un firewall de aplicaciones web o artefactos de seguridad implementados en un proxy programable, entonces sería mejor eliminar el firewall de la aplicación y el proxy y trasladarlos junto con la aplicación.

La capacidad de “levantar y cambiar” una arquitectura, en lugar de solo la aplicação, es una de las razones detrás de la creciente popularidad de una opción de nube ubicada conjuntamente. También hay argumentos a favor de ahorros de costos en comparación con las instalaciones locales y de un mejor control que en la nube, pero ciertamente una de las características más atractivas de una opción de nube ubicada conjuntamente es la capacidad de levantar y trasladar una arquitectura completa y aprovechar la "nube de al lado". A veces, las organizaciones desean mover la fuente de datos más cerca de las aplicaciones implementadas en la nube para evitar la latencia que destruye el rendimiento necesaria para regresar al centro de datos corporativo. A veces, la empresa quiere poder escalar el frontend sin interrumpir el back end (y, nuevamente, evitar la latencia). Pasarse a un proveedor de nube ubicado en el mismo lugar significa que pueden hacerlo, porque la nube está allí mismo, a través de una interconexión muy rápida de nivel de centro de datos.

Independientemente del enfoque hacia la nube (co-lo o pública), la clave para una migración a la nube exitosa es trasladar la mayor parte posible de la arquitectura. Independientemente de las opciones de servicios en la nube, es importante mantener los servicios de aplicaciones críticas con su aplicação durante su transición para garantizar que el rendimiento y la seguridad no se vean comprometidos por la reubicación. 

*También conocida como Ley de Hoff, que, aunque no es realmente una ley, sigue siendo una observación tan precisa hoy como cuando se observó por primera vez en 2009.