Hace unos años, todos los servicios de data de las compañías se desplegaban sobre plataformas on-premise, es decir, sobre máquinas físicas instaladas en sus propias instalaciones. Sin embargo, a medida que el dato se ha ido convirtiendo en la pieza que permite articular todas las interacciones con los consumidores, y, por ende, se ha puesto foco en recoger más y más dato, las estructuras monolíticas (sin capacidad de escalado en base a necesidad) han ido perdiendo terreno. En su lugar, se han hecho necesarias plataformas que permitan gestionar esta necesidad de manejar grandes cantidades de datos de una forma escalable, integrada y a un coste razonable. Estas plataformas no son otras que las plataformas de Cloud Computing.
Hoy en día, la mayor parte de las empresas están haciendo uso de las plataformas cloud en mayor o menor medida, pero muchos de los servicios relacionados con el dato aún siguen ejecutándose en plataformas on-prem. ¿Por qué? Porque, a veces, “da vértigo” migrar al cloud toda la lógica de servicios desplegada en máquinas propias, especialmente si es algo que a día de hoy no está dando problemas (aparentemente). El quid es que, quizás lo que ahora funciona, a medida que se van incorporando más datos, deje de funcionar.
En este post cubriremos las tres formas más habituales de migrar una solución on-premise a una plataforma cloud.
Lift and shift
Por sencillez, quizás la opción más buscada (que no por ello la mejor). Lift and shift (“levantar y mover”) busca lo que su nombre indica: “coger” lo que se tiene y moverlo a otro lado, en este caso, a una plataforma cloud. Es decir, la aplicación o el servicio on-prem, y todos sus datos asociados, se llevan tal y como están a una plataforma cloud. Esto hace que los cambios sean mínimos (no se modifica la arquitectura ni el código), y por tanto, que el time-to-market sea el más corto posible.
Sus principales ventajas son el ahorro de tiempo en la migración y que, en esencia, la aplicación o el servicio seguirá siendo el mismo, pero beneficiándose de estar desplegada en un entorno elástico.
Por el contrario, su principal desventaja es que la aplicación o servicio migrado no hará un uso óptimo del potencial de la plataforma cloud, ya que la arquitectura y el código seguramente no hayan sido diseñados para trabajar en entornos cloud escalables. Adicionalmente, los costes de infraestructura pueden no estar optimizados, ya que los servicios usados probablemente no sean los más adecuados para cubrir los casos de uso de la solución
Refactor
Esta forma de migración consiste en rediseñar la solución para hacerla nativa cloud. Esto significa rehacer el diseño de la arquitectura y del código bajo el prisma de los servicios que puede ofrecer una plataforma cloud, de forma que la solución saque el máximo partido de ellos.
Las ventajas de este escenario son que, al diseñar la aplicación como nativa cloud, los costes de infraestructura en el largo plazo se reducirán y la adaptabilidad de la solución ante nuevos requisitos será mayor. Adicionalmente, la forma de diseñar soluciones en el cloud hará que la escalabilidad sea más sencilla y que los workloads se ejecuten de una forma más eficiente.
Como principal desventaja está el time-to-market, que en este caso será el más largo, al tener que replantear toda la solución. Además, el coste de entrada al cloud para los perfiles que vengan de soluciones on-prem puede ser alto en función de la formación previa que hayan recibido en este ámbito.
Replatform
Esta metodología de migración está en un punto intermedio entre las dos anteriores. Consiste en llevar la aplicación y sus datos a la plataforma cloud, de una forma similar al lift and shift, pero cambiando alguna de las funcionalidades para hacer uso de las ventajas de la plataforma cloud. El ejemplo típico de este escenario es cambiar a una base de datos manejada para beneficiarse de su escalabilidad automática.
La ventaja de este método es que permite migrar a una plataforma cloud de una forma más escalonada (start small) que en el caso del refactoring. Sin embargo, esto puede convertirse en una desventaja si no se planifica correctamente, ya que la migración podría acabar convirtiéndose en un refactoring en fases tardías del proyecto, con el esfuerzo añadido de un cambio de enfoque una vez iniciada la migración.
Como veis, todas las soluciones tienen sus pros y sus contras. Nuestra recomendación es analizar cada caso en particular, y seguir un approach u otro en base a las necesidades de negocio en cuanto al time-to-market, y a las funcionalidades actuales y futuras.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
*Fuente imagen destacada: Pexels
Autor :
Publicado en : Marzo 25, 2021
Post por temática
