8

We are working on a cloud native app to be deployed in Cloud Foundry and after initial "let's use all the goodies from Netflix", we started to question if the overlap with CF is justifying usage of Netflix components.

Especially in case of Eureka, we were planning to use it for service discovery, but then very similar capability is provided out of the box by CF and routes. What we would miss is runtime registration of services (which in case of architecture that doesn't change frequently is not a big challenge and would be in fact a static map of serviceID -> CF route) and heartbeat (on the apps level, since I assume on the container level CF is making sure everything is fine).

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

Thank you,

Leszek

PS. Interesting note is that if the eureka stores simple map of serviceID -> CF route, then if I am right, value of Zuul also goes down (since LB would be delivered by CF and gorouter is a very good option).

Lech Migdal
  • 3,828
  • 5
  • 36
  • 63

2 Answers2

4

Eureka uses application IDs to do service discovery, which exist only in the context of your application design. Cloud Foundry routing uses URLs for addressing, which introduces a dependency in your code on the underlying infrastructure.

If I need to access account-service, I'd like to ask for it by that name. The URL for that service will be different depending whether I am testing on my local machine, running a deployed QA instance, or running in production. I don't want my app to have to know where it's running, and which URLs map to which environment. It's likely that those URLs can change over time, anyway.

If I use Eureka, then I just ask for account-service, and the environment-specific issues are abstracted away from my app.

Corby Page
  • 1,385
  • 10
  • 17
  • 1
    Well, this is true if we assume hardcoded URLs, but what if we use config service (which I hope most people use nowadays anyway) to store the information on the serviceID -> cloud foundry route mapping? The mapping will be different for local machine, for QA and for PROD (distinguished by spring profile) and will be abstracted away from my app. If I am right this approach would give me exactly what Eureka gives in CF, but would eliminate one component (Eureka Server) plus Eureka Client libs from each service. So a pure win from my pov...? :) – Lech Migdal Apr 18 '16 at 10:15
  • 2
    This is certainly a viable approach, but it does require you to maintain the routes in two places and keep them in sync. You will need to define the route associated with cf (e.g. in the manifest.yml), and then define the matching route in config-server. If something changes, you need to fix in both places. In larger deployments, it's nice to avoid those sorts of non-automated synchronization tasks. But if it works for you in your environment, that's great! – Corby Page Apr 18 '16 at 12:31
  • Good point. So now I wonder - if we already have Redis in the architecture, then such mapping of serviceID -> route could be kept in Redis. Benefits - no additional component, with all the value of Eureka if I am right? – Lech Migdal Apr 18 '16 at 15:31
  • From a functional standpoint, that is possible. Eureka is purpose-built to do service discovery, though, so you get out-of-the-box functionality that you would have to build yourself in a custom Redis setup. RestTemplate support, polyglot clients, dedicated UI, Ribbon support, etc. With Spring Cloud Services you also get OAuth2 support for secure deployments and HA in the next version. Tradeoff between deploying a new piece of infrastructure and having to update your custom Redis setup to keep up with the new Eureka features you want. – Corby Page Apr 19 '16 at 13:35
  • Thank you, it makes sense. I think that we will test the option of service registry with redis cluster, since it's already a key element of our architecture and I still struggle with Eureka :) Now I wonder about Ribbon - what is the value that you see of using it with CF? With a single route per service and LB done on the CF router level, well, client side load balancing seems to be rather tricky? :) (unless CF router is not used) – Lech Migdal Apr 21 '16 at 09:15
  • Yes, I prefer not to use client-side load balancing when CF routing is available. I was just citing an example of service discovery functionality in Eureka that would not be available in a build-your-own solution. – Corby Page Apr 21 '16 at 15:03
  • 1
    Minor update (one month later) - we've ended up with Eureka anyway, because of the reasons you've mentioned - at some moment of times I got tired of configuring the routes in too many places (including Zuul) ;-) Again - thank you for your help! – Lech Migdal Jun 01 '16 at 15:36
  • 1
    In case this wasn't discovered already - I can't find it on here - you can configure the Eureka client to announce the IP:port instead of the HTTP route. This way, e.g. using Ribbon, you can run load balancing targeting individual instances. Keep in mind, though, that you your CF instance needs to allow application instances to contact each other without going through the CF router. – C-Otto Jan 13 '17 at 13:18
3

With cloud foundry we also felt that using eureka can be an overkill. but We did one thing to externalize and tokenize the names of the service. We needed Spring configurations service initially to manage config but felt it can we used as a central source of service url maps too. (custom code had to be written to load from a central datasource).

We created a Spring config service with a custom datastore which contains many thing such as passwords, service urls etc. Using cups we connect to the Spring config service and the config template contains a set of token which then get translate to service urls on the fly.

We need Spring configurations service initially to manage config but felt it can we used as a central source of service url (custom code had to be written to load from datasource).

Cloud foundry does not have ip and ports, thus no need to track health check of an individual instance for load balancing. CF does that internally pretty good out of the box. So all you need is a central datasource to map us host.domain name with keys/tokens . eg. membership.v1=https://membership-1-0-2.

But if you want a single transaction hitting CF to able to call service hosted in multiple data center then u will need eureka or consul.io to overcome that . CF clusters do not span across Datacenters.

Sameer Tandon
  • 31
  • 1
  • One short update, as I came across your answer: https://youtu.be/DLjtm-v9DOM shows a new feature of CloudFoundry to enable it to run across multiple data centers, using a CPI, Cloud Provider Interface. – Bernd Jun 28 '18 at 12:26