Patrones y prácticas de nube híbrida y múltiples nubes

Este artículo es el primero de una serie de varias partes que trata sobre las implementaciones de nube híbridas y múltiples nubes, los patrones de arquitectura y las topologías de red. En esta parte, se analizan las oportunidades y los desafíos de las implementaciones de nube híbridas y múltiples nubes, y se proporciona orientación sobre cómo abordar la implementación de una configuración híbrida que usa Google Cloud.

La serie consta de las siguientes partes:

La digitalización y la necesidad de adaptarse con rapidez a las demandas cambiantes del mercado provocaron un aumento de los requisitos y las expectativas que se aplican a la TI empresarial. A muchas empresas les resulta difícil manejar y adaptarse a estas tendencias con la infraestructura y los procesos existentes.

Al mismo tiempo, los departamentos de TI son objeto de análisis y se encuentran bajo presión para mejorar la rentabilidad, lo que dificulta la justificación de inversiones de capital adicionales (gasto de capital) a fin de ampliar y modernizar los centros de datos y equipos.

Una estrategia de nube híbrida proporciona una solución pragmática. Mediante el uso de la nube pública, puedes ampliar la capacidad y las habilidades del departamento de TI sin la necesidad de realizar inversiones iniciales de capital. Si agregas una o más implementaciones de nube a tu infraestructura existente, no solo conservarás tus inversiones existentes, sino que evitarás tener que comprometerte con un único proveedor de TI. Además, con una estrategia híbrida puedes modernizar las aplicaciones y los procesos de forma progresiva mientras los recursos lo permitan.

Nube híbrida y múltiples nubes

Debido a que las cargas de trabajo, la infraestructura y los procesos son exclusivos de cada empresa, cada estrategia híbrida debe adaptarse a necesidades específicas. El resultado es que los términos nube híbrida y múltiples nubes a veces se usan de forma inconsistente.

En el contexto de Google Cloud, el término nube híbrida describe una configuración en la que las cargas de trabajo comunes o interconectadas se implementan en varios entornos de computación, uno basado en la nube pública y al menos uno privado.

El ejemplo más común es combinar un entorno de computación privado (por lo general, un centro de datos existente local) y un entorno de computación en la nube pública, como se muestra en el siguiente diagrama.

combinar un entorno de computación privado y uno en la nube pública

El término múltiples nubes describe las opciones de configuración que combinan al menos dos proveedores de servicios en la nube pública, como se muestra en el siguiente diagrama.

topología de múltiples nubes que combina al menos dos proveedores de servicios en la nube pública

Una configuración de múltiples nubes podría incluir entornos de computación privados.

topología de múltiples nubes que combina al menos dos proveedores de servicios en la nube pública y entornos privados

Impulsores para la configuración de nube híbrida y múltiples nubes

Las opciones de configuración de nube híbrida y múltiples nubes pueden ser temporales; se mantienen solo durante un período limitado para facilitar la migración. Sin embargo, estas pueden representar el estado futuro de la mayoría de las organizaciones, ya que crean sistemas nuevos y actualizan los existentes para aprovecharlos al máximo, sin importar dónde se ejecuten. Estas opciones de configuración pueden ser elementos permanentes en el panorama de TI.

Una configuración de nube híbrida o múltiples nubes rara vez es un objetivo en sí misma, sino más bien un medio para cumplir con requisitos empresariales. Por lo tanto, para seleccionar la configuración correcta es necesario conocer estos requisitos.

Impulsores y limitaciones empresariales

A continuación, se detallan los impulsores y las limitaciones empresariales comunes:

  • Reducción del gasto de capital o gastos de TI generales
  • Mayor flexibilidad y agilidad para responder mejor a las demandas del mercado cambiante
  • Desarrollo de capacidades, como los servicios de estadísticas avanzadas, que podrían ser difíciles de implementar en los entornos existentes
  • Mejora de la calidad y disponibilidad del servicio
  • Mejora de la transparencia de costos y consumo de recursos
  • Acatamiento de leyes y reglamentos sobre la soberanía de los datos
  • Elusión o reducción del compromiso con un solo proveedor

