Building Spring Microservices with Cloud Foundry's New Container Networking Stack

February 21, 2017 Chris Sterling

We’re excited to announce two new beta features for Pivotal Web Services (PWS)! Spring Cloud Services and Cloud Foundry's new container networking stack are now available.

First, Spring Cloud Services (SCS) is available as a beta in the PWS marketplace. SCS is an essential tool for building microservices architectures with Pivotal Cloud Foundry that is now available to any PWS user.

Second, the new Cloud Foundry container networking stack is available, also as a beta. This feature supports container-to-container networking. Using container networking, you can configure network policies for app-to-app interactions, and tailor efficient routes between containers to boost security and reduce latency. [UPDATE: As of July 2017: Container Networking is now generally available for all PWS users. This blog has been modified slightly to reflect this change.]

We've coupled the beta programs for these features because they work well together. Container networking and the Service Registry combine to boost efficiency in client communications. Further, developers can control how services access each other, boosting security.

Ready to use these new features together? Read on, and see how easy it is to connect application clients and their dependent services!

What You’ll Need

To use Service Registry with container networking in your Spring applications, you’ll need the following setup in your development environment:

Now, verify that you have SCS in your PWS marketplace, along with container networking support. Log in and run the following commands using the Cloud Foundry CLI:

$ cf marketplace | grep Spring
p-circuit-breaker-dashboard standard Circuit Breaker Dashboard for Spring Cloud Applications
p-config-server standard Config Server for Spring Cloud Applications
p-service-registry standard Service Registry for Spring Cloud Applications

$ cf network-policies
Source        Destination    Protocol    Port

An Example

The SCS development team has created example applications; you can find them in the “Who is Home?” repository on Github. The client application is named visitor. The visitor application knocks at the homeowner application’s virtual door, a REST API, to have a conversation. These applications show how clients and services use container networking through the service registry.

Deploy these applications and the dependent SCS Service Registry by following the instructions in the repository README.

Enabling Direct Access to Services

With Spring Cloud Services (SCS), an application registering itself in the service registry typically uses the route registration method. This is the default method when using the Spring Cloud Services Connector for Service Registry.

If you want to use direct container-to-container networking, you’ll use the direct registration method instead. Here’s the configuration block to add into the application configuration (such as application.yml) for the registering application:

     registrationMethod: direct

At the time of this writing, you must also use Spring Cloud OSS and SCS dependencies that add the ability to use direct container networking. An example build file using Gradle would add the following Maven BOM dependencies:

dependencyManagement {
   imports {
       mavenBom ""
       mavenBom ""

Or using Maven:


Now that our registering application is configured to use direct container networking, there is no need for Cloud Foundry to generate an external route when it is deployed.

For an application named homeowner, Cloud Foundry would usually generate a route with a URL such as In this case, we don’t want to expose our service externally. Therefore, our setup should tell PWS not to create a route for this application. This can be accomplished by adding the --no-route cf CLI option when pushing the application to PWS, or by setting no-route: true in the application’s manifest.yml.

Testing Direct Container Networking

If you just deployed your client and service applications for the first time, you probably don’t have any networking policies set up. Verify this by running the `cf network-policies`. If you go to the client application’s URL, the visitor application (in the “Who is Home?” sample), you will receive a message that the visitor application is not able to communicate with the registered service homeowner. Although the service registry provides the internal IP address and port for the service to connect to, there is no network policy allowing this communication. Communication is blocked by default.

To enable communication between the client and service applications, you can add a network policy. For example, to allow visitor to communicate with homeowner, use the following command:

$ cf add-network-policy visitor --destination-app homeowner --protocol tcp --port 8080

The add-network-policy command sets up a network route from visitor to homeowner using a TCP protocol on port 8080. Once this network policy has been added successfully, the visitor application can communicate with the homeowner application. And most importantly, it is not using an externally available route to do so: it is using direct container networking with an IP address and port for the service application. When we list the network policies we now see the following:

$ cf network-policies
Source		Destination	Protocol	Port
visitor		homeowner	tcp		8080


Direct container-to-container networking enables many new scenarios for applications deployed to Pivotal Cloud Foundry. One of those use cases: the ability to register applications using the direct registration method with a Spring Cloud Services Service Registry. Now, a registered service no longer needs an externally routable URL, and instead you can control communication with the service using network policies!

Set up an account on Pivotal Web Services to try out Spring Cloud Services, Container Networking, and much more.

[UPDATE: This blog post was updated with new CLI commands for container networking in November 2017.]

About the Author

Chris Sterling

Chris Sterling is Principal Product Manager for Spring Cloud Services at Pivotal ( Chris published the book Managing Software Debt: Building for Inevitable Change with Addison-Wesley in 2010 to provide a framework for teams and organizations to assess and manage debt in their software systems. Chris has successfully supported organizational transformation across multiple verticals with organizations of 10 up to 800 people. Chris co-founded a company in 2009 called Agile Advantage focused on solving portfolio management problems to leverage the value that Agile teams can deliver, which lead to a successful acquisition by Rally Software. Chris brings his diverse experience and deep passion for technology when presenting on topics such as Continuous Delivery, Cloud Native architecture, DevOps, Lean and Agile.

Follow on Twitter
Cloudbleed: What Pivotal Customers Need to Know

Pivotal is currently investigating whether any Pivotal products may be affected by the Cloudbleed vulnerabi...

Pivotal Achieves Cloud Foundry-Certification For a Second Year
Pivotal Achieves Cloud Foundry-Certification For a Second Year

The Cloud Foundry Foundation has certifications for providers. This tells customers that providers meet rig...

SpringOne at VMware Explore 2023

Learn More