►
From YouTube: Go + Microservices = Go Kit [I] - Peter Bourgon, Go Kit
Description
Go + Microservices = Go Kit [I] - Peter Bourgon, Go Kit
Go is emerging as the default programming language for cloud-native tooling and infrastructure. But it's also a perfect language for implementing your business logic—with a little bit of help! This talk introduces and deep-dives into Go kit, an independent open-source toolkit for writing microservices in Go. We first identify the defining characteristics and challenges of working in a cloud-native architecture, and then build a production-grade, highly idiomatic Go kit microservice to address all of the concerns. Special attention is paid to instrumenting with Prometheus, log storage with Fluentd, distributed tracing with OpenTracing, and deploying via Kubernetes — all of which work out-of-the-box.
About Peter Bourgon
Peter Bourgon is a distributed systems engineer who has seen things. He is the author of Go kit, a toolkit for writing business microservices in Go.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
A
That's
logo,
I,
don't
know
why
my
name
is
Peter
I,
it
doesn't
matter
who
I
am
you
can
decide
for
yourself
if
I'm
trustworthy
or
not
at
the
end
of
the
talk,
but
you
can
follow
me
I'm.
That's
my
Twitter!
Okay!
This
talk
is
about
so
cloud
native
con
right.
What
is
the
cloud
native
application?
It's
like
all
these
things
that
has
all
these
properties,
and
one
of
them
importantly
I
guess-
is
that
it's
kind
of
micro
service
oriented.
A
So
this
talk
in
this
talk,
I
want
to
convince
you
that
go
is
a
good
language
to
write
your
micro
services
in
and
I
think
go
kit
will
help
and
if
you
want
to
add
use
it
at
the
end
of
the
talk,
that's
great
I
support
that,
but
ultimately
I'm
not
really
pushing
go
kit.
It's
just
a
means
to
express
a
few
ideas
which
I
think
are
helpful,
so
maybe
it'll
help.
Maybe
it
won't.
If
you
don't
end
up
using
it,
that's
no
problem
for
me:
I'm,
really
more
motivated
to
get
you
all
to
consider.
A
Go
for
your
business
logic,
I!
Guess!
Ok!
So
on
that
note
like
what
is
go,
I'm
curious.
Have
we
all
raise
your
hand
if
you'd
like
at
least
dabbled
and
go
a
little
bit
right?
Ok,
how
many
of
you
have
like
done
serious,
like
production
work
and
go?
Ok,
yeah
still
quite
a
few
people,
that's
great
so
for
the
maybe
very
few
of
you
who
need
a
bit
of
an
introduction
to
the
language
like
what
it
is
where
it
sits
and
like
the
language
matrix,
I
thought.
I'd
take
a
few
minutes
to
kind
of
contextualise.
A
Everything
for
us
go
was
created
by
three
engineers
who
happen
to
be
employed
at
Google.
The
the
Apocrypha
is
that
it
was
designed
to
solve
at
a
language
level
problems
that
the
Google
engineers
were
kind
of
encountering,
and
this
is
as
far
as
I'm
aware,
the
first
recorded
piece
well
recorded.
Maybe
I
guess
I
could
have
faked
it,
but
I
promise.
A
I
didn't
the
first
recorded
piece
of
information
detailing
the
first
ideas
behind
go
the
language
and
it
is
an
email
sort
of
meeting
minutes
dated
23
September
2007,
which
is
a
really
long
time
ago,
if
you
think
about
it
in
in
this
world,
from
Robert
Griesemer
to
Rob,
Pike
and
Ken
Thompson,
and
the
subject
is
prog
line,
discussion
and
I
guess
this
is
the
first
meeting
when
they
decided
to
go
over
what
would
some
points
that
would
eventually
become
the
go
language
so
starting
point.
Seed
fix
from
all
these
flaws.
A
Remove
crud,
add
a
few
missing
features
and
you
can
kind
of
find
this
on
the
internet
a
few
places,
so
you
can
kind
of
get
a
sense
of
where
they
were
coming
from
they
like
see,
but
they
felt
that
maybe
it
was
not
up
to
the
task
of
modern,
modern,
modern
problems,
so
some
properties
of
go
I
mean
there's
many
of
them.
These
are
the
ones
that
I
find
the
most
interesting.
It
is
a
statically
typed
language,
it
is
a
compiled
language
and
one
of
the
key
things
is
that
it
is.
A
The
compiler
should
be
very,
very
fast,
and
a
lot
of
decisions
were
baked
into
what
the
language
is
and
what
features
it
supports
in
order
to
support
this
very
important
property.
So
the
build
test
run
cycles
are
very
quick
and
go.
It
produces
native
binaries
for
a
huge
number
of
platforms
and
you
can
cross,
compile
them
very
easily.
It's
just
setting
an
environment
variable.
So
if
you
have
go
installed
on
your
Mac,
you
can
produce
PowerPC
binaries.
You
can
produce
amd64
Linux
binaries,
no
problem.
A
It
is
garbage
collected
language
which
was
decided
very
early
to
be
an
important
usability
kind
of
handle.
This
does
mean
that
it's
not
totally
suitable
for
a
lot
of
the
things
that
C
is
suitable
for,
but
on
balance
the
go
authors
decide.
This
is
the
right
move
for
the
current
sort
of
epoch
that
were
in
it
looks
like
see.
A
A
I
think
it's
a
breath
of
fresh
air
from
what
I
would
call
like
kitchen-sink
languages,
which
is
like
the
languages
that
say,
oh
there's,
a
feature
that
sounds
good
there's
another
feature
that
sounds
good
and
to
me
like
the
canonical
example
of
this
is
Scala.
It
is
a
language
of
every
paradigm
which
I
guess
you
it's
nice
to
have
that
sometimes,
but
for
me,
I
really
struggle
to
get
productive
in
it.
A
Go
has
an
in
composed
of
simple
sort
of
orthogonal
features
that
when
you
stick
them
together,
they
don't
have
surprising
results
and
to
me
the
ultimate
like
counter
example
to
this
would
be
sort
of
the
node
ecosystem,
where
there's
lots
of
features
that
are
kind
of
thought
and
developed
in
isolation
and
when
you
sort
of
apply
them
together.
Well,
we've
all
seen
the
Gary
Brent.
A
So,
for
example,
there
is
only
one
way
to
do
four
loops,
there's
no
map
or
filter,
and
so
when
you
write
idiomatic
go,
it
tends
to
be
pretty
efficient,
like
not
quite
see
but
pretty
close.
And
to
me
this
stands
in
contrast
to
a
lot
of
dynamic
scripting
languages
like
Python
and
Ruby,
where
to
eke
out
performance.
A
You
have
to
do
things
non
idiomatically
very
often
go
has
predictable
runtime
behavior,
and
this
means
that
when
you
deploy
a
go
application,
there's
not
a
lot
of
knobs
to
turn
that
can
change
dramatically
the
way
it
performs
to
me.
This
is
standing
in
stark
contrast
to
all
the
jvm
languages
which
require,
in
my
experience,
like
quite
specialized
knowledge
to
operate
a
skill
and
finally
go
has
a
familiar
heritage.
Syntax
and
sort
of
basically
an
imperative
programming
paradigm,
which
is
familiar
to
most
of
us
I.
A
Guess
there
are
things
you
can
do
you
can
program
it
in
a
slightly
functional
way.
You
can
program
it
and
I
kind
of
object-oriented
way,
but
in
general
it's
like
pretty
straight
line
code
and
that's
a
great
draw.
It
makes
it
easy
to
learn
easy
to
spin
up
new
developers
on
and
in
that
way
sort
of
stands
in
contrast
to
languages
like
Haskell
and
maybe
elixir
to
some
degree.
A
So
when
we
talk
about
languages,
we
often
like
to
use
words
like:
oh,
it's
simple
right
or
it's
non
magical.
What
do
we
mean
by
these
things?
It
turns
out
these
things.
These
words
are
kind
of
like
weasel
words
right.
So
when
you
say
simple-
and
this
is
a
quote
I
found
on
the
lobsters
what
ones
that,
when
you
say
simple,
what
it
actually
means
is
totally
dependent
on
your
context
and
in
go
simple
means
and
I'll.
Try
to
read
this
here.
A
That
operational
interpretation
of
a
program
fragment
is
unique,
straightforward
and
never
in
question
after
you've
read
the
code.
So
this
means,
when
you
read
a
piece
of
go
code.
You
know
exactly
what
the
CP
is
going
to
do
to
it
some
order
of
approximation
from
this
no-nonsense
point
of
view.
Higher-Order
functions
are
already
suspicious
and
fancy
concepts
like
closures,
transducers
and
Haskell's
lenses
and
traversals
are
complete.
Abominations
I
wouldn't
go
quite
that
far,
but
I
think
this
gets.
It
goes
idea
of
simplicity.
A
What
do
you
call
this
thing?
A
post
on
hacker
news
about
the
idea
of
no
magic
or
magic
free
language,
and
the
key
quote
here
is
that
a
bit
of
code
is
magical
when
it's
not
sufficient
to
examine
the
tokens
that
the
code
is
composed
of
and
go
back
to
the
static
textual
definitions
of
those
tokens
to
understand.
What's
going
on.
A
So
if
you
look
at
a
piece
of
code-
and
you
read
all
the
things
that
should
be
enough
to
figure
out
what
that
code
is
doing
and
if
that's
not
true,
then
your
code
is
magical,
so
in
Python
Desk
pseudocode,
this
stuff
on
the
left
is
magic.
If
this
code
runs,
if
you
can
s
dot,
where
did
this
method
come
from
then
like?
How
did
that
happen
right
and
in
Python?
You
can
do
this
right
and
in
Ruby
you
can
do
this.
It's
called
like
monkey
patching,
not
magic.
A
To
subvert
your
understanding,
and
at
least
for
me,
I
love,
this
I
love,
it
I
love
it
I
love
it.
Ok,
another
sort
of
design
principle
at
of
go
was
captured
in
this
talk
by
Rob
plank.
It
is
a
language
that
was
design
in
the
service
of
software
engineering,
and
this
also
gets
at
dislike
industrial
bent
right.
A
A
Why
go
is
not
good
or
three
months
of
go
from
a
high
schoolers
perspective
and
they
make
very
negative
conclusions
and
I
think
that's
understandable,
because
in
a
large
way
goes
saying
all
these
programming
language
theory,
things
that
have
been
developed
and
and
reified
over
the
last
10
20
30
years.
That's
fine!
We
can
take
some
lessons
from
them,
but
we
don't
need
to
build
on
them
so
directly,
and
so
you
get
classic
reactions
like
this.
A
In
fact,
there's
an
entire
git
repo
of
articles
that
are
critical
of
go
and
they've
been
like
subdivided
into
the
topics
that
the
the
author
has
really
disliked,
and
it's
called
a
go
is
not
good.
A
curated
list
of
articles
complaining
the
go,
isn't
good
enough.
Ironically,
if
you
go
to
this
repo,
you
see
that
the
the
thing
that
produces
the
list
is
itself
a
go
program.
So
one
final
note
about
mine
share,
so
I
guess
go
is
a
young
language.
It's
like
seven
or
eight
years
old
you
can.
A
These
are
just
two
sort
of
random
articles.
I
found
you
can
find
lots
of
articles
saying
go
is
gaining
my
chair.
There's
lots
of
interest,
there's
lots
of
new
developers,
it's
not
at
the
Java
level
yet!
But
if
you
are
kind
of
staffing
up
a
project
and
you
are
considering
go
I
think
we're
at
the
stage
where
you're
going
to
be
able
to
reliably
find,
go
developers
or
at
a
minimum
trained
people.
People
are
going
to
have
heard
of
it,
they're
going
to
be
interested
potentially
and
learning
it,
and
that's
very
easy.
A
So
I
just
have
this
slide
here
to
say
my
chair
is
there
or
like
growing,
and
we
already
know
that
right
because
we're
cloud
native
people,
we
can
look
at
our
portfolio
of
projects
and
note
that
a
little
more
than
half
of
them
are
implemented
in
go.
G.
Rpc
has
of
course
go
bindings.
Linker
D
is
like
finagle
for
containers,
so
I
guess
it's
like
Scala,
but
maybe
it
maybe
somehow
qualifies
fluency
is
written
in
Ruby
and
see
if
I'm
not
mistaken.
Maybe
it
should
have
been
written
and
go.
I,
don't
know.
A
A
They
solve
some
technical
problems,
but
they
create
far
far
more
so
choosing
to
opt
into
a
micro
service
architecture
is
something
you
should
do
only
when
you
know
you
need
to
solve
problems
that
are
latent
in
your
organization
and
typically
this
means
you're
big
enough
that
well
I'll
get
into
some
of
them
now.
But
this
is
like
the
key
thing
that
we
learned
I
think
so
let
me
enumerate
some
of
the
problems
that
are
solved.
A
For
example,
my
team
is
too
large
to
work
effectively
on
a
shared
codebase
and,
by
this
I
mean
literally
the
mechanics
of
pushing
commits,
having
merge
conflicts
being
able
to
push
code
around
without
causing
too
many
like
frictional
problems.
Mic
receivers
have
solved.
The
problem
of
my
team
is
blocked
on
another
team
to
make
progress
towards
some
business
goal.
So
if
you
often
find
yourself
saying
well
like
am
I
part
of
the
features
done,
but
that
team
isn't
done
and
so
like
we
have
a
standstill
in
terms
of
our
business.
A
In
my
opinion,
this
is
what
they
solve
now,
what
do
they
cause
in
order
to
have
any
of
these
lovely
properties?
We
need
to
have
well-defined
business
domains
and
in
the
domain
driven
design
terminology.
This
is
called
the
bounded
context
right,
so
you
need
to
have
stable
API
is
each
microservice
needs
to
have
a
stable,
ish
API?
A
You
don't
get
chair
databases
anymore
right,
so,
like
micro
services
encapsulate
their
data
storage,
that's
sort
of
one
of
their
key
properties,
which
means
that
if
you
need
to
start
doing
distributed
transactions,
you're
you're
in
for
a
world
of
pain,
because
those
are
really
really
hard
like
like
PhD
thesis
heart-
and
you
don't
want
to
do
them.
Actually,
you
want
to
figure
out
another
way
to
do
it.
Eventual
consistency,
blah
blah
blah.
That's
also
hard
testing
becomes
really
hard
too,
in
fact,
I.
As
far
as
I'm
aware,
it
is
a
design
error.
A
It's
like
categorically
incorrect
to
try
to
integration
test
your
entire
micro
service
fleet.
You
can
approach
that
asymptotically
with
really
strong
unit
testing
and
like
contract
testing,
and
you
can
make
an
attempt
at
some
kind
of
like
burn-in
test,
but
really
what
you
want
to
do
is
optimize
for
MTTR
mean
time
to
recovery
right.
You
have
really
good
monitoring,
you're,
really
good
rollback
procedures
and
you
just
kind
of
test
and
prod
right
with
Canaries
or
Bluegreen
or
whatever.
So
this
is
hardened.
It's
like
a
mind
shift,
and
this
and
many
other
things
we
sought
required.
A
The
sort
of
DevOps
culture
mind
shift
culture
shift
where
devs
need
to
deploy
and
operate
their
own
work,
and
that
means
they
need
to
get
paged
when
their
stuff
goes
down,
which
means
they
need
to
be
on
pedra
duty
or
whatever,
and
this
is
often
problematic
for
organizations.
You
have
the
problem
of
job
scheduling,
which
kubernetes
helps
with.
If
you're
able
to
use
kubernetes
that's
great,
but
if
you
aren't,
then
you
have
to
kind
of
like
approach
it
and
realize
what
parts
you
need.
A
What
parts
you
don't
that
takes
time
that
takes
energy
that
takes
automation,
then
you
have
the
problem
of
addressability,
that
is
service
discovery,
how
to
service
a
figure
out
about
service
fee.
This
is
an
infrastructural
concern.
Then
you
have
monitoring
an
instrumentation.
They
should
really
be
much
higher
in
the
in
the
list.
Actually,
because
this
is
critical.
This
is
the
first
thing.
You
should
be
worrying
about
old
tools
like
tail
f4
like
Maggio's
and
new
relative.
It's
like
completely
insufficient
for
this
new
world.
You
start
realizing
hey.
A
We
need
to
have
better
insight
into
the
things
we're
deploying.
Maybe
we
need
something
like
distributed
tracing
and
you
can
go
next
door
in
there
and
all
the
ballot
learn
all
about
it,
but
you'll
find
out
quickly
that
that's
really
really
really
hard
it's.
It
requires
like
complete,
homogeneous
implementation
of
a
certain
stack
over
your
entire
fleet,
and
if
you
have
sort
of
decoupled
teams
that
are
responsible
for
doing
it,
it's
hard
to
get
them
all
aligned
and
the
infrastructure
concerns
are
big
and
bla.
A
Bla
bla
lots
of
problems
there
get
the
word
up,
build
pipeline,
see
ICD.
This
becomes
important
security.
Oh
there's
this
thing
called
security,
oops
yeah
I
need
to
wire
all
that
in
once,
I
have
my
first
zero
day
or
whatever.
Okay.
So
anyway,
there's
like
all
these
concerns
right.
So
a
lot
of
people
come
from
this
monolithic
mode
where
they
have
their
monolith
right
there,
big,
Java,
app
or
whatever,
and
then
all
these
things
I
talked
about
are
kind
of
like
little
piecemeal
solutions
around
it
right.
A
When
you
go
to
the
micro
service
model,
you
end
up
drinking
your
your
monolith
right
or
chipping
in
away,
and
you
create
more
of
them.
But
all
these
like
piecemeal
concerns,
they're
they're,
still
they're
still
present.
It's
just
that
they
no
longer
interact
with
a
single
deployable
artifacts.
They
interact
with
like
multiple
deplorable
artifacts.
A
So
the
touch
points
right,
there's
many
many
more
there's
like
exponentially
more
and
so
the
the
point
I
want
to
raise
is
that
all
these
concerns
because,
like
they've,
become
multiplicative-
and
you
have
to
have
not
only
like
answers
to
all
these
purple
boxes,
you
have
to
have
structure
a
way
of
like
solving
these
problems
in
a
reliable,
automated
structured,
coherent
way
across
your
entire
fleet
of
business
services.
So
at
Sound
Cloud,
the
chief
architect,
I,
don't
know
he's
kind
of
a
floater.
A
Is
a
guy
named
Shaun
Treadway
there
and
he
gave
a
talk
similar
to
this
last
year
and
he
did
a
survey
and
he
went
through
all
of
the
services
in
the
company
and
counted
up
the
number
of
purple
things
that
they
would
need
to
have
answers
for
before
they
could
be
considered
like
production
ready.
So
how
many
like
ancillary
concerns?
Does
a
single
service
need
to
have
answers
for
before
it
can
be
deployed?
Does
anybody
have
a
guess
what
that
number
is.
A
125,
okay,
it's
somewhere
between
he
counted
40
things,
and
some
of
them
are
obvious,
like
what
programming
languages
are
written
in
and
what
programming
paradigms
was
utilized.
What
transport
protocols
is
a
talk
on.
Some
of
them
are
kind
of
the
things
that
I
mentioned
here
like
what?
How
do
you
do
secret
management?
How
do
you
do
alerting?
How
do
you
do
logs
that
you
do
log
rotation?
What's
the
CI
pipeline
for
blah
blah
blah?
Some
of
them
are
really
subtle
like
how
do
you
do?
A
A
We're
want
to
do
micro
services
because
we
understand
that
they
can
help
our
businesses
achieve
much
better
velocity,
especially
as
those
businesses
grow,
but
we
need
help
to
structure
this
stuff
so
that
we
can
answer
all
these
questions
in
a
good
way,
and
so
that's,
where
gokit
kind
of
ventures
into
the
picture
initially
I
wanted
it
to
be
a
standard
library
for
micro
services,
something
like
finagle
for
gos
anyone
heard
of
finagle
or
like
its
kind
of
familiar
with
finagle.
It's
like
solving
some
of
these
problems
in
Scala.
A
The
idea
is
to
provide
adapters,
bindings,
etc.
It's
a
common
infrastructure
component
to
solve
many
of
these
problems.
It's
important
that
it
played
nice
in
your
existing
kind
of
heterogeneous
environment
that
a
don't
that
it
doesn't
have
like
strong
opinions
about.
You
need
to
structure
your
apps
structure,
your
infrastructure,
and
this
way
you
need
to
use
console
you
need
to
use
kubernetes
like
you
have
your
own
like
opinions
about
that
in
org.
You
have
your
own
history,
your
own
competencies.
I!
Don't
really
want
to
have
opinions
about
that.
A
I
just
want
to
make
it
possible
to
write,
go
and
have
it
slot
in
and
work
well.
So
at
the
end,
it's
like
just
some
way
of
providing
structure
to
tame
this
beast
that
we've
described
an
incidental
complexity
that
comes
with
micro
services.
So
those
were
the
initial
goals
today,
it's
mostly
the
same.
It
turns
out
over
time
the
project's
about
two
and
a
half,
or
three
years
old.
Now
we've
become
even
less
opinionated
about
infrastructure
than
we
anticipated
and
even
more
opinionated
about
application
architecture
than
we
anticipated.
So
that's
really.
A
What
I
want
to
talk
to
talk
about
today
is
how
to
structure.
Go
applications,
go
micro
services
to
we'll
be
able
to
solve
these
problems
in
Upland
like
a
coherent
way
and
I'm
going
to
use
gokit
to
sort
of
demonstrate
patterns,
but
you
can
obviously
use
whatever
you
like
important
non
goals
of
gokit
messaging
patterns
of
you
and
RPC
there's
a
whole
class
of
micro
service
stuff.
That's
so
called
like
streaming
or
event,
sourcing
or
event
oriented
those
are
cool
and
interesting,
but
it's
not
sort
of
what
I'm
focused
on
at
the
moment.
A
A
It's
in
my
opinion,
from
where
I
stand,
it's
very
opinionated,
it's
sort
of
all
in
you
have
to
buy
into
the
micro
ideology
and
its
framework
ish.
For
that
reason,
and
so
I
stand
apart
from
that,
finagle
was
sort
of
the
original
inspiration,
but
in
the
end
it's
much
lower
level
than
go
kid.
It's
more
concerned
with,
like
the
mechanics
of
pushing
bytes
over
a
wire
and
getting
bites
back,
and
it's
very
concerned
with
retry
strategies
when
things
go
down
and
that
sort
of
thing
we
go
kit
has
all
that
stuff.
A
A
It's
also
somehow
similar
to
Tokyo,
which
is
like
this
new
rust
thing,
but
Tokyo
I
think
is
meant
to
be
almost
as
close
as
possible
to
a
finagle
for
rust,
and
so
it's
also
quite
low
level
and
I
really
want
to
emphasize
I.
Don't
care
if
you
use
go
kit.
I
do
care
if
you
use,
go
I
I'm
really
sold
on
the
go
philosophy
as
a
way
of
like
being
a
happy
programmer
and
I
want
to
well
to
be
completely
Frank.
A
I
want
to
create
more
job
opportunities
for
myself
in
the
future
and
get
as
many
comfort
as
possible
to
buy
into
this,
but
no
I'd
like
it
truly
makes
me
happy
as
a
programmer
and
like
I
want
to
sort
of
share
that
joy.
That's
really
my
motivation,
okay,
so
I
said
many
times
ago
is
about
application
architecture.
What
do
I
mean
by
that?
So,
let's
build
up
a
little
dummy
service
and
let's
demonstrate
some
of
the
things
that
I'm
talking
about.
A
So
let's
say
this
is
our
service
and
if
you
know
go,
you
know
the
interface
I've
decided
to
model
the
service
as
an
interface,
and
what
I'm
saying
here
is
add
service
is
something
some.
You
know
box
in
a
diagram
that
can
sum
two
integers
and
return
an
integer
and
it
can
concatenate
two
strings
and
return
two
strings.
So
it's
like
the
stupidest
possible
thing.
You
could
write
because
it's
a
service
right
now.
We
want
to
be
able
to
return
errors.
Things
can
fail.
Okay,
so
that's
the
that's
what
we're
building
right.
A
So
that's
the
that's
the
interface
definition
or
naive.
First
draft
we've
started
adder
addr,
the
uber
for
addition
or
something,
and
we
need
to
like
write
our
add
service
and
and
get
that
hot
hot
VC
cache.
So
here's
our
basic
service,
it's
an
implementation
of
the
add
in
add
service
interface.
We
have
our
sum
method,
which
is
just
adding
the
two
numbers
and
we
have
our
concat
method
and
it's
adding
the
two
strings
and
you
know
not
much
to
it.
Okay,
so
this
is
our
legs
as
I
like
core
business
logic,
nice
easy.
A
So
here's
here's
our
here's,
our
Red
Square
right!
This
is
this
is
our
thing,
but
there's
a
lot
of
stuff
that
we
have
to
now
start
sort
of
layering
on
top
right
and
the
first
one
is
a
transport.
This
is
useless,
it's
just
sitting
in
memory.
We
need
to
be
able
to
talk
to
it.
So
how
do
we
talk
to
it?
Typically,
we're
going
to
do
like
a
JSON,
HTTP
thing
right,
so
here's
our
basic
service
one
way
to
do
it
is
to
attach
a
serve
HTTP
method
onto
the
struct.
A
So
it
becomes
an
HTTP
handler.
It
can
talk
HTTP,
so
we're
going
to
switch
on
the
path
and
let's
say:
if
it's
the
sum
we're
going
to
construct.
This
request
object
we're
going
to
try
to
deserialize
from
the
body.
You
could
also
do
URL
parameters
like
do
notice
right,
let's
just
say
we're
doing
it.
This
way
you
deserialize
the
JSON
object
on
the
body
into
that
thing.
It
can
fail,
so
maybe
it'll
fail.
A
You
use
it
to
invoke
the
some
method
on
the
type
okay,
we're
just
calling
into
our
business
logic,
cool
and
then
you're,
going
to
serialize
JSON
back
to
the
client
straightforward
enough.
Okay,
the
concat
thing
it's
going
to
be
the
same
thing,
different
sort
of
types,
but
exactly
the
same
code.
Okay-
and
this
is
pretty
like
isolated
I
guess
we
have
the
business
logic.
Are
these
methods
and
then
the
transport
logic?
Is
this
method
and
like
okay,
they
kind
of
don't
interact
too
much.
That's
pretty!
A
Okay,
great
so
what's
next
we
got
to
talk
about
logging
right.
Everything
has
to
log
okay.
So
how
do
we
do
logging
here?
Well,
I!
Guess
one
way
is
you
take
this
decode
block
of
code
and
we'd,
stick
in
some
log
statements
and,
of
course,
we're
going
to
love
the
errors.
So
whenever
we
encounter
an
error,
we
log
the
air
and
then
we
log
success,
maybe
at
the
bottom
there,
okay,
cool
basic
information
right.
A
We
do
the
same
thing,
maybe
at
the
actual
application
layer,
so
that
was
like
in
the
transport
now,
if
we
go
down
to
the
to
the
business
logically,
when
I,
maybe
log
the
results
of
our
computation,
so
we
log
are
some.
We
log
reckon
cat,
maybe
no,
no,
some
strawman!
Okay,
like
let's
say
that
solves
the
logging
problem.
Okay,
but
now
we
have
to
do
metrics.
Of
course
right.
We
have
to
monitor
our
thing.
Okay,
so
how
do
we
do
metrics?
A
Well,
let's
say
there
are
some
metrics
defined
globally
or
somewhere
and
like
in
the
error
cases.
We
want
to
increment
the
error
counter
in
the
success
case.
We
increment
the
success
counter,
maybe
in
the
business
logic
we
need
to
put
a
histogram
for
how
long
it
took
okay,
we
can
drop
that
in
okay,
we've
solved
metrics,
but
now
it's
time
to
do
tracing
and
then
maybe
now
it's
time
to
do
safety
mechanisms
like
circuit,
breaking
and
and
and
rate
limiting,
and
no
no.
A
A
They
need
to
talk
to
something
else
and
what's
our
deploy
strategy,
maybe
it
needs
to
go
to
communities
and
there's,
like
all
these
things
right,
suddenly,
there's
all
these
things
and
we
don't
want
to
like
just
do
like
little
edits
in
the
raw
code
right
for
every
single
thing
here,
because
then
we
get
the
spiraling
unco
here,
enlike
impossible
to
maintain
monster
of
the
service
right
and
I.
Think
we've
all
written
like
I've
written
more
of
these
when
I
care
to
admit
right.
A
So
what
we
want
is
some
kind
of
structure
to
allow
us
to
solve
these
problems
without
just
like
editing
the
code
for
every
single
thing,
just
randomly
right,
so
goki
promotes
the
so
called
onion
model.
What
is
the
onion
model?
Basically,
you
take
your
core
business
logic
is
sort
of
the
center
of
the
onion
and
then
for
every
other
concern.
Basically,
you
wrap
that
with
what
I
call
middleware,
it's
also
known
as
a
decorator
pattern
and
in
gokit
we
kind
of
chop
it
up
into
three
distinct
phases
or
layers
of
the
onion.
A
A
Have
to
click
apparently,
okay.
This
is
very
similar
to
other
architectures
that
you
might
read
in
literature.
There's
this
thing
called
the
hexagonal
architecture,
where
it's
broadly
the
same
model.
They
use
different
terms
of
art
like
in
the
core,
it's
like
the
core
domain
and
then
there's
like
a
domain
and
application
layer,
and
then
they
I
think
this
is
from
like
Java
world.
A
So,
of
course,
the
Audemars
layer
is
a
framework
layer
and
then
it's
like
interaction
points
to
all
the
other
services
that
you
talk
to
a
database,
a
sequel,
server,
a
mail
server,
blah
blah
blah.
It's
also
very
similar
to
something
I
like
a
bit
more,
which
is
the
the
clean
architecture
and
it's
the
same
basic
idea.
It's
a
bit
more,
a
Martin
Fowler
II
domain
driven
design,
II,
where
at
the
core,
you
have
your
entities.
A
This
is
like
your
core
domain
objects
and
then,
as
you
extend
out
of
the
circle,
you
think
you
have
start
solving
different
concerns.
So
around
the
core
entities
are
your
use
cases,
and
here
you
might
write
some
unit
tests
or
something,
and
then
you
have
controllers
and
gateways
and
presenters
which
in
turn
interface
with
the
web,
with
a
UI
layer
with
a
database
with
some
device
right
and
in
the
clean
architecture
that
the
core
rule
is
a
dependency
rule
which
states
that
source
code
dependencies
can
only
point
inwards,
which
is
key.
A
That
means
in
your
core
business
domain.
It's
like
pure
logic
right.
You
have
your
integers
that
you're
summing
together
your
users
that
are
like
being
manipulated
only
as
you
extend
out
of
the
onion.
Do
you
start
introducing
concepts
like
HTTP
or
G
RPC
right
and
the
core
stuff
has
no
idea
about
HTTP
or
G
RPC.
All
they
care
about
is
the
the
business
domain
and
that's
important,
that's
key!
A
So
let's
take
our
dumb
little
service
and
let's
model
it
sort
of
a
little
bit
as
in
this
onion
way
and
see
where
we
get
so
we're
going
to
take
our
service
interface
and
in
go
the
way
that
we
manage
request
scope
life's
life
cycles.
The
way
we
do
RPC
basically
is
to
have
every
method,
take
a
context
parameter
as
the
first
parameter,
and
that's
just
the
way
it
works.
I
won't
get
into
the
details
here,
but
so
what
will
update
our
service
interface?
A
To
have
that
then
we'll
take
our
basic
service
and
we'll
we'll
extend
it
a
bit
we'll
make
it
a
bit
more
interesting.
We'll
have
the
some
method
maybe
fail
in
some
cases
the
concatenated
can
also
do
the
same
okay.
So
now
we
have
our
core,
basically
the
same
core
service.
Let's
talk
about
how
we
can
fold
in
this
fun
stuff
at
the
service
layer
at
the
innermost
layer
and
I
mentioned
already
the
decorator
of
the
middleware
pattern.
Let's
talk
about
what
a
middleware
would
look
like
and
go.
A
This
is
one
way
to
express
a
middleware
that
is
a
function
that
takes
a
service.
Does
some
extra
stuff
to
it
and
returns
exactly
the
same
service
or
I
should
say
an
interface
that
you
can
use
in
the
same
way,
but
that
has
additional
behavior
kind
of
wired
into
it.
So,
for
example,
a
logging
middleware
might
amend
a
service
with
a
logger
and
here's
how
you
would
construct
it
right
and
in
the
some
method
of
that
logging
middleware.
A
It
would
eventually
call
the
next
layer
down,
but
in
the
meanwhile,
it
would
log
the
things
that
it
sees
right.
So
this
is
like
about
as
simple
as
it
gets.
It's
just
doing
one
extra
bit
of
work
as
the
request
traverses
through
the
logging
middleware
down
into
the
next
layer
down
okay.
What
about
instrumenting
right?
A
So
we
could
have
an
instrumenting
middleware
that
didn't
contain
just
a
logger
but
contained
metrics
like
counters
or
histograms,
and
you
can
construct
it
kind
of
in
the
same
way
and
in
your
sum
method,
as
the
request
traverses
through
the
instrumenting
middle,
where
you
can
increment
your
counters
depending
on
what
the
parameters
say,
and
in
this
way
we
can
sort
of
create
these
isolated
bits
of
kit.
These
isolated
little
objects.
They
can
do
solve
individual
pieces
of
this
whole
puzzle
without
complexing
our
core
business
logic
or
like
one
mega
function.
That
just
does
everything.
A
A
The
point
here
is
that
we're
going
to
solve
each
of
these
problems,
independent
of
the
others
like
I,
said,
but
also
that
we're
going
to
optimize
the
way
we
build
a
service
for
maintenance
that
is
for
adding
new
concerns.
It's
very
simple!
You
just
create
a
new
decorator
and
you
wire
it
in
when
you
want
to
modify
an
existing
one.
You
don't
have
to
care
that
you
might
mess
up
the
code,
that's
doing
something
else,
because
it's
very
single
purpose,
like
microservices
itself,
you
can
kind
of
keep
all
that
code
in
your
head.
A
Hopefully
it's
a
very
short
little
file
and,
of
course,
this
makes
it
very
easy
to
remove
concerns.
You
just
delete
the
middleware
and
then
hopefully
that's
that's
it.
So
that
was
the
service
layer.
That's
are
all
the
business
logical
is
I
introduced
this
endpoint
layer.
What
is
that?
Well,
it
turns
out
if
we
have
an
additional
abstraction
which
abstract
Sauveur
RPC
it
turns
out.
We
can
do
a
lot
of
fun,
easy
stuff
there
that
you
don't
have
to
write
that.
A
It
sucks
talk
to
me
later,
I'll
tell
you
all
about
it,
and
then
we
have
wire
in
our
context
right
because
that's
how
that
works,
and
of
course
this
can
sail
so
your
wire
and
air
and
wire
in
an
error
in
the
return,
and
so
this
is
what
it
looks
like
request
in
response.
This
is
the
actual
definition
in
gokit.
A
A
Concatenated
response
types,
it's
all
kind
of
boilerplate
that
can
be
generated.
What
does
this
get
us?
This
gets
us
the
ability
to
define
an
endpoint
middleware.
What
does
that
get
us?
Well,
this
allows
us
to
wire
in
behavior
that
doesn't
care
about
what's
actually
going
through
what
the
actual
like
a
and
B
values
are,
but
maybe
just
cares
about
stuff.
That
is
only
to
do
with
the
request
self.
A
For
example,
if
you
wanted
to
prevent
outgoing
requests
from
doing
a
thundering
heard
on
some
service
that
happens
to
be
down,
you
could
implement
a
circuit
breaking
middleware
that
detected
errors
and,
after
a
certain
number
of
errors,
tripped
the
circuit
and
prevented
more
requests
from
flowing,
and
this
for
this
behavior,
you
don't
need
to
know
what
is
actually
in
the
request.
You
just
need
to
see
that
the
request
is
gone
and
success
or
fail
right,
so
we
can
provide
this.
An
effective
kit
provides
this
with
a
number
of
different
implementations.
A
Similarly,
we
can
do
like
a
throttling
or
like
a
rate,
limiting
middleware
and
so
there's
a
lot
of
value,
ID
stuff
that
can
exist
at
this
level
that
you
don't
have
to
write
that
we
can
provide
for
you,
that's
cool.
What
else
does
this
get
us?
Well,
because
we
now
have
a
stable,
consistent
foundation
of
the
RPC
idiom.
We
have
the
foundation
that
can
we
can
build
a
lot
of
different
transports
on,
and
so
here
we
get
into.
What
is
the
transport
mean?
A
The
transport
is
the
way
your
service
talks
to
the
world
and
whether
it's
HTTP
or
JRPG,
or
whatever
it
always
works
in
the
same
way
a
request
comes
in.
You
have
to
decode
it.
You
do
some
stuff
and
then
you
encode
a
response
back
to
the
client,
so
gokit
can
provide
using
the
endpoint
as
like
the
basic
building
block
as
the
foundation,
we
can
provide
adapters
servers
to
all
the
different
transports,
so
we
have
an
HTTP
transport.
Here's
what
it
looks
like
you
give
it
an
endpoint.
A
That's
how
you
can
turn
an
endpoint
into
an
HTTP.
So
ever
similarly
GRP
see
we
have
a
G
RPC
transport
and
it
looks
exactly
the
same.
I
mean
the
type
definitions
are
different
decoding.
A
G
RPC
request
is
different
than
decoding
an
HTTP
request,
but
fundamentally
it
does
the
same
thing
and
here's
what
serve
G
RPC
looks
like
there.
It's
exactly
the
same
workflow
just
you
know
different
types,
so
this
is
cool.
This
is
like
maybe
a
model
of
a
service
that
we've
built.
A
We
have
our
core
service,
we've
done
logging
and
instrumenting
middleware
in
the
service
domain.
We've
split
out
our
two
endpoints
or
ten
endpoints,
we've
wrapped
them
with
you,
know
different
endpoint,
middlewares
and
then
at
the
end,
we've
and
then
like
expose
them
on
HTTP
individual
like
little
HTTP
servers
and,
at
the
end,
we've
wrapped
all
the
HTTP
servers
in
sort
of
a
box,
and
we
can
present
that
on
port,
and
that
can
be
how
you
talk
to
our
service
right
but
observe.
A
What's
cool
about
this,
like
we've
constructed
the
HTTP
server
around
the
endpoint
but
like
we
can
also
pass
the
exact
same
endpoint
to
a
G
RPC
server
and
we
can
expose
the
exact
same
service
exact,
same
business
logic,
exact
same
like
safety
checking
all
the
middlewares,
all
the
decorators,
all
the
way
down
on
to
ports
running
two
different
protocols.
At
the
same
time,
right
and-
and
this
is
like
key
for
me-
because
we
want
to
play
nice
in
your
existing
environment-
we
want
to
go.
A
Kate
wants
to
be
very
helpful
for,
like
so-called
brownfield
development
right
where
you
have
this
old
architecture,
and
you
want
to
kind
of
go
on
the
migration
path
to
the
cloud
native
future.
But
you
need
to
do
stuff
like
this
for
awhile
and
this
sort
of
extends.
This
is
an
example
of
transport
kind
of
like
adaptation,
but
we
also
have
the
same
idiom
in
in
the
metrics
package.
A
A
Above
all
else,
so
the
lifecycle
of
the
service
from
birth
to
death,
and
hopefully
all
services
die
at
some
point.
How
much
time
do
you
spend
writing
v1
of
the
service
right
vs.
operating?
It
I
think
it's
like
about
this
long
about
this
long
right
or
like
how
much
time
do
you
spend
writing
code
in
general
versus
reading
it
I'd
like
probably
about
this
much
this
much
right.
A
So
yoga
is
very
much
keeping
that
in
mind,
as
does
go,
I
think
optimizing
for
reading
rather
than
writing,
and
so
it's
a
bit
for
both
in
some
places,
but
I
think
it
pays
out
in
the
end.
So
I
have
I.
Think
like
three
minutes
left.
Is
that
right?
Something
like
that
so
I
wanted
to
quickly
go
through
and
talk
about
how
we
integrate
with
the
cloud
native
stack,
spoiler
alert,
it's
all
basically
decorators,
so
first
up
I
still
have
three
minutes.
A
A
Okay,
we're
going
to
do
it.
Prometheus
is
a
metrics
decorator.
It
works
exactly
like
this.
We
use
this
metrics
counter.
I've
already
explained
it
to
you:
cool,
open
tracing,
very
hard
to
do
if
you're
just
getting
started
but
return
to
this
model.
What
is
a
lifecycle
lever
request?
Well,
it
comes
through
it
traverses
all
of
these
layers
right.
It
goes
to
your
business
logic.
It
may
need
to
like
go
out
call
some
other
service
right
that
will
come
back
and
it'll
traverse
the
business
logic
and
then
go
back
out
to
the
original
requester.