Impulsores de diseño y desarrollo

A continuación, se detallan los impulsores de diseño y desarrollo comunes:

  • Automatización y aceleración de lanzamientos de aplicaciones para lograr un tiempo de salida al mercado más rápido y ciclos más cortos
  • Aprovechamiento de API y servicios de alto nivel para acelerar el desarrollo
  • Aceleración del aprovisionamiento de recursos de computación y almacenamiento

Requisitos y limitaciones de las operaciones

A continuación, se detallan los requisitos y las limitaciones de las operaciones:

  • Garantía de autenticación, autorización, auditoría y políticas coherentes en todos los entornos de computación
  • Uso de herramientas y procesos coherentes para limitar la complejidad
  • Visibilidad en los entornos

Limitaciones de arquitectura

A continuación, se detallan las mayores limitaciones de la arquitectura que, por lo general, derivan de los sistemas existentes:

  • Dependencias entre las aplicaciones
  • Requisitos de rendimiento y latencia para la comunicación entre los sistemas
  • Fiabilidad en el hardware o los sistemas operativos que podrían no estar disponibles en la nube pública
  • Restricciones de licencias

Objetivos generales

El objetivo de una estrategia de nube híbrida y múltiples nubes es cumplir con estos requisitos con un plan que describa las siguientes especificaciones:

  • Cuáles son las cargas de trabajo que deben ejecutarse en cada entorno de computación, o migrarse a ellos.
  • Cuáles son los patrones que deben aplicarse en varias cargas de trabajo.
  • Qué tecnología y topología de red usar.

En esencia, cualquier estrategia de nube híbrida y múltiples nubes deriva de los requisitos empresariales. Sin embargo, rara vez es claro cómo se obtiene una estrategia viable a partir de las necesidades empresariales. Las cargas de trabajo, los patrones de arquitectura y las tecnologías que seleccionas no solo dependen de los requisitos empresariales, sino también influyen unos en otros de forma cíclica. En el siguiente diagrama, se ilustra este ciclo.

Cómo las cargas de trabajo, los patrones y las tecnologías afectan a los requisitos empresariales y dependen de ellos

Define una visión

Dentro de esta red de dependencias y limitaciones, definir un plan que tenga en cuenta todas las cargas de trabajo y los requisitos es difícil en el mejor de los casos, especialmente en un entorno de TI complejo. Además, la planificación lleva tiempo y puede generar conflicto entre las partes interesadas.

Para evitar esta situación, primero define una visión que se centre en la perspectiva del negocio y aborde las siguientes preguntas:

  • ¿Por qué el enfoque y el entorno de computación actuales no son suficientes?
  • ¿Cuáles son las métricas principales que deseas optimizar mediante el uso de la nube pública?
  • ¿Por cuánto tiempo planeas usar una configuración de nube híbrida o múltiples nubes? ¿Consideras que esta configuración será permanente o provisoria durante toda la migración a la nube?

La visión no abarca cómo lograr estos objetivos.

Definir una visión y obtener la aprobación de las partes interesadas proporciona una base para los siguientes pasos en el proceso de planificación.

Define una estrategia de nube híbrida y múltiples nubes

Una vez establecida la visión, puedes desarrollar la estrategia:

  1. Realiza una evaluación de carga de trabajo inicial. Teniendo en cuenta los objetivos determinados en la visión, identifica una lista de posibles cargas de trabajo planificadas y existentes que podrían beneficiarse de la implementación o la migración a la nube pública. Este tema se analizará en detalle en la siguiente sección.

  2. Comienza por las posibles cargas de trabajo identificadas, reconoce los patrones aplicables y, en función de ellos, las posibles topologías.

    Si identificas más de un patrón y una topología aplicables, define mejor la selección de la carga de trabajo para establecer un único patrón y topología. Necesitarás la iteración para definir mejor las selecciones.

    La aplicación de varios patrones y topologías es un enfoque viable para grandes organizaciones. Sin embargo, este enfoque no siempre es el ideal debido a la complejidad adicional, lo que, a su vez, podría volver más lento el progreso.

  3. Establece una prioridad de cargas de trabajo. En función de la cantidad de requisitos, es mejor adoptar un enfoque de iteración.

  4. Selecciona la carga de trabajo inicial en la nube pública. Asegúrate de que esta carga de trabajo no sea crítica para la empresa o demasiado difícil de migrar, pero que sea lo suficientemente habitual a fin de servir de modelo en las próximas implementaciones o migraciones.

    Cuando selecciones una carga de trabajo para migrar, comienza a preparar Google Cloud.

  5. Configura la organización, los proyectos y las políticas de Google Cloud que necesitas a fin de preparar el entorno de nube para las primeras implementaciones.

  6. Implementa la topología de red y establece la conectividad necesaria entre Google Cloud y los entornos de computación privados.

