Consul patterns fro service discovery and config management about consul-client HOT 8 CLOSED

Well, to my dismay the question was put on hold. However I was hoping someone here might be able to speak to it anyway. The one dev that answered claims to use a "consul agent/app/orbitz client/ribbon" stack, but to me, that seems almost as complicated as Airbnb's "smart" stack.

from consul-client.

The Ribbon approach is likely using the Consul support Spring recently added, which is heavily coupled to the Netflix stack.

I was going to answer the question, but as you said, it's on hold. Not saying our approach is the best, but it's relatively simple and has been working in production for half a year.

from consul-client.

Thanks for the update @rickfast - I guess to me, the Airbnb "Smart Stack" and this other user's "Ribbon Stack" both seem convoluted to me, although I'm a total Consul newbie.

As a Java developer, I'd prefer to keep as much of my app logic in Java, and so if the Orbitz Consul/Java client allows me to do everything that these other stacks accomplish, then I'd prefer to just stick with it and not add all this other stuff (local load balancers, etc.).

So at the core of my question is this: Am I simply not seeing the "forest through the trees" here, and are there concrete reasons (available features/capabilities, etc.) as to why a Java dev would choose these stack-based solutions over the Orbitz client, or does the Orbitz client currently offer everything these other stacks do?

from consul-client.

Hoy! I'm the dev that answered on SO before the question was put in hold.

I forgot to mention an important point in my SO answer: we know for sure that one day something will fail, hence we chose to use the netflix stack to help us deal with that.

So our http clients rely on Hystrix that relies on Ribbon for software lb, that relies on Consul for server discovery.

I don't think you can "simply" do all that with the sole (awesome) orbitz consul client.

@rickfast : could you share your approach here?

from consul-client.

There's one layer above the basic Consul Client functionality that we have built internally at Orbitz. This is the layer that actually does the in memory caching of service registrations and load balancing. Ours is implemented as a Spring Boot autoconfiguration that every one of our services use. Each Mesos slave that our services run on has a Consul agent that is configured and managed by Chef, and the services just long polls the agent for registrations. These registrations are stored in memory, and are updated whenever the "watch" call to the local agent returns something new. The downside of this approach is that non-JVM services (which we have a few of) can't share this logic. Fortunately, there really isn't much logic to share. It hasn't been a major issue so far.

As for the Smart Stack stuff, I understand why they took the approach of externalizing discovery. We use Consul for more than just discovery. We went with the Consul approach because it helps with efficient service discovery, gives us a great monitoring solution (we have a number of our monitoring tools integrated with it), and it allows us to simplify environmental configuration of certain services across environments (e.g. we can use the same hostname across environments for static things like databases using Consul DNS). We're also moving things like feature flags to the Consul k/v store.

Hope that helps.

from consul-client.

This is starting to make more sense to me - thanks @rickfast and @looztra.

I think I'll need to set up both options and compare them side by side. To me these additional "layers" still are a fuzzy concept to me (caching/registrations, monitoring, failover, etc.) and once I see a smart stack-like setup compared to just using the "raw" Orbitz client, it should become pretty obvious as to why these additional tools/configs are a necessity.

Thanks for all the help here!

from consul-client.

@hotmeatballsoup I'm actually working on a screencast course for O'Reilly now on this exact subject (also Docker, Mesos, Monitoring, etc). Unfortunately, it won't be available til later this year :/

Feel free to come back with any questions

from consul-client.

Good to know! Please keep this issue (and maybe me :-) ) in mind when its publicly available!

from consul-client.