Can You Use Ribbon Client-Side Load Balancing with Pivotal Cloud Foundry (PCF)? #

Great question—let’s unpack this thoroughly, since it’s a common point of confusion when working with PaaS platforms like PCF.

Short Answer #

Yes, you technically can use Ribbon (or other client-side load balancers) in PCF to let app clients communicate directly with app instances. But there are critical caveats, tradeoffs, and practical considerations you need to weigh before going this route.

How It’s Possible (And What You Need) #

To make this work, you’ll need to address two core requirements:

• Access to Instance Network Addresses: PCF app instances run on Diego cells with internal IP addresses. Clients can only reach these instances if they’re within the same PCF foundation’s trusted internal network (e.g., another app deployed in the same org/space, or a service running in the foundation’s private network). External clients won’t be able to reach these internal IPs directly—they’ll still have to go through PCF’s edge load balancer.
• Dynamic Instance Discovery: Ribbon needs a way to fetch the current list of app instances (since PCF scales, restarts, and replaces instances automatically). You can achieve this by:
  • Integrating with Spring Cloud Cloud Foundry: If you’re using Spring Boot apps, Spring Cloud’s PCF integration hooks into the platform’s service registry to expose instance metadata to Ribbon.
  • Using a dedicated service discovery tool like Eureka: Register your PCF apps with Eureka, and configure Ribbon to pull instance lists from Eureka instead of static config.

Why You Might Not Want to Do This #

While technically feasible, bypassing PCF’s built-in load balancer comes with significant downsides:

• Losing Platform-Managed Features: PCF’s edge LB handles critical tasks like SSL termination, health check-based instance pruning, routing rules (for blue-green deployments, canary releases), rate limiting, and traffic shaping. If you go client-side with Ribbon, you’ll have to implement and maintain these features yourself—adding unnecessary complexity.
• Operational Overhead: You’ll need to manage service discovery integrations, ensure network policies allow direct instance access, and handle edge cases like instance failures or scaling events (Ribbon’s health checks won’t be as robust as PCF’s native instance monitoring).
• Reduced Portability: Direct instance communication ties your architecture tightly to PCF’s internal network model. If you ever migrate to another PaaS or cloud provider, you’ll have to rework this layer entirely.

Recommendation #

In most cases, sticking with PCF’s native load balancing is the better choice. It’s simpler, leverages the platform’s built-in reliability features, and aligns with PaaS best practices.

Only consider using Ribbon if you have a very specific need that PCF’s LB can’t address—like ultra-low-latency internal service calls with custom load balancing logic that the platform doesn’t support. Even then, make sure you fully account for the operational overhead involved.

内容的提问来源于stack exchange，提问作者Adam Siemion