¿Vas a migrar aplicaciones a la nube? Lee esto primero.
Introducción
Los entornos de computación en la nube son ya un elemento predominante del panorama de TI, y cada vez son más las organizaciones que trasladan a la nube sus aplicaciones heredadas alojadas en sus propias instalaciones. Sin embargo, migrar una aplicación a la nube requiere algo más que trasladarla a una máquina virtual de un proveedor de servicios en la nube. Las motivaciones para migrar a la nube varían de una organización a otra, pero hay factores clave que todas deberían tener en cuenta, así como buenas prácticas que pueden contribuir al éxito del proceso. Para aprovechar al máximo las ventajas de la migración a la nube, es necesario planificar con antelación tanto la arquitectura de la aplicación como la transición de la infraestructura local a la nube.
Descripción general
Nube frente a infraestructura local: diferencias clave
Un entorno en la nube se comporta de forma diferente a un entorno local. Algunas de las diferencias entre ambos entornos son evidentes, como el hecho de que los recursos informáticos pertenecen a otra empresa y son gestionados por ella, en lugar de ser propiedad de la propia organización y gestionarse internamente. Sin embargo, varias de las diferencias más importantes no dependen de la tecnología. En general, cualquier tecnología disponible a través de un proveedor de servicios en la nube también está disponible en las instalaciones de la organización. Lo que ofrece la nube es un modelo de consumo alternativo, no una tecnología alternativa. Dicho de otro modo, las ventajas de migrar a un proveedor de servicios en la nube radican en cómo se consumen los recursos informáticos, no en los propios recursos informáticos.
Los proveedores de servicios en la nube no pueden reproducir todas las capacidades de los entornos locales, como las políticas de cumplimiento de auditoría de datos diseñadas para el hardware local. Dado que los componentes de la nube están dispersos geográficamente, la latencia suele ser mayor en las implementaciones en la nube. Los proveedores de servicios en la nube también se enfrentan a otras limitaciones. Como aplican estándares comunes a todos sus clientes, existen límites reales a la personalización de los entornos informáticos. Por ejemplo, pocos proveedores de servicios en la nube ofrecen equipos informáticos poco comunes y especializados.
Pero, si una empresa puede operar dentro de esos límites, un proveedor de servicios en la nube puede ofrecer capacidades de consumo que están fuera del alcance de la mayoría de las empresas. Un proveedor de servicios en la nube puede operar centros de datos en todo el mundo, lo que permite a las organizaciones elegir en qué centro de datos ubicar sus recursos informáticos. También puede asumir los costes fijos, de modo que la empresa pague únicamente por los recursos que realmente utilice. Dado que un proveedor de servicios en la nube cuenta con economías de escala que la mayoría de las empresas no puede igualar, puede realizar grandes inversiones en sistemas para gestionar y automatizar las implementaciones. Cabe señalar que ninguna de estas ventajas es de carácter técnico; más bien, las ventajas de un proveedor de servicios en la nube radican en las opciones y la estructura de costes que ofrece al consumidor.
Para mitigar las limitaciones y aprovechar las ventajas de un proveedor de servicios en la nube, un departamento de TI debe cambiar la forma en que implementa las aplicaciones y modificar los flujos de trabajo para sacar el máximo partido de los puntos fuertes de dicho proveedor, evitando al mismo tiempo depender de aspectos en los que un entorno en la nube se encuentra en desventaja, como la latencia.
Motivaciones para la migración a la nube
El ahorro de costes suele mencionarse como uno de los principales motivos para migrar a la nube, pero las verdaderas razones suelen tener más matices. La mayoría de las motivaciones se engloban en tres categorías: certidumbre, productividad y agilidad.
Los proveedores de nube pública aumentan la certidumbre al ofrecer la tecnología en paquetes que facilitan su consumo y, de este modo, asumen parte del riesgo operativo de TI. Dado que los proveedores mantienen la infraestructura y se responsabilizan de ella, las organizaciones pueden desentenderse de esas cuestiones. Asimismo, los proveedores de servicios en la nube suelen ofrecer herramientas que permiten conocer mejor las operaciones de TI, lo que aumenta la visibilidad. Como los costes de la nube pública suelen depender del consumo, una organización puede vincular más estrechamente los beneficios de una aplicación (como los ingresos) con sus costes operativos. A medida que aumenta el uso de la aplicación, también lo hacen los costes, pero también los beneficios. Al pasar de gastos de capital a gastos operativos, se reduce la necesidad de prever un margen para el crecimiento futuro al tomar decisiones de compra. Gestionar estas incertidumbres en el ámbito del proveedor de servicios en la nube aporta beneficios cuantificables.
Otro motivo para adoptar la nube pública es el aumento de la productividad. Las herramientas de colaboración y automatización de los proveedores se encuentran entre las más avanzadas del mercado. Además, al no tener que gestionar la infraestructura, el personal de TI puede centrarse en iniciativas estratégicas para el negocio, mientras que unas operaciones optimizadas que pueden gestionarse desde cualquier lugar aumentan su productividad.
La última razón para adoptar la nube pública es quizá la más convincente: la agilidad. Dado que el proveedor de servicios en la nube crea la ilusión de disponer de recursos infinitos en cualquier momento, la velocidad y la orientación de las iniciativas empresariales dejan de estar condicionadas por las limitaciones del aprovisionamiento de TI. Los recursos pueden desplegarse en cuestión de segundos o minutos. Un proyecto puede utilizar un entorno informático complejo durante un breve periodo sin tener que preocuparse por retirar el hardware cuando finalice. Las aplicaciones pueden desplegarse, escalarse y eliminarse rápidamente sin preocuparse por los activos de hardware.
Barreras para la migración a la nube
Aunque la migración a la nube ofrece numerosas ventajas, también plantea varios desafíos. Los obstáculos y riesgos varían en función de la fase del proceso en la que surjan: antes, durante o después de la migración. Abordarlos desde el principio aumenta las probabilidades de que la migración se lleve a cabo con éxito.
La planificación previa a la migración es quizá la parte más crítica del proceso. Las iniciativas de migración pueden fracasar si no se rediseña la arquitectura de la aplicación para aprovechar las capacidades de la nube. También es un buen momento para evaluar la complejidad de la aplicación y empezar a gestionarla. Asimismo, la formación del personal de TI debe impartirse al inicio de la iniciativa. Las implementaciones en la nube tienden a ejecutarse de forma aislada y a provocar una proliferación de herramientas, por lo que planificar durante las primeras fases puede ayudar a agilizar el proceso de migración.
La migración de aplicaciones a la nube suele llevar más tiempo y ser más compleja de lo previsto inicialmente. Para minimizar los problemas, empiece con una aplicación pequeña y relativamente independiente, de modo que cualquier problema que surja tenga un impacto mínimo. Las lecciones aprendidas durante esta primera migración podrán aplicarse a futuras migraciones.
Los problemas a largo plazo de las migraciones se hacen evidentes una vez finalizada la migración. Pueden surgir problemas de seguridad y cumplimiento normativo, a menudo porque resulta más difícil definir el perímetro de seguridad en un entorno de nube. El soporte de los sistemas heredados puede ser más complicado cuando los sistemas antiguos y nuevos no solo se encuentran en entornos diferentes, sino que además se han desarrollado con culturas distintas. Algunas organizaciones han mostrado preocupación por la dependencia de un proveedor de servicios en la nube, especialmente con el auge de los contenedores. Por último, el presupuesto puede plantear dificultades, ya que los costes variables de la nube pueden ser difíciles de prever cada trimestre.
Cómo elegir qué aplicaciones migrar
Una técnica para evaluar aplicaciones es la matriz de madurez frente a ubicación. Examine sus aplicaciones para determinar qué grado de madurez necesita. Las aplicaciones que aportan una diferenciación competitiva o que están orientadas a un nicho pueden funcionar mejor en las instalaciones. En el otro extremo del espectro, las aplicaciones de bajo coste o centradas en el liderazgo en costes (especialmente en lo que respecta al coste de los cambios) suelen adaptarse bien a un entorno de nube. Otro factor que debe tenerse en cuenta es la escalabilidad. Supongamos que se ha implementado una nueva aplicación y que, con el tiempo, su carga podría llegar a ser 100 veces superior a la actual. Para anticiparse al crecimiento en una implementación local, sería necesario sobredimensionar considerablemente la infraestructura, lo que generaría costes de capital adicionales por recursos inactivos. Sin embargo, si esa misma aplicación se implementara en un entorno de nube, los costes aumentarían en función del crecimiento y no sería necesario sobredimensionar la infraestructura.
Los aspectos relacionados con la red también pueden influir a la hora de decidir qué aplicaciones migrar a un entorno de nube. Si una aplicación cuenta con una gran proporción de usuarios distribuidos, como una extensa red de distribuidores, o con un número considerable de usuarios de correo electrónico remoto, una implementación local canaliza todo ese tráfico hacia el centro de datos. Dado que el tráfico ya circula por Internet, las aplicaciones no son sensibles a la latencia. Cuando este tipo de aplicaciones se trasladan a un entorno de nube, la latencia de la red no cambia, pero se libera ancho de banda en los centros de datos locales que, de otro modo, consumirían los usuarios distribuidos.
Al mismo tiempo, hay motivos para mantener algunas aplicaciones en las instalaciones. En el caso de las aplicaciones con una vida útil más corta, puede que los riesgos y costes de la migración no compensen. Algunas aplicaciones dependen de una baja latencia de red y de la velocidad del almacenamiento, por lo que podrían ofrecer un rendimiento mucho peor en un entorno de nube. Las cuestiones relacionadas con el cumplimiento normativo y la seguridad suelen ser motivos para mantener las aplicaciones en las instalaciones. Algunos procedimientos de auditoría presuponen el acceso físico a los sistemas y los datos para poder verificarlos, mientras que otros exigen que la aplicación y el sistema operativo se ejecuten directamente sobre el hardware (es decir, que no se ejecuten en una máquina virtual). Con el tiempo, los procedimientos de cumplimiento normativo se adaptarán al entorno de nube, pero en muchos casos esto aún no ha sucedido. En lugar de asumir el riesgo de no superar las auditorías de cumplimiento normativo con aplicaciones en la nube, por ahora puede ser más sensato mantener esas aplicaciones sensibles en las instalaciones. Algunas aplicaciones deben ser compatibles con sistemas y procesos heredados y, por tanto, no resulta viable rediseñar su arquitectura para que funcionen en la nube. Estas aplicaciones también podrían ser candidatas a permanecer en las instalaciones. Por estos motivos, algunas aplicaciones deberían tener una prioridad de migración menor que aquellas que se adaptan mejor a un entorno de nube.
Aplicaciones que es mejor mantener en las instalaciones
- Aplicaciones con una vida útil corta
- Aplicaciones que requieren baja latencia
- Aplicaciones que plantean problemas de cumplimiento normativo
- Aplicaciones compatibles con sistemas heredados
Consideraciones sobre la transición
Muchas organizaciones deben superar diversos retos durante el proceso de migración. Una cuestión importante que habrá que resolver es cómo llevar a cabo la transición propiamente dicha. Un enfoque consiste en utilizar DNS para dirigir a la aplicación local hasta que la aplicación en la nube se haya probado exhaustivamente y, a continuación, modificar los registros DNS para que dirijan a la aplicación en la nube. DNS contiene un valor de tiempo de vida (TTL) que permite a los clientes almacenar en caché la respuesta DNS durante un periodo determinado. Antes de la transición, puede ser conveniente establecer un TTL bajo, quizá de solo unos segundos, para que, tras el cambio, los clientes se dirijan rápidamente a las nuevas aplicaciones. Sin embargo, este enfoque conlleva ciertos riesgos. Reducir el TTL puede aumentar considerablemente el tráfico DNS y la carga de los servidores. Una organización podría ignorar el TTL y mantener los datos en caché durante más tiempo del especificado, lo que haría que algunos usuarios siguieran siendo dirigidos a la aplicación local mucho después de haberse realizado la transición. Considere la posibilidad de comprobar la solidez de su infraestructura DNS antes de utilizar este enfoque.
El proceso de transición también puede poner de manifiesto problemas de la nueva aplicación que no se detectaron durante las pruebas. Una forma de protegerse frente a una aplicación problemática consiste en disponer de un plan de contingencia que permita volver a procesar las operaciones con la aplicación local en caso de que surjan problemas. Por desgracia, una transición bidireccional complica la sincronización de los datos, por lo que requiere mucha más planificación y pruebas previas. Un enfoque más sofisticado consiste en realizar una transición parcial, denominada prueba canary, en la que una parte de los usuarios pasa a utilizar la aplicación en la nube mientras esta se supervisa. A medida que aumenta la confianza en la aplicación, se puede migrar a más usuarios hasta que, finalmente, todos hayan completado la transición. A la inversa, si surge algún problema, los usuarios que ya hayan realizado la transición pueden volver a utilizar la aplicación local. Las pruebas canary pueden llevarse a cabo mediante un controlador de entrega de aplicaciones (ADC) programable a través de F5® iRules®, lo que minimiza los riesgos y amplía las opciones disponibles para el equipo de operaciones durante el periodo de transición.
Recomendaciones
Crea aplicaciones de otra manera para la nube
Uno de los mayores errores que cometen las organizaciones al migrar aplicaciones es no rediseñar su arquitectura para la nube. Dedicar tiempo a modificar la estructura de la aplicación para aprovechar las particularidades de un entorno en la nube puede aportar importantes beneficios.
Por ejemplo, escalar en un entorno de nube es trivial en comparación con hacerlo en una infraestructura local. En lugar de diseñar la aplicación y probarla para la carga máxima prevista, diseñe una aplicación ligera pero escalable. No es necesario mantener la sobrecarga que supone una gran infraestructura cuando el uso de la aplicación puede variar considerablemente. En su lugar, empiece con una infraestructura pequeña y prepárela para escalar. Del mismo modo, determinados fallos, como los cortes de suministro eléctrico, son menos probables en un entorno de nube, por lo que hay menos necesidad de diseñar la arquitectura para afrontarlos.
Por otro lado, los entornos en la nube introducen nuevas limitaciones que no suelen darse en las instalaciones locales. Los arquitectos de la nube señalan que el diseño debe contemplar el fallo de cualquier instancia de máquina virtual en cualquier momento como parte del funcionamiento habitual. El almacenamiento también es diferente en un entorno de nube. Los diseños locales suelen utilizar almacenamiento en bloques local. Esta misma opción está disponible en los entornos de nube, pero no se puede compartir. La combinación de un estado local no compartido y el fallo de una instancia podría ser desastrosa. Existen otros paradigmas de almacenamiento, como el almacenamiento basado en objetos o los servicios de almacenamiento de clave-valor. Las limitaciones de un entorno de nube pueden mitigarse rediseñando la arquitectura de la aplicación.
Considere qué mantener en las instalaciones
Tiene sentido mantener algunas aplicaciones o sistemas de control en las instalaciones. Muchas organizaciones conservarán Active Directory en sus instalaciones y utilizarán la federación para extender la identidad a un entorno en la nube. Del mismo modo, un ADC ofrece numerosos servicios de seguridad para facilitar la entrega de aplicaciones, como cortafuegos, cortafuegos de aplicaciones web, protección contra ataques DDoS e interceptación SSL/TLS, además del encadenamiento de servicios. Un ADC también proporciona gestión avanzada del tráfico y un proxy programable, así como gestión de identidades y accesos.
Tradicionalmente, las organizaciones han consolidado estos servicios de aplicaciones fuera de la propia aplicación, ya que no forman parte de la lógica de negocio, sino que responden a necesidades operativas. Para poder realizar cambios operativos con independencia de los calendarios de lanzamiento de las aplicaciones, muchas empresas concentran conocimientos especializados que pueden aplicarse a todas las aplicaciones mediante un ADC como punto de control estratégico. Sin embargo, los entornos en la nube cambian este modelo.
Uno de los primeros enfoques para la entrega de aplicaciones en entornos de nube consistía en replicar los servicios de ADC mediante herramientas nativas en cada entorno de nube. Pronto se hizo evidente que los proveedores de servicios en la nube no ofrecían el mismo nivel de capacidades nativas, lo que obligaba a las organizaciones a elegir entre mantener estándares heterogéneos de entrega de aplicaciones en los entornos de nube y locales, o rediseñar todas las aplicaciones ajustándolas al mínimo común denominador.
A medida que las empresas se expandían a múltiples entornos de nube, ambas opciones resultaban menos atractivas. Supongamos que una organización utiliza tres proveedores de servicios en la nube y también mantiene un centro de datos local. La organización tenía que mantener cuatro equipos de especialistas en SSL/TLS, cuatro equipos de especialistas en DDoS, etc., o bien estandarizar un conjunto cada vez más inconexo (y limitado) de servicios básicos. Implementar una sola aplicación nueva en otro entorno de nube suponía un coste marginal considerable, ya fuera por la necesidad de contar con otro equipo de expertos en la materia o por tener que definir un nuevo conjunto de estándares aplicables a todas las aplicaciones existentes.
Pero existe una tercera opción para ofrecer servicios uniformes en todos los entornos. F5 Application Connector permite que un único equipo de expertos en la materia gestione todas las aplicaciones, independientemente de dónde estén alojadas. Mediante el uso de dispositivos de hardware o software BIG-IP® existentes, una organización puede incorporar servicios avanzados de aplicaciones completos delante de cualquier aplicación, esté donde esté, lo que proporciona a todas las aplicaciones un punto de control estratégico gestionado por un único equipo de expertos en la materia. Además, Application Connector refuerza la seguridad al eliminar todas las direcciones IP públicas visibles, lo que reduce las superficies de ataque. Al almacenar las claves de cifrado de forma centralizada y no en las instancias en la nube, las organizaciones pueden tener la certeza de que su información criptográfica crítica permanece privada. Por último, Application Connector aumenta la eficiencia de la implementación en la nube al permitir que la instancia de proxy detecte automáticamente los nuevos nodos de carga de trabajo.
Evalúa cuidadosamente el almacenamiento
Una de las principales diferencias entre las aplicaciones locales y las aplicaciones en la nube es el almacenamiento del estado de la aplicación. En su inmensa mayoría, los diseños locales utilizan almacenamiento local en bloques, como un disco duro o una unidad de estado sólido. Una aplicación en la nube también puede utilizar almacenamiento en bloques, pero este es local para la instancia y los diseños deben prever que las instancias pueden fallar. Si las organizaciones no modifican ningún otro aspecto del diseño de una aplicación al migrarla a la nube, deberían cambiar la forma en que se gestiona el estado.
Un tipo habitual de almacenamiento en la nube es el almacenamiento de objetos, en el que cada objeto es básicamente un archivo, pero se identifica mediante un nombre. Por lo general, el almacenamiento tiene como máximo un nivel de jerarquía (es decir, una carpeta o un directorio), por lo que asignar un sistema de archivos tradicional a objetos puede resultar problemático. Dado que los objetos no se pueden editar, sino únicamente crear, leer y eliminar, el almacenamiento de objetos es una buena opción para contenido estático, como imágenes, pero no para almacenar el estado. Muchas aplicaciones presuponen que los archivos se pueden modificar, por lo que no funcionan con objetos.
Otras opciones de almacenamiento incluyen los almacenes de clave-valor y las bases de datos transaccionales tradicionales. No son sistemas de almacenamiento como un sistema de archivos, pero almacenan datos y se ofrecen como un servicio adicional. Con un diseño eficaz, el estado puede almacenarse en un servicio de clave-valor o de base de datos.
En resumen: prepárate antes de migrar
Los entornos de computación en la nube ofrecen ventajas, pero solo si se rediseña la arquitectura de las aplicaciones clave para aprovechar las funcionalidades de la nube y, al mismo tiempo, mitigar el impacto de sus limitaciones. Los entornos en la nube presentan distintos escenarios de fallo y suelen tener una mayor latencia de red, pero permiten escalar rápidamente y elegir entre centros de datos de todo el mundo. Entre los aspectos que deben tenerse en cuenta para la migración a la nube se encuentra determinar qué aplicaciones migrar y cuáles mantener en las instalaciones.
También es necesario reflexionar y planificar cuidadosamente el propio proceso de transición, así como disponer de un plan de reversión por si la aplicación en la nube no se comporta según lo previsto. Como parte del proceso de planificación, algunas organizaciones mantienen un ADC en sus propias instalaciones como punto de control estratégico para todas las aplicaciones, independientemente de dónde estén alojadas. Por último, planifique cuidadosamente cómo almacenará la aplicación en la nube los datos y el estado. Sea cual sea la forma que elija para trasladar sus aplicaciones —y su negocio— a la nube, considere la posibilidad de contar con un socio con experiencia en la nube.
PUBLICADO EL 16 DE AGOSTO DE 2017