Cargas de trabajo

La decisión sobre qué cargas de trabajo se ejecutarán y en qué entornos de computación tiene un gran impacto en la eficacia de una estrategia de nube híbrida y múltiples nubes. Poner la carga de trabajo incorrecta en la nube puede complicar la implementación y proporcionar pocos beneficios. Poner la carga de trabajo adecuada en el lugar correcto no solo ayudará a la carga de trabajo, sino también te ayudará a conocer los beneficios de cada entorno.

Estrategia centrada en la nube

Una forma común de empezar a usar la nube pública es la estrategia centrada en la nube. En este enfoque, implementas las cargas de trabajo nuevas en la nube pública. En ese caso, considera una implementación clásica para un entorno de computación privado, solo si no se puede implementar en la nube por razones técnicas o de la organización.

Esta estrategia tiene ventajas y desventajas. Uno de los aspectos positivos es que la estrategia es prospectiva. Puedes implementar cargas de trabajo nuevas de forma limpia y nativa en la nube, y evitar (o al menos minimizar) las complicaciones de la migración de las cargas de trabajo existentes.

Uno de los aspectos negativos es que esta estrategia centrada en la nube puede hacer que pierdas oportunidades para tus cargas de trabajo existentes. Las cargas de trabajo nuevas pueden constituir solo una parte de la carga de trabajo general de TI, y el impacto en el gasto y rendimiento general de TI puede ser limitado. El tiempo que pasas migrando una carga de trabajo existente puede producir mayores ventajas o ahorros que intentar alojar una nueva carga de trabajo en la nube.

Seguir una estrategia estricta centrada en la nube también puede aumentar la complejidad general de tu entorno de TI. Este enfoque puede crear redundancias, disminuir el rendimiento debido a la comunicación excesiva en el entorno o generar un entorno de computación que no es adecuado para la carga de trabajo individual.

En función de estos riesgos, podría ser mejor usar un enfoque centrado en la nube solo para cargas de trabajo seleccionadas. De esa forma, podrás concentrarte en las cargas de trabajo que más se beneficien de la implementación o migración a la nube. Este enfoque también considera la modernización de las cargas de trabajo existentes, que se analizan en la siguiente sección.

Migración y modernización

La modernización de la nube híbrida, múltiples nubes y TI son conceptos diferentes que se vinculan en un círculo virtuoso. El uso de la nube pública puede facilitar y simplificar la modernización de las cargas de trabajo de TI; modernizar tu entorno de TI te ayudará a aprovechar al máximo la nube.

A continuación, se detallan los objetivos principales de la modernización de las cargas de trabajo:

  • Lograr mayor agilidad para adaptarse a los cambios en los requerimientos.
  • Reducir los costos de infraestructura y operaciones.
  • Aumentar la confiabilidad y resiliencia para minimizar el riesgo empresarial.

Como se describe en la sección Migración a Google Cloud, puedes implementar uno de los siguientes tipos de migración, o incluso combinar varios tipos según sea necesario:

  • Lift-and-shift
  • Mejorar y mover
  • Extraer y reemplazar

Lift-and-shift

Lift-and-shift describe el proceso de migración de una carga de trabajo desde un entorno de computación privado hasta la nube pública sin cambiar la carga de trabajo de forma significativa. Con frecuencia, este proceso implica la migración de máquinas virtuales (VM) existentes y sus imágenes a Compute Engine.

