►
From YouTube: Solving Service Discovery by Richard Roger, Nearform
Description
Solving Service Discovery - Richard Roger, Nearform
The microservice architecture is a powerful way to structure large scale Node.js systems. Microservices bring many benefits, enabling rapid development, making continuous delivery easier, and making fine-grained scaling practical. But this architecture is a distributed system, and brings with it all the associated challenges of such systems, not least of which is the need for individual services to find each other. Deciding how to solving the service discovery problem is a key decision point for any architect building microservice systems.
A common approach is to use a service registry. Unfortunately service registries bring their own problems, such as ensuring consistency while scaling, or increasing deployment complexity with the need to run agents. All this could be forgiven, but for a greater sin - registries encourage strong coupling between microservices by providing a concept of serviceidentity. The very purpose of the registry, service discovery, is poisonous to one of the key benefits of microservices - that the system is dynamic and flexible.
There is a better way. Services can find each other dynamically, using gossip protocol algorithms. Highly efficient algorithms such SWIM (Scalable Weakly-consistent Infection-style Process Group Membership Protocol) mean that microservices can do away with service discovery altogether, relying instead on an constantly evolving, dynamic map of their local network. By pushing intelligence to the edges of the network, not only does this approach make failure detection orders of magnitude faster (no more waiting for heartbeats to timeout), but it also makes deployment much easier, as the network configures itself.
This talk will examine the use of the SWIM algorithm to build a Twitter clone in Node.js, one microservice at a time.
About Richard Rodger
Richard Rodger is co-CEO and co-founder of nearForm. He is an expert and thought leader in next-generation cloud and mobile technologies, with a current focus on Node.js and microservices. His book Mobile Application Development in the Cloud (Wiley, 2010) is one of the first major works on the subject.
Richard was previously CTO of FeedHenry, a mobile application platform provider that was acquired by RedHat for €63.5m in 2014.
Since Richard co-founded nearForm in 2011, the company has become the world’s largest Node.js and microservices consulting company.
Richard has long been an active member and influencer of the global open source software (OSS) community, specializing in OSS for enterprise. As CTO of nearForm, he has placed OSS at the heart of how the company works. Most recently, he created Seneca.js, a microservices tool kit for Node.js that is a key component of nearForm’s software development and delivery arsenal.
The Tao of Microservices (Manning), Richard’s new book, will be published in 2016.
A
Thank
you
very
much
so
I'm
talking
about
service
discovery
and
in
the
context
of
nodejs
micro
services-
and
this
is
the
put
up
your
hand,
question
how
many
of
you
guys
are
doing
no
js'
micro
services,
cool
okay.
So
this
is
said.
This
should
hopefully
give
you
some
interesting
ideas
about
some
of
the
approaches
that
my
company
near
Frome
has
taken
this
talk.
Is
it's
not
really
telling
you
how
to
do
things?
It's
more.
A
You
know,
here's
a
bunch,
here's
here's,
the
history
and
the
story
that
we
went
on
with
node
or
micro
services,
and
this
is
kind
of
one
of
the
places
that
we've
ended
up
and
we've
tried
to.
We've
used
a
whole
bunch
of
different
service
discovery
mechanisms
and
they
all
have
downsides,
but
we
like
to
think
that
we've
kind
of
found
an
approach
which
is
really
really
nice,
which
is
what
I'm
going
to
talk
about
today,
but
first
a
little
bit
of
discover
a
little
bit
of
philosophy.
A
This
is
the
flight
deck
of
the
space
shuttle
Atlantis.
The
cool
thing
about
the
Space
Shuttle
is
that
the
flight
software
is
some
of
the
most
perfect
software
ever
written.
It's
about
four
hundred
thousand
lines
of
code.
They
had
something
like
one
bug
per
release
and
each
line
of
code
costs
a
thousand
dollars,
and
it's
it's
pretty
much
as
close
as
humanity's
ever
come
to
software.
A
That
is
just
without
any
flaws,
but
the
reason
I
have
it
up
here
is
that
the
big
problem
that
we
see
in
enterprise
software
development-
and
that
is
a
theme
now
in
node
and
a
story
of
node,
because
we've
won
because
node
adoption
has
taken
off
in
a
really
really
big
way.
Lots
and
lots
of
big
companies
are
using
node.
A
node
is
exposed
to
the
same
flaws
that
all
of
the
older
platforms,
Java,
and.net,
etc.
Also
we're
exposed
to
enterprise
software
development
is
predicated
on
building
software.
That
is
this
perfect.
A
So,
though,
this
is
beautiful
software,
if
we
don't
learn
from
the
mistakes
in
the
past,
all
of
our
node
applications
end
up
trying
to
emulate
this,
and
we
end
up
in
the
same
place
as
we
did
before,
where
we
can't
build,
suffer
really
really
fast.
There's
a
different
vehicle,
a
different
aircraft
which
I
think
is
more
inspirational.
This
is
the
gossamer
albatross.
It's
the
first
human
powered
airplane,
the
first
human
powered
airplane
to
fly
across
the
English
Channel.
A
A
The
problem
was
being
able
to
iterate
on
the
design
of
the
aircraft
so
that
you
could
quickly
fix
problems,
so
he
came
up
with
a
system
of
aluminium
piping
and
Kevlar
and
wires
that
let
him
build
sometimes
three
different
aircraft
designs
a
day
and
once
that
system
was
in
place,
it
only
took
a
year
to
win
the
prize
and
I
feel
at
our
experience
of
notice.
That
node
is
this:
empowering
node
lets.
A
You
build
and
iterate
really
really
quickly,
and
the
node
module
system
in
particular
is
something
that
we've
seen
as
being
a
key
element
of
that.
But
one
of
the
challenges
that
you
get
in
larger
scale,
enterprise
development-
is
that
the
node
module
system.
Well,
it's
really
great
as
a
component
model
at
the
infrastructure
layer.
A
You
know
for
building
things
like
authentication
systems
or
templating
systems
or
stuff,
like
that.
It's
not
so
great
as
a
component
system
at
the
business
logic
layer
and
we
ended
up
moving
towards
a
model
where
micro
services
become
that
component
model.
But
that
then
engenders
all
of
the
other
questions
about
how
you
run
and
manage
micro
services
and
have
those
components
talk
to
each
other.
A
But
let's
not
forget
the
problems
we're
trying
to
solve
here,
because
node
has
now
seen
this
wonderful
adoption
and
if
you
saw
michael
rogers
keynotes,
you
see
all
these
wonderful,
huge
numbers.
We
are
in
grave
danger.
Node
development
is
in
grave
danger
of
ending
up
like
this,
so
this
is
a.
This
is
a
yak
in
himalayas.
A
Enterprise
development
is
like
this.
You
want
to
do
something,
and
you
end
up
having
to
do
a
series
of
increasingly
small
frustrating
things
that
end
up
with
having
to
shave
a
yak
in
the
Himalayas
to
get
anything
done.
This
is
the
place
that
note
is
going.
If
we
don't
do
something
about
it,
if
we
don't
adopt
a
method
of
building
software,
that
is
joyful,
and
this
is
what
we
want.
Enterprise
suffer
to
be
like
right,
I
love,
this
picture,
that
this
is
an
ad
for
Legos
from
1981
I.
A
A
A
That
is
the
key
thing
that
makes
components,
work
and
composability
is
something
that's
it's
quite
difficult
to
achieve,
because
the
way
that
components
talk
to
each
other
very
much
determines
how
come
how
composable
they
are.
So,
yes,
node
modules
are
fantastic,
but
if
you
think
about
it,
they're
not
very
composable.
Node
streams
are
extremely
composable
because
you
can
put
them
together
and
you
can
pie
between
streams.
A
They
have
three
key
kind
of
properties:
they're,
small,
independent
processes.
That
independence
means
you
can
deploy
them
independently,
which
is
the
important
thing.
They're
communicating
via
messages
and
I.
Think
it's
important
to
realize
that
level
of
abstraction
means
it
doesn't
matter
if
their
rest
calls
or
using
a
message,
bus
or
something
else.
A
And
then
you
get
all
these
wonderful
benefits
like
avoiding
technical
debt
because
they
never
get
very
big
and
you
avoid
complex
data
structures.
You
get
continuous
delivery
because
you
start
using
docker
and
kubernetes
and
all
that
good
stuff,
and
then
you
can
build
quickly
and
you
can
build
quickly
because
you
can
compose
them
together
and
I'm.
Sure.
A
lot
of
you
if
you've
been
using
micro
services
are
also
familiar
with
some
of
the
trade-offs
right
deployment
is
definitely
way
more
complicated
and
it
does
have
this
weird
programming
model.
A
The
last
speaker
was
showing
traces
of
flow
through
micro
service
systems.
You
not
only
have
to
understand
the
micro
service
that
you're
working
with,
but
you
also
have
to
understand
these
message
flows.
So
we
use
things
like
Zipkin
and
stuff
like
that
to
kind
of
understand
how
they
fit
together,
but
it
is
the
nature
of
this
type
of
system
that
you
have
to
think
at
a
level
above
your
programming
language.
So
it's
not
just
how
do
node
modules
communicate
with
callbacks
or
promises
or
streams?
A
You
also
have
to
think
about
these
message
flows
and
how
they
fit
together,
and
then
how
do
they
find
each
other?
How
does
one
service
find
another
service,
which
is
a
much
much
deeper
problem
and
a
much
trickier
problem
to
solve
than
deployment
which
is
essentially
just
getting
to
know
and
use
the
right
tools?
So
if
you've
done
a
computer
science
degree
after
three
or
four
years
of
study,
you
end
up
being
able
to
do
this.
This
is
the
final
result
of
studying
computer
science.
You
get
to
troll
two
boxes
that
communicate
with
each
other.
A
A
Coupling
somehow
a
has
to
know
about
be
somehow
a
has
to
know
the
identity
of
B
and
that's
the
core
weakness,
because
if
you
just
blindly
follow
through
on
a
rest-based
model-
and
you
build
those
and
microservices
you
end
up
with
a
distributed
monolith,
there
is
no
essential
difference.
Logically
between
one
object
instance
calling
another
object:
instance,
and
all
the
issues
of
dependency,
injection
and
design
patterns
and
one
process
on
the
network
calling
another
process
on
the
network,
because
you
still
depend
on
this
notion
of
identity.
You
still
have
this
coupling.
A
This
is
the
world
that
we
want.
We
want
a
world
where
a
sends
out
a
message,
and
it
doesn't
know
who
implements
the
other
side
of
the
message.
Who
does
the
action
and
B
receives
messages,
but
it
doesn't
know
who
it's
receiving
them
from
and
now
you
have
decoupling,
and
now
you
can
change
a
or
deploy
multiple
instances
of
a
and
do
the
same
with
B.
A
This
is
the
world
that
we
want
to
get
to.
This
is
sort
of
the
promised
land.
This
is
the
power
the
micro
service
is
supposed
to
get
us
give
us,
but
if,
in
your
micro
services,
you're
doing
HTTP
rest
calls,
you
don't
get
this,
you
get
tight
coupling
and
you
end
up
with
a
mess.
A
lot
of
a
lot
of
people
have
ended
up
in
that
place.
We've
done
it
ourselves.
So,
as
I
said,
this
is
sort
of
a
story.
A
We've
made
all
these
mistakes
as
well.
So
how
can
you
do
service
discovery
right?
A
that's
the
sentiment
it
should
be,
but
it
has
to
know
where
B
is
and
if
B
has
a
strong
identity
for
a.
If
it's
a
specific
network
location,
that's
bad!
So
can
you
reduce
the
strength
of
the
coupling
those
different
ways,
different
approaches?
You
can
take
to
service
discovery.
We've
done
all
of
these.
Some
are
worse
than
others
for
coupling,
so
you
can
bake
in
configuration
into
docker
images.
Everything
is
immutable.
A
You
can
have
intelligent
load,
bouncing
how
that
one
works
quite
nicely
right.
So,
instead
of
talking
to
a
specific
micro
service,
you're
talking
to
load
balancers,
maybe
they're
agents
on
each
box,
but
there's
all
sorts
of
different
ways.
You
can
play
that
one.
You
can
have
service
registries
right,
so
who's
using
a
service
registry,
not
to
okay,
Wow,
okay
service
registries.
Don't
work
in
production.
A
A
A
A
Now,
let's
return
to
the
notion
of
components
this
this
is
book
called
507
mechanical
movements,
which
has
been
digitized
there's
a
website.
You
check
it
out
on
Google.
Some
of
these
are
animated,
which
I
find
again
really
inspirational,
because
these
are
physical.
These
are
mechanical
components
but
they're
based
on
physical
principles,
and
if
you
can
identify
some
principles
that
let
you
get
components
talking
to
each
other,
then
you
can
move
forward,
and
in
the
years
they've
been
we've
been
working
on
this
stuff.
We've
kind
of
identified
two
key
principles.
A
Transport
independence
is
simply
it
shouldn't
matter
whether
it's
a
message,
bus
or
rest
or
whatever-
the
mechanism
whereby
a
message
gets
from
one
place
to
another
should
not
matter
so
in
your
code.
You
need
to
have
some
sort
of
abstraction
layer
that
abstracts
that
away,
so
that
you
aren't
making
a
decision.
We
must
use
rest
to
make
that
decision
is
to
jump
ahead.
To
far
pattern.
Matching
is
how
you
get
away
from
this
notion
of
identity.
A
You
send
out
a
message
and
the
micro
services
that
care
about
it
should
respond
in
a
in
an
idealized
world.
Every
micro
service
sees
every
other
every
message
and
then
decides
to
respond
to
the
messages
that
it
cares
about,
but
obviously
doesn't
work
in
practice,
which
is
where
we
come
in
to
using
some
interesting
algorithms
to
solve
this
problem
in
practice.
This
is
what
it
looks
like
conceptually
right,
microservice
a
is
sending
it
a
message:
let's
call
it
the
King
of
Hearts
and
microservice
be
for
heart
cards.
A
It
listens
to
the
heart
suit,
which
means
that
whatever
heart
card
that
a
sends
out
B
will
respond
to
it.
It's
just
a
kind
of
a
conceptual
metaphor.
This
is
the
way
that
pattern
matching
works.
If
I
send
out
a
user
login
message,
it
doesn't
matter
what
type
of
user
it
is
an
employee,
your
contractor
or
a
manager.
The
login
service
recognizes
that
it's
a
login
message
because
of
certain
properties
of
that
message.
It
doesn't
matter
what
they
are.
It
doesn't
matter.
A
Services
can
then
have
zero
knowledge
of
other
services
using
this
pattern
matching
approach,
but
to
make
this
work
in
practice,
you
need
to
use
a
peer-to-peer
approach
and
there's
multiple
different
ways
of
doing
this.
I
mean
you
can
have
a
complete
broadcast
of
all
the
information
to
every
micro
service
that
doesn't
scale,
but
because
people
have
been
trying
to
solve
that
problem.
A
couple
of
interesting
algorithms
have
arisen.
A
For
example,
if
you
want
to
do
scale,
you
just
add
new
instances
of
B
and
your
little
abstraction
layer
can
round-robin
between
them.
If
you
want
to
do
things
like
pub/sub
well,
I
can
add
other
micro-services
that
do
other
things
that
also
listen
for
these
patterns.
Again,
it's
very
very
simple:
to
implement
that
in
the
abstraction
layer
you
don't
need
any
extra
infrastructure
as
part
of
my
component
model.
I
can
do
things
like
moving
from
a
general
implementation
to
a
specific
one.
I
can
progressively
add
features
to
my
system.
A
In
this
case,
B
was
the
first
micro
service,
I
wrote,
but
then
I
have
C
which
handles
the
ace
cards.
It's
a
special
case,
so
I
add
features
to
my
system
by
adding
new
micro-services
and
finally,
who
gets
composability
a
was
talking
to
be
originally,
but
then
I
can
inject
C
in
the
middle
of
that
conversation
and
C
can
do
caching
or
it
can
add,
a
permissions
check
or
auditing,
or
something
like
that.
A
A
still
thinks
it's
talking
to
B,
but
now
see
is
added
a
layer
above
that
business
logic,
and
this
is
where
you
get
composability
and
I
believe
I'm
now,
just
exactly
out
of
time.
So
if
you
want
to
see
this
in
a
node
context,
if
you
want
to
see
an
actual
system
and
code
and
how
this
fits
together,
we've
written
a
little
Twitter
clone
in
about
14
micro
services
that
uses
these
ideas,
pattern,
meshing
and
transport
independence
and
the
composability.
A
B
A
So,
in
a
request
response
model,
where
a
is
expecting
a
response,
that's
up
to
a
so
a
could
handle
that
they
could
just
take
the
first
response,
say
I'm
done
and
ignore
everything
else
or
in
other
models.
They
can
say.
Okay,
I've
got
five
responses
now,
I'm
gonna
rank
them
or
maybe
use
the
best
one.
But
it's
up
to
eight
great
thank.