pressmaster - Fotolia

Evaluar Conozca los pros y contras de las tecnologías, productos y proyectos que está considerando.

Encuentre el mejor camino para su estrategia de migración de nube

Las migraciones a la nube pueden ser arduas, con muchas consideraciones. Primero, las empresas deben elegir entre elevar y cambiar o rediseñar.

Como tantas cosas en TI, no hay un enfoque de talla única para todos en la migración de aplicaciones hacia la nube. De hecho, una organización elige su ruta de migración de aplicaciones basado en una serie de factores: todo, desde la edad de una aplicación, hasta si se desarrolló externa o internamente, darán forma a cómo se mueve hacia la nube y se desempeña en ella.

Al migrar una aplicación a la nube pública, la mayoría de las organizaciones de TI eligen ya sea el enfoque "de elevación y cambio" o rediseñan la aplicación. Y aunque ambos enfoques tienen sus ventajas, las organizaciones deben elegir cuidadosamente al momento de elaborar una estrategia de migración hacia la nube.

Como su nombre indica, la migración de elevar y cambiar toma una aplicación interna y replica esa la aplicación en la nube, sin modificar su arquitectura o diseño.

Mientras tanto, el enfoque de rediseño, también conocido como refactorización de la aplicación, implica hacer cambios en la forma en que se desempeña una aplicación antes de moverla hacia la nube. Estos cambios pueden incluir la revisión del código fuente, reescribir las API e interfaces de la aplicación, y acoplar o desacoplar datos. Otros cambios, como el diseño de una aplicación para que escale recursos dinámicamente utilizando APIs nativas de nube o haciendo sus llamadas a base de datos orientadas a objetos, están destinados específicamente a maximizar el valor de la nube.

"Usted está rompiendo la aplicación hasta sus componentes funcionales y rediseñándola específicamente para una plataforma en la nube", dijo David Linthicum, vicepresidente senior de  Cloud Technology Partners, una firma de consultoría con sede en Boston.

El modelo de elevar y mover puede variar drásticamente del enfoque de rearquitectura en términos de tiempo y costos adelantados. Si bien elevar y cambiar se puede lograr en tan solo una semana, dijo Linthicum, el proceso de rediseño puede tardar meses –en algunos casos, incluso más tiempo– dependiendo de la aplicación y de si el trabajo se realiza de manera interna o por un tercero.

Los costos de elevar y cambiar tienden a comenzar en alrededor de 10,000 dólares por aplicación, dijo Linthicum. Pero ese número puede crecer significativamente en función del tipo de aplicación y del número de dependencias externas –es decir, en las bases de datos– que tiene. Sin embargo, si las organizaciones migran un gran número de aplicaciones a la vez, ese costo de 10,000 puede también ser reducida hasta la mitad.

"[El costo] cae exponencialmente si usted hace, tal vez, un centenar de [apps] a la vez o mil a la vez, y estamos viéndolas por ahí", dijo Linthicum.

Los cambios en los procesos de rediseño basados ​​en la aplicación y en quién los realiza, por lo que es difícil medir exactamente cuánto costaría una organización.

Linthicum estimó que 100,000 dólares por aplicación estaría en el extremo inferior de los costos de refactorización. Sin embargo, eso no significa necesariamente que elevar y mover es la opción más rentable en el largo plazo.

Dónde se queda corto el elevar y mover

Cuando una aplicación heredada se migra a una infraestructura como una plataforma de servicios con poca o ninguna modificación, no se puede sacar el máximo provecho de uno de los mayores beneficios de la nube: la rentabilidad a través de la autoescala. En la nube, los recursos de cómputo escalan automáticamente hacia arriba o hacia abajo sobre la base de la demanda de la aplicación. Pero la mayoría de aplicaciones heredadas no fueron diseñadas específicamente para sacar provecho de esa característica nativa de la nube. Así que cuando esas aplicaciones se mueven a la nube, consumen más recursos de almacenamiento y cómputo de lo que realmente necesitan, lo que puede conducir a una costosa factura.

"La idea con la nube es que puedo ganar valor y reducción de costos haciendo coincidir los picos de mi carga a la cantidad de infraestructura que estoy usando", dijo Robert Green, consultor principal en Enfinitum Inc., una firma de consultoría con sede en San Antonio. El problema con  elevar y mover, dijo, es que las instalaciones internas se construyen para adherirse a los picos de carga. Y cuando esas aplicaciones se mueven a la nube, siguen funcionando de esa manera, incluso si la demanda o el uso es bajo.

"Por lo tanto, los tiempos en los que no estoy en el pico, que podrían ser el 80% del día, estoy pagando de más", dijo.

Debido a esta ineficiencia, elevar y mover aplicaciones a la nube, en algunos casos, puede costarle a una organización, en última instancia, más que la rearquitectura de software por adelantado, dijo Green. Y, a veces, elevar y mover es incluso más cara que dejar la aplicación en las infraestructuras internas existentes.

"Imagínese mantener las luces encendidas todo el día y toda la noche", dijo. "Va a ser más caro que ir alrededor de la casa cada noche apagando todo. Con elevar y cambiar, todo está encendido, todo el tiempo, 24 por 7, no importa qué”.

Cuando Jonathan Feldman, CIO de la ciudad de Asheville, Carolina del Norte, comenzó a trabajar en una nueva aplicación para un portal de información para los residentes de Asheville, optó por diseñar esa aplicación desde cero para aprovechar la autoescala.

"El punto saliente es que, sin el control de la API para el tejido de la nube desde dentro del código fuente de la aplicación, en realidad no es la nube", dijo Feldman. "Es arrancar y subir, porque no  puede escalar hacia arriba y hacia afuera”.

Otros estuvieron de acuerdo en que elevar y mover no siempre produce los ahorros de costos que uno esperaría en la nube.

"Tuvimos un producto de analítica que tenía mucha hambre por masticar todos estos datos y llegó a un punto en el que, en realidad, estaba representando más de una cuarta parte de todos nuestros costos en AWS, aunque era tres servidores de trescientos", dijo Alex Witherspoon, ingeniero senior de DevOps y software en FlightStats, un proveedor de aplicaciones para hacer seguimiento de estados de vuelo."Y tenía ninguno de esos costos [cuando estaba] alojado en privado”.

Kristin Knapp es editora del sitio de SearchCloudComputing. Póngase en contacto con ella en: kknapp@techtarget.com o sígala en Twitter: @kknapp86.

Próximos pasos

Si está interesado en migrar sus aplicaciones a la nube, puede interesarle también:

Consejos para una fluida migración a la nube

El curioso caso de una migración de aplicaciones a la nube

Los servicios de migración a la nube exigen nuevos talentos, enfoques y más

Profundice más

Inicie la conversación

Envíenme notificaciones cuando otros miembros comenten sobre este artículo.

Por favor cree un Nombre de usuario para poder comentar.

- ANUNCIOS POR GOOGLE

Close