Comprender cómo viaja la información dentro de Google Cloud Platform marca una diferencia real en el rendimiento de tus aplicaciones. La red privada de Google, sus regiones, puntos de presencia y herramientas de conectividad son piezas fundamentales que cualquier función serverless puede aprovechar para reducir la latencia y mantener la comunicación segura con recursos internos.
¿Cómo está estructurada la red global de Google Cloud?
El pilar principal de la infraestructura de Google Cloud son las regiones [01:01]. Cada región aparece como un punto en el mapa global y dentro de cada una existe un número determinado de data centers o zonas disponibles. Al desplegar una función, seleccionamos la región donde vivirá, y esa decisión importa mucho.
Si tu base de datos —por ejemplo, Data Store— está desplegada en US Central 1 (Iowa), no tendría sentido colocar tu función en el sureste asiático [01:33]. Esa distancia generaría una latencia innecesaria. La regla es simple: despliega tu función lo más cerca posible de los recursos que consume.
¿Por qué la red privada de Google reduce la latencia?
Google es dueño de su propio cableado global, incluyendo cables submarinos que conectan continentes [02:10]. Desde la costa del Pacífico, un cable llega hasta Chile, salta a Buenos Aires, entra a Brasil y así sucesivamente. Cuando se genera una solicitud, Google intenta encaminarla al punto de presencia más cercano al origen.
- Si alguien en Perú hace una solicitud, esta puede dirigirse a Santiago [02:52].
- Desde Santiago viaja por la red privada de Google hasta Los Ángeles.
- El resultado: menor latencia porque la información no sale a Internet público.
Google siempre que puede mantiene tus solicitudes dentro de su propia red [03:14]. Solo cuando no es posible, la información pasa a un proveedor externo de Internet.
¿Qué limitaciones de red tienen las funciones serverless?
Las funciones serverless aprovechan la infraestructura de red, pero están más acotadas porque Google administra qué operaciones son permitidas [03:35]. Un ejemplo claro: las funciones de segundo plano no tienen un endpoint público; solo las funciones HTTP lo tienen.
Esto genera un reto concreto: ¿cómo comunicarse con recursos que no están expuestos a Internet? Pensemos en un clúster de máquinas virtuales o un clúster de Kubernetes dentro de una red privada, con un segmento como 10.128.0.0/28 y sin IP externa [03:58].
¿Cómo funcionan los conectores VPC en Google Cloud?
La solución son los conectores VPC (VPC connectors), que establecen un canal unidireccional [04:22]. La función puede comunicarse con los recursos privados, pero no al revés.
El proceso para configurarlos tiene pasos claros:
- Habilitar la API del servicio de conectores VPC [04:38].
- Definir el conector asignándole un nombre, la red de destino y la región, que debe coincidir con la región de tu red privada.
- Asignar un rango de red al conector que no se traslape con el rango de la red destino.
- Configurar cuentas de servicio con permisos de viewer y usuario de red [05:02]. La cuenta de servicio lleva el número del proyecto como parte de su nombre.
- Desplegar la función indicando que usa un conector VPC.
Una vez desplegada, la función queda lista para hablar con los recursos privados. Si ya no necesitas la conexión, puedes eliminar la función o usar la bandera --clear-vpc-connector [05:30].
¿Cuándo usar un conector VPC desde una función?
Cada vez que necesites que una función serverless acceda a recursos sin IP pública —bases de datos internas, clústeres privados o cualquier servicio dentro de una VPC— el conector VPC es la herramienta indicada [05:42]. Recuerda que la latencia también depende de elegir la región correcta y de aprovechar la red privada de Google.
Si has trabajado con conectores VPC o tienes dudas sobre cómo configurar la comunicación entre funciones y recursos privados, comparte tu experiencia en los comentarios.
