El patrón de entrada y salida cerradas usa una combinación de entrada y salida cerradas para situaciones que exigen el uso bidireccional de las APIs seleccionadas entre las cargas de trabajo. Las cargas de trabajo se pueden ejecutar en Google Cloud, en entornos locales privados o en otros entornos de nube. En este patrón, puedes usar puertas de enlace de API, extremos de Private Service Connect o balanceadores de cargas para exponer APIs específicas y, de forma opcional, proporcionar autenticación, autorización y auditorías de llamadas a la API.
La distinción clave entre este patrón y el patrón de malla se encuentra en la aplicación para situaciones que solo requieren el uso bidireccional de la API o la comunicación con fuentes y destinos de direcciones IP específicas, por ejemplo, una aplicación publicada a través de un extremo de Private Service Connect. Debido a que la comunicación está restringida a las APIs expuestas o a direcciones IP específicas, las redes de los entornos no necesitan alinearse en tu diseño. Entre las situaciones comunes aplicables, se incluyen las siguientes:
- Fusiones y adquisiciones
- Integraciones de aplicaciones con socios
- Integraciones entre aplicaciones y servicios de una organización con diferentes unidades organizativas que administran sus propias aplicaciones y las alojan en diferentes entornos.
La comunicación funciona de la siguiente manera:
- Las cargas de trabajo que implementas en Google Cloud pueden comunicarse con la puerta de enlace de API (o direcciones IP de destino específicas) mediante direcciones IP internas. No se puede acceder a otros sistemas implementados en el entorno de computación privado.
- Por otro lado, las cargas de trabajo que implementes en otros entornos de computación pueden comunicarse con la puerta de enlace de API del lado de Google Cloud(o una dirección IP de extremo publicada específica) mediante direcciones IP internas. No se puede acceder a otros sistemas implementados en Google Cloud .
Arquitectura
En el siguiente diagrama, se muestra una arquitectura de referencia para el patrón de entrada y salida cerradas:
El enfoque de diseño del diagrama anterior tiene los siguientes elementos:
- En el lado de Google Cloud , implementas cargas de trabajo en una VPC (o VPC compartida) sin exponerlas directamente a Internet.
- La red del entorno Google Cloud se extiende a otros entornos de procesamiento. Ese entorno puede ser local o estar en otra nube. Para extender el entorno, usa un patrón de comunicación de conectividad híbrida y multinube adecuado para facilitar la comunicación entre entornos, de modo que puedan usar direcciones IP internas.
- De manera opcional, si habilitas el acceso a direcciones IP de destino específicas, puedes usar una VPC de tránsito para agregar una capa de seguridad perimetral fuera de la VPC de tu aplicación.
- Puedes usar el firewall de nueva generación de Cloud o dispositivos virtuales de red (NVA) con firewalls de última generación (NGFW) en la VPC de tránsito para inspeccionar el tráfico y permitir o prohibir el acceso a ciertas APIs desde fuentes específicas antes de llegar a la VPC de tu aplicación.
- Se debe acceder a las APIs a través de una puerta de enlace de API o un balanceador de cargas para proporcionar una capa de proxy y una abstracción o fachada para tus API de servicio.
- En las aplicaciones consumidas como APIs, también puedes usar Private Service Connect para proporcionar una dirección IP interna para la aplicación publicada.
- Todos los entornos usan un espacio de direcciones IP RFC 1918 sin superposición.
Una aplicación común de este patrón implica implementar backends de aplicaciones (o un subconjunto de backends de aplicaciones) en Google Cloud mientras se alojan otros componentes de backend y frontend en entornos locales o en otras nubes (patrón híbrido por niveles o patrón de multinube particionada). A medida que las aplicaciones evolucionan y migran a la nube, a menudo surgen dependencias y preferencias para servicios específicos de la nube.
A veces, estas dependencias y preferencias llevan a la distribución de aplicaciones y backends entre diferentes proveedores de servicios en la nube. Además, algunas aplicaciones se pueden compilar con una combinación de recursos y servicios distribuidos en entornos locales y de varias nubes.
En el caso de las aplicaciones distribuidas, las capacidades de la conectividad externa y de nubes híbridas de Cloud Load Balancing se pueden usar para finalizar las solicitudes de los usuarios y enrutarlas a frontends o backends en otros entornos. Este enrutamiento se realiza a través de una conexión de red híbrida, como se ilustra en el siguiente diagrama. Esta integración permite la distribución gradual de los componentes de la aplicación en diferentes entornos. Las solicitudes del frontend a los servicios de backend alojados en Google Cloud se comunican de forma segura a través de la conexión de red híbrida establecida que facilita un balanceador de cargas interno (ILB en el diagrama).
El uso del diseño Google Cloud en el diagrama anterior ayuda con lo siguiente:
- Facilita la comunicación bidireccional entre Google Cloud, de forma local y en otros entornos de nube mediante el uso de APIs predefinidas en ambos lados que se alinean con el modelo de comunicación de este patrón.
- Para proporcionar frontends globales para aplicaciones orientadas a Internet con componentes de aplicaciones distribuidos (frontends o backends) y lograr los siguientes objetivos, puedes usar capacidades avanzadas de carga de balanceo y seguridad de Google Cloud distribuidas en puntos de presencia (PoP):
- Usa servicios administrados sin servidores para reducir los gastos de capital y simplificar las operaciones.
- Optimiza las conexiones a los backends de la aplicación de forma global para mejorar la velocidad y la latencia.
- Google Cloud Red multinube permite la comunicación multinube entre componentes de aplicaciones a través de conexiones privadas óptimas.
- Almacena en caché el contenido estático de alta demanda y mejora el rendimiento de las aplicaciones que usan Cloud Load Balancing global mediante el acceso a Cloud CDN.
- Protege los frontends globales de las aplicaciones orientadas a Internet con las capacidades de Google Cloud Armor que proporcionan servicios de firewall de aplicación web (WAF) y mitigación de DSD distribuidos en todo el mundo.
- De manera opcional, puedes incorporar Private Service Connect en tu diseño. Esto permite el acceso privado y detallado a las APIs de servicio de Google Cloud o a los servicios publicados desde otros entornos sin atravesar la Internet pública.
Variantes
Los patrones de arquitectura de entrada y salida cerradas se pueden combinar con otros enfoques para cumplir con diferentes requisitos de diseño, sin dejar de considerar los requisitos de comunicación de este patrón. Los patrones ofrecen las siguientes opciones:
- Puertas de enlace de API distribuidas
- Comunicación bidireccional de la API con Private Service Connect
- Comunicación bidireccional con extremos e interfaces de Private Service Connect
Puertas de enlace de API distribuidas
En situaciones como la que se basa en el patrón de múltiples nubes particionadas, las aplicaciones (o los componentes de la aplicación) se pueden compilar en diferentes entornos de nube, incluido un entorno local privado. El requisito común es enrutar las solicitudes del cliente al frontend de la aplicación directamente al entorno en el que se aloja la aplicación (o el componente de frontend). Este tipo de comunicación requiere un balanceador de cargas local o una puerta de enlace de API. Es posible que estas aplicaciones y sus componentes también requieran capacidades específicas de la plataforma de API para la integración.
En el siguiente diagrama, se ilustra cómo Apigee y Apigee Hybrid están diseñados para abordar estos requisitos con una puerta de enlace de API localizada en cada entorno. La administración de la plataforma de API está centralizada en Google Cloud. Este diseño ayuda a aplicar medidas estrictas de control de acceso en las que solo las direcciones IP aprobadas con anterioridad (APIs de destino y destino o direcciones IP de extremo de Private Service Connect) pueden comunicarse entre Google Cloud y los otros entornos.
En la siguiente lista, se describen las dos rutas de comunicación distintas del diagrama anterior que usan la puerta de enlace de la API de Apigee:
- Las solicitudes del cliente llegan al frontend de la aplicación directamente en el entorno que aloja la aplicación (o el componente de frontend).
- Las puertas de enlace y los proxies de API dentro de cada entorno controlan las solicitudes a la API del cliente y de la aplicación en diferentes direcciones en varios entornos.
- La funcionalidad de la puerta de enlace de API en Google Cloud (Apigee) expone los componentes de la aplicación (frontend o backend) que se alojan en Google Cloud.
- La funcionalidad de la puerta de enlace de API en otro entorno (híbrido) expone los componentes de frontend (o backend) de la aplicación que se alojan en ese entorno.
De forma opcional, puedes considerar usar una VPC de tránsito. Una VPC de tránsito puede proporcionar flexibilidad para separar las inquietudes y realizar la inspección de seguridad y la conectividad híbrida en una red de VPC independiente. Desde el punto de vista de la accesibilidad de las direcciones IP, una VPC de tránsito (en la que se conecta la conectividad híbrida) facilita los siguientes requisitos para mantener la accesibilidad de extremo a extremo:
- Las direcciones IP de las APIs de destino deben anunciarse a los otros entornos en los que se alojan los clientes o solicitantes.
- Las direcciones IP para los hosts que necesitan comunicarse con las APIs de destino deben anunciarse al entorno en el que reside la API de destino, por ejemplo, las direcciones IP del solicitante de la API (el cliente). La excepción es cuando la comunicación se produce a través de un balanceador de cargas, un proxy, un extremo de Private Service Connect o una instancia de NAT.
Para extender la conectividad al entorno remoto, este diseño usa el intercambio de tráfico de VPC directo con la función de intercambio de rutas del cliente. El diseño permite que las solicitudes de API específicas que se originan en cargas de trabajo alojadas en la VPC de la Google Cloud aplicación se enruten a través de la VPC de tránsito. Como alternativa, puedes usar un extremo de Private Service Connect en la VPC de la aplicación que está asociado con un balanceador de cargas con un backend de grupo de extremos de red híbrido en la VPC de tránsito. Esa configuración se describe en la siguiente sección: Comunicación bidireccional de APIs con Private Service Connect.
Comunicación de API bidireccional con Private Service Connect
A veces, es posible que las empresas no necesiten usar una puerta de enlace de API (como Apigee) de inmediato o que quieran agregarla más adelante. Sin embargo, es posible que haya requisitos empresariales para permitir la comunicación y la integración entre ciertas aplicaciones en diferentes entornos. Por ejemplo, si tu empresa adquirió otra, es posible que necesites exponer ciertas aplicaciones a esa empresa. Es posible que deban exponer aplicaciones a tu empresa. Ambas empresas pueden tener sus propias cargas de trabajo alojadas en diferentes entornos (Google Cloud, local o en otras nubes) y deben evitar la superposición de direcciones IP. En esos casos, puedes usar Private Service Connect para facilitar una comunicación eficaz.
En las aplicaciones consumidas como APIs, también puedes usar Private Service Connect para proporcionar una dirección privada a las aplicaciones publicadas, lo que permite el acceso seguro dentro de la red privada entre regiones y a través de una conectividad híbrida. Esta abstracción facilita la integración de recursos de diversas nubes y entornos locales a través de un modelo de conectividad híbrida y de múltiples nubes. También permite el ensamblado de aplicaciones en entornos de múltiples nubes y locales. Esto puede satisfacer diferentes requisitos de comunicación, como la integración de aplicaciones seguras en las que no se usa una puerta de enlace de API o no se planea usarla.
Si usas Private Service Connect con Cloud Load Balancing, como se muestra en el siguiente diagrama, puedes lograr dos rutas de comunicación distintas. Cada ruta se inicia desde una dirección diferente para un propósito de conectividad independiente, idealmente a través de llamadas a la API.
- Todas las consideraciones y recomendaciones de diseño de Private Service Connect que se analizan en esta guía se aplican a este diseño.
- Si se requiere una inspección adicional de la capa 7, puedes integrar los NVA en este diseño (en la VPC de tránsito).
- Este diseño se puede usar con o sin puertas de enlace de API.
Las dos rutas de conectividad que se muestran en el diagrama anterior representan conexiones independientes y no ilustran la comunicación bidireccional de una sola conexión o flujo.
Comunicación bidireccional con extremos e interfaces de Private Service Connect
Como se explica en el patrón de entrada cerrada, una de las opciones para habilitar la comunicación cliente-servicio es mediante un extremo de Private Service Connect para exponer un servicio en una VPC de productor a una VPC de consumidor. Esa conectividad se puede extender a un entorno local o incluso a otro entorno de proveedor de servicios en la nube a través de una conectividad híbrida. Sin embargo, en algunos casos, el servicio alojado también puede requerir comunicación privada.
Para acceder a un servicio determinado, como recuperar datos de fuentes de datos que se pueden alojar dentro o fuera de la VPC del consumidor, esta comunicación privada puede ser entre la VPC de la aplicación (productor) y un entorno remoto, como un entorno local.
En tal caso, las interfaces de Private Service Connect permiten que una instancia de VM de productor de servicios acceda a la red de un consumidor. Para ello, comparte una interfaz de red, a la vez que mantiene la separación de los roles de productor y consumidor. Con esta interfaz de red en la VPC del consumidor, la VM de la aplicación puede acceder a los recursos del consumidor como si residieran de forma local en la VPC del productor.
Una interfaz de Private Service Connect es una interfaz de red adjunta a la VPC de tránsito (consumidor). Es posible llegar a destinos externos a los que se puede acceder desde la VPC del consumidor (de tránsito) a la que está conectada la interfaz de Private Service Connect. Por lo tanto, esta conexión se puede extender a un entorno externo a través de una conectividad híbrida, como un entorno local, como se ilustra en el siguiente diagrama:
Si la VPC del consumidor es una organización o entidad externa, como una organización de terceros, por lo general, no tendrás la capacidad de proteger la comunicación con la interfaz de Private Service Connect en la VPC del consumidor. En tal caso, puedes definir políticas de seguridad en el SO invitado de la VM de la interfaz de Private Service Connect. Para obtener más información, consulta Configura la seguridad para interfaces de Private Service Connect. También puedes considerar un enfoque alternativo si no cumple con el cumplimiento o los estándares de seguridad de tu organización.
Prácticas recomendadas
En situaciones en las que un frontend alojado en un entorno privado local o en otro entorno de nube debe recibir solicitudes de clientes de Internet de forma local, considera usar Hybrid como solución de puerta de enlace de API.
- Este enfoque también facilita la migración de la solución a un entorno alojado por completo en Google Cloudy, al mismo tiempo, mantiene la coherencia de la plataforma de API (Apigee).
Para minimizar la latencia y optimizar los costos de grandes volúmenes de transferencias de datos salientes a tus otros entornos cuando estos se encuentran en configuraciones híbridas o de múltiples nubes a largo plazo o permanentes, considera lo siguiente:
- Usa Cloud Interconnect o Cross-Cloud Interconnect.
- Para finalizar las conexiones de los usuarios en el frontend de destino en el entorno apropiado, usa híbrido.
Cuando corresponda para tus requisitos y la arquitectura, usa el adaptador de Apigee para Envoy con una implementación híbrida con Kubernetes.
Antes de diseñar las rutas de conectividad y enrutamiento, primero debes identificar qué tráfico o solicitudes de API deben dirigirse a una puerta de enlace de API local o remota, junto con los entornos de origen y destino.
Usa los Controles del servicio de VPC para proteger los servicios de Google Cloud en tus proyectos y mitigar el riesgo de robo de datos. Para ello, especifica perímetros de servicio a nivel del proyecto o de la red de VPC.
- Puedes extender los perímetros de servicio a un entorno híbrido a través de una VPN autorizada o con Cloud Interconnect. Para obtener más información sobre los beneficios de los perímetros de servicio, consulta la Descripción general de los Controles del servicio de VPC.
Usa Reglas de firewall de la nube privada virtual (VPC) o políticas de firewall para controlar el acceso a nivel de red a los recursos de Private Service Connect a través del extremo de Private Service Connect. Por ejemplo, las reglas de firewall de salida en la VPC de la aplicación (consumidor) pueden restringir el acceso desde las instancias de VM a la dirección IP o a la subred de tus extremos.
Cuando usas una interfaz de Private Service Connect, debes proteger la comunicación con la interfaz configurando la seguridad para la interfaz de Private Service Connect.
Si una carga de trabajo en una subred privada requiere acceso a Internet, usa Cloud NAT para evitar asignar una dirección IP externa a la carga de trabajo y exponerla a la Internet pública.
- Para el tráfico web saliente, usa el proxy web seguro. El proxy ofrece varios beneficios.
Revisa las prácticas recomendadas generales para los patrones de redes híbridas y de múltiples nubes.