Nube híbrida hecha realidad: F5, Azure y Azure Stack

Hoy en día, muchos departamentos de TI reciben presión de los grupos de liderazgo para alejarse de la naturaleza estática de los centros de datos internos tradicionales y adoptar arquitecturas más dinámicas centradas en la nube, lo que aumenta la agilidad, la flexibilidad y la escalabilidad y, al mismo tiempo, reduce los costos operativos. Y como las nubes públicas y privadas tienen sus ventajas y desventajas, alrededor del 71%¹ de las empresas implementan modelos híbridos para beneficiarse más de las ventajas, anulando al mismo tiempo muchas de las desventajas. Sin embargo, casi todas estas organizaciones lo hacen empleando servicios de aplicação e infraestructura de nube no homogéneos, lo que aumenta drásticamente la complejidad para los equipos multifuncionales encargados de diseñar y mantener estas implementaciones.

Vincular dos (o más) entornos de nube distintos para crear una nube híbrida no solo es beneficioso desde el punto de vista de la agilidad, la flexibilidad y la escalabilidad, sino que también permite una gran cantidad de casos de uso especializados que serían mucho más difíciles (o imposibles) de implementar. Podría decirse que los más comunes son:

Establecer y mantener una copia de seguridad de alta disponibilidad y redundancia geográfica de una nube privada para evitar el tiempo de inactividad de las aplicações esenciales es muy costoso y probablemente duplicaría la inversión necesaria para ejecutar una sola nube privada. No solo necesitaría el doble de hardware físico, sino que también necesitaría un centro de datos separado, con su propia energía, refrigeración y personal en una ubicación geográficamente separada.

Como alternativa, los entornos de alta disponibilidad y recuperación ante desastres se pueden alojar en la nube pública por una fracción del costo. Los datos de la aplicação se almacenan cada vez que se realiza una copia de seguridad desde la nube privada, mientras que los recursos reales de la aplicação y de la red permanecen inactivos hasta que se los necesite, es decir, en caso de un desastre o una falla de la nube privada. Si es necesario, estas aplicações y recursos se ponen en funcionamiento y utilizan los datos almacenados, lo que garantiza la disponibilidad de las aplicação y la continuidad del negocio.

Desarrollar una nueva aplicação en una nube privada puede ser sustancialmente más costoso que en la nube pública. Requiere una inversión de capital inicial para ejecutar la carga de trabajo, sin garantía de que funcione o sea adoptado en el mercado actual. Por estos motivos, las empresas están siguiendo el mantra “fallar rápido, fallar barato” y utilizan la capacidad bajo demanda de la nube pública para desarrollar, probar y ejecutar nuevas aplicaciones en modo de producción. Una vez que se considere que las aplicaciones son operativamente sólidas o que han sido ampliamente adoptadas por los usuarios, se pueden migrar a la nube privada, que puede ser más segura y operativamente más barata a largo plazo. Como alternativa, podrían permanecer en la nube pública, implementadas en un entorno más rentable y a largo plazo, utilizando instancias reservadas más baratas y similares.

Considerada a menudo como la capacidad de nube híbrida más deseable, la explosión de nubes es probablemente la más difícil de implementar y con frecuencia se convierte en la ballena blanca de muchas estrategias de nube híbrida. Con la expansión de la nube, una aplicação se ejecuta predominantemente en la nube privada. Cuando la demanda excede la capacidad, las solicitudes adicionales se redirigen a una réplica exacta que se ejecuta en la nube pública en una infraestructura alquilada. Sin embargo, este es un estado temporal, diseñado para manejar picos de tráfico inesperados que duran períodos cortos de tiempo. Una vez que los períodos de mayor tráfico se vuelven sostenidos, las empresas pueden ampliar la capacidad de su nube privada.

Configurar un entorno de nube híbrida para la expansión de la nube es inherentemente difícil y complejo. Requiere una relación sinérgica entre los dos entornos, así como una orquestación a prueba de fallos para garantizar que la redirección se realice de forma autónoma y sin problemas, con poco o ningún impacto en la experiencia de los usuarios finales. La dificultad se amplifica aún más para los equipos encargados de la configuración y la gestión cuando la infraestructura, los servicios y las herramientas utilizadas para ejecutar y soportar las aplicações son diferentes para cada entorno.

