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

Demo

Learnings

Technology doesn't matter

Embrace change

Integrate with your environment

Questions?

Thank you!

 

Image attributions: