A journey through the world of

Service Discovery

Team Black

• SaaS eCommerce company
• Business model B2B2C
• > 140k shops worldwide

...and, btw, we're hiring

If you're interested: contact Serena Tansil(or anyone else from ePages)

What is our use case?

The existing ePages software stack:

• Implementation language: Perl
• Running in monolithic application server
• Features provided as modules

What is our use case?

Goals for a future architecture/implementation:

• Modern architecture
• State-of-the-art software stack
• Easily scalable across teams

Why Service Discovery?

• Service instances come and go
• Routing requests to corresponding instances
• Balance load dynamically between instances

What's on tonight?

• Different implementations of Service Discovery
• Pros & Cons (from our point of view)
• Lessons learned

The journey begins...

Greenfield prototype

• No preset technology stack

First choice: Netflix Eureka

• Used several components of Netflix OSS
• Netflix being a well-known early adaptor
• Fulfilled basic requirements

Eureka at a glance

Service Discovery, i=1

Wrap-up

• Eureka simply works
• Easy to get started
• Requires code changes

Stony passage

K.I.S.S.

• Keep service discovery out of code
• Deployment with Docker containers

Pivot to Consul

• Server-based load balancing
• Agent-based registration

Consul distilled

Add-on: Registrator

Service Discovery, i=2

Wrap-up

• Fulfills all (currently known) requirements
• Fully automated with Registrator

Relieving the burden

New ingredient: Kubernetes

• Orchestration for Docker containers
• Each "pod" addressable with its own IP

Kubernetes services & KubeDNS

Streamlining

• Service Discovery duplicated
• Additional runtime dependencies
• Additional components to be managed

Service Discovery, i=3

Wrap-up

• Reduced complexity
• No add-on infrastructure

Broadening the view

Being too focused

• System works well for full environment
• .. but hardly usable in developer setup

Side step:Spring Cloud Discovery

• Single annotation plus some configuration
• Re-introduces additional infrastructure
• Re-introduces discovery-specific client-side code

Ribbon

• IPC library with HTTP support, including REST-style
• Optionally provides client-side load balancing
• Highly configurable, both dynamically and statically

Service Discovery, i=4 - Kubernetes

Service Discovery, i=4 - dev

Wrap-up

• Works in development & managed environments
• No additional infrastructure & code

Learnings

Technology doesn't matter

Embrace change

Integrate with your environment