El patrón de arquitectura multinube particionada combina varios entornos de nube pública operados por diferentes proveedores de servicios en la nube. Esta arquitectura ofrece la flexibilidad necesaria para desplegar una aplicación en un entorno de computación óptimo que tenga en cuenta los factores y las consideraciones multicloud que se han tratado en la primera parte de esta serie.
En el siguiente diagrama se muestra un patrón de arquitectura multicloud particionada.
Este patrón de arquitectura se puede crear de dos formas diferentes. El primer enfoque se basa en desplegar 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 que el del patrón de arquitectura híbrida por niveles. Sin embargo, en lugar de usar un entorno local con una nube pública, utiliza 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 consiste en implementar diferentes aplicaciones en distintos entornos de nube pública. En la siguiente lista no exhaustiva se describen algunos de los factores empresariales que impulsan el segundo enfoque:
- Para integrar completamente las aplicaciones alojadas en entornos de nube dispares durante una fusión o adquisición entre dos empresas.
- Para fomentar la flexibilidad y adaptarse a las diversas preferencias de la nube de tu organización. Adopta este enfoque para animar a las unidades organizativas a elegir el proveedor de la nube que mejor se adapte a sus necesidades y preferencias específicas.
- Para operar en un despliegue multinube o global. Si una empresa tiene que cumplir las normativas de residencia de datos en regiones o países específicos, debe elegir entre los proveedores de servicios en la nube disponibles en esa ubicación si su proveedor principal no tiene una región de nube allí.
Con el patrón de arquitectura multinube particionada, 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 fundamental. Cuando despliegues cargas de trabajo en varios entornos de computación y quieras mantener la capacidad de mover cargas de trabajo entre entornos, debes abstraer las diferencias entre los entornos. Con GKE Enterprise, puedes diseñar y crear una solución para resolver la complejidad multicloud con una gestión, operaciones y posturas de seguridad coherentes. Para obtener más información, consulta GKE Multi-Cloud.
Como hemos mencionado anteriormente, hay situaciones en las que puede haber motivos empresariales y técnicos para combinar Google Cloud con otro proveedor de servicios en la nube y para particionar las cargas de trabajo en esos entornos de nube. Las soluciones multinube te ofrecen la flexibilidad de migrar, crear y optimizar la portabilidad de las aplicaciones en entornos multinube, a la vez que minimizan la dependencia y te ayudan a cumplir los requisitos normativos. Por ejemplo, puedes conectarte Google Cloud con Oracle Cloud Infrastructure (OCI) para crear una solución multinube que aproveche las funciones de cada plataforma mediante una interconexión privada de Cloud para combinar componentes que se ejecuten en OCI con recursos que se ejecuten en Google Cloud. Para obtener más información, consulta el artículo Google Cloud y Oracle Cloud Infrastructure: aprovecha al máximo tu solución multinube. Además, Cross-Cloud Interconnect facilita la conectividad dedicada de gran ancho de banda entre Google Cloud y otros proveedores de servicios en la nube admitidos, lo que te permite diseñar y crear soluciones multinube para gestionar un gran volumen de tráfico entre nubes.
Ventajas
Aunque usar una arquitectura multinube ofrece varias ventajas empresariales y técnicas, como se explica en Factores, consideraciones, estrategia y enfoques, es fundamental llevar a cabo una evaluación detallada de la viabilidad de cada posible ventaja. En tu evaluación, debes tener en cuenta detenidamente los problemas directos o indirectos que puedan surgir, así como tu capacidad para afrontarlos de forma eficaz. Además, ten en cuenta que el crecimiento a largo plazo de tus aplicaciones o servicios puede introducir complejidades que superen las ventajas iniciales.
Estas son algunas de las principales ventajas del patrón de arquitectura multicloud particionada:
En los casos en los que necesites minimizar el compromiso con un solo proveedor de servicios en la nube, puedes distribuir las aplicaciones entre varios proveedores. Por lo tanto, podrías reducir relativamente la dependencia de proveedores gracias a la posibilidad de cambiar de plan (hasta cierto punto) entre tus proveedores de servicios en la nube. Nuestra nube abierta te ayuda a llevar las Google Cloud funciones, como GKE Enterprise, a diferentes ubicaciones físicas. Al ampliar las funciones on-premise, en varias nubes públicas y en el perímetro, ofrece flexibilidad, agilidad y impulsa la transformación. Google Cloud
Por motivos normativos, puedes ofrecer un segmento determinado de tu base de usuarios y datos desde un país en el que Google Cloud no tenga una región en la nube.
El patrón de arquitectura multinube particionada puede ayudar a reducir la latencia y mejorar la calidad general de la experiencia de usuario en las ubicaciones en las que el proveedor de nube principal no tenga una región de nube o un punto de presencia. Este patrón es especialmente útil cuando se usa una conectividad multicloud de alta capacidad y baja latencia, como Cross-Cloud Interconnect y CDN Interconnect, con una CDN distribuida.
Puedes desplegar aplicaciones en varios proveedores de servicios en la nube de forma que te permita elegir entre los mejores servicios que ofrecen otros proveedores.
El patrón de arquitectura multinube particionada puede facilitar y acelerar las fusiones y adquisiciones, en las que las aplicaciones y los servicios de las dos empresas pueden alojarse en diferentes entornos de nube pública.
Prácticas recomendadas
- Empieza desplegando una carga de trabajo no esencial. Esta implementación inicial en la nube secundaria puede servir como patrón para futuras implementaciones o migraciones. Sin embargo, este enfoque probablemente no sea aplicable en situaciones en las que la carga de trabajo específica deba residir en una región de la nube concreta por motivos legales o normativos, y el proveedor de la nube principal no tenga una región en el territorio requerido.
- Minimiza las dependencias entre los sistemas que se ejecutan en diferentes entornos de nube pública, sobre todo cuando la comunicación se gestiona de forma síncrona. Estas dependencias pueden ralentizar el rendimiento, reducir la disponibilidad general y, posiblemente, generar cargos adicionales por la transferencia de datos salientes.
- Para abstraer las diferencias entre entornos, considera la posibilidad de usar contenedores y Kubernetes cuando las aplicaciones lo admitan y sea factible.
- Asegúrate de que los flujos de procesamiento de CI/CD y las herramientas de despliegue y monitorización sean coherentes en todos los 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 estés usando.
- La comunicación debe ser precisa y controlada. Usa APIs seguras para exponer componentes de la aplicación.
- En función de tus requisitos empresariales y técnicos específicos, puedes usar el patrón de arquitectura de malla o uno de los patrones de redes con acceso controlado.
- Para cumplir tus expectativas de disponibilidad y rendimiento, diseña una alta disponibilidad (HA) de extremo a extremo, una latencia baja y niveles de rendimiento adecuados.
Para proteger la información sensible, te recomendamos que cifres todas las comunicaciones en tránsito.
- Si se requiere cifrado en la capa de conectividad, hay varias opciones disponibles en función de la solución de conectividad híbrida seleccionada. Entre estas opciones se incluyen los túneles VPN, la VPN de alta disponibilidad mediante Cloud Interconnect y MACsec para Cross-Cloud Interconnect.
Si usas varias CDNs como parte de tu patrón de arquitectura particionada multicloud y estás rellenando tu otra CDN con archivos de datos de gran tamaño de Google Cloud, considera la posibilidad de usar enlaces de CDN Interconnect entre Google Cloud y proveedores admitidos para optimizar este tráfico y, posiblemente, su coste.
Amplía tu solución de gestión de identidades entre entornos para que los sistemas puedan autenticarse de forma segura en diferentes entornos.
Para equilibrar las solicitudes de forma eficaz entre Google Cloud y otra plataforma en la nube, puedes usar Cloud Load Balancing. Para obtener más información, consulta Dirigir el tráfico a una ubicación local u otra nube.
- Si el volumen de transferencia de datos salientes de Google Cloudhacia otros entornos es alto, plantéate usar Cross-Cloud Interconnect.
Para superar las incoherencias en los protocolos, las APIs y los mecanismos de autenticación de los diferentes back-ends, te recomendamos que, cuando sea posible, despliegues una pasarela o un proxy de APIs como fachada unificadora. Esta pasarela o proxy actúa como punto de control centralizado y lleva a cabo las siguientes medidas:
- Implementa medidas de seguridad adicionales.
- Protege las aplicaciones cliente y otros servicios frente a cambios en el código del backend.
- Facilita las pistas de auditoría de la comunicación entre todas las aplicaciones de distintos entornos y sus componentes desacoplados.
- Actúa como una capa de comunicación intermedia entre los servicios antiguos y los modernizados.
- Apigee y Apigee hybrid te permiten alojar y gestionar pasarelas híbridas y de nivel empresarial en entornos locales, perimetrales y de otras nubes, así como enGoogle Cloud entornos.
En algunos de los siguientes casos, usar Cloud Load Balancing con una API Gateway puede proporcionar una solución sólida y segura para gestionar, proteger y distribuir el tráfico de APIs a gran escala en varias regiones:
- Despliega la conmutación por error multirregional para los tiempos de ejecución de la API de Apigee en diferentes regiones.
Mejorar el rendimiento con Cloud CDN.
Proporciona protección frente a ataques DDoS y cortafuegos de aplicaciones web (WAF) a través de Google Cloud Armor.
Utiliza herramientas coherentes para el registro y la monitorización en los entornos de nube siempre que sea posible. Puedes usar sistemas de monitorización de código abierto. Para obtener más información, consulta Patrones de almacenamiento de registros y monitorización para despliegues híbridos y multinube.
Si vas a implementar componentes de aplicaciones de forma distribuida, es decir, si los componentes de una misma aplicación se van a implementar en más de un entorno de nube, consulta las prácticas recomendadas del patrón de arquitectura híbrida por niveles.