Ejecutar VM en Compute Engine, y no en un entorno de computación privado, tiene los siguientes beneficios:

  • Puedes aprovisionar recursos de computación y de almacenamiento con rapidez y evitar demoras causadas por la adquisición y la instalación de equipos en centros de datos clásicos (privados o locales).

  • Solo pagas por los recursos de computación que usas, sin compromiso anticipado o inversión.

  • Puedes automatizar tareas operativas y reducir el esfuerzo y los costos.

Además, si vuelves a escribir las aplicaciones para que sean más nativas de la nube, podrás aprovechar importantes beneficios adicionales:

  • Mediante el uso del ajuste de escala automático, puedes asegurarte de que los recursos de computación se aprovisionen solo cuando sean necesarios, y evitar así cualquier costo de aprovisionamiento excesivo.

  • Puedes aprovechar los administradores de clústeres, como Kubernetes, para aumentar la resiliencia de tus aplicaciones reiniciándolas de forma automática o migrándolas a diferentes máquinas en caso de fallas.

  • Puedes reducir aún más la sobrecarga operativa con los servicios administrados.

  • Puedes automatizar la implementación, lo que ayuda a acelerar los procesos de desarrollo y lanzamiento de productos. Esto permite que tu negocio reaccione de una forma más rápida a los comentarios, los cambios en los requerimientos y las demandas del mercado.

modernizar una carga de trabajo mediante el traslado y la mejora de una aplicación para que sea nativa de la nube

Como se muestra en este diagrama, cuando modernizas una carga de trabajo existente, considera cambiar la aplicación a la nube y mejorarla para que sea nativa de la nube.

Mejorar y mover

Aunque es común trasladar una aplicación a la nube antes de invertir en la mejora, el enfoque inverso podría ser mejor para algunas aplicaciones. La idea de mejorar y mover es comenzar una migración mediante la reestructuración y modernización de una aplicación existente. Incluso antes de mover la aplicación a la nube, esta mejora tiene una serie de beneficios:

  • Puedes mejorar el proceso de implementación.

  • La inversión en la infraestructura y herramientas de integración continua/implementación continua (IC/EC) puede acelerar la cadencia de actualización y acortar los ciclos de respuesta.

Después de la mejora, mueve la aplicación a la nube, lo que te ayudará a aprovisionar los recursos con rapidez y aumentar la rentabilidad mediante el ajuste de escala automático y, por lo tanto, evitar el aprovisionamiento excesivo.

Para que mejorar y mover funcione de forma correcta, considera realizar algunas inversiones de infraestructura y herramientas locales, como configurar un registro de Docker local y aprovisionar clústeres de Kubernetes a fin de crear contenedores para aplicaciones.

Extraer y reemplazar

Extraer y reemplazar implica quitar un sistema y reemplazarlo. En algunos casos, tratar de actualizar un sistema y una base de código existentes podría no ser rentable ni posible. Los requisitos podrían haber cambiado de manera sustancial o las aplicaciones existentes podrían basarse en una pila de software o hardware que no es apta para inversiones futuras. En esos casos, un mejor enfoque podría ser reemplazar el sistema, lo que podría significar la compra de una solución nueva o el desarrollo de una aplicación moderna y nativa de la nube desde cero.

Combina y adapta enfoques de migración

Cada uno de los tres enfoques de migración tiene algunas fortalezas y debilidades. Una ventaja principal de la estrategia de nube híbrida y múltiples nubes implica que no es necesario establecer un solo enfoque. En cambio, puedes decidir qué enfoque funciona mejor para cada carga de trabajo.

Selecciona lift-and-shift si las cargas de trabajo cumplen con las siguientes condiciones:

  • Tienen una cantidad relativamente pequeña de dependencias en sus entornos.
  • No vale la pena reestructurarlas.
  • Se basan en software de terceros.

Considera mejorar y mover para cargas de trabajo que cumplan con las siguientes condiciones:

  • Tienen dependencias que deben ser desvinculadas.
  • Se basan en sistemas operativos, hardware o sistemas de bases de datos que no se pueden alojar en la nube.
  • No usan de manera eficiente los recursos de computación o de almacenamiento.
  • No se pueden implementar fácilmente de manera automatizada.

