►
From YouTube: Bottoms-Up Adoption of a Microservices Workflow Using Kubernetes & Envoy - Rafael Schloming
Description
Bottoms-Up Adoption of a Microservices Workflow Using Kubernetes & Envoy - Rafael Schloming & Phil Lombardi, Datawire
Many organizations start their microservices journey by (re)designing their application architecture and operational infrastructure. We started building our cloud application using this approach. We discovered that this takes a long time.
In this talk, we’ll talk about how we ended up with a different approach when we started thinking about microservices as a workflow, and not an architecture. We’ll talk about our first goal: enabling a single developer to be able to code, ship, and manage a microservice, as quickly as possible. We’ll show how we integrated Kubernetes, Docker, Prometheus, and Envoy to achieve this goal.
Finally, we’ll talk about scaling this initial goal beyond a single developer. We’ll talk about the tradeoffs of this bottoms up approach to the conventional PAAS / service mesh / application architecture strategy, and show how you can get to the same place in the end.
About Phil Lombardi
Phil Lombardi is a Senior Platform Engineer at Datawire.io where he is building a development platform aimed at small companies adopting or using microservices and with a need for their platform to be simple, resilient and adaptable to the ever-changing tech landscape. He has spoken on microservices at many technical conferences like Velocity, NGINX Conf, and Boston DevOps Days. When not pounding on his keyboard or wrangling cloud infrastructure Phil is often found hitting the links to play golf or wandering around the city of Boston looking for the next exciting thing to do.
About Rafael Schloming
Rafael Schloming is Co-founder and Chief Architect of Datawire. He is a globally recognized expert on messaging and distributed systems and a spec author of the AMQP specification. He has spoken on microservices at numerous technical conferences including ApacheCon, the O’Reilly Software Architecture Conference, Velocity, and the Microservices Practitioner Summit. Previously, Rafael was a principal software engineer at Red Hat. Rafael has a B.S. in computer science from MIT.
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
B
B
B
B
B
B
B
A
B
B
B
A
A
What
we're
going
to
talk
about
today
is
how
to
go
about
using
kubernetes,
an
envoy
to
get
a
whole
lot
of
developers
working
together
and
building
awesome
stuff.
We
call
this
bottom-up
approach
to
micro
services,
service-oriented
development
and
I'm
going
to
talk
about
why
we
think
this
is
one
of
the
most
effective
perspectives
to
benefit
from
micro
services
and
Phil's.
Going
to
talk
about
the
platform
we
ended
up
building
for
ourselves
to
actually
do
service
oriented
development
for
the
services
we
were
building.
A
Hi
so
first
I
want
to
say,
with
a
quick
poll,
though
show
of
hands
how
many
of
you
have
asked
these
sorts
of
questions
about
microservices
stuff
like
how
do
I
break
up
the
mallet?
How
do
I
could
take
my
app?
What
kind
of
tooling
and
platform
do
I
need
to
actually
benefit?
Okay,
all
right!
That's
a
good
number.
A
So
these
were
the
same
exact
questions
we
had
when
we
started
out,
and
we
kind
of
learned
the
hard
way
that
these
weren't
really
the
right
questions
to
be
asking
when,
when
you
start
out,
so
what
is
the
right
question?
Well,
I'm
going
to
talk
about
that,
but
first
I'm
gonna
cover
a
little
bit
of
our
early
history,
so
that
you
can
understand
the
painful
lessons
that
go
along
with
this
question.
So
we
were
founded
in
about
2014.
My
co-founder
and
I
were
both
sort
of
tool.
A
A
This
picture
of
an
emerging
architecture
form
and
looks
something
like
this
control
plane
and
a
data
plane,
a
control
plane
doing
a
bunch
of
stuff
like
discovery,
logging
tracing
and
metrics
the
data
plane,
basically
consisting
of
a
bunch
of
smart
endpoints
with
resilience
for
l7
network
stability.
Things
like
timeouts
rate,
limiting
circuit
breakers,
all
that
good
stuff.
And
so
we
looked
at
this
and
said:
well,
that's
a
lot
of
technology
to
build
just
to
benefit
from
micro
services.
So
we
can
help
people
by
building
some
of
this
for
them.
A
To
start
with,
we
actually
at
least
we
built
a
prototype
and
released
it
pretty
quickly,
but
right
after
we
launch
things
started
slowing
down,
and
so
we
kind
of
took
a
step
back
scratch
our
heads
and
try
to
figure
out
why
things
were
going
slow
for
us,
and
you
know,
as
is
the
case
with
this
sort
of
thing,
when
you're
in
the
middle
of
things,
it's
not
necessarily
obvious,
even
though
it
becomes
clear
later
with
hindsight.
So
you
know
we
went
through
a
couple
releases.
We
tried
a
bunch
of
different
things.
A
We
we
picked
a
bunch
of
different
tools
to
try
to
help
accelerate
things.
We
went
through
a
bunch
of
different
deployment
systems
which
took
a
look
at
our
architecture
and
tried
a
bunch
of
different.
We
thought.
Maybe
we
decompose
the
problem
wrong.
We
tried
a
bunch
of
different
different
options
there.
A
None
of
that
really
made
a
difference
for
us
and
after
going
through
a
couple
of
releases
and
looking
back
pretty
carefully
asking
a
bunch
of
question,
we
finally
figured
out
what
was
going
on
every
feature
actually
required,
pretty
carefully
coordinating
the
efforts
of
multiple
different
people.
Some
of
this
was
for
bad
reasons
and
we
fixed
those.
Some
of
this
was
for
very
good
reasons.
We
didn't
want
to
break
our
users,
and
so,
in
the
end
we
decided
it
wasn't
really
our
technology
or
our
architecture
that
was
slowing
us
down
I,
was
actually
our
process.
A
A
A
The
slow
movers
kind
of
fell
into
two
camps,
companies
that
were
doing
extensive
tech,
bake-offs
very
carefully
choosing
their
technology
and
other
companies
that
were
very,
very
carefully
re,
are
connecting
their
monolith
sort
of
in
a
refactor
process
to
get
to
micro
services,
and
then
there
were
the
fast
movers
and
we
really
wanted
to
understand
what
was
different
about
the
fast
movers.
So
we
asked
them
a
bunch
of
things,
but
what
really
stuck
out
was
the
story
of
their
first
service.
All
of
their
first
services
were
different.
In
some
ways.
A
There
was
a
file
upload
service
that
it
was
created
because
of
the
occasional
multi
gigabyte
file
that
would
take
down
a
rails
monolith.
Another
case
was
wanting
to
isolate
the
impact
of
auto
requirements
for
PPI,
and
another
company
just
wanted
to
adopt
modern
and
CI
CD
tools
and
didn't
have
time
to
retrofit
their
monolith,
so
they
started
building
new
features
and
in
separate
services
with
more
modern
tooling.
A
But
the
thing
that
all
of
these
stories
had
in
common
was
that
they
all
had
an
urgent
need
that
could
not
be
dressed
quickly
enough
in
the
context
of
their
existing
process.
So
we
put
two
and
two
together
with
our
own
experiences
and
said:
velocity
actually
comes
from
process,
not
architecture,
and
this
makes
a
lot
of
sense.
A
If
you
think
about
it,
you
don't
stand
in
front
of
a
white
board
and
architected
Deathstar
with
thousands
and
thousands
of
services
you
get
there
by
enabling
a
different
way
of
working
that
as
a
byproduct
makes
it
way
faster
and
easier
to
churn
out
hundreds
of
services,
and
this
is
when
we
ditched
service-oriented
architecture,
fine,
grained
or
otherwise,
and
started
thinking
about
service-oriented
development.
And
to
understand
this,
it
helps
to
recognize
two
things
that
dramatically
impact
the
way
we
work
as
developers.
A
A
The
development
process
involves
a
bunch
of
distinct
activities
that
I'm
sure
you're
all
familiar
with
and
something
that
can
be
harder
to
notice
when
you're
small.
As
that,
you
can
really
only
do
one
of
the
activities
in
this
process
at
a
time.
Yet
when
organizations
try
to
scale,
they
seem
to
do
it
by
building
specialized
teams
associated
with
some
or
all
of
these
activities
and
as
an
organization
like
this
grows,
this
turns
into
some
combination
of
dramatic
underutilization
and
departments
fighting
each
other.
A
A
This
is
the
question
to
ask
if
you
want
to
go
faster,
and
this
is
the
perspective
to
approach
microservices
from
because
microservices
lets
you
have
as
many
different
processes
as
you
like,
you
can
think
of
microservices
as
a
distributed
development
workflow,
and
this
lets
you
customize
the
process
for
each
of
your
team's
to
that
ideal.
Stability
versus
velocity
trade
off
for
whatever
service
they
are
working
on,
and
when
you
do
this,
that's
how
you
can
move
fast
and
keep
things
stable
and
get
benefits
almost
immediately.
A
So
this
sounds
great
right.
So
how
do
we
get
started
with
this?
Well,
starting
from
the
right.
The
right
principles
makes
this
thing
a
whole
lot
easier,
but
it
is
still
a
big
shift
in
how
people
operate,
and
this
requires
both
organizational
and
technical
changes
and
the
organizational
changes
really
impact
the
technology
and
how
you
use
it
and
so
I'm
going
to
cover
some
of
this
in
some
ways.
You
can
make
this
easier
on
both
fronts.
A
But
when
you
do
this
right,
you
get
a
whole
lot.
Your
specialists
turn
into
generalists
and
you
get
better
holistic
systems
with
learning
outcomes,
personal
growth
and
much
higher
job
satisfaction
with
better
communication
that
conflict
that
existed
in
the
organization
before
it
turns
into
collaboration
and
with
delegation.
Of
course,
you
get
massive
organizational
scale
and
the
benefits
when
this
is
done
well,
they're
pretty
hard
to
overstate.
So
what's
the
best
way
to
actually
go
about
doing
this?
Well,
you
need
to
create
self-sufficient
autonomous
software
teams
why
self
sufficiency
and
autonomy?
A
Well,
if
you
have
to
work
directly
with
other
teams
to
get
stuff
done,
then
their
process
is
interjected
into
yours.
If
you
have
autonomy,
you
can
choose
the
best
process
to
actually
meet
your
goals
so
to
get
there,
there's
two
things
to
be
aware
of:
first,
you
need
to
be
aware
of
centralized
specialist
functions
and
try
to
eliminate
them,
try
to
avoid
centralized
architecture,
teams
and
centralized
Operations
teams
and
don't
get
confused
between
a
platform
team
that
provides
a
platform
and
tooling
as
a
service
and
a
centralized
Operations
team.
A
A
The
second
thing
is
to
think
of
your
teams
like
their
own
little
spin-off
companies.
You
probably
already
consumed
external
services
like
stripe
and
Twilio.
Well,
you
can
think
of
your
micro
service
teams.
The
same
way
pick
a
real
urgent
business
problem
that
you
wish
you
could
buy
instead
of
build
and
then
form
an
internal
spin-off
to
build
it,
and
this
sets
up
the
right
mindset
for
a
lot
of
things.
It
helps
you
define
your
service
because
you're
thinking
mission
statement
who's
the
user.
A
What
do
you
tried
to
help
them
do,
and
this
is
a
way
more
effective
way
of
defining
services
than
big
upfront
design.
It
also
helps
with
communication.
You
set
up
a
customer
relationship
versus
a
co-worker
relationship
and
it
helps
you
form
the
right
team
because
you
put
people
with
all
the
different
specialties.
You
need
on
one
small
team,
and
you
can
even
do
this
with
no
fancy
tooling
or
technology
at
all,
but
tooling
can
help
a
whole
lot,
and
that
brings
us
to
the
technical
implementation.
A
Now,
if
you
recall
from
earlier,
this
is
sort
of
the
rough
picture
of
what
most
microservices
tech
stacks
look
like,
and
it
turns
out.
This
picture
is
actually
missing.
Something
that's
really
really
important
and
that's
the
people.
People
are
the
topmost
layer
of
the
control
plane
when
a
service
breaks,
a
person
has
to
find
out
about
it
and
fix
it,
and
for
a
service
to
improve
a
person
needs
to
change
it,
hopefully
for
better
and
the
people
factors
involved
have
a
big
impact
on
the
tooling
as
well.
A
In
fact,
this
gives
us
the
goals
for
our
tooling.
We
need
to
build
tools
that
make
our
small
autonomous
teams
productive
and
right
away.
This
tells
us
a
few
things.
We
need
our
tools
to
be
good
for
the
generalists,
we're
trying
to
create
and
a
generalist
UX
is
very,
very
different
from
a
specialist
UX
think
about
all
the
specialist
tooling
out
there
for
operations.
A
Things
like
monitoring
logging
analytics
deployment,
all
the
l7
proxies
and
routers
you
can
choose
from
all
of
these
tools,
have
enormous
surface
area
and
flexibility,
which
is
exactly
what
you
want,
is
a
specialist
specialist
prioritize,
something
general
enough
to
handle
any
possible
application.
A
developer
might
conceivably
write
and
they
don't
care
about.
A
The
learning
curve
generalists,
on
the
other
hand,
want
something,
that's
an
easy
starting
point
that
works
out
of
the
box
for
their
particular
application,
and
that
then
lets
them
discover
the
more
advanced
features
if
and
when
they
run
into
the
need
for
them
now.
The
other
thing
this
tells
us
is
that
our
teams
are
learning,
so
we
need
to
our
tools
to
actually
help
with
that.
This
means
building
on
familiar
concepts
and
providing
training,
wheels
safety
faults,
so
we
don't
get
into
trouble
and
great
feedback.
A
Every
error
message
should
really
have
a
pointer
to
whatever
it
is.
You
need
to
learn
to
solve
the
problem
and,
finally,
because
their
teams
are
autonomous
in
each
one
can
choose
their
own
process.
Our
tools
need
to
be
flexible
enough
to
fit
many
different
processes.
So
this
is
sort
of
the
Platonic
ideal
platform
for
doing
service-oriented
service
oriented
development,
and
we
even
managed
to
actually
accomplish
some
of
this,
and
Phil
is
actually
going
to
talk
now
about
what
it
is
that
we've
built.
What's
worked
well
for
us
and
what
hasn't.
A
B
Thanks
so
it
may
be
nice
to
believe
that
raphe
has
just
come
up
with
all
these
things
on
his
own
by
sitting
in
an
armchair
and
drinking
scotch,
and
going
and
I
can
tell
you
all
these
people
in
his
audience
about
this
next
week
when
I
get
here.
But
it's
actually
a
bunch
of
hard
learned
lessons
over
the
course
of
200
years
and
some
change
from
when
we
started
building
the
back
end
at
data
wire.
So
a
little
context,
I
joined
data
wire
at
the
end
of
2015.
That's
pretty
much.
B
The
first
back
end
engineer
to
join
the
company
and
at
the
time
Rafi
was
working
in
Boston
I
was
working
in
Boston.
We
had
two
other
engineers,
one
down
in
New
York
and
one
in
Europe.
At
the
time
they
were
kind
of
working
on
some
other
stuff
and
I
came
in
and
start
building
the
back
end
and
we
started
building
the
back
end.
B
We
were
gonna
bring
into
the
company
to
work
on
and
also
the
existing
engineers
to
just
pick
up
and
go
so
they
didn't
have
to
bother
me
all
the
time
with
their
problems,
so
I
kind
of
go
like
alright.
Well,
the
only
way
to
really
do
this
is
build
self-service.
You
know,
automation
around
all
this
stuff,
and
so
I
was
like.
Alright
we're
gonna
build
out
a
self-service
platform
that
anyone
at
the
company
can
use
it'll
be
documented.
B
Well,
we'll
have
a
nice
readme
that
people
can
look
at
go
alright,
here's
all
the
instructions
to
get
a
service
started
and
here's
the
tools
they're
gonna
be
using
and
there's
gonna,
be
these
various
URLs
they
go
to.
They
can
put
things
in
here
and
they'll,
build
off
the
CI
pipeline
to
build
the
deployment
pipeline,
all
that
jazz,
and
so
there
were
some
design
considerations
along
with
that
that
I
had
to
keep
in
mind
so
dated
wire
has
always
been
a
polyglot
programming
shop.
B
You
know
raphe
and
the
other
engineers
at
the
time
we're
working
mostly
in
Python
I,
came
on
board.
It's
back
in
engineer
with
a
lot
of
Java
and
JVM
experience.
So
I
was
writing
Java
stuff,
we've
always
kind
of
had
a
you
know,
openness
about
picking
whatever
tool
works
for
you,
so
you
know
like
Java
Script
tends
to
just
creep
into
anyone's
codebase,
despite
everyone's
best
attempts
to
avoid
it
go
has
become
really
popular
and
stuff
like
that
with
any
programming
language
set,
you
end
up
having
a
lot
of
tool
chains.
B
So
not
everyone
is
going
to
be
using
the
same
tool
chain
if
you're,
a
Java,
developer,
you're,
obviously
familiar
with
you,
know
maven
or
Gradle,
but
Python
folks
don't
use
those
tools
at
all
in
will
actively.
You
know,
laugh
at
you
if
you
suggest
any
kind
of
idea
using
that
stuff.
The
engineering
org
started
out
is
distributed
by
default
and,
while
we're
now
all
co-located
together,
we
still
kind
of
follow
a
distributed
team
pattern.
So
some
engineers
come
in
early
some
engineers
work
late.
B
Some
engineers
work
mornings
take
the
afternoon
off
and
start
working
again
late
in
the
evening,
so
we
have
a
one.
It
would
be
a
co-located
team
with
distributed
engineering.
You
know
personality.
Basically,
when
I
came
in,
I
was
really
the
only
person
with
a
strong
services,
development,
background
and
micro
service
to
develop
backgrounds.
So
we
had
to
have
a
way
that
anyone
who
was
coming
to
start
working
on
this
could
pick
it
up
easily
enough,
despite
not
having
that
background,
and
because
we
were
building
the
actual
backend
for
the
product.
There's.
B
B
B
You
know
put
my
fingers
in
my
ears
and
kind
of
said:
no,
no,
no!
It's
not
your!
It's
not
my
fault.
It's
your
fault!
You're
not
reading
the
documentation
right
or
you're,
not
doing
it
correctly,
which
is
completely
the
wrong
response,
but
when
I
finally
sat
down
and
started
to
look
at
the
metrics
for
like
how
you
know
slow,
we
were
going
versus
like
what
we
should
be
actually
be
able
to
do
was
like
ooh.
This
is
really
bad.
B
We
got
an
issue
here,
so
we
kind
of
had
to
basically
have
a
reset,
and
fortunately
we
had
some
time
at
the
end
of
2016,
where
we
kind
of
set
aside,
you
know,
take
a
look
at
everything
we
were
able
to
set
step
back
go.
Maybe
this
is
not
correct,
so
we
stood.
You
know,
took
a
step
back,
looked
at
it.
What
what
do
we
want
to
do?
B
But
in
the
meantime
it's
not
what
we
really
learned
was.
None
of
this
is
about
tools.
You
can
throw
as
many
tools
as
you
want
at
these
problems
and
you're
never
gonna
fix
people
in
process,
because
people
in
process
is
actually
the
most
important
thing
and
they're
not
really
not
trying
to
fix
them.
When
he
say
fixing,
you
tend
to
imply
they're
broken
they're,
not
broken
they're.
Just
doing
things
in
a
way
they
want
to
do
and
they
makes
them
the
most
productive
and,
at
the
end
of
the
day,
people
are
trying
to
be
productive.
B
They
want
to
get
their
job
done.
So
you
know
they
keep
everyone
else
happy.
The
business
is
happy
keeps
going,
but
you
can't
throw
tools
and
the
expectation
I
had
started
with
was:
let's
throw
tools
of
the
thing.
Engineers
are
really
finicky.
They
don't
like
actually
picking
up
tools
that
they
don't
believe
in.
They
don't
believe
the
tool
is
gonna
work
for
them
or
they
actively
find
the
tool
gets
in
their
way
and
makes
their
life
harder.
B
They
will
not
like
that
tool
and
so
I
started
putting
tools
in
front
of
their
way
that
was
slowing
them
down,
even
though
they
knew
what
they
were
trying
to
do
and
they
got
angry
and
they
got
grumpy
and
they
complained,
and
it
was
a
bad
experience,
so
all
the
tooling
in
the
world,
it's
not
gonna,
make
your
problems
go
away.
It's
you
got
to
think
about
the
people
in
the
process.
Finally,
there's
another
really
important
point
with
tools.
Every
tool
has
basically
a
cost
to
it.
B
So
a
couple
problems
with
read
nice
I
know:
I,
do
not
write,
read
Me's,
particularly
well,
so
I
have
somewhat
of
an
expert
blind
spot
when
it
comes
to
putting
this
stuff
together,
I
will
jump
from
step
one
to
step
two
and
not
realize
that
I
have
missed.
You
know
a
B
and
C
of
one
that
led
to
not
having
complete
information.
The
next
person
who
reads
it
then
also
reads:
it
goes
well.
I
have
no
idea.
What's
going
on
this
leads
to
arguments
in
the
office
where
people
are
like
well,
I
felt
followed.
B
You
read
me
and
you
didn't
actually
document
what
you
wanted
me
to
do
here,
because
well,
I
don't
have
that
information.
That's
one
problem.
Another
problem
read
Me's
are
often
treated
as
opinion
rather
than
as
the
facts
of
the
world,
so
think
of
it
like
baking.
First
is
cooking
in
cooking.
You
can
take
a
lot
of
liberties.
You
can
look
at
a
recipe
and
tweak
it
and
do
whatever
you
want
to
it.
Developers
tend
to
look
at,
read,
Me's
and
go.
B
Oh
I
see
steps
one
two
three
I
know
how
to
do
step
two
already
so
I'll.
Do
it
my
own
way
it'll
end
up
in
the
same
result,
I
think,
whereas
the
person
who
wrote
the
readme
actually
was
treating
it
like
a
recipe
for
a
cake,
and
we
all
know
when
you
start
messing
with
recipes
for
cake
like
adding
baking
soda,
you
get
to
yield
better
flavor
you're,
not
actually
gonna
get
what
you
expected.
B
It's
going
to
taste,
terrible
and
you're
gonna
have
a
lot
of
problems
there,
so
we
went
back
to
the
drawing
board
at
the
end
of
2016.
We're
like
okay.
What
do
we
actually
want?
We
really
want
a
way
for
everyone
to
kind
of
have
a
common
tool
chain
that
can
be
exist
on
their
laptop
or
on
your
co-workers,
laptop
or
on
your
friend's
laptop
or
your
grandmother's
laptop
or
in
the
CI
system,
wherever
you
put
it
for
whatever
language
for
whatever
environment.
B
It's
going
to
be
the
same,
and
we
said
we're
gonna
do
this
initially
by
just
starting
with
dr.
as
our
primitive,
so
we
will
package
everything
into
docker
and
we
will
then
figure
out
how
to
run
docker
stuff
so
voice.
You
got
into
docker
the
big
questions,
but
time
became
like
how
do
we
run
this
and
I'm
sure
everyone?
B
This
room
is
familiar,
obviously,
with
things
like
me,
so
since
warm
but
I
had
been
following
kubernetes
pretty
closely
since
2014
when
I
first
heard
about
it
and
by
the
time
at
2016
rolled
around
I
was
like
okay.
This
looks
like
it's
ready
for
primetime.
This
looks
like
where
everyone's
aligning
and
so
I
said
all
right,
we're
gonna
use
criminais
days.
This
seems
like
the
place,
its
configuration
driven.
It's
pretty
simple
in
terms
of
what
it's
actually
trying
to
do
has
concepts
that
everyone
will
find
pretty
familiar.
B
B
B
We
noticed
everyone
has
for
files
in
the
repository
and
everyone
started
having
and
the
K
the
kubernetes
manifests
in
a
particular
directory
like
alright,
we'll
make
that
a
standard
we'll
make
it
so
that,
whatever
you
put
certain
things
in
these
directories,
you
know
the
tool
will
just
know
what
to
do
as
it
goes
off
and
does
it
thing
so,
for
anyone
actually
really
wants
to
kind
of
go
back
to
their
own?
You
know
development,
workflow
and
start
building
like
this.
Your
first
step
that
you
actually
have
to
follow
us
provide
fast.
B
B
They
don't
need
to
know
the
individual
steps
going
on
the
person
who
wrote
the
project
and
started.
It
knows
that,
but
people
who
are
working
on
it
don't
need
to
know
those
individual
steps,
they're
codified
in
to
the
doctor,
build
process,
so
it
gets
rid
of
that
whole
problem
of
well.
This
was
a.
This
was
actually
a
baking
recipe
and
you
treated
it
like
a
cooking
recipe
and
when
I
said
it
had
to
work
for
everyone,
I
meant
everyone.
So
we
didn't.
We
made
sure
we
weren't
forgetting
about
people
who
were
working
with.
B
You
know
different
tool
chains,
it's
imperative
that
you
have
a
tool
that
works
across
your
entire
organization
for
any
type
of
situation,
because
you
know
everyone
eventually
becomes
a
polyglot
shop,
whether
they
actually
believe
it
or
not.
You're
either
get
through
acquisition
or
through
some
other
mechanism,
are
going
to
end
up
with
services
written
languages
that
you
didn't
expect.
So
you
need
this
process
to
be
resilient
to
change
for
in
your
organization
as
people
come
and
go.
B
A
B
Step
two:
you
have
to
provide
fast
self
service,
deploy
as
well
so
dinnerwire
when
we're
actually
building
code.
We
have
the
ability
to
either
deploy
into
our
shared
cluster,
pre-commit
or
post-commit,
and
so
that
means,
when
you're
working
on
a
branch,
you
can
have
an
isolated
environment
for
your
code
that
another
person
working.
Another
branch
is
completely
isolated
from
them.
So
like
Rafe,
you
will
have
to
be
working
on
a
particular
feature
of
one
of
the
project.
I'll
be
working
on
other
part
till
you
feature
that
project
and
I
can
be
running
the
same
code.
B
B
So
to
recap,
for
step
one
and
to
codify
and
put
your
entire
build
process
into
a
docker
image
make
it
so
that
whenever
you
do
a
docker
build
it
actually
does
the
entire
build
to
get
what
you
want
to
do
and
that's
going
to
be
your
runnable
artifact.
And
then
you
use
kubernetes
to
actually
do
the
deployments
we
found.
As
you
know,
we
did
these
things.
B
We
started
to
codify
them
into
tools
so,
like
we've,
wrapped
doctor
build
now
in
our
own
tool,
called
Forge,
which
does
the
docker
build
and
contain
compiler,
caches
and
stuff
like
that.
It
can
also
do
things
like
shortcut
building
an
image
if
it
knows
that
the
image
is
already
in
the
existing
registry,
so
you
don't
have
to
bother
doing
that.
It
just
looks
at
the
commit
the
commit
history
and
goes
this
hat.
You
know
this
shot
for
the
entire
repository
is
the
same
I'm
not
gonna,
bother
building
a
new
image
for
you.
B
But
there
is
really
a
third
in
a
most
important
greeting
here.
It's
step
three:
you
have
to
make
it
easy
to
reach
the
changed
code
and
we
do
this
with
envoy.
So
we
use
envoy-
and
our
is
our
basically
entry
point
to
our
cluster
and
we've
put
a
thing
called
ambassador,
which
is
this
thing
that
listed
two
changes
on
annotations
that
we
put
on
these
service
manifests
that
are
applied
into
kubernetes.
So,
basically,
a
typical
set
up
is
someone's
working
on
a
branch
at
data
wire
for
a
particular
service.
B
So
it
makes
it
super
easy
for
someone
to
actually
have
like
dev
awesome
feature
got
data,
wired,
IO
or
Pete
Lombardi
data.
Why
do
where
they
put
whatever
they
want,
also
makes
it
super
easy,
just
spin
up
projects
in
general,
because
you
only
have
to
think
about
this
little
block
of
annotation
code.
They
are
config
that
you
put
into
your
service
manifest
and
off.
You
are
to
the
races.
Is
it
perfect?
No,
it's!
It's
really
not
perfect.
We
still
got
a
long
way
to
go,
but
it's
so
much
better
than
woodwork.
B
We
really
started
putting
this
into
effect
earlier
this
year
and
like
the
speed
at
which
we're
actually
able
to
build
our
services
now
is
monumentally
faster.
It's
basically
it's
hard
to
actually
quantify
how
fast
it
is
now
compared
to
what
it
is,
but
we
still
have
a
long
way
to
go.
So
there's
a
bunch
of
things.
We
are
working
on
actively
going
into
2018
that
we're
going
to
improve
these
things
really
for
us
self
service,
bootstrapping
I
should
have
put
self
service
there.
B
Anyone
can
start,
but
we'd
like
to
have
some
easy
wait
for
developers
who
come
on
to
the
company
to
easily
start
services
that
doesn't
involve
usually
some
kind
of
like
taking
an
existing
service
and
ripping
out
the
code
from
it.
So
we
haven't
really
come
off
like
good
cookie
cutter
mechanism
that
we
like
for
me,
I'm
still
continually
hounded
by
self
cert
for
self
service.
You
know
stateful
infrastructure,
so
I'm,
usually
the
only
person
who
knows
how
to
get
that
working
and
so
I'd
really
like
to
figure
out
how
people
are
gonna.
B
A
So
looking
Thanks,
so
looking
back
after
kind
of
reliving
some
of
the
some
of
the
past
couple
years,
thanks
to
Phil,
if
I
could
give
myself
some
advice
from
the
future,
I
would
really
tell
myself
that
kubernetes
and
envoy
really
do
have
the
bulk
of
the
capabilities.
You
need
to
get
started
with
microcircuits,
but
capabilities
really
aren't
enough.
A
So
that's
that's
our
talk
thanks
for
coming
we're
happy
to
answer
any
questions.
Now,
if
you
want
to
talk
to
us
more
later,
you
can
visit
us
at
our
booth
s-58.
If
you're
interested
in
using
some
of
the
tools
we've
built
for
your
own
platform,
there,
they
are
free
and
open
source.
We
publish
some
hands-on
guides
at
the
link
above,
send
us
a
tweet
email
us
and
we're
happy
to
chat.