Recommended approach for Eureka across life cycle environments (e.g. dev, test, production)

269 views
Skip to first unread message

erich.o...@gmail.com

unread,
Feb 25, 2015, 9:02:03 PM2/25/15
to eureka_...@googlegroups.com
Hi, I'm interested in using Eureka to support a services infrastructure. I am curious about best practices/patterns in terms of its usage in the development life cycle. Would you typically use a single set of Eureka servers to serve all environments, and just manage the service references via naming, or do you typically have a distinct dev, test and production Eureka servers?

Tomasz Bak

unread,
Feb 26, 2015, 11:27:11 AM2/26/15
to eureka_...@googlegroups.com
I would recommend having separate Eureka cluster at least for prod. This will make upgrades easier for you, as you can try out new release in test/dev environment prior to rolling them out in prod. But of course single cluster will do as well. One way of separation would be to agree on naming convention for VIPs (server groups), with suffix differentiators (_prod, _dev, _test).

On Wed, Feb 25, 2015 at 6:02 PM, <erich.o...@gmail.com> wrote:
Hi, I'm interested in using Eureka to support a services infrastructure.  I am curious about best practices/patterns in terms of its usage in the development life cycle.  Would you typically use a single set of Eureka servers to serve all environments, and just manage the service references via naming, or do you typically have a distinct dev, test and production Eureka servers?

--
You received this message because you are subscribed to the Google Groups "eureka_netflix" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eureka_netfli...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Nitesh Kant

unread,
Feb 26, 2015, 1:45:08 PM2/26/15
to eureka_...@googlegroups.com
I think the biggest reason for having different eureka deployments per deployment would be for failure isolation. eg: a bad client in test, should not bring down prod.

On top of that, having isolation built via best practices like different vip suffix, etc, is fragile. It can lead to accidental cross-environment interaction.

erich.o...@gmail.com

unread,
Feb 26, 2015, 5:28:06 PM2/26/15
to eureka_...@googlegroups.com
Yeah, separation was the direction I was leaning... I was just wondering since it's almost DNS-like for services. Thanks a lot guys!
Reply all
Reply to author
Forward
0 new messages