Eureka value in Cloud Foundry / PaaS?

Question

We are working on a cloud-based native application that will be deployed to Cloud Foundry, and after the initial “let you use all the goodies from Netflix”, we began to doubt that the overlap with CF justifies the use of Netflix components.

Especially in the case of Eureka, we planned to use it to discover services, but then very similar capabilities are provided from the CF box and routes. What we missed is the temporary registration of services (which in the case of an architecture that does not change often is not a big problem and will actually be a static map of the serviceID → CF route) and heartbeat (at the application level, since I assume that at CF container level sure everything is ok).

So now I am wondering - how do you use it in your applications (real applications) when using CF? What are the benefits of keeping it in architecture?

Thanks,

Leshek

PS. It is interesting to note that if eureka stores a simple map of the serviceID → CF route, then if I am right, the Zuul value will also decrease (since LB will be delivered to CF, and gorouter is a very good option).

Answer 1

Eureka uses application identifiers to discover services that exist only in the context of your application’s design. Cloud Foundry Routing uses URLs for addressing that injects your code dependency in the underlying infrastructure.

If I need to access account-service , I would like to ask for it under this name. The URL of this service will differ depending on whether I am testing on my local machine, running a deployed QA instance, or working in production. I don’t want my application to know where it works and what URLs are displayed in which environment. These URLs are likely to change over time.

If I use Eureka, then I just ask for account-service , and the problems associated with the environment will be distracted from my application.

Answer 2

With the cloud foundry, we also felt that using eureka might be redundant. but we did one to externalize and symbolize service names. At first we needed a Spring configuration service for configuration management, but it felt like we could use it as a central source of URL service maps. (user code had to be written to be downloaded from a central data source).

We created the Spring configuration service with a custom data warehouse that contains many things, such as passwords, service URLs, etc. Using the cups, we connect to the Spring configuration service, and the configuration template contains a set of tokens, which then go to the service URLs on the fly.

Initially, we needed the Spring configuration service to manage the configuration, but it felt like we could use it as the central source of the service URL (user code had to be written to load from the data source).

The cloud foundry has no ip and ports, so there is no need to track the health check of a single instance to balance the load. CF does it very well out of the box. Thus, all you need is a central data source for matching host.domain with keys / tokens. eg. membership.v1 = https: // membership-1-0-2 .

But if you want one transaction to hit CF so that you can call a service hosted in several data centers, then you will need eureka or consul.io to overcome this. CF clusters do not cover data centers.