New in Spring Cloud Services 1.2: Multi-Site Service Discovery

October 18, 2016 Chris Sterling


36596-service-registry-sfeaturedAs microservice architectures increase in popularity, so too has the interest in Spring Framework projects. The most popular use case: modernizing legacy JVM-based applications to use cloud-native patterns. For years, enterprises have entrusted their most critical business functions to apps running on the JVM. But these systems have struggled to support an accelerated rate of change in business workflows. This has lead to the rise of microservices generally and Spring Boot and Spring Cloud specifically; microservice architectures built with Spring tooling give enterprises a proven path to upgrade legacy systems and rapidly respond to new business opportunities.

Spring Cloud Services (SCS) builds on the foundation of Spring Boot and Spring Cloud to simplify crucial patterns for microservices running on Pivotal Cloud Foundry (PCF). SCS includes Config Server, Circuit Breaker Dashboard, and Service Registry. This collection of services is a ready-made option for developers who don’t want to implement, deploy, maintain, and upgrade their own Spring Cloud services. With SCS, developers can focus on delivering business value, while Pivotal secures, maintains, and operates these components.

And this option has proven extremely popular. Developers have seen success with the PCF/SCS microservices pattern, and are now requesting features that allow them to expand their deployments. To this end, the Spring Cloud Services team is excited to release a new feature to help with multi-site availability: Service Registry peer replication.

Now GA: Spring Cloud Services 1.2

With the release of Spring Cloud Services 1.2, operators can now configure peer replication of Service Registry service instances. Now, when an application registers with a Service Registry instance, that same application is available for lookup by consumers in a PCF installation in another data center, or across organizations within a single PCF installation.

Consider a recent real-world use case from a financial services organization. This bank has a large number of services deployed across many organizations and spaces in its Pivotal Cloud Foundry environment. A subset of these services need to be discovered and used across the bank, and they want these services to be consumed by apps regardless of their PCF organization and space. With Service Registry peer replication, applications can be managed within the authorization model of a space and made accessible in a controlled way across organizations.


Service Registry peer replication works across PCF installations, or across organizations within a single PCF installation. The diagram above expresses a simple Service Registry peer replication configuration across multiple data centers. If we look at the West PCF data center, the A and C services in light blue are registered with the local Service Registry, and also are made available for lookup in the East PCF data center. The same is true of services in East PCF—those in light green, which are registered locally and also made available for lookup in West PCF.

Once peer replication is enabled, development and operations teams enjoy:

  • Increased availability for their microservices in the face of partial failures
  • Load balancing across network boundaries
  • Successful discovery of services across distinct PCF installations or organizations

Setting Up Peer Replication

Creating a new Service Registry instance can be as simple as running `cf create-service`:

$ cf create-service p-service-registry standard service-registry

This will result in a newly-deployed Service Registry instance named `service-registry`. Now, you can create Service Registry service instances either in 1) multiple PCF installations, or 2) in separate organizations within a single PCF installation. We’ll examine the configuration steps for option 1.

Let’s assume that you have created two Service Registry instances, each named `service-registry`, one in a PCF installation located in a `east` datacenter and one in a PCF installation located in an `west` datacenter. The URIs for these Service Registry instances are:


We’ll now configure each of these Service Registry instances to replicate registrations with each other. To do this, we will set the `peers` property for each instance to point at the other.

First, we can target the PCF installation in the `east` availability zone and run the following command to update its `peers`:

$ cf update-service service-registry -c '{"peers": [{"uri": ""}]}'

Then we can target the instance in the `west` availability zone, running the following command to complete the peer replication circuit:

$ cf update-service service-registry -c '{"peers": [{"uri": ""}]}'

It’s important to note that the `cf update-service` command is asynchronous. You can check on the status of the update process by running `cf service service-registry`. Look for `update succeeded`, as in the following example output:

$ cf service service-registry
Service instance: service-registry
Service: p-service-registry
Plan: standard
Description: Service Registry for Spring Cloud Applications
Documentation url:
Last Operation
Status: update succeeded

Once both Service Registry instances are successfully updated and have their respective peers configured, each instance’s dashboard will show the other instance in its `Peers` parameter value.


Learn More

For more information about Spring Cloud Services, the Service Registry, and peer replication support, see the detailed user documentation at the links below.

Download Spring Cloud Services 1.2 from Pivotal Network.


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
7 Ways Pivotal And Google Simplify Cloud-Native For The Enterprise
7 Ways Pivotal And Google Simplify Cloud-Native For The Enterprise

Pivotal Cloud Foundry is now generally available to run on Google Cloud Platform (GCP). Now enterprises can...

Pay Transparency Matters
Pay Transparency Matters


Subscribe to our Newsletter

Thank you!
Error - something went wrong!