Finalmente, extraer y reemplazar podría ser la mejor estrategia para los tipos de cargas de trabajo que cumplen con estas condiciones:

  • Ya no cumplen con los requisitos actuales.
  • Se basan en tecnología de terceros ya obsoleta.
  • Requieren tarifas de licencia de terceros que ya no son económicas.

Portabilidad

En la mayoría de las migraciones, el esfuerzo de cambiar una carga de trabajo a la nube es irreversible y único. Pero en el caso de una nube híbrida y, en especial, para situaciones de múltiples nubes, es posible que quieras cambiar las cargas de trabajo entre las nubes más adelante. Para facilitar esta capacidad, asegúrate de que las cargas de trabajo sean portátiles:

  • Asegúrate de que puedes cambiar una carga de trabajo de un entorno de computación a otro sin modificaciones significativas.
  • Asegúrate de que la implementación y la administración de la aplicación sean coherentes en todos los entornos de computación.
  • Asegúrate de que mantener la carga de trabajo portátil no genere un conflicto con la carga de trabajo nativa de la nube.

En cuanto a la infraestructura, puedes usar herramientas como Terraform para automatizar y unificar la creación de recursos de infraestructura, como VM y balanceadores de carga en entornos heterogéneos. Además, puedes usar herramientas de administración de configuración, como Ansible, Puppet o Chef para establecer un proceso común de implementación y configuración. Otra alternativa es usar una herramienta de creación de imágenes como Packer a fin de crear imágenes de VM para diferentes plataformas con un solo archivo de configuración compartido. Por último, puedes usar soluciones como Prometheus y Grafana para garantizar la supervisión coherente en los entornos.

En función de estas herramientas, puedes combinar una cadena de herramientas similar a la que se muestra en el siguiente diagrama. Esta cadena de herramientas abstrae las diferencias entre los entornos de computación y te permite unificar el aprovisionamiento, la implementación, la administración y la supervisión.

cadena de herramientas que abstrae las diferencias entre los entornos de computación y te permite unificar el aprovisionamiento, la implementación, la administración y la supervisión

Aunque una cadena de herramientas común puede ayudarte a lograr la portabilidad, esta presenta varias deficiencias:

  • No podrás usar determinadas funciones que un entorno de nube ofrece de forma nativa. En particular, el uso de VM como base común dificulta la implementación de las aplicaciones nativas de la nube. A veces, esto impide usar servicios administrados, por lo que puedes perder oportunidades para reducir la sobrecarga administrativa.

  • El desarrollo y mantenimiento de una cadena de herramientas generan gastos de sobrecarga y operativos.

  • Con el tiempo, la cadena de herramientas puede llegar a ser compleja en formas que son exclusivas de la empresa. Esta complejidad puede provocar un aumento de los gastos de entrenamiento.

Contenedores y Kubernetes

Desarrollar y mantener una cadena de herramientas personalizada para lograr la portabilidad de la carga de trabajo mediante la VM implica muchos desafíos. Una solución es aprovechar los contenedores y Kubernetes.

Los contenedores ayudan a que el software se ejecute de manera confiable cuando lo mueves de un entorno a otro. Kubernetes se encarga de la organización, implementación, escalamiento y administración de tus aplicaciones en contenedores, lo que proporciona los servicios que forman la base de una aplicación nativa de la nube. Debido a que puedes instalar y ejecutar Kubernetes en una variedad de entornos de computación, también puedes usarlo para establecer una capa de entorno de ejecución común en los entornos de computación:

  • Kubernetes proporciona los mismos servicios y las API en una nube o en un entorno de computación privado. Además, el nivel de abstracción es mucho mayor que cuando se trabaja con VM, lo que se suele traducir en un menor trabajo de base y una mayor productividad de los desarrolladores.

  • A diferencia de una cadena de herramientas personalizadas, el uso de Kubernetes es muy popular para el desarrollo y la administración de aplicaciones, por lo que puedes aprovechar la experiencia, la documentación y la asistencia de terceros existentes.

  • Kubernetes usa contenedores de Docker, un estándar adoptado por la industria para empaquetar aplicaciones que no están vinculadas a ningún proveedor específico. Kubernetes es de código abierto y se rige por Cloud Native Computing Foundation.

