Spring Cloud Services

Make sure you have the cf client installed and that you’re targeting a Pivotal Cloud Foundry instance that has the Spring Cloud Services tile installed.

Pivotal Cloud Foundry has the notion of applications and services. We deploy applications with the cf push command, and we create services with the cf create-service command. Finally, services are attached to applications via a process known as binding, using the cf bind command.

The general process of deploying our system to Cloud Foundry involves:

To orient ourselves to the syntax for creating our first service, invoke the command:

If you recall from the marketplace listing above, the name of the service type is p-service-registry, and it sports two plans. Select the one named "trial".

⇒ Create the service:

Here’s the response:

Notice the message create in progress. At this point, Spring Cloud Services (which from now on I’ll abbreviate as SCS) begins the work of standing up a eureka server on our behalf. This process is asynchronous and can take a couple of minutes.

Check on the status of your service creation with the cf services command:

Within a short time, the "last operation" value will change to create succeeded.

At this point, it’s worth jumping over to the Apps Manager, the Graphical User Interface for PCF (in PWS, the url is http://console.run.pivotal.io/). Log in to the apps manager and navigate to the org and space that matches your cf target. In the service tab, you should see the service that was just created, as shown here:

Click on the service registry, and in the upper right-hand corner, you’ll see a link titled Manage. This is standard for many managed services in cloud foundry: they expose some kind of management dashboard. For the service registry, the dashboard is essentially the same eureka dashboard we’ve been working with all along, only styled with a different color scheme.

Of course, we have no registered applications at this time. Let’s move on to creating a configuration server in PCF.

The process here is very similar, but with one major difference: we must configure our config server with our git repository.

The services that both fortune and greeting depend on are now running.

There’s a difference between the way these services are configured locally and the way they’re configured in PCF:

⇒ The PCF services are secured with an OAuth2 server

This means that clients cannot just connect to these services without authenticating (i.e. providing credentials). SCS boils this task down to modifying the client applications' build dependencies.

Let’s, once more, run through the scenario of modifying the feature toggle greeting.displayFortune, pushing that change to the github repository, and submitting an HTTP post to the /refresh endpoint of the greeting application in PCF, and observing that the application reloads the configuration and alters its behavior correspondingly.

However, before we do that, consider the following question:

⇒ If greeting were scaled to, say 100 instances, how would we go about refreshing the configuration from every single instance?

I suppose we could script submitting a "/refresh" command in a for loop. There’s a better way.

The Spring team offers a project named Spring Cloud Bus designed to solve this very problem, via messaging.

The idea is for all application instances to communicate over a message bus. Sending a /bus/refresh signal (an http POST) to any instance will have the side effect of having that instance broadcast the message to all other running instances.

To add this capability to an application requires:

Do this for greeting:

In CloudFoundry, all application instances have the same URL, handled by a component known as the Gorouter, which fronts and load-balances requests across application instances.

So the task of load balancing can be left up to the platform, and we don’t need to use Ribbon. It’s not harmful to leave Ribbon in place, but the work that Ribbon does, of selecting an instance from among multiple candidates is for naught, since each service instance resolves to the same URL.

We can glean that this is so by inspecting the eureka dashboard:

Here we see three instances of GREETING. It happens that each serviceId is composed of multiple pieces of information, the first element being the instance’s hostname. The hostname is clearly the same value, for all three instances.

There is however a use case, and a good reason for using Ribbon instead of the Gorouter. In PCF, we can enable a feature called container-to-container networking, giving applications the permission to contact each other directly (i.e. without going through the Gorouter).

In this configuration, client-side load-balancing with Ribbon becomes meaningful. In fact this configuration is more secure.

In CloudFoundry, when an application is given a route, it becomes directly accessible to the outside world. If some of our services, for example the fortune service, are strictly backing services, not meant to be accessed directly by clients, then we can make them only accessible to the services within PCF that need to talk to them. We can remove the route from fortune altogether, and let greeting contact it directly via its internal IP address.

You may need to wait a minute or so, for the new instances to come up, for their registrations to show up in eureka, and for the greeting application’s cache of the service registry to expire. Afterwards, greeting should be using ribbon to communicate with fortune directly, not only doing so more securely, but also eliminating an extra network "hop".

Tail the logs for fortune and visit the greeting page multiple times. The output should reveal two things:

The goal here is to be able to monitor the greeting application’s circuit breaker in Cloud Foundry. Again, SCS does all of the hard work for us. We simply need to:

In this scenario, we’ll also scale greeting back up to three instances and observe that Spring Cloud Services automatically aggregates metrics from all application instances into a single dashboard, courtesy of the Netflix Turbine project, and Spring Cloud’s Turbine Stream.

In the above screenshot, notice that the graph for the circuit breaker represents aggregate metrics across three instances of greeting. As we did in the circuit breakers lab, at this point, we can experiment by simulating requests against greeting, stopping the fortune application, and seeing the circuit open. In the reverse direction, we can restart fortune, and watch the circuit close once more.

Spring Cloud Services helps make Spring Cloud-based microservice applications first-class citizens on Cloud Foundry. It provides a production-grade implementation of a Cloud Foundry service broker that can stand up secure instances of the Spring Cloud services on demand. The product’s documentation goes deeper into more sophisticated configurations, such as standing up discovery services as a cluster with multiple peers.

Congratulations for making it through this course!