El patrón de arquitectura de múltiples nubes con particiones combina varios entornos de nube pública que operan diferentes proveedores de servicios en la nube. Esta arquitectura proporciona la flexibilidad para implementar una aplicación en un entorno de procesamiento óptimo que tenga en cuenta los impulsores y las consideraciones de multinube que se analizaron en la primera parte de esta serie.
En el siguiente diagrama, se muestra un patrón de arquitectura de múltiples nubes con partición.
Este patrón de arquitectura se puede compilar de dos maneras diferentes. El primer enfoque se basa en implementar los componentes de la aplicación en diferentes entornos de nube pública. Este enfoque también se conoce como arquitectura compuesta y es el mismo enfoque que el patrón de arquitectura híbrida por niveles. Sin embargo, en lugar de usar un entorno local con una nube pública, usa al menos dos entornos de nube. En una arquitectura compuesta, una sola carga de trabajo o aplicación usa componentes de más de una nube. El segundo enfoque implementa diferentes aplicaciones en diferentes entornos de nube pública. En la siguiente lista no exhaustiva, se describen algunos de los impulsores empresariales del segundo enfoque:
- Para integrar por completo las aplicaciones alojadas en entornos de nube dispares durante una fusión y adquisición entre dos empresas.
- Para promover la flexibilidad y satisfacer las diversas preferencias de nube dentro de tu organización. Adopta este enfoque para alentar a las unidades organizativas a elegir el proveedor de servicios en la nube que mejor se adapte a sus necesidades y preferencias específicas.
- Para operar en una implementación de nube multirregional o global. Si una empresa debe cumplir con las reglamentaciones de residencia de datos en regiones o países específicos, entonces debe elegir entre los proveedores de servicios en la nube disponibles en esa ubicación si su proveedor de servicios en la nube principal no tiene una región de nube allí.
Con el patrón de arquitectura de múltiples nubes particionadas, puedes mantener la capacidad de cambiar las cargas de trabajo de un entorno de nube pública a otro según sea necesario. En ese caso, la portabilidad de tus cargas de trabajo se convierte en un requisito clave. Cuando implementas cargas de trabajo en múltiples entornos de computación y deseas mantener la capacidad de mover las cargas de trabajo entre entornos, debes abstraer las diferencias entre los entornos. Con GKE Enterprise, puedes diseñar y compilar una solución para resolver la complejidad de varias nubes con posturas de administración, operaciones y seguridad coherentes. Para obtener más información, consulta GKE multinube.
Como se mencionó anteriormente, hay algunas situaciones en las que puede haber motivos técnicos y comerciales para combinar Google Cloud con otro proveedor de servicios en la nube y particionar las cargas de trabajo en esos entornos de nube. Las soluciones de múltiples nubes te ofrecen la flexibilidad para migrar, compilar y optimizar la portabilidad de las aplicaciones en entornos de múltiples nubes, a la vez que minimizas la dependencia de un solo proveedor y te ayudan a cumplir con los requisitos reglamentarios. Por ejemplo, puedes conectar Google Cloud con Oracle Cloud Infrastructure (OCI) para crear una solución de múltiples nubes que aproveche las capacidades de cada plataforma con un Cloud Interconnect privado para combinar componentes que se ejecutan en OCI con recursos que se ejecutan en Google Cloud. Para obtener más información, consulta Google Cloud y Oracle Cloud Infrastructure: Aprovecha al máximo las múltiples nubes. Además, Cross-Cloud Interconnect facilita la conectividad dedicada de ancho de banda alto entre Google Cloud y otros proveedores de servicios en la nube compatibles, lo que te permite diseñar y crear soluciones multinube para controlar un gran volumen de tráfico entre nubes.
Ventajas
Si bien el uso de una arquitectura multinube ofrece varios beneficios técnicos y comerciales, como se explica en Factores de impulso, consideraciones, estrategia y enfoques, es fundamental realizar una evaluación de viabilidad detallada de cada beneficio potencial. Tu evaluación debe considerar cuidadosamente cualquier desafío directo o indirecto asociado, o posibles obstáculos, y tu capacidad para navegar por ellos de manera eficaz. Además, ten en cuenta que el crecimiento a largo plazo de tus aplicaciones o servicios puede generar complejidades que podrían superar los beneficios iniciales.
A continuación, se incluyen algunas ventajas clave del patrón de arquitectura de múltiples nubes con partición:
En situaciones en las que debas minimizar el compromiso con un solo proveedor de servicios en la nube, puedes distribuir las aplicaciones en varios proveedores de servicios en la nube. Como resultado, podrías reducir de forma relativa la dependencia del proveedor con la posibilidad de cambiar de plan (hasta cierto punto) entre tus proveedores de servicios en la nube. La nube abierta ayuda a llevar las capacidades de Google Cloud , como GKE Enterprise, a diferentes ubicaciones físicas. Cuando se extienden las capacidades de Google Cloud en las instalaciones, en varias nubes públicas y en el perímetro, se proporciona flexibilidad, agilidad y se impulsa la transformación.
Por motivos regulatorios, puedes publicar un segmento determinado de tu base de usuarios y datos de un país en el que Google Cloud no tiene una región de la nube.
El patrón de arquitectura de multinube particionada puede ayudar a reducir la latencia y mejorar la calidad general de la experiencia del usuario en ubicaciones donde el proveedor de servicios en la nube principal no tiene una región ni un punto de presencia. Este patrón es especialmente útil cuando se usa conectividad multinube de alta capacidad y baja latencia, como interconexión entre nubes y interconexión de CDN con una CDN distribuida.
Puedes implementar aplicaciones en múltiples proveedores de servicios en la nube de tal manera que puedes elegir entre los mejores servicios que estos ofrecen.
El patrón de arquitectura de multinube particionada puede ayudar a facilitar y acelerar las situaciones de fusión y adquisición, en las que las aplicaciones y los servicios de las dos empresas pueden alojarse en diferentes entornos de nube pública.
Prácticas recomendadas
- Comienza por implementar una carga de trabajo que no sea fundamental. Esta implementación inicial en la nube secundaria puede servir como patrón para futuras implementaciones o migraciones. Sin embargo, es probable que este enfoque no se aplique en situaciones en las que la carga de trabajo específica esté legalmente o regulatoriamente obligada a residir en una región de nube específica y el proveedor de nube principal no tenga una región en el territorio requerido.
- Minimiza las dependencias entre sistemas que se ejecutan en diferentes entornos de nube pública, en especial, cuando la comunicación se maneja de forma síncrona. Estas dependencias pueden disminuir el rendimiento, reducir la disponibilidad general y, posiblemente, generar cargos adicionales por la transferencia de datos salientes.
- Para abstraer las diferencias entre entornos, considera usar contenedores y Kubernetes cuando las aplicaciones lo admitan y sea factible.
- Asegúrate de que las canalizaciones de CI/CD y las herramientas para la implementación y la supervisión sean coherentes en los diferentes entornos de nube.
- Selecciona el patrón de arquitectura de red óptimo que proporcione la solución de comunicación más eficiente y eficaz para las aplicaciones que usas.
- La comunicación debe ser detallada y controlada. Usa APIs seguras para exponer componentes de la aplicación.
- Considera usar el patrón de arquitectura en malla o uno de los patrones de redes con puertas de enlace, según tus requisitos técnicos y comerciales específicos.
- Para cumplir con tus expectativas de disponibilidad y rendimiento, diseña para una alta disponibilidad (HA) de extremo a extremo, baja latencia y niveles de capacidad de procesamiento adecuados.
Para proteger la información sensible, te recomendamos que encriptes todas las comunicaciones en tránsito.
- Si se requiere encriptación en la capa de conectividad, hay varias opciones disponibles según la solución de conectividad híbrida seleccionada. Estas opciones incluyen túneles VPN, VPN con alta disponibilidad en Cloud Interconnect y MACsec para la interconexión entre nubes.
Si usas varias CDN como parte de tu patrón de arquitectura particionada de varias nubes y propagas tu otra CDN con archivos grandes de datos de Google Cloud, considera usar los vínculos de CDN Interconnect entre Google Cloud y los proveedores admitidos para optimizar este tráfico y, potencialmente, su costo.
Extiende tu solución de administración de identidades entre los entornos para que los sistemas puedan autenticarse de manera segura a través de los límites del entorno.
Para equilibrar de manera eficaz las solicitudes entre Google Cloud y otra plataforma en la nube, puedes usar Cloud Load Balancing. Para obtener más información, consulta Cómo enrutar el tráfico a una ubicación local o a otra nube.
- Si el volumen de transferencia de datos salientes de Google Cloud a otros entornos es alto, considera usar Cross Cloud Interconnect.
Para superar las incoherencias en los protocolos, las APIs y los mecanismos de autenticación en diversos backends, recomendamos, cuando corresponda, implementar una puerta de enlace de API o un proxy como una fachada. Esta puerta de enlace o proxy actúa como un punto de control centralizado y realiza las siguientes medidas:
- Implementa medidas de seguridad adicionales.
- Protege a las apps cliente y a otros servicios de los cambios en el código de backend.
- Facilita los registros de auditoría para la comunicación entre todas las aplicaciones multientorno y sus componentes desacoplados.
- Actúa como una
capa de comunicación intermedia
entre los servicios heredados y los modernizados.
- Apigee y Apigee Hybrid te permiten alojar y administrar puertas de enlace híbridas y de nivel empresarial en entornos locales, perimetral, otras nubes y entornos deGoogle Cloud .
En algunos de los siguientes casos, usar Cloud Load Balancing con una puerta de enlace de API puede proporcionar una solución sólida y segura para administrar, proteger y distribuir el tráfico de API a gran escala en varias regiones:
- Implementa la conmutación por error multirregional para los tiempos de ejecución de la API de Apigee en diferentes regiones.
Aumenta el rendimiento con Cloud CDN.
Proporcionar protección contra DSD y WAF a través de Google Cloud Armor
Usa herramientas coherentes para el registro y la supervisión en todos los entornos de nube cuando sea posible. Considera usar sistemas de supervisión de código abierto. Para obtener más información, consulta Patrones de registro y supervisión híbridos y de múltiples nubes.
Si implementas componentes de aplicación de forma distribuida, en la que los componentes de una sola aplicación se implementan en más de un entorno de nube, consulta las prácticas recomendadas para el patrón de arquitectura híbrido por niveles.