Un equipo de TI debe sopesar dos preguntas importantes antes de implementar una estrategia de nube híbrida. ¿Cómo debería reorganizar los activos locales y cómo debería crear una arquitectura de aplicación y un modelo de implementación?
Los equipos de TI no pueden tener una nube híbrida exitosa sin abordar estas dos preguntas, y deberán hacerlo en una estrategia coordinada que involucra varias decisiones importantes. Analicemos algunas de esas opciones para ayudar a su equipo a planificar su entorno de nube híbrida.
Establezca su API DMZ
Una buena estrategia de nube híbrida asume que la nube pública proporciona soporte de aplicaciones de front-end, incluido el soporte de información diseñado para estimular o mejorar una aplicación transaccional. Es más probable que la aplicación transaccional se ejecute en el centro de datos, lo que significa que el centro de datos tiene que exponer API a las que un front-end en la nube puede conectarse razonablemente.
El primer paso es definir, asegurar y exponer las API adecuadas para vincular la nube y el centro de datos. Piense en este límite de nube híbrida como una zona desmilitarizada (DMZ), un lugar que tiene sus propias reglas, pero que también debe ser compatible con ambos mundos y, en algunos casos, ser parte de cada uno. Estas API son el límite en el medio de la DMZ.
Las API también representan una especie de transferencia funcional entre la nube y el centro de datos. Los recursos implementados y diseñados en la nube están en un lado de las API; en el otro lado de la DMZ, las aplicaciones comerciales centrales que la política, los costos y otros factores permanecen en las instalaciones. Esto expone características que la nube puede utilizar sin requerir ningún cambio en sus aplicaciones principales. De esta forma, el desarrollo en la nube y el centro de datos permanecen divididos.
También puede decidir dónde trazar exactamente esa línea. Las API abstractas de nivel superior limitan los cambios que se pueden realizar en la nube. Alternativamente, puede exponer API de nivel inferior, tal vez hasta el acceso a la base de datos y las capas de actualización. Esto exporta una gran cantidad de trabajo de personalización a la nube, pero también crea riesgos de seguridad y cumplimiento que deberán mitigarse.
Desbloquee la escalabilidad con contenedores de nube híbrida
Una vez que haya establecido su API DMZ, debe asegurarse de que su centro de datos pueda adaptarse a la escalabilidad y resistencia de la nube.
Las nubes públicas pueden agregar instancias rápidamente a medida que aumenta la carga y reemplazar componentes defectuosos, pero no tiene sentido construir una superautopista de 10 carriles si desemboca en un camino de tierra de dos carriles, es decir, su centro de datos mal preparado. Por lo tanto, a medida que incorpore una mayor escalabilidad con su componente de nube pública, deberá tener en cuenta la escalabilidad en los componentes que están expuestos a través de sus API DMZ.
En este punto, deberá definir un grupo de recursos y crear componentes que puedan adaptarse a sus demandas de escalado, como equilibradores de carga y una forma de control estatal. También necesita un programador para operar en el grupo de recursos que ha creado. Puede abordar todos estos requisitos con un concepto central único: el alojamiento de contenedores.
Los contenedores proporcionan una estrategia eficaz para la virtualización, ya que puede alojar más de ellos en un servidor que con las máquinas virtuales. Los contenedores son fáciles de implementar en el centro de datos, incluso para aplicaciones heredadas, y son adecuados para todas las formas de modelos de aplicaciones escalables y con estado. En la nube, puede implementar su propio sistema de contenedores en instancias informáticas o puede utilizar un sistema de contenedores administrado por un proveedor de la nube. Lo mejor de todo es que existen muchas formas de armonizar sus entornos de nube y centro de datos a través de contenedores.
Kubernetes es la herramienta de planificación y orquestación de contenedores de referencia, y es igualmente adecuada para centros de datos privados o nubes públicas. Hay una serie de fuentes de Kubernetes, como Anthos de Google, Kabanero de IBM, Topaz de VMware y OpenShift de Red Hat, que pueden admitir la orquestación y programación híbridas, incluso a través de la API DMZ discutida anteriormente.
Prepare su orquestación entre entornos
La siguiente consideración importante es la orquestación y programación transfronterizas. Debe decidir si sus componentes DMZ escalables estarán vinculados a la nube o si puede programar componentes a través de ese límite. Si elige lo último, el centro de datos y la nube pueden respaldarse mutuamente o proporcionar recursos adicionales según sea necesario.
El uso de Kubernetes tanto para la nube como para el centro de datos permite la opción más robusta y flexible para la explosión de la nube y para usar los recursos de la nube y del centro de datos como respaldo en caso de que algo falle. Si el centro de datos y la escalabilidad transfronteriza son importantes para usted, querrá organizar y particionar sus servidores para optimizarlos.
Los servidores que alojan sus contenedores como parte de este grupo de recursos escalables deben ubicarse más cerca de las conexiones a Internet de los usuarios para una latencia mínima y un rendimiento óptimo. Sus configuraciones deben estandarizarse tanto como sea posible, y los componentes de la aplicación en sí mismos no deben usar recursos que no estarán ampliamente disponibles en sus entornos públicos o privados. Esto mejorará la eficiencia general de su grupo de recursos.
Cuanto más extienda su DMZ en el centro de datos, más importante será adoptar una estrategia de contenedor para implementar y programar componentes. Incluso las aplicaciones que no necesitan escalar se beneficiarán de este enfoque porque armonizará las prácticas operativas y reducirá los costos operativos. También preparará a su organización para un compromiso más profundo con la nube pública, a medida que evoluciona su experiencia en la nube híbrida.
