Las organizaciones que estén considerando trasladar aplicações empresariales a la nube pública deben asegurarse de trasladar también los servicios de distribución de aplicação de los que dependen sus aplicações en el centro de datos. Además, la migración a la nube presenta una oportunidad para organizar y racionalizar la seguridad y el acceso, ganar visibilidad en el tráfico de aplicação basadas en la nube y diseñar un sólido plan de recuperación ante desastres.
Para muchas organizaciones, trasladar aplicações empresariales a la nube pública puede ser una propuesta muy atractiva. Les permite deshacerse de los costos fijos y de los activos involucrados en la operación de infraestructura de TI a gran escala, incluidos centros de datos costosos repletos de equipos de diferentes generaciones y niveles de capacidad de soporte. Mientras estos servidores hacen funcionar la empresa, también consumen energía, generan calor y exigen costosos contratos de soporte. La gestión del ciclo de vida, el mantenimiento y el alojamiento físico de la infraestructura de TI exige habilidades, tiempo y presupuesto que pueden desviar la atención de la misión general de las organizaciones de TI: proporcionar las aplicações que hacen funcionar el negocio.
Deshacerse de este dolor de cabeza operativo y de esta pérdida financiera a cambio de un nuevo mundo en el que un servidor o una aplicação viejos se pueden retirar con una simple llamada API a menudo tiene sentido financiero y operativo. Si ya no necesita administrar la infraestructura básica que ejecuta su TI, puede concentrarse más en la seguridad, el rendimiento y la disponibilidad de las aplicações que representan el valor real que la TI aporta a la empresa.
Pero antes de llegar a este nirvana de infraestructura virtualizada y sin necesidad de mantenimiento, tendrá que encontrar la mejor forma de trasladar sus aplicações a su nuevo hogar. Migrar una aplicação a la nube pública implica algunas decisiones. Puede rediseñar completamente la aplicação para un entorno de nube, lo que puede generar una experiencia de usuario elegante y optimizada, pero a menudo puede ser un proceso que requiere mucho tiempo y trabajo. Como alternativa, puede simplemente tomar las aplicações que se ejecutan en su centro de datos y colocarlas en una nube pública sin realizar grandes cambios de diseño o plataforma.
Hay varias buenas razones para explorar este modelo de "elevación y traslado": Se estima que es aproximadamente 10 veces más barato.1 Casi siempre es mucho más rápido y, en algunos casos, simplemente no vale la pena reescribir una aplicação con una vida útil limitada. Pero si desea tener una migración "lift and shift" exitosa, hay algunas reglas que debe seguir (y una que deberá romper).
Empezaremos con el que hay que romper. El concepto de tratar a los servidores como ganado a menudo se considera intrínseco a las arquitecturas de nube. Si una instancia de servidor no funciona correctamente, no pierda tiempo solucionándola, simplemente elimínela y vuelva a implementarla. No actualice los sistemas operativos ni el software; simplemente implemente nuevas instancias y finalice las antiguas. Este es un consejo sólido. Pero puede ser contraproducente si intentas trasladar una aplicação que nació y creció en el lujo protegido del centro de datos al mundo frío y duro de la nube pública.
La mayoría de las aplicações empresariales no fueron diseñadas teniendo en mente arquitecturas y metodologías de nube. Mantienen el estado localmente, tardan un tiempo en conectarse después de que se inicia el servidor subyacente y los apagados repentinos probablemente generarán datos inconsistentes. Hay que tratarlos como las mascotas mimadas que son, no como ganado.
Las aplicações empresariales trasladadas a entornos de nube necesitan en gran medida los mismos servicios de cuidado, gestión y entrega de aplicação (seguridad, disponibilidad y rendimiento) que reciben en el centro de datos. Incluso los servicios básicos de equilibrio de carga que requieren estas aplicações serán más complejos que los que necesita una aplicação diseñada y nacida en la nube. Si desea que su aplicação prospere en la nube, debe trasladar con ella su infraestructura de soporte. Afortunadamente, la mayoría de los componentes de infraestructura ahora están disponibles en la nube pública de su elección, y puede reutilizar sus conocimientos, habilidades e incluso políticas organizacionales en la nube.
La evolución de la mayoría de las TI empresariales sigue un camino similar al de un panel de conexión de cableado. Ya sabes a cuál me refiero. Comienza hermoso, bien diseñado y perfectamente ejecutado. (Eche un vistazo a reddit.com/r/cableporn para ver algunas configuraciones realmente inspiradoras). Sin embargo, en el plazo de un año, las necesidades de tiempo y urgencia dieron como resultado que aquí se tomara un atajo y allá se utilizara un color equivocado ("¡el rojo es para la DMZ, maldita sea!"). En solo tres años, el gabinete se ha degenerado en un nudo gordiano de cableado Ethernet multicolor y sin etiquetas que simplemente necesita ser arrancado y reconfigurado.
Migrar a la nube es su oportunidad de deshacerse de ese panel de conexiones desordenado y recuperar el control de la seguridad y la gestión de acceso. Si bien necesitará trasladar algunos de sus servicios de infraestructura junto con la aplicação, debe aprovechar esta oportunidad para racionalizar, visualizar y organizar su estrategia de acceso a la red y a las aplicação .
Probablemente, el control más importante que puede implementar es la gestión de la identidad del usuario en sus entornos de nube. A medida que traslada algunas aplicações a la nube, retira algunas aplicações en favor de ofertas de software como servicio (SaaS) o reescribe algunas aplicações por completo, deberá tomar varias decisiones clave sobre la gestión de la identidad de los usuarios.
Ejecutar múltiples servicios de identidad puede ser oneroso, riesgoso e ineficiente, y puede generar parte de la complejidad que debería intentar eliminar. La gestión de identidad debe estar centralizada, pero el acceso debe estar federado en todas las ubicaciones requeridas. La tecnología que se integra con su servicio de identidad (generalmente Microsoft Active Directory) y lo extiende a servicios en la nube y SaaS mediante protocolos como SAML y OAuth permite que las aplicações autentiquen a los usuarios con una única fuente, en lugar de depender de la identidad local.
Pero a medida que las aplicações se han vuelto más dispersas, también lo han hecho los usuarios. Agregar controles que identifiquen la ubicación y los dispositivos de un usuario, combinados con opciones de autenticación de dos factores y contraseñas de un solo uso, puede brindar defensa contra la ingeniería social e intentos similares de comprometer la seguridad de la información de su organización.
Los entornos de nube abstraen múltiples capas de infraestructura de su interés directo. Esto es bueno porque ahora no es necesario brindar servicio ni soporte a una infraestructura física. Sin embargo, esta externalización de responsabilidad también conlleva una cesión de control directo.
Una de las cosas que deberá hacer para contrarrestar esto es monitorear el rendimiento de la aplicação con más cuidado. Agregar un mejor monitoreo que brinde información relevante y procesable puede facilitar la resolución de problemas y la planificación de la capacidad.
Otro beneficio puede ser la eliminación de algunas preocupaciones dentro del negocio. Las preguntas sobre la seguridad y el rendimiento en la nube provienen en parte de los aspectos multiinquilino y de conexión pública de la nube pública, pero también surgen de la percepción de pérdida de control. Agregar un mejor monitoreo de las aplicações y el comportamiento empresarial puede ayudar significativamente a promover esta migración y eliminar las barreras emocionales para la adopción de la nube.
La recuperación ante desastres y la continuidad del negocio (DR/BC) son pilares de una buena infraestructura de centro de datos y de un buen diseño de aplicação . El uso de una nube pública no elimina su responsabilidad de mantener las aplicações funcionando y seguras. Sin embargo, esto reduce la barrera de entrada para los servicios de DR/BC.
Antes de que existieran servicios de nube pública, crear una ubicación física de recuperación ante desastres podía implicar costos y plazos de entrega significativos. Ahora, puedes acceder a la infraestructura de otro continente desde un proveedor diferente utilizando una tecnología subyacente diferente en cuestión de minutos. Pero aunque la infraestructura puede estar mucho más disponible, crear una aplicação de alta disponibilidad aún requiere una planificación y configuración significativas.
Si bien existe amplia documentación dedicada al tema de la recuperación ante desastres y las infraestructuras en la nube, un buen marco para la planificación y el diseño de DR/BC se puede reducir a unas pocas decisiones y preocupaciones clave.
Primero, tendrás que pensar en el riesgo y el retorno de la inversión (ROI). ¿Valdrá la pena el tiempo y el gasto en adoptar la solución definitiva para múltiples regiones y múltiples proveedores? Si bien los servicios en la nube pueden reducir el costo de adquisición, los costos operativos de mantener servicios DR/BC sólidos seguirán existiendo.
En segundo lugar, debes pensar en cómo vas a almacenar y distribuir los datos transaccionales y mantenerlos consistentes. Este es un problema bien comprendido, pero es quizás la parte más difícil de crear aplicações geográficamente dispersas y de alta disponibilidad. Muchas soluciones requieren conexiones de gran ancho de banda y baja latencia entre ubicaciones, o diseños más esotéricos como un modelo de consistencia eventual que las aplicações empresariales rara vez adoptan. Crear una conectividad de baja latencia entre diferentes proveedores de nube no está al alcance de la mayoría de las empresas, pero ya están disponibles algunas opciones.
El tercer desafío clave es gestionar el acceso a sus aplicações. Para la mayoría de los diseños activo-activo o activo-DR, el uso de DNS para dirigir el tráfico al centro de datos óptimo en función de la disponibilidad, la proximidad o el rendimiento representa el mejor equilibrio entre simplicidad y funcionalidad. Esto es especialmente cierto cuando estás considerando un modelo de múltiples nubes en el que utilizas diferentes proveedores de nube para tus aplicações. El uso de protocolos de red como BGP también podría ser una opción, pero eso generalmente agrega complejidad y cierto riesgo. Otra opción podría ser simplemente equilibrar la carga o cambiar el tráfico de red a través de las nubes utilizando equipos o servicios ubicados en ubicaciones fuera de la nube, pero cerca de ella, lo que nos lleva a nuestra regla final.
La mayoría de las organizaciones medianas y grandes que migran aplicações empresariales a la nube querrán crear un acceso privado seguro a su infraestructura en la nube. Si bien ejecutar una solución VPN a través de Internet público puede ser apropiado para algunos, muchas organizaciones utilizarán una conexión más directa y dedicada al proveedor de nube. Estos enlaces dedicados proporcionados por proveedores de servicios ofrecen privacidad, ancho de banda garantizado y menor latencia que las conexiones públicas a Internet, pero tienen un precio.
Y si necesita conexiones resistentes a más de una nube, tendrá que aprovisionar múltiples enlaces. ¿O qué sucede si necesita conectar su nube a algunos componentes de infraestructura, pero sus centros de datos existentes están geográfica o lógicamente demasiado lejos de los puntos de intercambio de la red en la nube?
Cada vez más, las organizaciones consideran la posibilidad de colocar equipos en entornos conectados a la nube (comúnmente llamados intercambios de nube) que ofrecen conexiones de alta velocidad a múltiples proveedores de nube. Esto le permite alojar algunos de sus activos de TI extremadamente cerca de su infraestructura virtual en la nube, lo que le brinda conexiones privadas y de baja latencia entre las aplicações que se ejecutan en la nube y los componentes de infraestructura, como dispositivos de almacenamiento o seguridad, alojados en el centro de coubicación. Además, este acuerdo le permite aprovechar el equipo de TI existente y ampliar los controles de red y seguridad a la infraestructura de la nube.
Por último, la colocación en un intercambio en la nube le permite colocar controles en el nexo de su centro de datos corporativo, sus infraestructuras en la nube e Internet público. Puede ampliar o crear las políticas de seguridad que su negocio requiere y lograr un mayor control y visibilidad de los flujos de datos de las aplicação , mejorando su postura de seguridad general y ayudándole a racionalizar y estandarizar los servicios de acceso y seguridad.
La migración de aplicações empresariales a una nube pública puede permitir a las organizaciones ahorrar dinero, aumentar la flexibilidad y migrar rápidamente a un entorno de nube. Sin embargo, reconocer que las aplicações empresariales aún necesitan una infraestructura circundante es fundamental para una migración exitosa.
Asegurarse de que los servicios de los que dependen sus aplicações para su seguridad, rendimiento y disponibilidad estén presentes en la nube mantendrá sus aplicações empresariales tradicionales en funcionamiento y a sus usuarios contentos. La incorporación de un sistema de monitoreo le permitirá detectar áreas problemáticas rápidamente y ayudará a mitigar la ansiedad que los propietarios de aplicação pueden sentir a medida que sus servicios se trasladan a la nube.
El acto de levantar y trasladar también puede actuar como catalizador para restablecer controles sólidos, racionalizar el acceso y mejorar la continuidad del negocio, lo que aumentará el retorno de la inversión general de la migración. Por último, si está aprovechando múltiples nubes públicas, considere los beneficios de ubicarse en un intercambio de nube, lo que puede mejorar el rendimiento y permitirle estandarizar las políticas de seguridad y acceso desde un único punto de control.
1 Knapp, Kristin, “Los medios para el fin”, Modern Infrastructure, julio/agosto de 2015, http://docs.media.bitpipe.com/io_12x/io_125304/item_1181222/MI_JULY.pdf .