Many of you choose to develop serverless applications on Google Cloud so that you don’t have to worry about provisioning and managing the underlying infrastructure. In addition, serverless applications scale on-demand so you only pay for what you use. But historically, serverless products like App Engine used a different HTTP load balancing system than VM-based products like Compute Engine. Today, with new External HTTP(S) Load Balancing integration, serverless offerings like App Engine (standard and flex), Cloud Functions and Cloud Run can now use the same fully featured enterprise-grade HTTP(S) load balancing capabilities as the rest of Google Cloud.

With this integration, you can now assign a single global anycast IP address to your service, manage its certificates and TLS configuration, integrate with Cloud CDN, and for Cloud Run and Functions—load balance across regions. And over the coming months, we will continue to add features like support for Cloud Identity-Aware Proxy (IAP) and Cloud Armor.

Introducing serverless Network Endpoint Groups

These new capabilities are courtesy of a foundational feature of Google Cloud networking and load balancing: network endpoint groups (NEGs). These collections of network endpoints are used as backends for some load balancers to define how a set of endpoints should be reached, whether they can be reached, and where they’re located. Google Cloud HTTP(S) Load Balancing already supports a number of different types of NEGs, like internet NEGs and Compute Engine zonal NEGs, and today, we’re expanding this list to include serverless NEGs, which allow External HTTP(S) Load Balancing to use App Engine, Cloud Functions, and Cloud Run services as backends.

Serverless NEG

Adding serverless NEGs to External HTTP(S) Load Balancer brings a whole host of benefits to your serverless workloads. Let’s take a deeper look.

Seamless integration with other services

One of the key features of Google Cloud HTTP(S) load balancing is load balancing across multiple, different backend types, and the integration of serverless NEGs improves on that: the load balancer’s URL map can now mix Serverless NEGs with other backend types. For example, your external IPv4 and IPv6 clients can request video, API, and image content by using the same base URL, with the paths /catalog, /queries, /video, and /images. Via the load-balancer’s URL map, requests to various paths are routed to different backends:

• /queries - > a backend service with a serverless NEG backend
• /catalog -> a backend service with a VM instance group or a zonal NEG backend
• /images -> a backend bucket with a Cloud Storage backend
• /video -> a backend service that points to an internet NEG containing an external endpoint that is located on-premises outside of Google Cloud.

#serverless #networking