Puedes evitar el esfuerzo de instalar y usar Kubernetes mediante el uso de una plataforma administrada, como Google Kubernetes Engine (GKE), para que el personal de operaciones pueda cambiar el enfoque de la infraestructura a las aplicaciones. En el siguiente diagrama, se muestra cómo podría ser una plataforma de Kubernetes administrada.

Plataforma de Kubernetes administrada

Límites de portabilidad de la carga de trabajo

Para ayudar a que tus cargas de trabajo sean más portátiles, Kubernetes proporciona una capa de abstracción que oculta muchas complejidades y diferencias entre los entornos de computación. Sin embargo, esa abstracción tiene algunas limitaciones:

  • Una aplicación puede ser portátil para un entorno diferente con cambios mínimos, pero eso no implica que se desempeñará de la misma manera en ambos entornos. Las diferencias en la infraestructura de computación o de red subyacente, junto con la proximidad a servicios dependientes, pueden dar lugar a un rendimiento sustancialmente diferente.

  • Mover una carga de trabajo entre los entornos de computación también puede requerir mover datos. Además del tiempo, esfuerzo y presupuesto necesarios para copiar o mover los datos entre los entornos de computación, estos difieren en los servicios y las instalaciones que proveen para almacenar y administrar esos datos.

  • Kubernetes ofrece una manera unificada para aprovisionar diferentes tipos de balanceadores de cargas. El comportamiento de estos balanceadores de cargas no se define en detalle, pero pueden existir algunas diferencias sutiles entre los entornos.

  • GKE integra un control de acceso según la función (RBAC) con Cloud Identity and Access Management, pero las formas de configurar el RBAC y asegurar las cargas de trabajo pueden ser diferentes en otros entornos.

Incluso con Kubernetes, puede ser difícil abstraer las diferencias entre los entornos de computación o las nubes públicas. El objetivo principal de la portabilidad de la carga de trabajo es simplificar las migraciones entre entornos, no automatizarlas.

Evaluación de la carga de trabajo

Cuando tienes proyectos nuevos en curso y cientos, o incluso miles, de cargas de trabajo que ya se ejecutan, puede ser abrumador decidir qué cargas de trabajo implementar o migrar, y en qué entorno de computación.

Para tomar esas decisiones de forma coherente y objetiva, clasifica y califica las cargas de trabajo por oportunidad, riesgo y dificultad técnica.

Los siguientes factores pueden ayudarte a evaluar las oportunidades de migración:

  • Diferenciación del mercado o innovación posible que permite el uso de servicios en la nube
  • Ahorros posibles en el costo total de propiedad de una aplicación
  • Inversiones posibles en disponibilidad, resiliencia, seguridad o rendimiento
  • Aceleración posible de los procesos de desarrollo y actualización

Los siguientes factores pueden ayudarte a evaluar los riesgos de migración:

  • Impacto posible de las interrupciones causadas por una migración o por la experiencia inicial limitada con implementaciones en la nube pública
  • Necesidad de cumplir con las restricciones legales o reglamentarias existentes

Estos factores pueden ayudarte a evaluar las dificultades técnicas de una migración:

  • Tamaño, complejidad y antigüedad de la aplicación
  • Cantidad de dependencias con otras aplicaciones
  • Cualquier limitación impuesta por licencias de terceros
  • Dependencias de versiones específicas de sistemas operativos, bases de datos o configuraciones de entorno

Después de evaluar las cargas de trabajo iniciales, puedes organizarlas por prioridad y reconocer patrones de arquitectura y topologías de red aplicables. Este paso puede requerir varias iteraciones. Debido a que esta evaluación puede cambiar con el tiempo, también vale la pena volver a evaluar las cargas de trabajo después de realizar las primeras implementaciones en la nube.

Próximos pasos