Relationship between Forwarding Rules, Target HTTP Proxy, URL Map, and Backend Service, in GCP

Question

I'm new to GCP and pretty confused by the load balancing setup if you have an HTTP service (I asked a different question about TCP load balancing here: purpose of Target Pools in GCP).

It seems like, if you have a service which uses HTTP and you want to use Load Balancing, you have to create a lot of different components to make it happen.

In the tutorial I'm going through in Qwiklabs (https://google.qwiklabs.com/focuses/558?parent=catalog), you need to set things up so that requests flow like this: Forwarding Rule -> Target HTTP Proxy -> URL Map -> Backend Service -> Managed Instance Group. However, it doesn't really explain the relationship between these things.

I think the purpose of the Managed Instance Group is clear, but I don't understand the relationship between the others or their purpose. Can you provide an easy definition of the other components and describe how they are different from each other?

Answer 1

All these entities are not different components - they are just a way to model the configuration in a more flexible and structured way.

• Forwarding Rule: This is just a mapping of IP & port to target proxy. You can have multiple forwarding rules pointing to the same target proxy - this is handy when you want to add another IP address or enable IPv6 or additional ports later on without redeploying the whole loadbalancer.

• Target Proxy: This is all about how to handle connections. In your case with a target HTTP proxy, it sets up HTTP handling. With a target HTTPS proxy, you can configure SSL certificates as well.

• URL Map: This only makes sense in the HTTP/HTTPS case - since the HTTP/HTTPS proxy parses requests, it can make decisions based on the requested URL. With a URL map, you can send different parts of your website to different services - this is for example great for microservice architectures.

• Backend Service: This encapsulates the concept of a group of servers / endpoints that can handle a class of requests. The backend service lets you fine-tune some aspects of load balancing like session affinity, how long to wait for backends, what to do if they're unhealthy and how to detect it. The set of backends can be identified by an instance group (with or without autoscaling etc.) but can also be something like a GCS bucket for serving static content.

The reason for having those all separate entities is to let you mix and match or reuse parts as makes sense. For example, if you had some sort of real-time communication platform, you might have forwarding rules for web and RTC traffic. The web traffic might go through a HTTP(S) proxy with a URL map, serving static content from a GCS bucket. The RTC traffic might go through a target TCP proxy or even a UDP network level load balancer but point at the same set of backends / the same instance group.