►
From YouTube: Microservice Developer Experience
Description
Peter Elger, nearForm
Whilst micro-service based architectures promise many benefits in production, such as rapid continuous deployment cycles, current developer tools are lagging behind. Irrespective of platform our current toolchains are very much oriented around the construction of monolithic application stacks and are unwieldy and cumbersome when applied to micro-service based systems. This talk will demonstrate a dynamic and responsive developer toolchain
for micro-services that is more aligned with this architectural style, with live coding examples and deployment through to staging.
This talk will cover the tools that nearForm use to develop micro-services in the wild, something we've discovered and iterated on over the last three years.
A
Some
of
the
challenges
that
we
faced
in
that
and
some
tooling
that
we've
developed
to
help
us
in
those
endeavors,
so
first
off
I,
guess
to
say
micro
services,
every
probably
probably
come
across
the
term
now
has
an
idea
of
what
micro
services
are,
maybe
even
developing
in
that
type
of
environment,
that
type
of
architecture
and
not
a
new
concept.
The
idea
of
small
components
that
fit
together
well
has
been
around
for
a
long
time.
A
The
idea
of
having
small
components
that
are
easily
understood,
easy
to
reason
about
in
isolation
is
generally
a
good
one,
supporting
kind
of
a
rapid
iterative
deployment
model
and
it's
an
architectural
style.
That's
particularly
suited
to
2-node
when
we
first
started
off
building
systems
in
node
way
back
in
2011
right
at
the
start,
around
zero
four
zero.
We
found
that
the
way
that
node
has
its
module
system,
the
way
that
it's
put
together,
naturally
drove
us
to
write
micro
service
based
systems.
A
So
we,
the
first
system
we
actually
put
into
production,
was
one
where
we
had
a
number
of
small
processes
that
are
all
cooperating
with
each
other
to
deliver
the
system.
Now.
The
time
we
didn't
know
that
was
a
micro
service
system.
The
term
had
yet
to
be
coined,
but
it
was
just
interesting
to
observe
as
the
rising
popularity
that
architecture
has
taken
place,
how
it
suits
very
well
the
kind
of
node
ethos.
So
that's
all
awesome.
Okay,
but
there
are
challenges
right
shall
Hal.
A
If
anyone
here
has
got
experience
with
developing
micro
service
systems,
you
know
that
it
can
be
difficult
to
run
these
these
systems
in
development.
That's
fine
about
all
the
things
that
the
benefits
that
they
give
you
in
production,
but
in
development
it
can
be
hard
to
run
all
of
these
all
of
these
processes.
How
do
you
run
an
integration
on
your
local
system?
So,
there's
a
number
of
trade-offs.
There
right
micro
services
give
you
small
units
of
code,
very
easy
to
reason
about
in
isolation,
they're
easy
tests
and
they
support
that
rapid
development
deployment
model.
A
A
The
code
is
highly
coupled
and
it
gives
you
risky
deployments,
however,
in
development.
If
you
want
to
run
your
your
micro
services,
you've
got
a
you've
got
to
deal
with
multiple
processes.
You've
got
a
lot
of
processes.
They've
got
to
run
at
one
time,
even
if
you're
running
just
the
subset
of
the
system.
So
it's
trickier
to
apply
our
standard
kind
of
tooling
and
debugging
approaches
to
micro
services,
whereas
with
moralists,
of
course,
it's
easier
to
run
a
system
in
development.
A
It's
typically
a
single
process
and
a
lot
of
tooling
is
is
oriented
towards
doing
that.
So
what
are
our
options?
What
can
we
do
about
this?
Well,
one
approach
is
just
develop
our
services
in
isolation,
they're,
easy
to
reason
about
they're,
easy
to
unit
tests.
We
can
get
good
code
coverage
and
then,
let's
maybe
have
some
kind
of
staging
system
or
even
production,
push
our
services
onto
that
staging
system
and
do
the
integration
there.
So
have
one
integration
point
and
that's
an
approach
that
can
work.
Another
approach
is
to
develop
some
custom
scripts.
A
So
we've
done
this
on
a
number
of
occasions
where
we
have
a
project,
we've
got
a
bunch
of
services.
We
need
to
run.
We
want
to
do
an
integration
test.
We
want
to
test
part
of
the
system
operating
on
our
local
development
machines.
So
we
we
write
a
bunch
of
scripts
and
those
spin
up
the
processes
on
various
ports
and
allow
parts
of
the
system
to
operate
and
allow
us
to
run
debugs
or
whatever
it
is.
We
want
to
do
as
we're
developing
the
system.
It
can
work.
Well,
there's
overhead!
A
A
Another
approach,
of
course,
is
to
use
containers,
so
obviously
docker
has
become
incredibly
popular
and
is
it
is
a
very
nice
fit.
It
fits
well
with
a
whole
micro-service
paradigm,
where
you
have
single-process
running
in
a
single
container.
You've
got
these
units
that
you
can
deploy
and
you
can
use
those
on
in
development
as
well,
particularly
using
tools
like
docker
compose,
which
allow
you
to
specify
how
your
services
fit
together
in
us
in
a
single
configuration
file.
Allow
you
to
spin
all
of
those
processes
that
managed
by
docker
and
run
your
system.
A
A
Also,
there
are
some
environmental
differences
when
you're
trying
to
run
in
this
mode.
If
you,
if
you're
using
compose
or
docker
on
a
Mac
or
on
a
Windows
machine,
you'll,
know
that
there's
actually
a
VM,
that's
booted
up
under
the
hood,
and
your
containers
run
on
that.
So
you're
now
dealing
with
differences
between
running
on
localhost
and
having
another
IP
address
to
talk
to
and
also
setting
up
debugging
environments
can
be
a
little
challenging.
A
So
given
all
of
that,
what
we've
done
is
we've
taken
all
of
the
knowledge
that
we
we
built
up
on
these
projects
to
create
a
bit
of
open-source
tooling
to
help
us
develop
micro
services
more
efficiently.
The
codes
up
on
get
Herberger
check
it
out
and
we
had
really
a
couple
of
a
couple
of
goals.
One
we
were
building
a
huge
one
was
to
give
us
a
tool
that
generated
a
micro
server
scaffolding
for
us.
A
A
We
see
it
that
might
not
be
your
best
practice,
but
it's
the
way
that
we're
doing
at
the
moment
and-
and
the
second
thing
was
to
provide
a
runtime
environment
for
micro
services
to
allow
us
to
do
rapid
development
and
reduce
the
friction
between
containers
and
running
processes.
So
we
want
to
be
able
to
do.
Is
we
want
to
be
able
to
run
process
processes?
Debug
them
make
changes
to
them?
Have
those
changes
be
reflected
very
quickly,
but
also
take
advantage
of
container
technology
to
run
our
infrastructure
databases
and
so
on?
A
So
I'm
gonna
demonstrate
that
to
in
a
moment,
just
a
quick
word
on
the
systems
that
we
kind
of
develop.
Usually,
we
use
a
combination
of
happy
and
Seneca
in
when
we're
developing
micro
service
systems,
both
both
awesome
projects.
If
you
don't
know
them,
you
should
go
check
them
out.
We
use
happy
for
our
for
the
kind
of
front
and
API
layers
and
then
Seneca
for
micro
service
construction.
The
Seneca
allows
you
to
build
a
like
a
pattern:
language
for
your
micro
services,
so
check
it
out
and
github
you'll
get
a
little
detail
on
it.
A
So
this
is
a
type
of
system
I'm
talking
about.
We
have
a
usually
a
return
to
the
system,
so
it's
an
API
layer
and
then
some
form
of
service
discovery
or
overlay
network
to
allow
us
to
connect
into
our
services.
And
then
a
bunch
of
services
might
be
kind
of
direct
response,
so
there
HTT
base
HTTP
base
and
maybe
some
some
more
synchronous
services
are
running
connected
over
a
bus,
maybe
rabbitmq,
0
and
Q,
or
something
like
that.
The
services
themselves
make
taking
care
of
their
own
world
of
data
and
then
potentially
consuming
legacy.
A
A
Okay,
so
and
I'm
an
empty
folder
here,
so
I'm
just
going
to
run
fuge
generate
system
and
under
that's
just
asking
me
with
transponder
one
of
you
so
I'm
gonna
just
take
the
default,
which
is
HTTP
under
the
hood.
Now.
What
that's
doing
is
using
an
spinning
up
a
number
of
yeoman
generators
to
put
a
system
in
place
for
me,
so
I
can
now,
if
I
flip
back
I'll
show
you
this
we'll
leave
that
running
just
for
a
second.
This
is
what
I'm
going
to
get
at
the
end
of
that
command
running.
A
It's
going
to
give
me
a
front
end
and
a
couple
of
services
in
a
proxy
layer.
I'll
talk
a
little
bit
more
about
that
in
a
moment.
So
it's
going
to
create
a
few
directories
for
me,
it's
going
to
create
a
huge
folder
which
has
some
control
files
in
it,
a
couple
of
services
and
then
a
site
directory,
which
is
where
my
my
front-end
API
layer
lives
in
each
of
those.
A
It's
going
to
give
me
a
docker
file
and
then
it's
going
to
hook
those
together
with
a
docker
composed
file,
so
we're
using
the
standard,
dhaka,
syntax,
but
few
G's
introspecting
those
to
run
the
system
and
allow
us
to
run
processes
which
we
can
debug
in
the
standard
way
or
containers
or
a
mixture
of
both.
And
it's
allowing
us
to
run
that
mixture
of
containers
and
processes
that
gives
us
a
rapid
development
environment.
A
A
Okay,
so
fuse
has
now
introspected
are
composed
file.
It's
looked
at
the
daka
files
and
it's
figured
out
that
it's
got
to
run
to
services
in
the
front
end.
So
now,
I
can
start
those
up
and
my
systems
up
and
running
so
I've
generation
of
micro
service
system
to
services
up
and
running,
and
now
we
can
go
and
test
that
out.
If
we
just
go
to
chrome
here,.
A
A
So
next
I'm
going
to
add
I'm
going
to
add
another
service
into
the
system,
so
I'm
going
to
use
fuse
to
generate
a
second
service
and
when
I
do
that,
my
system
is
going
to
look
like
that
exactly
as
before,
but
with
an
additional
service
that
I
can
now
go
and
edit
make
changes
to
and
make
it
do
something
useful.
Okay.
So
let's
pop
back
here
and
I
will
do
a
fuge
I.
A
A
You'll
see
there's
now
another
service
available
and
I
can
start
that
up
as
before
and
I've
got
an
additional
service
now
running.
Okay.
So
that's
fine!
It's
it's
not
that
interesting,
because
it's
a
skeleton
so
let's
go
and
let's
do
something
a
little
more
interesting
with
it.
Let's
have
some
infrastructure,
so
we're
going
to
add
in
a
MongoDB
database
container
and
to
do
that.
A
A
Here
now,
you'll
see
that
in
my
compose
file,
I've
now
got
a
container
linked
in
with
the
image
tag,
my
three
services
and
my
front
end
and
if
we
just
go
and
have
a
quick
look
under
my
service,
one
code
you'll
see
that
I've
got
I've
added
in
to
my
my
my
Seneca
handler
here
some
code
to
consume,
to
talk
to
it's
not
doing
anything
that
interesting.
It's
just
writing
a
record.
In
every
time
the
service
gets
called
and
it's
returning
the
count
plus
an
offset
and
again
that's
being
called
through
this
API
layer
here.
A
A
So
again,
huge
huge
sees
my
additional
containers,
but
now
what
it's
going
to
do?
You'll
see
that
it's
taking
it's
got
listed
there
as
type
docker
and
the
others
is
type
process.
So
what
future
is
going
to
do
now
is
going
to
run
as
a
container
using
the
the
docker
VM
that's
on
this
system
and
then
it's
going
to
proxy
those
connections
across.
A
A
A
A
A
You'll
notice
now
that
what's
happened
is
that,
because
fuge
is
watching
that
process
its
restarted
service
one.
So
there's
been
a
change
to
the
service
service.
One
has
been
restarted
by
fuge,
so
my
system
is
now
completely
in
sync,
with
the
changes
that
I've
made
and
also
able
to
talk
and
proxy
through
to
my
container.
Are
that
that's
running
in
the
VM
so
we'll
just
we'll
just
give
out
a
test
if
I
now
come
over
here
and
hit
action
to
no
change
action,
one
okay!
Now
my
count
is
minus
the
offset
now.
A
A
A
A
A
So
the
the
point
of
all
of
this
is
to
have
a
tool
that
allows
us
to
develop
these
micro
service
systems
and
give
us
a
bunch
of
convenience
methods
to
start
and
stop
services,
control
them
all
without
having
shell
Hal
and
allow
us
to
interoperate
between
containers
and
and
Microsoft
and
and
processes.
So
that's
great,
if
you're
doing,
if
you're
doing
so,
what
I'm
going
to
do
now
is
just
stop
the
system.
A
So
as
an
example,
I've
taken
a
system
that
we
use
for
training
purposes
called
nodes
ooh,
and
no,
so
it
has
a
few
more
bits
and
pieces
in
it.
Okay,
what
knows?
Who
does?
Actually
it's
interesting?
You
can
have
a
look
at
nodes.
Ooh
calm
for
a
live
example.
Is
it
does
kind
of
PageRank
on
node
modules,
so
it
goes
off
and
it
has
a
bunch
of
services
that
go
and
look
at
github
NPM,
and
then
it
index
those
and
do
a
bit
of
computation
and
return
the
result.
A
So
in
order
to
retrofit
fuge
on
two
nodes
you
to
allow
us
to
run
it
without
having
multiple
shell
processes
everywhere,
all
we
need
to
do
is
modify
our
composer
llaman
or
create
a
compose
file
for
it.
The
references
each
of
the
components
and
what
I'm
going
to
do
in
this
instance
is
run
the
system
using
a
mixture
of
docker
compose
and
fuge
and
I'm
getting
close
to
time.
So
I'm
just
going
to
go
and
do
this
very
quickly.
A
And
now
you
can
see
the
fuge
understands
that
it's
not
managing
those
docker
containers,
but
it
is
managing
the
processes.
You'll
see
that
it's
proxying
across
to
Redis
elasticsearch
influx
and
beanstalk
d,
so
I
can
now
start
all
those
processes.
Up
and
now
I've
got
my
mixture
of
containers
being
run
on
the
one
hand,
which
gives
me
the
convenience
of
downloading
and
running
containers
from
docker,
along
with
the
ability
to
run
my
processes,
run
debug
and
manage
them
in
a
nice,
clean
environment
and
I.
A
So
so
just
to
wrap
up
then
in
summary,
developing
micro
services
is
a
challenge.
Tooling
can
help
fujas
one
of
the
tools
that
we've
developed,
we're
using
it
now
on
a
couple
of
projects.
It's
it's
all
open
source.
So
we'd
love
you
to
go,
take
a
look
at
it.
If
you're
working
in
micro
services
or
in
a
micro
service
environment,
please
check
it
out
any
any
comments
or
or
pull
requests
even
would
be
much
appreciated.