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 pueden ejecutarse 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 las direcciones IP específicas, no es necesario que las redes de los entornos se alineen en tu diseño. Las situaciones comunes aplicables incluyen, entre otras, 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 con las 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 de Google Cloud (o con una dirección IP específica de extremo publicada) 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 salida y entrada cerradas:
El enfoque de diseño del diagrama anterior tiene los siguientes elementos:
- En Google Cloud, implementa cargas de trabajo en una VPC (o VPC compartida) sin exponerlas directamente a Internet.
- La red del entorno de Google Cloud se extiende a otros entornos de computación. 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 de múltiples nubes adecuado para facilitar la comunicación entre los entornos para que puedan usar direcciones IP internas.
- De forma opcional, si habilitas el acceso a direcciones IP de destino específicas, puedes usar una VPC de tránsito para ayudar a 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 el espacio de dirección 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 alojas otros componentes de backend y frontend en entornos locales o en otras nubes (patrón híbrido en niveles o patrón de múltiples nubes particionados). A medida que las aplicaciones evolucionan y migran a la nube, suelen surgir las dependencias y las preferencias de servicios específicos en la nube.
A veces, estas dependencias y preferencias conducen a la distribución de aplicaciones y backends entre diferentes proveedores de servicios en la nube. Además, algunas aplicaciones pueden compilarse con una combinación de recursos y servicios distribuidos en entornos locales y en varios entornos de nube.
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 produce en 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 de 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):
- Reduce los gastos de capital y simplifica las operaciones mediante servicios administrados sin servidores.
- Optimiza las conexiones a los backends de aplicaciones de forma global para obtener velocidad y latencia.
- Cross-Cloud Network de Google Cloud permite la comunicación de múltiples nubes entre los componentes de la aplicación mediante 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 a 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, a la vez que se consideran 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 API con Private Service Connect
- Comunicación bidireccional con interfaces y extremos de Private Service Connect
Puertas de enlace de API distribuidas
En situaciones como la basada en el patrón de múltiples nubes con partición, las aplicaciones (o componentes de la aplicación) se pueden compilar en diferentes entornos de nube, incluidos los siguientes: un entorno local privado. El requisito común es enrutar las solicitudes de los clientes 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. Estas aplicaciones y sus componentes también pueden requerir 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 en el diagrama anterior que usan la puerta de enlace de API de Apigee:
- Las solicitudes del cliente llegan directamente al frontend de la aplicación en el entorno que aloja la aplicación (o el componente de frontend).
- Los proxies y las puertas de enlace 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 los problemas y realizar una inspección de seguridad y conectividad híbrida en una red de VPC independiente. Desde el punto de vista de la accesibilidad de la dirección IP, una VPC de tránsito (en la que se adjunta 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 realiza 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 directo de VPC con la capacidad de intercambio de rutas de clientes. El diseño permite que las solicitudes a la API específicas que se originan en cargas de trabajo alojadas dentro de la VPC de la aplicación de Google Cloud 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á asociada 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 la API con Private Service Connect.
Comunicación bidireccional de API 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 deseen agregarla más adelante. Sin embargo, puede haber requisitos empresariales para habilitar la comunicación y la integración entre ciertas aplicaciones en entornos diferentes. Por ejemplo, si tu empresa adquirió otra, podrías tener que exponer ciertas aplicaciones a esa empresa. Es posible que necesiten exponer aplicaciones a tu empresa. Ambas empresas pueden tener sus propias cargas de trabajo alojadas en diferentes entornos (Google Cloud, locales 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 nubes diversas y entornos locales en un modelo de conectividad híbrida y de múltiples nubes. También permite el ensamblaje de aplicaciones en entornos locales y de múltiples nubes. 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 está planificada para usarse.
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 de diseño y recomendaciones 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 interfaces y extremos 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 pueden estar alojadas dentro de la VPC del consumidor o fuera de ella, esta comunicación privada puede estar entre la VPC de la aplicación (productor) y un entorno remoto, como un entorno local.
En este caso, las interfaces de Private Service Connect permiten que una instancia de VM del 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 conectada a la VPC del consumidor (tránsito). Es posible llegar a destinos externos a los que se puede acceder desde la VPC del consumidor (tránsito) en 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 esta situación, puedes definir políticas de seguridad en el SO invitado de la VM de la interfaz de Private Service Connect. Si deseas obtener más información, consulta Configura la seguridad para interfaces de Private Service Connect. O bien, puedes considerar un enfoque alternativo si no cumple con el cumplimiento o los estándares de seguridad de tu organización.
Prácticas recomendadas
Para situaciones en las que un frontend alojado en un entorno privado local o en otra nube deba recibir solicitudes de clientes de Internet de manera local, considera usar Hybrid como una solución de puerta de enlace de API.
- Este enfoque también facilita la migración de la solución a un entorno completamente alojado en Google Cloud y, 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 esos entornos 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 usuario en el frontend objetivo en el entorno adecuado, usa Hybrid.
Cuando corresponda a tus requisitos y la arquitectura, usa Apigee Adapter for Envoy con una implementación híbrida con Kubernetes.
Antes de diseñar la conectividad y las rutas de enrutamiento, debes identificar el tráfico o las solicitudes a la API que se deben dirigir a una puerta de enlace de API local o remota, junto con los entornos de origen y de 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 mediante la especificación de perímetros de servicio a nivel de proyecto o de 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 salientes en la VPC de la aplicación (consumidor) pueden restringir el acceso de 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 mediante la configuración de 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 sobre los patrones de red híbridas y de múltiples nubes.