►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Istio in Production: Real Customers, Real Solutions - Craig Box, Google
What was so compelling about Istio that people would choose to run it in production at version 0.2 Alpha, just two months after it was released?
In this presentation attendees will learn:
- how different Kubernetes customers have been using it in production for over 12 months
- some of the use cases at Google which inspired Istio
- concrete next steps about how you can integrate Istio into your testing environment and start validating if it's useful for you
To learn more click here: https://sched.co/FuLm
A
A
I'll
be
right:
okay,
you're,
recording
the
video
output
as
well,
so
okay,
so
it
will
matter
if
it
goes
wrong.
Okay,
all
right!
Thank
you
very
much
all
for
coming
here
today.
My
name
is
Craig
box
I
lead
the
developer,
advocacy
teams
for
kubernetes
and
Misty
Oh
on
Google
Cloud
based
in
London,
so
my
job
is
traveling
the
world
and
talking
to
people
about
the
open-source
projects
that
we've
built
our
cloud
products
that
were
built
on
top
of
them
and
getting
feedback
from
people
about
what
they
like
and
what
they
would
like
to
see
changed.
A
One
month
after
we
released
it
as
open
source
along
with
IBM,
we
launched
sto
and
we
know
of
customers
who
were
using
version
zero
point
two,
so
you
have
to
be
very
brave
to
want
to
use
something
so
young,
but
it
must
solve
a
real
problem
that
people
have
and
it's
important
to
know
what
those
problems
are.
So
we
can
see
if
we
can
apply
them
to
your
business
now.
A
The
most
common
use
case
for
something
like
sto
is
when
you're
looking
at
moving
a
monolithic
application
to
micro
services,
monolithic
applications
used
to
just
be
the
only
way
we
would
build
software.
It
was
fantastic
because
we
would
write
everything
in
one
process,
and
so
we
knew
that
it
all
worked.
We
compiled
everything
together,
you
could
call
any
function,
so
some
of
those
modules
they're
just
sort
of
call
each
other
around
in
the
circle,
but
that's
okay.
There
are
downsides
to
this.
A
You
have
to
write
the
whole
thing
in
one
programming
language,
it's
hard
to
test
those
modules
independently,
especially
when
they
can
be
called
around
in
that
order.
You
can't
redeploy
only
part
of
this.
You
have
to
take
the
entire
application
and
redeploy
it
all
at
once,
and
because
of
that,
you
can
only
move
as
fast
as
the
slowest
person
in
your
release
cycle.
You
have
to
synchronize
your
teams
together,
find
out
when
they
are
ready
to
release
and
businesses
with
applications
like
this.
A
Have
a
person
called
the
release
manager
and
that
person
says
no
to
everybody
and
then
six
months
time
they
say:
ok,
we
can
release
now
and
if
you
miss
that
train,
then
you
have
to
wait
a
long
time
to
get
on
the
next
one.
So
we
moved
to
micro-services
in
order
to
try
and
solve
these
problems.
We
are
solving
business
problems
here
and
we're
using
a
technical
means
to
do
this.
A
We
talk
about
decomposing
a
monolith,
so
we
remove
the
dependencies
we
make
it
so
things
only
call
each
other
in
a
straight
line.
We
define
interfaces
between
these
modules
so
that
you
expose
an
API
and
you
publish
that
as
a
contract.
So
you
know
people
who
call
you
are
going
to
be
able
to
call
you,
regardless
of
what
version
of
that
software
you've
released
and
we
can
update
these
independently
as
long
as
we
keep
to
that
API
contract.
A
That's
a
summary
of
the
reasoning
behind
this.
Ultimately,
it's
about
organizational
issues:
Jeff
Bezos,
the
founder
of
Amazon
talks
about
two
pizza
teams.
You
want
a
team
of
people,
the
small
you
can
take
two
pizzas
to
feed
them
and
that's
the
number
of
people
that
should
work
on
any
individual
service.
So
we
can
get
that
velocity,
so
they
can
deploy
their
software
faster.
A
A
You
have
to
run
on
the
JVM,
for
example,
we're
decreasing
how
much
a
single
person
needs
to
know,
so
they
can
care
about
the
things
that
matter
to
them
and
then
they
know
the
services
that
they
have
to
interact
with,
and
hopefully
something
that
goes
wrong
somewhere
else
in
that
graph
won't
affect
them.
So
that's
fantastic,
great
we've
decomposed
down
monolith,
we're
moving
faster.
We
can
test
easier,
we
have
these
abstractions
and
we
can
scale
our
services.
So
the
question
is
what
what
was
the
cost?
What
have
we
lost
here
inside
our
monolithic
process?
A
We
were
the
caller
and
we
were
the
destination.
So
we
knew
that
it
was
reliable
because
we
were
both
ends
running
in
that
same
process.
Now
that
call
goes
over
a
network.
The
network
may
be
insecure,
the
latency
on
the
network
might
be
high
or
it
might
change
over
time.
As
the
network
is
saturated,
you
have
to
worry
about
access
control.
Previously,
you
were
both
the
caller
and
the
destination.
A
Now
we
are
having
to
call
someone
and
verify
who
we
are
all
the
way
through
and
we
used
to
debug
these
processes
by
attaching
a
debugger
to
it
and
stepping
through
and
looking
at
what
happened.
Now
we
have
to
say
well,
I'm,
not
really
sure
what
we
do
here.
How
can
we
debug
these
things?
There
are
some
fixes
that
we
can
do
here.
A
If
we're
worried
about
service
a
calling
service
B,
we
can
say,
try
again,
maybe
wait
a
while
longer
if
the
first
one
fails
and
try
again
exponential
back-off,
and
then
we
can
add
some
headers
to
our
calls
to
say:
isolators,
printf,
debugging,
basically,
I
started
I
called
this
other
service.
I
responded
like
where
we
got
through
and
you
can
look
through
a
trail
of
logs
from
many
different
applications
to
figure
this
out.
A
A
A
A
We
need
to
be
able
to
say
what
is
it
that
our
application
is
doing,
and
then
we
can
monitor
and
alert
on
those
we
want
to
be
able
to
handle
the
encryption
and
identity
both
from
people
calling
outside
and
inside
the
network,
and
then
do
things
like
rotation
identity,
make
sure
that
only
services
that
are
allowed
to
call
each
other
can
do
so.
We
need
to
handle
traffic
management.
A
We
want
to
be
able
to
do
deployments
of
new
services
if
we
deploy
a
new
service,
we'd
like
to
send
a
small
portion
of
the
traffic
to
it.
Until
we
know
it's
successful
and
if
a
service
fails,
we
might
say
we
don't
want
to
keep
calling
that
service.
We
want
to
gracefully
degrade
if
we
display
a
webpage
and
it
has
a
little
widget
that
displays
the
weather.
If
the
weather
widget
is
broken,
you
can
still
display
the
rest
of
the
page.
Ok,
you
don't
need
to
wait
until
that
gets
built.
A
So
this
is
a
start-up
there's
about
40
people,
I
guess
working
here
at
the
time
and
ultimately,
when
we
think
of
what
we've
developed
internally
is
since
we
were
that
size.
We
talked
about
the
culture
of
site,
reliability,
engineering
or
SRE,
and
we
look
at
the
way
that
we
have
developed
services,
micro
services
or
larger
scale.
A
A
Ultimately,
we
can
think
of
this
is
a
food
group
pyramid
or
Maslow's
hierarchy
pyramid,
and
we
can
say
you
need
monitoring
before
anything
else
and
what
we've
done
is
we've
taken
monitoring
here
and
saying?
Well,
let's
break
monitoring
down
what
should
you
be
monitoring
for
micro-services?
So
we
call
these
four
the
golden
signals.
These
are
the
things
that
you
need
to
fundamentally
know
about
traffic
on
your
micro
services.
Environment
traffic
is
actually
the
first
one.
So
that's
the
the
volume
of
requests
or
requests
per
second
coming
in
to
your
service.
A
Then,
once
you
know
that
number
you
can
see
the
number
of
areas
knowing
the
number
of
areas
alone
isn't
good
enough,
because
if
you
have
a
hundred
errors,
is
that
a
lot
if
you
have
a
hundred
requests
than
100
areas
is
a
lot?
But
if
you
have
millions
upon
millions
of
requests,
then
that's
okay,
that's
a
small
percentage
and
that
might
be
within
your
acceptable
boundaries.
A
A
Customers
expect
apps
to
be
fast,
so
we
need
to
make
them
fast
and
we
need
to
measure
not
just
the
average
of
requests,
but
the
slowest
requests
you
talk
about
the
percentiles
99th
percentile
99.9,
the
tail
latency.
What
is
it
that
the
slowest
people
are
seeing
because,
ultimately,
that
will
dictate
when
things
get
slow
throughout
a
chain
of
course
to
microservices,
and
then
saturation
will
be
something
that
matters
custom
to
you
and
your
workload.
A
A
So
how
do
we
monitor
all
of
these
things?
Well,
we
use
a
proxy
server.
Traditionally,
people
will
think
of
a
proxy
service.
Something
like
this.
You
have
a
bunch
of
front-end
services
and
a
bunch
of
back-end
services
and
for
these
to
call
into
that.
They
call
into
this
mid
proxy
that
sits
between
them.
It's
able
to
do
some
authorizations
and
traffic
routing
or
a
load
balancer,
for
example,
and
you
have
a
proxy
per
certain
number.
A
So
if
you
have
10
replicas,
you
might
have
one
proxy
if
you
scale
up
you'll
need
to
scale
that
as
well,
so
we
moved
very
quickly
inside
Google
to
what
we
call
the
sidecar
model.
What
we
do
here
is
we
take
one
proxy
server,
a
smaller
one
and
we
deploy
it
along
with
every
back-end
servers.
So
we
wrap
these
things
up
and
deploy
them
together,
which
means
we
don't
need
to
make
any
changes
to
the
code.
We
basically
just
intercept
the
traffic.
A
That's
going
to
hit
that
service
through
the
proxy,
and
now
we
can
transparently
collect
that
telemetry.
We
don't
need
to
make
any
changes
to
the
service.
We
can
use
that
as
the
way
we
do
security
for
these
applications,
so
it
can
terminate
our
TLS
services
and
because
they're
distributed,
we
have
one
tied
with
every
back-end
we're
getting
rid
of
the
single
point
of
failure
of
that
single
proxy
server.
So
we
gain
distributed
load
balancing
you
end
up
with
something
like
this.
A
If
the
front-end
service
wants
to
talk
to
the
payment
service,
it
just
calls
out,
it
looks
up
the
hostname
payments
and
it
connects
out
to
that.
It
is
transparently
intercepted
by
a
proxy
on
the
way
out
and
then
at
the
payment
service
which
can
make
decisions
on
whether
or
not
to
allow
that
traffic.
But
it
doesn't
know
the
front-end
service
doesn't
know
it
just
calls
out
to
payments,
and
it
just
works
from
its
perspective.
A
That
gives
us
a
lot
of
flexibility
here.
So
the
traffic
into
our
workloads
being
intercepted
means
we
can
do
things
like
look
at
quota.
Is
there
a
too
many
requests
being
made
to
the
service?
For
that
particular
user?
We
can
take
authentication
and
authorization
decisions
and
move
them
out
of
your
application.
So
your
developers
don't
need
to
keep
rewriting
that
same
code,
and
we
can
do
the
same
thing
on
the
way
out.
A
So,
with
all
of
the
same
things
there
for
metrics
and
logs
and
ensure
that
those
services
don't
have
to
worry
about
security
themselves,
they
just
trust
that
the
network
does
that
for
them.
We're
able
to
also
do
things
like
dynamic
routing,
so
we've
said
before
we
want
to
send
a
certain
percentage
of
queries
to
a
new
service.
It
doesn't
know
that
it's
happening
at
the
service
level,
but
we
program
the
proxies
to
do
that.
For
us
all
of
this
is
done
without
having
to
make
any
changes
to
your
application
code.
A
So
you
start
off
with
a
micro
services
architecture.
It's
very
simple:
it
just
looks
something
like
this.
You
describe
in
the
standard
format,
perhaps
of
a
communities
deployment.
This
is
what
I
want
to
have,
and
the
cluster
knows
that
it
needs
to
deploy
these
proxies
when
you
deploy
these
workloads.
So
it
puts
them
in
there
like
this
again
we're
still
talking
in
the
abstract
here
about
the
service.
What
becomes
a
service
mesh?
A
So
then,
once
you've
got
all
of
these
proxies
running
along
with
your
backends
and
an
ingress
proxy,
so
that
you
can
work
on
traffic
from
outside.
How
does
it
know
what
to
do?
Well,
we
already
have
a
pattern
for
taking
a
lot
of
nodes
and
telling
them
what
it
is
to
do
and
it's
the
born
pattern.
What
became
the
kubernetes
pattern?
A
You
have
a
control
plane,
you
can
figure
that
control
plane
and
then
it
sends
information
out
to
a
bunch
of
agents
that
control
plane
will
then
program
and
maintain
the
proxies,
so
it
will
inform
them
all
of
the
state
of
the
services
in
your
environment,
so
everything
that's
deployed.
It
tells
each
proxy
server
for
this
particular
service.
Here
are
the
endpoints,
so
if
it
is
doing
round-robin
load
balancing,
for
example,
it
knows
the
things
it
needs
to
round-robin.
It
doesn't
need
to
call
out
to
someone
else
to
do
that.
A
It
needs
to
teach
the
proxy
servers
where
to
send
the
metric
information
so
when
it
has
requests-
and
it
reports
back
the
latency
so
on,
what's
back-tracing
headers,
it
sends
that
to
a
central
place,
which
is
part
of
the
control
plan,
proxies
enforce
policy.
So,
if
you've
enforced
something
about
rate
limiting
or
quotas
or
which
users
can
access
a
particular
service,
you
need
to
teach
the
proxies
how
to
do
that.
A
So
we
do
that
with
the
control
plane
also,
and
then
it
also
handles
certificate,
provisioning
and
rotation
so
that
we
can
encrypt
the
traffic
between
all
of
these
services
now,
hopefully
by
now.
This
will
sound
very
familiar
to
you
all.
So,
first
of
all,
if
anyone's
remembers,
Software
Defined
Networking
anyone
works
at
that
layer.
We've
basically
just
reinvented
that,
but
the
difference
is:
is
that
we're
doing
it
at
layer
7,
so
we're
able
to
make
decisions
based
on
application?
A
Headers,
we're
able
to
say
this
traffic
came
in
from
a
particular
user,
whose
name
we
know
or
a
device
of
a
particular
type
and
we're
able
to
say
here's
a
new
service
that
we're
testing,
which
is
going
to
work
for
Android
users,
we're
not
testing
on
iPhone
users
today.
So
anyone
who
has
a
user
agent
that's
his
Android,
we
can
redirect
their
traffic
and
that
is
only
exposed
to
us
in
an
HTTP
header.
A
A
Ibm
had
an
open
source
project
called
amalgamate,
which
was
doing
network
routing.
We
talked
to
them
and
said:
look
we're
looking
to
do
something
in
this
space
and
then
we
said
great,
we'll
work
together,
and
so
that
is
where
we
got
to
sto
now,
I'm
not
going
to
do
too
much
more
of
an
overview
of
sto,
because
I
already
have
so
everything
you've
seen
so
far.
While
it
also
describes
our
internal
system
at
Google,
it's
a
fairly
good
description
of
the
things
you
can
do
with
this.
A
Do
you
install
the
control
plane
into
your
kubernetes
environment?
You
configure
the
cluster
so
that
when
you
deploy
a
pod
spec
to
it,
it
knows
that
it
needs
to
deploy
the
sidecar
proxy
along
with
it.
The
proxy
server
that
we
use
is
called
Envoy,
which
is
a
CNC
F
project.
It
is
built
initially
by
lift
the
car
company
ride-sharing
company
in
San
Francisco
for
their
micro
services
infrastructure.
So
it
is
purpose-built
for
this
kind
of
thing.
A
We
built
the
control
plane
to
configure
it
and
when
you
deploy
that
into
your
environment,
you
get
all
of
that
stuff
before
I'm,
pretty
much
for
free.
So
I
want
to
talk
to
you
today
about
three
customers
that
I
work
with
about
why
they
have
had
problems
that
needed
a
solution
like
this
and
what
they
found.
A
The
first
company
is
called
Descartes
labs.
Descartes
labs
are
a
reasonably
new
company,
they're,
a
spinoff
of
the
Los
Alamos
National
Laboratory
in
the
USA,
and
they
make
machine
learning
models
on
earth
data.
They
get
geospatial
data,
they
get
it
from
satellites,
they
get
it
from
weather
imagery.
They
look
at
light
over
time
and
they
combine
all
of
these
things
together
to
get
ideas
of
what's
happening
around
the
planet
and
how
they
can
apply
that
predictively
to
other
parts.
A
They
sell
this
information
to
forestry,
to
agriculture,
businesses
and
they
allow
people
to
make
predictions
about
things
like
global
food
supply,
and
will
there
be
political
unrest
in
a
particular
region
because
of
that
they
can't
built
their
environment
with
micro-services
architecture.
They
build
it.
On
top
of
kubernetes
running
on
GK
and
Tim
told
me
a
great
story
about
the
early
deployment.
He
was
out
riding
his
mountain
bike
in
the
Sedona
forest
in
the
USA
and
he
got
a
text
message.
A
That
said,
someone
had
accidentally
deleted
all
of
their
VMs
they'd,
just
taken
everything
out
by
the
time
he
got
back
to
have
a
look
at
it.
Kuba
net
is
GK,
had
recreated
the
VMS,
and
then
kubernetes
had
said
the
workload
that
you
asked
for
isn't
running,
so
did
it
recreated
it,
and
everything
came
back
up.
That's
exactly
what
kubernetes
is
meant
to
do.
That's
why
we're
all
here,
because
it
solves
that
exact
problem,
so
they've
got
an
environment
which
is
running
great
for
them
on
kubernetes,
it's
running
a
little
bit
too.
Well,
it
turns
out.
A
Sometimes
it's
a
bit
slow.
Sometimes
a
call
to
one
of
their
services
takes
longer
than
it
should,
but
they
don't
know
why.
Now
they
have
monitoring
in
their
applications,
so
they've
deployed
things
like
graph
honor
and
in
flux
so
that
they
can
get
metrics
out
of
their
particular
services,
but
sometimes
one
of
the
microservices
would
just
spike,
and
you
know
it
has
spiked,
but
you
don't
know
why
the
requests
have
just
gone
up
is
really
hard
to
tell
what
it
was
that
caused
that
so
by
deploying
sto
into
their
environment.
A
They're
now
able
to
get
metrics
of
the
traffic
between
the
services
and
find
out
who's,
calling
who-
and
it
turns
out
that
they
made
these
micro
services
that
are
very,
very
useful
to
do
certain
things
in
their
environment,
they've
scaled
them
for
the
size
that
they
need
for
their
production
workloads.
But
other
teams
have
said.
Oh,
that's,
a
useful
micro
service,
I'm
gonna
start
calling
that
service
as
well
I'm,
going
to
send
development
tests
traffic
to
that
service
at
a
particular
rate
and
because
they've
sized
everything
for
production
or
they
haven't
thought
to
order
scale.
A
This
particular
service.
This
one
service
is
getting
hammered
and
that
is
therefore
causing
all
of
their
users
who
are
paying
for
the
service
to
get
a
slow
service
and
so
they're
able
to
see
visibility
into
the
amount
of
traffic
going
to
each
service.
Very
quickly.
Identify
this
and
then
water
scale
the
service
or
find
out
who's,
calling
their
service
and
say
hey.
It's
not
designed
for
this.
Please
don't
do
that,
so
it
gave
them
an
overview
of
the
system
and
let
them
identify
the
areas
that
were
troubled
now.
A
They
sell
that
service
out
to
customers
and
they
want
to
be
able
to
offer
an
SLA.
So
an
SLA
is
basically
a
legal
agreement
that
says
if
the
software
wasn't
available
for
at
least
99.5%
of
the
time,
then
we
give
you
back
some
money
in
order
to
be
able
to
do
that,
they
need
a
couple
of
other
things.
They
actually
need
to
set
their
objective
and
say:
well,
we
need
to
try
and
hit
this.
That's.
A
The
99.5
is
what
we
call
a
service
level
objective
or
an
SLO,
and
then
in
order
to
know
whether
or
not
you
hit
that
you
need
to
indicate
it,
you
need
a
way
of
saying
what
was
it
that
succeeded
or
failed,
and
you
need
to
understand
the
baseline
performance.
They
say
this
is
how
things
work
in
the
general
case,
so
that
you
know
when
things
are
out
of
whack.
A
If
you
want
to
be
able
to
offer
a
service
that
is
this
reliable,
you
need
to
make
sure
all
the
services
you
depend
on.
Are
that
reliable
or
more?
And
you
need
to
be
able
to
know
what
your
own
target
s
loz
are
in
order
to
be
able
to
offer
one
out
to
a
customer
so
being
able
to
tell
the
amount
of
traffic
going
to
each
service
being
able
to
see
for
this
particular
set
of
service
calls
or
for
traffic
coming
in
from
this
particular
user?
A
This
is
what
it
has
looked
like
over
time,
the
the
all
of
the
requests
that
have
come
and
we
have
been
able
to
serve
98%
of
them
this
month,
the
others
have
returned
500
errors,
or
something
like
that.
You
get
all
of
this
graphed
for
you
automatically.
The
telemetry
information
is
sent
to
the
sto
mixer
service,
and
then
you
can
configure
that
to
send
it
to
Prometheus
to
send
the
spectro
monitoring
to
in
flux
DB
anything.
But
you,
like
you,
configure
that
you
define
what
is
acceptable
for
you
and
your
business.
A
How
many
errors
are
okay,
where
the
latency
is
okay
or
whether
things
have
to
return
within
a
certain
period?
And
then
you
can
sit
alerting
on
this.
You
can
say
I'm
trending
downwards.
I
know
that
I've.
Ninety
nine
point:
five
percent
is
seven
minutes
per
day
that
the
service
can
be
unavailable.
So
if
you
know
that
you're
trending
down
for
a
particular
day,
you
might
say
that's
a
problem
or
you
might
define
the
service
generally
SLO
zero,
like
a
30
or
a
28
day
period.
A
So
you
need
to
be
able
to
be
aware
that
you're
trending
downwards
in
this
re.
We
flip
that
around
and
say
that
that's
seven
minutes
per
day,
that's
called
your
error
budget.
That's
how
much
you're
allowed
to
be
down.
If
you
wanted
to
be
down
less
than
that,
you
should
make
your
SLA
higher
usl
Ohio,
sorry,
but
that's
a
business
choice,
because
that
costs
more
to
do
so.
When
you
start
eating
up
that
error
budget,
you
should
be
alerted
or
you
need
a
human
at.
A
A
This
is
one
for
a
sample
app
that
we
have
and
it's
great
it
says
this-
should
call
that,
and
this
should
call
that
and
so
on,
but
that
was
true
at
the
time
it
was
drawn
and
because
environments
are
always
changing,
it
might
not
be
true
anymore,
so
you
are
able
to
draw
based
on
the
traffic,
that's
actually
flowing
through
your
environment,
either
now
or
at
a
point
in
time
in
the
past,
because
you
have
all
this
information
stored
in
prometheus.
Something
like
this.
A
This
is
a
version
of
that
same
application
deployed.
This
is
a
now
stackdriver
service,
but
you
can
see
what's
calling
what
and
you
can
drop
drill
in
to
each
of
those
links.
Click
on
them
and
find
out
what
the
number
of
requests
per
second
are
between
them
and
then
go
through
and
set
those
this
allows,
for
example,
another
good
tool
for
that
is
a
key
ally
which
I
think
is
being
integrated
with
the
SDO
to
replace
the
default
service
mesh
that
was
built
by
Red
Hat.
A
It's
an
open-source
again
a
service
graph
that
can
that's
looking
at
the
default
book
info
that
comes
with
this.
Do
there,
but
can
draw
these
things
here,
not
just
for
individual
services,
but
for
versions
of
the
service
that
are
defined
with
them.
That
Descartes
were
one
of
the
very
early
users
of
osteo.
They
were
in
the
0.2
timeframe.
We
said
so
just
a
couple
of
months
after
sto
was
released.
They
were
running
it
in
production,
another
very
early
user
of
sto,
auto
trader.
A
A
So
this
company
was
founded
before
the
cloud
they
have
their
own
data
centers
like
everyone
in
that
particular
time
they
have
an
app.
That's
mostly
written
in
Java
I
have
a
personal
story:
I'm
gonna
have
to
go
cuz,
we
started
a
bit
later
on.
We
have
to
go
a
little
bit
over
time,
but
that
should
be
okay,
because
we're
going
into
lunch,
but
I've
only
ever
owned.
One
car
in
my
life,
it
is
a
was
a
1993.
Vauxhall
cavalier
looks
very
much
like
that.
A
One,
there
I
went
I'm
from
New
Zealand
and
the
first
time
I
went
so
second
time
I
went
to
England
was
on
holiday.
With
some
friends,
it
was
going
to
cost
a
thousand
pounds
to
rent
a
car
for
three
weeks.
So
what
I
did
is
I
went
to
auto
trader
and
I
bought
a
car
I
bought
it
for
300
pounds
now,
I
had
to
pay
a
hundred
and
fifty
pounds
to
get
car
insurance
for
three
weeks
and
then
at
the
end
of
that
three
weeks,
I
sold
the
car
for
280
pounds.
A
A
A
They
didn't
have
to
do
any
of
that
after
they
chose
kubernetes,
they
had
to
decide
where
they
wanted
to
run
and
again
they
don't
have
to
worry
about
machinery,
so
they
made
the
choice
to
move
to
cloud,
so
they
have
moved
some
services
again
to
Google
communities
engine,
but
they
needed
to
make
three
migrations
all.
At
the
same
time,
they
need
to
move
to
containers
for
kubernetes
they
had
to
move
to
cloud
and
they
also
needed
to
upgrade
the
Java
version
at
the
time.
A
So
they
thought
that
a
great
way
to
validate
everything
worked
at
the
end
of
this
would
be
using
a
service
mesh.
Now
around
the
same
time,
in
Europe.
We're
working
on
this
thing
called
the
general
data
protection
regulation
gdpr,
which
means
certain
rules
are
required
for
businesses
in
terms
of
privacy,
and
it
used
to
be
that
you
just
let
people
send
encrypted
traffic
to
the
edge
of
your
network,
and
then
you
just
send
clear
text
inside
it's
not
really
good
enough
anymore
with
the
gdpr.
A
So
we
need
to
be
able
to
prove
to
regulators
or
so
on
that
everything
is
secure,
so
they
wanted
to
be
able
to
deploy
services
and
guarantee
that,
with
security
all
the
way
through
now
they
have
these
Java
applications.
Java
is
not
traditionally
the
best
way
to
terminate
TLS.
You
normally
put
some
sort
of
sidecar
in
front
of
it,
so
they
were
looking
at
nginx.
A
They
were
looking
at
the
boulder
service
which
powers
let's
encrypt,
but
then
they
would
still
have
to
write
all
their
own
code
for
certificate
rotation,
so
this
was
again
was
when
Ostia
was
announced.
They
were
great.
This
will
give
us
not
only
TLS
and
encryption,
but
it'll
give
us
mutual
TLS
where
we
can
validate
the
identity
of
both
ends
and
within
one
day
they
were
able
to
get
something
that
they'd
wanted
for
three
months
by
installing
sto
in
their
test
environment.
They'd
wanted
that
capability.
It
was
great.
A
Most
of
that
work
was
done
by
two
guys
between
Christmas
and
New
Year's,
so
security
was
their
first
driver.
Observability
was
their
second
driver,
so
their
test
application.
They
actually
found
a
memory
leak
in
the
application
that
they
ran.
The
major
website
for
that
had
been
running
in
production
for
a
very
long
time
and
they
were
able
to
go
back
and
tell
that
team
actually
yeah.
We
found
the
problem
that
you
don't
normally
see
cuz,
maybe
you
just
reboot
the
thing
every
day
or
something,
but
they
found
now
that
they
have
teams
coming
to
them.
A
The
cloud
team
who
are
saying
we
want
to
run
our
app
in
the
cloud
not
because
it's
cheaper
or
because
it's
more
scalable,
but
because
we
think
your
tools
are
going
to
be
able
to
help
us
find
errors
in
our
application
better
than
our
own
tools
on
the
topic
of
pricing
and
so
on.
Auto
trader
have
built
some
great
dashboards.
A
A
They
take
the
amount
of
CPU
it
requests
and
multiply
that
by
the
price
of
a
core
hour
on
the
cloud
and
they're
able
to
say
this
is
how
much
it
costs
to
run
each
application
and
then,
by
connecting
it
with
this,
do
they're
able
to
say
this
is
the
traffic.
This
is
the
the
success
rate
of
that
application.
If
I
lower
those
limits,
I'm
still
succeeding,
so
they
actually
found
they're
able
to
drop
how
much
CPU
they're
allocating
to
their
applications
while
maintaining
it
still
does
what
it
wants
and
they've
cut
their
prices
substantially.
A
As
a
result
of
this,
some
of
this
is
open
source.
There's
a
a
blog
post
which
I'll
put
a
link
to
in
the
end,
but
they're
showing
dashboards
like
this
to
their
customers.
Some
of
the
metrics
come
from
Prometheus
and
from
the
applications
some
come
from
sto,
but
they
don't
care
as
far
as
the
service
owner
is
concerned,
they're
seeing
a
dashboard
that
relates
to
their
service.
It's
not
so
much.
A
Maybe
we
both
for
businesses
and
then
a
payments
and
payroll
service,
and
these
two
applications
both
have
their
own
data,
but
because
they
both
deal
with
employee
data.
They
have
to
have
what
they
call
magic,
synchronize
them
and
they
have
a
service
which
links
those
two
things
together
and
ultimately
they
wanted
to
be
able
to
decouple
these
things
and
get
to
point
where
they
were
building
fast
and
micro-services
environment
and
helping
the
developers
focus
only
on
their
business
logic.
A
They
knew
that
as
they
scaled
the
number
of
services
from
two
to
hundreds
generally
with
linear
scale
length,
you
would
need
to
scale
the
number
of
people
that
you
have.
Also
your
one
person
supporting
each
service.
You
now
go
from
two
people
to
100
people,
so
they
want
to
scale
sub
linearly.
They
want
to
be
able
to
automate.
They
want
to
be
able
to
fight
what
we
call
toil
and
sre,
which
is
running
repetitive
tasks
over
and
over
again
things
that
are
not
particularly
necessary.
A
So
to
do
that,
they
want
to
cut
down
that
toil
by
making
sure
that
every
developer
uses
standard
libraries
they
use
the
same
RPC
mechanism
and
that
they
don't
have
to
worry
about
things
like
authorization
and
authentication
that
can
just
be
done
as
boilerplate,
so
they
adopted
this.
Do
they
put
that
on
top
of
again
they're
Cubans
clusters,
these
ones
running
on
Amazon,
and
they
get
metrics
exported
for
free?
You
don't
have
to
write
boilerplate
code
to
say,
please
send
out
these
metrics.
All
of
that
stuff
is
done
for
you.
A
It's
sent
out
to
the
monitoring
service.
People
would
have
to
write
the
retry
logic
before
they'd
have
to
write
their
own
implementations
with
bugs
in
many
different
languages.
It
was
toil,
it
was
unnecessary.
They
got
rid
of
it.
If
you
call
a
service
and
the
service
says:
hey
I'm
overloaded
gives
you
a
500
error.
They've
got
a
circuit
breaker,
so
they
say
we
won't
call
that
again
for
10
minutes
or
so
on,
we'll
let
it
calm
down.
We
don't
need
to
show
those
reviews
if
we
don't
have
to.
A
If
we
think
that's
going
to
be
done,
they
can
validate
authentication,
so
they
put
the
users
information
encrypt
that
into
a
jot
and
then
each
service,
all
the
way
through
as
part
of
sto,
can
just
validate
that
job.
So
you
can
configure
it
with
the
key
that
has
signed
it
and
then
each
service
in
the
Envoy.
This
is
just
straight
out
of
the
sto
Docs.
You
configure
a
policy
that
says,
take
that
key
check
that
it's
still
valid.
If
it's
timed
out,
it's
not
valid.
A
Another
very
cool
thing
that,
namely
have
done
used
another
CN
CF
project
called
telepresence,
which
lets
you
substitute
a
two-way
proxy
server
for
a
particular
workload
in
a
kubernetes
cluster
that
sends
traffic
back
to
a
developer's
laptop
and
they
use
it
like
this.
They
have
services
that
call
each
other
in
the
cloud.
A
But
if
a
particular
user
wants
to
debug
something,
they
configure
it
to
say
that
when
a
request
comes
through
with
ver
user
header,
instead
of
the
traffic
being
routed
to
service
B,
it
gets
routed
to
serve
as
B
prime,
which
is
a
telepresence
pod,
which
sends
it
back
to
the
developers
laptop
over
the
tunnel.
Then
they're
able
to
attach
the
debugger
to
their
local
version
of
this
and
they're
able
to
debug
that
themselves
without
having
to
do
anything
complicated
running
on
the
cloud
and
this
dios
traffic
routing
makes
that
possible
just
wrapping
up
very
quickly.
A
You
can
adopt
sto
in
pieces.
My
colleague
Dan
likes
to
call
it
Sto
a
la
carte.
The
three
main
things
that
we
see
is
people
taking
as
a
benefit
out
of
Sto.
Are
a
traffic
control
being
able
to
do
canary
deployments
and
routing
people
for
various
versions,
telepresence
and
so
on
the
observability
and
then
the
security
you
get
from
applying
mutual
TLS?
If
you
want
to
know,
what's
going
on
in
your
environment,
deploy
the
sidecars
deploy,
mixer,
see
what's
happening,
but
don't
configure
any
policy,
don't
do
security.
A
Things
might
break
if
you
put
TLS
into
your
environment,
so
you
don't
want
to
do
that
unless
you're
able
to
validate
it.
If
you're
worried
about
only
traffic
coming
from
the
inside,
so
we'd
have
customers
where
they
don't
have
any
service
to
service
traffic.
They
host
for
many
different
customers.
They
host
one
pod
per
customer.
All
the
traffic
comes
from
the
Internet
to
that
pod.
If
pod
a
talks
to
pod
B,
that's
wrong,
it
shouldn't
ever
happen,
so
they
only
run
the
SDO
ingress
and
they
don't
run
the
sidecars.
A
Therefore,
I
don't
need
to
worry
about
shaping
my
network.
You
can
run
a
flat
network
and
move
the
security
to
your
application
layer.
So
two
pieces
of
advice
where
this
do
start
small
find
the
piece
that
works
for
you
and
then
a
play
that
we
are
working
in
the
project
to
make
it
possible
to
deploy
it
in
parts.
So
the
third
with
a
helmet
installation,
you
just
install
the
pieces
that
make
sense
for
you.
If
you
don't
need
security,
don't
install
security.
A
My
second
piece
of
advice
is:
you
should
listen
to
the
kubernetes
podcast,
which
I
co-host
with
my
friend
Adam,
who
I
was
around
before
I.
Don't
see
him
now,
but
I've
seen
at
least
a
few
stickers
in
the
audience.
So
thank
you
very
much
for
those
of
you
who
have
gone
and
got
them,
but
you
can
just
throw
that
into
your
podcast
player
or
go
to
kubernetes
podcast
comm.
If
you
enjoy
listening
to
me
talk
and
with
that,
that's
the
end
of
my
presentation.
Thank
you
very
much.