Pertinency of a Platform agnostic Service Registry

Application level language specific service discovery has been popularised by Netflix and Pivotal. Netflix developed and contributed a highly available service registry, Eureka. Spring team from Pivotal simplified the use of Netflix OSS through Spring Cloud projects. Spring Cloud project bootified a rather complex Eureka and other Netflix OSS as a simple annotation driven easy to use components. Spring Cloud based services automatically register with Eureka and client can use it through simple annotations.

A lot has happened over the years in the cloud native space. Side care discovery or Platform local/native discovery pattern is being experimented as an alternative for language specific discovery to decouple the infrastructure concerns from the core application logic and at the same time being language and framework agnostic.

Though the main drawback of application level discovery is, it is language native and you need a library for every language and in few cases possibly for frameworks, but if you are language centric let’s say Java and Spring, then Spring Cloud Services would suffice most of your needs. Though most of the platforms offer platform native discovery service, application level library still makes sense in the scenario where the services are deployed across multiple platforms like Cloud Foundry and Kubernetes. In such cases you can have instances of Eureka per platform as a platform neutral discovery for services running in CF automatically discovering services in K8s. These are typical use cases that leverage the best of both the worlds, both the platform native and neutral discovery mechanisms. Services within the platform would leverage platform native discovery and across the platforms would leverage application level platform neutral discovery.

In this blog, we shall go through how to set up a Spring Cloud Netflix-Eureka discovery service between two platforms CF and K8s and have apps seamlessly talk to each other through this platform neutral discovery model.

CF and K8s Platforms

Source code of a simple registry service based on Spring Cloud is available in the below repo,

https://github.com/srinivasa-vasu/spring-cloud-registry-server.git

Eureka: CF Deploy

Git clone the above repo to your local workstation

git clone https://github.com/srinivasa-vasu/spring-cloud-registry-server.git

Execute a local build

mvn clean package -DskipTests

Finally, run the magical cf push to deploy the app to a specific org and space in CF

cf push

CF Eureka Server

Eureka: K8s Deploy

Deploy the same codebase to K8s. K8s manifests are available under src/main/k8s. Replace host path in ingress.yml accordingly.

kubectl apply -f deployment.yml
kubectl apply -f service.yml
kubectl apply -f ingress.yml

Eureka: Replication

Next is to enable peer replication between these instances running in two different platforms. Update src/main/resources/application-cloud.yml with K8s Eureka endpoint and redeploy to CF and vice versa (update K8s deployment with CF Eureka’s endpoint) so that these two services can see each other. If the replication is successful, both the instances should start replicating the registry info seamlessly.

Replicated instance-info

Now push a sample producer app to CF and a consumer app to K8s.

Source code of these apps are available in GitHub,

https://github.com/srinivasa-vasu/spring-cloud-sample-producer.git
https://github.com/srinivasa-vasu/spring-cloud-sample-consumer.git

If you query either of the Eureka instances, it should list both the producer and consumer instances,

Replicate Service Info

When you hit the endpoint of the consumer app (/hello) running in K8s, through Eureka K8s discovery FeignClient should be able to make a REST call to the producer endpoint running in CF and should get the below output,

Output

This use case actually uses both platform native and neutral discovery.

• Services in a platform uses Eureka for auto discovery of services in the other platform
• Services within the platform uses platform native discovery mechanism (check the property service-url in src/main/resources/application-cf.yaml and src/main/resources/application-k8s.yaml)

One of the main concerns of application level discovery at longer run is, it is our responsibility setting up and managing the discovery service instances. Some of the day-2 concerns like patching, upgrading, scaling etc,. are solely our responsibility. That’s where enterprise grade cloud foundry release (PCF ) shines a lot. It offers registry as a fully managed service through OSB. Spring Cloud Service Registry is a managed service offering where the heavy lifting of the concerns mentioned above are handled by the platform. If you want to create a registry service, then it is just few clicks away through the market place distribution.

PCF Marketplace

During the creation time you should be able to specify the number of instances for high availability as well the peer replication service’s whereabouts. This implementation is done through industry standard Open Service Broker that manages create, update, delete and bind of this service to an application instance. When you bind this service to an app (with Spring Cloud libraries), then it would automatically register itself with the registry server. It is more of a self-service model where a developer doesn’t need to worry about the nitty-gritty, where a simple cf bind-service with the right set of libraries gets the job done.

Application level language specific discovery mechanism still makes sense in use cases where you have to auto-discover services across data centres and platforms. It very well complements platform native discovery in these kind of requirements.

Links

https://github.com/srinivasa-vasu/spring-cloud-sample-producer.git
https://github.com/srinivasa-vasu/spring-cloud-sample-consumer.git
https://github.com/srinivasa-vasu/spring-cloud-registry-server.git
https://docs.pivotal.io/spring-cloud-services/2-0/common/service-registry/enabling-peer-replication.html