With the increasing adoption of Cloud Foundry across industries, the community continues to improve technological efficiency and create new Cloud Foundry projects. One such project is Cloud Foundry Networking Release, which provides policy-based container networking for Cloud Foundry.
Since its inception, the Cloud Foundry Networking Release has been solving one problem after another faced by developers. Instead of making every app go through the hoops and loops of GoRouter and load balance, apps can now talk to each other. It also gives better networking policy control to developers so they can see which apps are talking to each other.
The Cloud Foundry Networking Release embraced CNI (Container Networking Interface) that allows for third-party plugins like VMware NSX-T to integrate with Cloud Foundry and provide users with more control and flexibility.
Users can also use Silk Release in conjunction with the Networking Release to enforce the policy that is stored in the policy server. Silk Release puts all containers on an overlay network which runs VXLAN and gives every single container its own IP. It is self-service so developers can configure policies for their apps if operators allow it.
Previously, there was no container to container (C2C) service discovery on the platform. Developers had to figure out which ports were open and to what to connect. To solve the service discovery problem, Cloud Foundry Networking Release added support for polyglot service discovery on the platform with an experimental release called CF App Service Discovery Release.
CF App Service Discovery Release has served its purpose and has been depreciated. All features have moved to Cloud Foundry Networking Release. It uses BOSH DNS to look up the DNS name for a destination app. A new hard-coded domain called apps.internal is created by Cloud Controller to allow app developers to map routes that make it easier to connect to a container on the container network.
Cloud Foundry Networking Release uses new terminologies for routes. Routes going through the router are called “external routes” and routes that use the direct container-to-container communication are called “internal routes.” Any route that is mapped to the app’s internal domain is going to be an internal route. When there is a lookup for this route, there is an actual container IP for that container to which an app can connect. No service discovery burden on a developer!
The Cloud Foundry Networking Release team has identified three major use cases that benefit from this ongoing work:
- Secure Microservices: Frontend microservices with one external route and everything else as an internal route take advantage of C2C policy that controls what can talk to what. That traffic stays within Cloud Foundry.
- Blue-Green Deployment: A developer can map multiple applications to the same route, offering the same experience for internal routes as well as external routes. It allows developers to map a new version of their app to the same route and after testing they can retire the old app.
- Clustering app: If an app needs a peer-to-peer communication, a developer can use index space route so that every app also gets a zero dot or one dot route for each instance, in addition to a load balancer.
As the need for more advanced features grows, the Cloud Foundry Networking Release is looking to embrace new technologies, such as Service Mesh.
To learn more about how they plan to use Service Mesh, and to get a deep dive into the evolution and use cases, please watch this talk and demo. If you love cats and dogs, you will enjoy it even more!