No debería sorprenderte saber que no todas las nubes son iguales. Cada uno tiene su propia infraestructura, servicios de red y aplicação , herramientas de desarrollo, interfaz de usuario y diferenciación frente a otros competidores de la nube. Por ejemplo, es mucho más fácil para los usuarios de Sharepoint, Exchange, SQL Server u otras tecnologías de Microsoft migrar a Microsoft Azure que trasladarse a AWS o Google Cloud. Estas diferencias entre plataformas y servicios generan incompatibilidades entre nubes y hacen que la tarea de desarrollar entornos de nube híbrida sea increíblemente desafiante.

Sin embargo, Microsoft ha logrado avances considerables en el apoyo a la creación de nubes híbridas al ofrecer recursos y servicios sinónimos en entornos de nubes públicas y privadas a través de Azure y Azure Stack, respectivamente. Azure Stack, que se presentó recientemente, ofrece a los usuarios muchas de las características y beneficios de la nube pública con el control y la seguridad de un centro de datos interno.

Compararemos tres modelos comunes de nube híbrida de alto nivel para demostrar cómo este nuevo enfoque, cuando se combina con los servicios de aplicação avanzados de F5, simplifica drásticamente el desarrollo y la operación de la nube híbrida.

Modelo 1: Plataformas de nube y servicios de aplicação no homogéneos

Nuestro primer ejemplo es un entorno de nube híbrida que utiliza Azure con servicios de aplicação nativos de Azure para el aspecto de nube pública, mientras que aprovecha VMware con servicios de aplicação F5 para el componente de nube privada, como se muestra en la figura 1.

La clara falta de coherencia entre entornos hace que este sea el modelo más difícil de implementar y operar. En el caso de uso de HA/DR analizado anteriormente, cada aplicação debería configurarse individualmente para ejecutarse de manera idéntica en cada nube. Dadas las diferencias en las máquinas virtuales, las API y los recursos de red subyacentes, es poco probable que esta sea una tarea sencilla. Estas diferencias contribuyen a reducir la portabilidad general de la aplicação debido a la compleja infraestructura necesaria para ponerla en funcionamiento en cada nube, lo que efectivamente duplica el trabajo necesario para lograr resultados similares. Además, cada plataforma también tiene su propia interfaz de portal única y herramientas para desarrolladores y administradores, por lo que este modelo rápidamente se vuelve prohibitivamente complicado.

Y eso sólo considerando las diferencias en las plataformas. Cuando se suma el efecto de servicios de aplicação diferentes, con interfaces, herramientas de administración y requisitos de configuración distintos, la complejidad crece exponencialmente. Y la disfunción en la gestión no es el único problema; las inconsistencias en las características impiden que las aplicações se configuren con los mismos servicios en cada nube, lo que lo expone a un riesgo adicional. Por ejemplo, servicios de seguridad diferentes dan lugar a conjuntos de reglas y políticas de firewall independientes. Estos pueden crear vulnerabilidades de seguridad que resulten en tiempos de inactividad de la aplicação o pérdida de datos de los clientes como resultado de cualquier ciberataque resultante.

Modelo 2: Plataformas de nube no homogéneas con servicios de aplicação homogéneos

Esta configuración es similar a la del Modelo 1, pero con cada entorno de nube respaldado por los servicios de aplicação de F5, como se muestra en la figura 2.

Con servicios de aplicação consistentes, todos los servicios, configuraciones y políticas de F5 se pueden replicar en todos los entornos con una gestión desde un único panel, lo que reduce la presión sobre los administradores de sistemas. En lugar de aprender y equilibrar dos conjuntos separados de características, interfaces y terminología, se puede implementar un conjunto de servicios estandarizados y ricos en funciones en todo el entorno de nube híbrida. Y estos servicios son independientes de la nube (es decir, se ejecutan de manera idéntica en todas las nubes), lo que elimina los temores de dependencia del proveedor que pueden asociarse con el uso de servicios nativos de la nube. Sin embargo, este modelo no aborda los problemas asociados con la infraestructura de plataformas dispares, que deberán tenerse en cuenta.

Modelo 3: Plataformas de nube homogéneas y servicios de aplicação

Este modelo final ve una mejora incremental adicional; tomando la configuración descrita en el Modelo 2 y reemplazando la nube privada VMware con Microsoft Azure Stack, como se ilustra en la figura 3.