Thanks to Dan from Engineer Better for prompting this update. We (the CF-Networking team) haven't reached out in a while. 

Last October we shared that with our integration between and CF and Istio Pilot, we were able to offer weighted routing via a new Envoy-base ingress gateway and Cloud Controller APIs or a CLI plugin, enabling developers to have more control in shifting traffic from one version of their application to another. That thread is here: https://lists.cloudfoundry.org/g/cf-dev/message/8328

Since then we've been working on extending our integrations to the application-to-application data plane. Our target milestones are enabling developers to rely on the platform for client-side load balancing, timeouts, retries, and mTLS between applications over the C2C overlay network. These features will remove additional toil from developers for having to implement these behaviors, increasing productivity, and give platform operators and security teams confidence that intra-application traffic is secured in a consistent way.

We already support routing of traffic from apps to internal routes through the sidecars and have default policies set for load balancing, timeouts and retries. But this only works at a relatively low scale; 300 total internal routes. Scaling past this will likely require enhancing our integration with Istio to uniquely configure the sidecars for each application based on c2c security policies. 

We've successful spiked out having the consumer and provider sidecars negotiate mTLS, but we've set that down while we work on the scaling problem above. On this topic we want some feedback from the community on a rollout strategy. Look for a follow up email coming soon.

All this work has been happening in istio-release (https://github.com/cloudfoundry/istio-release), which you can deploy with BOSH alongside cf-deployment using an ops file. Documentation can be found on the README. Warning: our integration with Istio is not yet ready for production use cases. In addition to scaling concerns, the control plane is not yet HA nor is it sufficiently instrumented for monitoring. 

In parallel with the Networking team's efforts, other CF teams are doing great work toward the same vision:

• A collaboration between CAPI and CLI teams, responsible for completing the v3 CC API and delivering the v7 CLI, have been working on the APIs and CLI commands to support declarative configuration of routing rules, starting with percentage-based traffic splitting for external routes. 
• One engineer from the Windows team has been laboring to contribute Windows support to the Envoy Proxy OSS project, which will enable developers of .NET apps to achieve all the same outcomes planned for Linux apps, plus any outcomes delivered with service mesh in the future. Once the sidecars are in place, the operating system is abstracted. 

We'd love help with all of this. If you'd like to contribute please reply here or reach out to us in #networking.

At CF Summit in Philadelphia earlier this year, I gave a presentation at User Day sharing our journey from routing to service mesh in CF, with the ever present goal of delivering business outcomes for platform operators and the development teams they serve. I've attached the slides. I plan to attend CF Summit EU in The Hague in September, and SpringOne Platform in Austin October; reach out if you'd like to meet up. 

Best,

Shannon Coen

Product Lead, PCF Networking

Pivotal, Inc.