►
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
In a productive cloud-native development workflow, individual teams can build and ship software independently from each other. But with a rapidly evolving Cloud Native Landscape, creating an effective developer workflow on Kubernetes can be challenging. We are all creating software to support the delivery of value to our customers and to the business, and therefore, the developer experience from idea generation to running (and observing) in production must be fast, reliable, and provide good feedback.
In this webinar, we’ll discuss:
- Why an efficient development workflow is so important
- The role of Kubernetes, Envoy, Prometheus, and other popular cloud-native tools in your workflow
- Key considerations in implementing a cloud-native workflow
A
All
right
we're
going
to
go
ahead
and
get
started.
Welcome
to
today's
CN
CF
webinar,
creating
an
effective
developer
experience
on
communities,
I'm,
Bob,
Kealing
senior
research,
cloud
administrator
for
the
University
of
Michigan
I'd
like
to
thank
everyone
for
joining
us
today.
We
would
like
to
send
a
warm
welcome
to
Daniel
Bryant
I'd
architect
that
data
wire
you'll
be
our
presenter.
Today.
We
appreciate
him
sharing
his
expertise
on
effective
developer
workflow
with
our
listeners
today
before
I
hand
it
over
to
him
there's
just
a
couple
housekeeping
items
during
the
webinar.
You
are
able
to
talk.
A
Isn't
there
you
are
not
able
to
talk
to
the
attendees
right.
There
is
a
chat
window
at
the
bottom
or
the
Q&A
function.
Please
feel
free
to
drop
your
questions
in
there
and
we'll
get
as
many
as
we
can.
At
the
end,
the
session
is
being
recorded
and
will
be
sent
out
afterwards,
along
with
a
link
to
the
presentation.
With
that,
I
would
like
to
go
ahead
and
hand
it
over
to
Daniel
awesome.
B
Thanks
to
the
enjoyable
great
stuff,
so
let's
get
started
so
the
title
itself
may
be
a
little
cryptic
there
cryptic
and
not
sure
everyone's
heard
of
developer
experience.
Yet
so
I
thought
I
just
start
by
introducing
and
some
of
the
kind
of
concepts
a
little
bit
pictorially
and
then
we'll
look
at
the
actual
text
as
well.
So
for
me,
developer
experience
is
primarily
about
having
this
great
idea.
B
Maybe
a
hypothesis,
you
know
a
new
business
kind
of
idea,
whatever
taking
all
the
resources
we've
got
and
I'm
going
to
use
the
container
and
the
shipping
yard
analogy,
because
we
all
love
containers
and
shipping
words
yeah.
But
we've
got
this
idea
in
these
resources.
How
do
we
get
it
to
I
uses
delivering
business
value?
You
know
making
their
day
better,
making
their
lives
easier.
Do
they
bring
some
form
of
value?
Now,
most
of
us.
You
know
if
you're
here,
you're,
probably
interested
in
deploying
apps,
using
something
like
communities
and
containers
and
so
forth.
B
So
pretty
much
now,
I
use
the
container
metaphor
exactly
here.
Developer
experience
is
the
bit
in
the
middle
the
bit
that
we
know
taking
our
ideas
through
delivering
around
you
now
using
the
shipping
energy.
It's
pretty
much
the
loading
of
the
containers,
its
inspecting
the
manifests
and
when
something
goes
wrong,
knowing
how
to
fix
it.
That's
kind
of
a
key
developer
experience.
That's
a
good
developer
experience.
They
can
be
hard
to
quantify
sometimes
but
I'm
sure
many
of
you
listening
recognize
a
bad
developer
experience.
B
Maybe
you've
got
that
kind
of
tool
that
you
know
promises
great
things,
but
it
constantly
falls
over
and
we
had
that
my
career-
or
maybe
you
know,
you're
getting
close
to
production
and
or
you're
in
production.
Something
falls
over
and
you
can't
figure
out.
What's
going
on,
you
can't
debug.
You
can't
observe
now
this.
B
For
me,
this
bit
in
the
middle
is
fundamentally
the
experience
I
have
as
a
developer
or
an
engineer,
and
it
is
really
important
to
get
this
right
and
with
every
new
technology
that
comes
along
I've,
been
in
the
industry
about
15
or
so
years.
Now
the
developer
experience
subtly
shifts
from
kind
of
sower
to
monoliths
now
to
micro
services
and
containers
and
so
forth,
and
we
as
engineers
need
to
kind
of
adapt
our
experience.
B
If
you're
a
platforms
engineer,
you
need
to
adapt
what
you're
offering
say
your
users,
your
developers,
your
engineers
and,
if
you're,
an
engineer
yourself,
you
need
to
adapt
to
the
platform
work
very
closely
with
the
ops
team,
with
the
platform
team,
so
help
figure
out
exactly
what
we
do
need
to
create
that
smooth
kind
of
path
from
idea
to
delivering
value.
The
kind
of
TLDR
really
today
is
that
developer.
Experience
is
all
about
minimizing
the
friction
from
the
idea
through
to
the
code
in
the
config
to
delivering
business
value.
B
It
is
gonna,
be
a
conceptual
talk
not
with
lots
of
code
in
the
screen,
for
example,
but
I'm
trying
to
get
you
to
think
about
the
developer
experience
with
kubernetes
and
there's,
hopefully
there's
some
links
that
you'll
find
useful
for
going
into
more
of
the
details
with
only
sort
of
like
you
know,
40
minutes
the
talk
or
whatever
there's
only
so
much
opinion
and
so
much
code.
You
can
kind
of
share,
so
I'm
gonna
focus
more
on
the
concepts.
B
This
is
me
at
Daniel,
Bryant,
UK,
on
github,
on
Twitter,
on
LinkedIn
and
so
forth.
I
started
my
career
as
an
academic
move
through
to
the
software
development
working
from
everything,
from
small
startups
to
government
departments
as
a
CTO,
a
couple
of
small
Penny's
than
some
training
and
now
I'm
working
with
a
company
called
data
wire,
a
boston-based
company,
we're
focusing
very
much
around
developer
experience
on
kubernetes
and
we've
got
the
CNC
F
hosted
tool
a
telepresence.
We
were
the
creators
of
that
and
we
also
do
the
Ambassador
open
source,
API
and
Gateway
as
well.
B
I'm
shameless
plug
I'm
writing
a
couple
of
books.
So
I'd
love
your
feedback
on
the
books
as
well.
You
can
see
the
links,
bank
and
well
now
share
the
slides
and
later,
but
I
do
realize
throughout
my
15
years.
As
an
engineer,
it's
as
much
about
the
teamwork
and
the
people
as
it
is
about
technology,
I,
love,
containers,
love,
Cuba,
Nettie's,
love,
Java
and
so
forth,
but
I
realized
that
to
really
get
the
the
best
out
of
my
team
and
have
the
most
fun
and
deliver
the
most
value.
B
We've
got
to
think
about
the
whole
experience
and
that's
what
we're
gonna
look
at
today,
so
setting
the
scene
and
your
cloud
native
is
a
thing.
If
you
haven't
heard
it's
a
thing:
yeah
they've
got
a
whole
foundation,
man
at
the
CN,
CF
and
so
forth,
and
it
really
is
driving
all
forms
of
software
development.
You
know
I
definitely
up
towards
a
CNC
F
I've
been
to
coop
cons
and
the
cloud
native
cons,
fantastic
conferences
and
I
do
sort
of
lean
towards
the
CNC.
B
After
my
definition
of
cried
native
I
know,
there's
a
new,
a
definition
coming
out.
If
you're
involved
in
the
talk
you
sort
of
seeing
some
new
definitions
coming
around,
but
fundamentally
what
the
CNC
F
are
saying
with
cloud
native
tech
is
its
container
packaged
and
dynamically
orchestrated
or
dynamically
managed,
and
we're
typically
developing
new
applications
using
certain
sort
of
patterns
like
micro
services,
like
event-driven
architecture
and
reactive
and
reactive
kind
of
very
much
things
like
that:
a
dead,
a
while
we've
talked
a
lot
about
and
this
being
sort
of
a
flywheel.
B
If
you
get
the
client
native
thing
right,
we've
kind
of
got
sort
of.
You
know
four
bits
to
our
wheel.
Here
you
get
it
right.
It's
a
it's
a
virtuous
circle.
You
can
go
so
much
faster
and
you
can
very
sort
of
developments
perience
across
your
teams,
depending
on
who
needs
to
go
faster,
who
need
stability.
These
kind
of
things
so
feel
free
to
explore
these
links.
I'd
also
recommend
having
a
look
at
Sam.
Newman's
idea
on
cloud
native
Sam
is
a
slightly
contrarian
view
here,
but
I
always
like
Sam's
work
as
Sam
is
created.
B
The
building
microservices
book
I'm.
Sure
many
of
you
bumped
into
his
work,
always
enjoyed
chatting
to
Sam,
always
learning
a
bunch,
and
this
talk
is
a
bit
different
in
terms
of
Sam
saw
here.
But
what
cloud
native
is,
but
it's
a
nice
kind
of
thing
to
read
fully
rise,
our
our
view
of
what
cloud
native
is
but
I'm
gonna,
mostly
assume
you
know
we're
building,
microservices
we're
pushing
sort
of
code
down
a
CI
CD
pipeline
and
we're
packaging
ink
in
containers
and
deploying
and
cube
Nettie's
for
this
presentation.
B
Workflow
is
super
critical.
These
are
the
three
kind
of
things
I
look
at
and
I
didn't
ask
Wendy's
in
a
couple
of
weeks
ago,
actually
and
I
think
it's
kinda
like
Maslow's
hierarchy
of
needs.
You
know,
definitely
need
to
get
the
infrastructure
right
and
then
build
the
platform
on
top
and
then
correspondingly
create
a
workflow,
but
I
also
think
it's
more.
The
workflow
can
have
a
bigger
impact
on
velocity
and
business
value.
You've
gotta
build
on
firm
foundations,
but
how
you
how
we
as
engineers,
work
together
and
create
code
from
idea
to
value?
B
Is
it
really
makes
a
massive
difference?
If
you
don't
invest
time
in
it?
In
my
experience,
you
can
have
the
most
amazing
platform
in
the
world,
but
you
still
might
be
slow
or
you
might
have
REM
systems
falling
down
around
you.
For
example,
we're
gonna
be
focusing
on
the
platform
on
work
phone
today
you
know
what
is
workflow
critical
question
to
ask
and
the
platform
heavily
influences
the
workflow,
so
how
you
use
kubernetes,
how
you
interact
with
communities
as
an
operator
as
a
developer,
makes
a
massive
difference
and
then
I'm.
B
B
But
Waterfall
assumes
you
know
all
your
a
crime
requirements
upfront
if
you're
building
kind
of
you
know
defense
systems
which,
where
this
kind
of
model
came
from
alchemy,
you
would
know
a
lot
of
these
requirements
upfront
if
you're
building
bridges,
for
example,
you
know
to
look
at
a
real
world
scenario.
You
know
requirements
up
front,
but
with
software
we
often
don't.
B
Loop
now
I've
taken
this
graphic
I'm,
a
Netflix
blog
I'll
share
the
link
later
in
a
minute,
but
we
really
now
need
to
focus
on
maximizing
the
sort
of
time
to
so
minimizing
the
time
to
value
maximizing
our
through
foot
and
the
Netflix
team
talked
about
very
much
around
having
cross-functional
teams
and
these
teams
have
got
developers.
They've
got
QA,
they've
got
PM's
they've
got
everything
you
need
to
basically
offer
a
product,
so
they're
moving
sort
of
away
from
projects
a
to
products.
B
They're
now
offering
you
know
the
streaming
playback
service
or
in
Netflix's
case
well,
they're
offering
some
kind
of
analytics
service,
and
this
puts
a
lot
more
demand
on
individual
engineers
and
teams
of
engineers
and
the
platform
itself,
and
that
kind
of
you
know
comes
together
as
an
experience.
We're
looking
at
particular
kubernetes
and
I've
pulled
part
some
of
this
stuff
on
on
the
dead
of
our
blog
and,
fundamentally,
you
can
see
on
the
bottom
left
of
the
diagram
there.
We
have
our
idea,
you
might
need
to
do
some
sort
of
coding
locally.
B
You
deploy
it
to
Cuba
Nettie's,
you
experiment,
you
can
Airi
test
all
these
kind
of
things
and
then
you
measure
the
impact
using
maybe
like
a
tool
of
Prometheus.
Something
like
that.
Now
a
lot
of
these
tools.
You
know
the
different
stages
here
are
interchangeable.
You
can
kind
of
you
know,
create
your
workflow
as
you
desire
and
there's
also
sort
of
some
core
ideas
like
get
ops
coming
up
around.
That
sort
of
how
the
whole
workflow
is
assembled,
but
fundamentally
these
for
me,
are
the
five
key
stages
in
the
workflow.
We
have
our
idea.
B
We
code
we
deploy,
might
have
right.
There
experiment
we
canary
we
sort
of
ideally
with
real
users,
and
then
we
measure
the
impact
we're
having
and
we
go
back
around.
The
loop
I
saw
a
fantastic
talk
by
Steven
until
cough
in
Jay
and
Bern
Berlin
I
think
it
was
in
March
this
year
at
micro
exchange,
and
he
talks
about
how
most
of
us
are
moving
towards
building
services
using
autonomous
cells,
kind
of
picking
up
on
the
Netflix
analogy
here:
kind
of
Conway's
law
type
thing
as
well.
B
The
structure
of
your
organization
dictates
the
look
of
your
software
effectively
how
you
assemble
software,
and
this
we're
finding
is
a
good
thing.
Developing
in
and
small
cross-functional
teams
allows
us.
Autonomy
allows
us
speed
and
so
forth,
but
one
slightly
negative
Antep
and
you
can
see
is
the
particular.
If
you're
developing
with
multiple
languages,
I
worked
on
project
with
Java
go
and
ruby.
Is
you
start
implementing
bits
of
the
platform
in
each
of
the
language
services?
B
Hence
we're
sort
of
we're
discovering
a
good
pattern
as
to
push
a
lot
of
this
responsibilities
down
into
the
platform,
so
that
you
look
at
things
in
particular.
Kubernetes
is
a
good
example
of
this,
with
deployment
and
even
more
recently,
really
things
like
service
meshes
in
particular
envoy,
and
doing
amazing
work
that
allows
us
fine-grained
deployment,
control
and
things
like
circuit,
breaking
and
all
this
kind
of
good
stuff
at
the
communication
level,
but
providing
a
centralized
place.
B
We
we
control
the
circuit
breaking
say
via
the
control
plane,
but
the
data
planes
are
running
a
sidecar
proxies
and
we
can
update
them
all
completely
separately
from
how
we
update
our
apps
yeah.
So
what
we
see
is
is
kind
of
like
this.
In
a
typical
organization,
you
have
multiple
teams:
I've
just
picked
five
here,
for
example,
probably
working
at
different
paces
I
might
have
some
code
and
this
one
here
this
team
is
working.
B
It's
a
well-established
product,
we're
looking
for
stability,
perhaps
more
than
we
are
velocity,
whereas
over
here
we've
got
a
completely
new
idea,
a
new
product
and
we
want
to
go
slightly
faster.
You
know
same
kind
of
loop,
but
we're
gonna
do
different
side.
Different
things,
I
think
we
still
as
it
as
a
kind
of
your
organization.
We
need
some
cross
bunks,
so
the
cross-functional
support
we
need
some
centralized
support.
B
We
often
need
subject
matter:
experts,
sres
platform,
architects,
infrastructure,
people,
ops,
people,
there's
a
lot
of
value
in
being
specialized
in
certain
things,
as
well
as
being
cross-functional
in
individual
product
teams.
Now
to
support
the
subject
matter,
experts
you
clearly
do
kubernetes
cluster
and
you
need
things
like
developer,
tooling
and
the
CD
and
observability
tooling,
and
how
you
offer
those
how
you
create
those
very
much
impacts,
the
developer,
experience
that
is
felt
in
the
teams
around
the
outside
here.
So
that's
pretty
much
it.
The
platform
drives
the
developer.
B
Experience
the
platform
drives
the
workflow
now
the
CNC
F
mission
is
is
fantastic.
Then
everyone's
bumped
into
the
the
landscape,
the
cloud
native
trail
map
when
I
first
bumped
into
it,
really
helped
me
sort
of
understand
some
of
the
key
components
within
the
actual
CN
CF
landscape.
You
know
this
Kweli
communities
mentioned
there's
container
dimension.
There's
brief
this
all
these
kind
of
good
things,
and
it
talks
about
sort.
A
B
A
journey
you
might
go
on
when
you're
looking
to
move
to
a
cloud
native
kind
of
experience.
Now
the
thing
with
the
sensor
vision
is
primarily
focused
at
the
ops
level
at
the
moment,
I
think
what
was,
in
my
opinion,
there
I
think
the
developer
experiences
is
equally
important
platform.
An
and
developer
experience
are
super
important,
actually
created
this
or
a
little
blog
post
and
shared
a
Google
Doc
to
open
up
answer
comments
to
try
and
understand
what
other
people
think
as
well.
B
B
That
link
they're
read,
they
know,
please
read
the
medium
post
and
then
have
a
look
at
the
Google
Doc.
Please
be
able
to
contribute
I'm
trying
to
kind
of
create
a
year,
not
definitive
guide,
perhaps
because
everyone's
context
is
subtly
different
in
the
way
they're
developing
applications,
but
at
least
trying
to
create
a
place
where
people
can
to
share
best
practices,
share
good
ideas
around
developer
experience
got
a
quote
Kelsey.
Of
course,
any
kind
of
you
know
talk
you
do
on
communities.
B
B
Now,
closely
goes
on
to
say,
you
know
it's
not
a
bad
thing,
basically,
if
you're
building
a
pass
but
recognize
what
you're
doing
yeah-
and
this
is
a
key
thing
and
I'm
gonna
explore
a
few
questions
now
to
get
you
thinking
when
you
are
looking
to
create
your
developer
experience
and
fish.
Where
should
you
be
investing
your
time
because
you
gotta
remember
every
sort
of
moment
you
spend
creating
a
pass
or
creating
a
work
flow
is
opportunity
cost
you
could
be
developing
other,
perhaps
business
value
and
functionality
or
whatever?
B
But
a
lot
of
principles
are
the
same
in
that
they're,
providing
a
paved
road
in
kind
of
a
centralized
team
offering
a
platform
and
offering
support
for
you
developing
your
applications
as
an
engineer
and
then,
if
you
stay
on
this
paved
road
they'll
give
you
help
they'll,
give
you
support
and
then
raise
the
work
with
you.
As
a
Netflix
engineer.
They
really
value
freedom
and
responsibility.
You
know
we're
all
grown
up
so
they'd
like
to
say,
and
you
have
the
freedom
to
do
what
you
want.
B
B
Call
for
that
and
I
are
like
this
model
a
lot
and
we're
seeing
people
starting
to
do
this
more
more
now,
with
kubernetes
and
awesome
talk,
I
saw
a
kook
on
New
York
by
nico
from
Shopify.
He
talked
about
how
he
and
his
team
have
built
a
pass.
They
kind
of
paved
road
has
on
top
of
kubernetes
and
they've
done
this
new
things
like
using
custom
controllers
and
operator
star
things
which
we
look
at
a
bit
more
in
a
second
but
I've
written
up.
B
This
talk
and
info
queue
you
can
pop
along
and
read
more
about
it
and
Nico
really
talked
about
some
of
the
decision
points
they've
made
as
a
team
along
the
way
when
they
decided
on
cloud.
They
decided
on
Cuba
Nettie's
and
they
kind
of
they
can't
with
a
bunch
of
problems,
and
they
found
even
more
along
the
way.
But
it's
really
nice
to
understand
someone
who's
already
done
this
journey
sort
of
learn
from
someone
who's
done
this
journey
as
well.
B
So
please
do
check
out
Nico's
talk
there,
so
the
key
question
should
I
build
a
pass
on.
Caretti
should
I
build
some
form
of
platform.
Key
questions
I
like
to
ask
for
clients
is
when
you're,
developing
and
testing.
Do
you
want
to
do
everything
locally,
using
something
like
that's
mini,
cube
or
doc
format,
these
kind
of
things
or
do
you
want
to
do
more
more
stuff
in
the
cluster?
Do
you
want
to
have
a
Cloud
Foundry
like
an
experience
where
perhaps
even
people
don't
install
docker
or
contain
anything
container
related
on
their
local
machine?
B
They
just
get
pushed
and
they
work
with.
You
know
the
cluster
remotely
so
Dana.
Well,
we've
kind
of
come
with
a
little
infographic
here
trying
to
weigh
off
some
of
the
benefits.
You
know
it's,
it's
all
a
trade-off,
we're
not
saying
that
one
ways
better
than
the
other.
If
you
run
everything
locally,
it's
probably
not
realistic
to
production.
I'd
also
argue
if
you
do
just
spin
up
everything
locally,
you
might
have
a
slightly
highly
coupled
system
kind
of
a
beautiful
and
also
I
work
with
many
clients.
You
simply
cannot
spin
up
their
entire
system
locally.
B
Just
you
know,
resources
or
there's
a
legacy
system
or
third-party
system.
They
cannot
spin
up
locally.
Now,
on
the
flip
side,
if
you
move
to
all
remote
development,
you
lose
some
of
your
debug
tools,
locally
yeah,
which
is
quite
tricky
so
working
locally
as
many
advantages,
and
you
definitely
not
running
lots
of
things
in
there
in
the
cloud
or
not
running
and
lots
of
clusters,
for
example,
some
people
do
want
to
maintain
these
minimal
developer
environment,
so
they
want
to
hide
docker
and
Cuban
entities
from
developers.
I,
don't
think
that's
a
bad
thing
again.
A
B
The
maturity,
the
skill
level
of
your
development
team
do
you
want
to
expose
them
to
things
like
kubernetes,
because,
let's
be
honest,
I'm
sure
many
of
you
watching
the
webinar
are
fans
of
communities,
and
you
know
communities
quite
well.
But
when
you
try
and
explain
it
to
your
friends,
you
suddenly
realize
how
how
much
there
is
to
know
of
Cuba
at
ease
and
much
there
is
to
know
of
the
surrounding
ecosystem.
It's
quite
a
lot
to
take
in,
and
many
developers
just
want
to
write
code.
B
They
just
want
to
get
stuff
into
production,
yeah,
so
docker
and
communities
can
be
a
distraction.
There
is
a
kind
of
hybrid
approach
which
you
know.
Telepresence
I've
mentioned
already.
It's
a
CNC
F
hosted
project.
Now
it's
basically
a
two-way
proxy,
allowing
you
to
proxy
into
a
remote
cluster.
So
you
can
spin
up
all
your
services
in
a
remote
cluster.
You
can
then
spin
up
a
service
locally,
say
with
all
your
debug
tools
and
often
we're
working
on
Java
services
with
IntelliJ
I
run.
B
Telepresence
and
I
can
work
on
one
service
as
if
it
was
in
the
cluster
I'm
working
locally.
But
it's
proxying.
Two
ways:
yeah
I,
can
pump
in
a
request
sort
of
by
the
UI
see
what
happens
and
I
can
even
debug
a
locally
on
my
machine
because
my
machines
who
have
thinks
it's
in
the
cluster,
so
that's
the
kind
of
hybrid
tools
like
squash,
fantastic
tall,
squashes,
very
similar
kind
of
approach
to
telepresence,
but
it's
using
an
the
Envoy
proxy.
B
B
How
quick
do
you
need
user
feedback?
Is
another
thinking
point
now
many
companies,
many
of
the
sort
of
unicorns
and
I
appreciate,
with
not
all
unicorns
and
far
from
it.
We're
not
all
Netflix
were
not
all
Google,
but
canary
testing
is
becoming
very
powerful
and
I'm
working
with
companies
are
not
you're,
definitely
not
Netflix,
but
they're,
really
embracing
and
canary
testing,
pushing
things
to
life,
hiding
things
behind
feature
flags,
all
kind
of
smart
routing
and
then
getting
a
very
small
amount
of
their
traffic.
B
Their
live
traffic
Dober
to
get
to
these
canary
deployments
and
looking
for
KPIs
things
like
tech,
KPIs,
but
also
business,
KPIs
and
understanding
you
know,
is
the
thing
we're
doing
now:
making
the
system
better
or
making
it
worse
kind
of
a/b
test
these
things.
It
does
need
app
and
platform
support.
B
You
know
you're
going
to
need
to
put
the
metrics
into
your
inch,
perhaps
exposing
the
KPIs
and
you're
gonna
need
to
kind
of
hook
up
all
the
observability
and
bits
and
pieces
now
Netflix
with
an
awesome
tool
called
Cantor
which
hooks
into
their
spinnaker
deployment
platform.
So
please
do
have
a
look
at
that.
It
also
hooks
into
prometheus
I,
think
they'll,
dog
and
a
few
other
ones
as
well,
but
more
more
companies
are
looking
at
canary
analysis
and
trying
to
automate
it
as
well,
but
it
does
impact
the
developer
experience
quite
a
bit.
B
In
my
experience,
particular
more
traditional
teams.
They
get
a
bit
nervous,
and
you
know
sometimes,
quite
rightly,
about
testing
in
production
about
diverting
real
user
traffic
to
a
kind
of
experiment
effectively.
Absolutely
some
financial
teams-
they
you
know
for
governance
reasons.
They
can't
do
this
kind
of
thing,
but
just
have
a
think
about
this
question.
How
quickly
do
you
need
user
feedback?
Do
you
want
to
be
continued
experimenting,
or
do
you
want
perhaps
a
little
bit
more
stability.
B
Also
worth
asking
is:
do
you
have
a
strong
opinion
on
code
repository
structure,
and
this
is
the
old
classic
mono
repo
versus
micro,
repos
and
a
great
blog
post
by
ship
bull
talks
about
their
journey
around
these
kind
of
things,
but
fundamentally,
if
you're
running
a
mono
repo
with
lots
of
different
services
in
it
and
coordination
of
integration,
testing
across
services
is
generally
easier.
You
know
famous
there's
a
lots
of
talk
about
Google's,
mono
repo.
You
know
you
can
check
it
out
and
kind
of
refactoring
across
it's
nice
and
easy
looking
for
dependencies
across
it.
B
It's
nice
and
easy.
The
trade
offs,
though,
is
it's
all
one
thing.
It's
all
one
big
mono
repo
and
it's
a
lot
of
code
to
deal
with
you
know.
Google
have
even
got
different
tools,
I
basil,
to
to
optimize
the
way
they
build
from
the
mono
repo,
because,
if
you're
not
careful
soon,
as
you
got
a
lot
of
services
during
a
traditional
build
when
the
mono
repo
can
become
quite
challenging
on
the
multi
repo
side,
I
like
this
one
I've
got
the
most
experience
of
this.
B
So
it's
kind
of
anecdotal,
I
guess,
there's
clearer
ownership,
sort
of
teams
own
different
repos
associated
with
various
micro
services,
various
products
and
it's
it
can
promote,
looser
coupling
I
think
sometimes
within
a
mono
repo,
it's
kind
of
like
when
you
had
a
monolith.
It's
easy
to
cheat
sometimes
kind
of
you
know,
sneak
around
the
back
and
highly
couple
something
kind
of
accidentally
and
but
refactoring
code
level.
Standardization
across
the
all
the
services
can
be
really
challenging
because
everyone's
checking
out
individual
repos.
B
You
need
to
really
push
a
lot
of
the
standardization
into
the
pipeline,
so
you
need
to
do
things
like
limiting
code
quality
checks,
security
checks.
All
these
kind
things
you
need
to
you
know
agree
on
these
kind
of
things
and
push
them
into
the
pipeline,
rather
than
relying
on
on
people
to
sort
of
be
more
RAM
dude.
It's
just
sort
of
that
with
their
use
of
things
in
a
mono
repo.
B
B
You
can
use
and
sort
of
maybe
hiding
a
few
things
or
locking
a
few
things
away,
that
people
sort
of
to
guide
keyboards
do
good,
behaviors,
basically
they're
larger
teams
and
more
enterprise
teams,
and
my
experience
often
do
you
want
to
provide
comprehensive
guide
rails
I've
had
a
lot
of
success
with
things
like
open
shifting
and
enterprises,
things
like
Cloud
Foundry,
because
you
can
provide
a
more
standardized
workflow.
This
allows
developers
from
different
teams
to
swap
very
easily
because
once
they've
learned
the
workflow
and
the
tooling,
once
they
can
jump
between
teams.
B
So,
there's
a
lot
of
advantage
by
doing
this
kind
of
thing,
but
my
experience
I've
done
a
lot
of
more
work
recently
with
startups
and
SMEs,
and
the
teams
there
there's
often
you
know
three
or
four
teams
say
within
a
smaller
company,
still
looking
for
kind
of
product
market
fit
or
just
getting
they're
sort
of
beat
in
the
market.
They
value
team
independence
themselves.
You
know
they
don't
want
guide
rails.
They
want
to
be
able
to
do
anything,
no
matter
how
crazy,
but
they
will
take
responsibility
for
it
all.
B
You
can
kind
of
go
for
the
hybrid
model,
the
paved
road
or
the
paved.
You
know
pay
rope,
as
we
looked
at
just
a
minute
ago,
where
you
perhaps
offer
a
kind
of
platform
that
the
paved
road,
but
you
allow
individual
service
teams
to
go
off
kind
of
you
know
and
do
their
own
thing,
but
there's
there's
an
understanding
that
if
they
do
have
the
freedom
they
have
the
responsibility.
So,
if
you're
looking
for
something
a
bit
more
practice
but
more
strictly,
the
guide
rails
definitely
have
a
look
at
open
shift.
B
It's
a
nice
blog
post,
a
link
there
they're
doing
some
very
interesting
sort
of
work
over
and
above
and
the
communities
platform
itself.
How
much
platform
should
we
build?
Should
you
build
kind
of
thing?
It's
always
an
interesting
question
and
I'm
a
big
fan
of
Simon
Wardley
stuff.
So
go
to
my
talk,
so
you
often
seen
you
mentioned
Simon
Ward
link
along
with
Kelsey
Hightower,
but
many
things
are
interesting
of
Simon's
work,
but
I,
particularly
like
a
model.
B
He
talks
about
with
regards
to
pioneers
settlers
and
tank
planners
and
kind
of
the
pioneers
are
the
people
that
are,
you
know,
blazing
the
trail
when
you're
a
startup
you're
looking
for
product
market
fit.
You
know,
you're
experimenting,
you're
prototyping,
that
is
a
pioneer
settlers,
are
taking
the
ideas
from
the
pioneers
and
making
them
a
bit
more
stable.
B
A
bit
more
robust
and
the
town
planners
are
taking
it
in
further
they're
kind
of
you
know,
pulling
out
sort
of
components,
modernizing
and
and
almost
laying
the
platform
for
the
Pioneers
to
build
the
next
iteration
of
their
prototypes
and
Simon.
Talks
about
every
organization
has
this
combination
of
pioneer
settlers
in
town
planners
or
ideally
should
and
depending
on
what
problem
your
team
is
solving
you're,
probably
going
to
be
in
sort
of
one
of
these
and
three
areas
and
I.
B
Think
for
me,
they're
why
we've
often
talked
around
calling
this
of
notion
of
whether
we're
prototyping
a
service,
whether
we've
got
a
service
in
production
effectively
or
whether
we're
running
mission-critical
services.
If
we're
prototyping,
you
know
going
back
to
the
previous
slides.
We
often
like
local
development.
Very
fast.
You
can
spin
everything
up.
We've
only
got
a
few
services
I'm
a
prototyping.
B
Typically,
we
maybe
use
something
like
telepresence
to
do
some
kind
of
hybrid
and
development,
but
we
like
Canarian,
we
like
releasing
stuff
to
live
as
quickly
as
possible,
getting
user
feedback,
and
you
know,
and
basically
iterating
as
fast
as
we
can
frequently.
We
choose
mono
repos,
in
this
case
over
multi,
just
cuz,
it's
easier
with
small
team
moment
we're
working
together
and
in
terms
of
guide
rails
where
I
put
Yolo.
Basically,
we
turn
one
guide
rails
in
this
space.
We
want
to
be
able
to
go
as
fast
as
we
can.
B
Typically,
teams
with
and
working
this
face,
their
skill
sets
a
cross-functional,
so
you
expect
them
to
be
a
kind
of
you
know:
hybrid,
a
software
developer,
sre,
ops
person
that
can
I
think
when
you've
got
the
service.
You
know
you've
kind
of
got
a
bit
of
product
mark
that
market
fit
it's
kind
of
productionize.
We
still
do
a
lot
of
local
testing,
a
lot
of
hybrid
testing
using
things
like
telepresence
and
we
also
canary.
We
want
to
get
V
fast
feedback,
but
we're
also
probably
increasing
pre-production
testing.
B
We've
got
a
few
more
users
now,
so
we
want
to
put
a
slightly
higher
guarantee
on
that.
Anything
that
doesn't
make
it
to
a
canary
is
more
successful
than
perhaps
we
were
comfortable
with
with
prototypes
prototypes,
get
it
as
fast
as
possible
production.
They're,
more
careful.
In
this
stage,
you
often
split
their
multi
repo
in
my
experience
and
guide,
really
starting
to
want
some
kind
of
limited
guide
rails
in
this.
B
B
B
The
quality
attributes
like
performance,
like
security,
that
kind
of
stuff
by
this
point
we're
typically
in
a
multi
Reaper
situation,
just
the
sheer
scale
of
how
a
working
kind
of
thing-
and
you
do
often
want
stronger,
guide
rails
in
this
situation,
because,
there's
you
know
bigger
teams
by
virtue
of
being
more
people,
their
communications
are
often
stretched.
Is
it
you
know
sheer
sort
of
basic
communication
primitives.
You
know
you've
got
like
a
hundred
people
and
on
your
individual
department.
There's
like
99
relationships.
B
You've
got
to
maintain,
therefore,
having
some
guide
rails
to
remove
some
of
those
necessary
conversations.
Once
you've
agreed
on
how
to
do
certain
things
is
quite
valuable
so,
where
to
focus
and
I
think
if
you're
prototyping
I
often
recommend
getting
started
with
the
CI
seedy
part
of
the
experience,
you
know
you
wanna
craps
have
your
own
local
tools.
You
know
you,
your
team,
maybe
it's
ring
as
fast
as
possible
with
canary,
but
you
still
need
this
pipeline.
You
need
the
ability
to
you
know,
package
up
your
app
into
a
container.
B
Do
some
kind
of
you
know
basic
testing
and
push
it
out
into
production
and
into
life
when
you
move
into
the
mall
we're
calling
the
production
space
on
the
settlers
space
I
often
recommend
then
focusing
on
the
scaffolding.
So
when
we're
spinning
up
a
new
service,
I
consider
the
scaffolding
kind
of
stuff
that
I
get
when
I.
You
know
initialize
new
service
I,
probably
like
you
know
hooks
for
various
tests.
B
I've
got
the
implement,
I
spin
up,
and
you
say
maybe
I
use
that
yeomen
or
some
kind
of
templating
system
that
crates
me
a
directory
with
all
my
code
with
a
doc
file,
jenkins
file,
communities,
animal
file,
these
kind
of
things,
but-
and
it's
maybe
got
a
basic
Java
service
outline
or
something
with
some
hooks
for
tests.
It's
also
got
some
hooks
and
some
slots
in
for
things
like
observability,
so
you
know
as
soon
as
I
crank
the
handle
and
get
a
new
service.
B
It's
automatically
linked
in
to
say,
Prometheus
or
automatic,
linked
into
the
alerting
system.
I
find
at
this
stage
having
the
scaffolding,
making
the
cost
as
low
as
possible
to
crank
out
a
new
service
or
upgrade
services
is
where
the
values
that
you
still
need
see
ICD.
But
scaffolding
is
really
important.
With
the
mission-critical
put
and
stuff
I
find
testing
is
you
know
our
biggest
bugbear
here?
We
need
to
be
able
to
recreate
environments
to
recreate
data.
B
I,
don't
know
if
any
of
you
are
following
along
with
don't
mesh
and
Luke,
and
the
team
working
on
some
very
interesting
technology
around
being
able
to
pre-canned
data
capture,
data
and
ship
it
from
production
to
dev
and
test.
Obviously,
GDP
RS
use.
Therefore,
in
Europe,
you've
gotta
think
about
how
you
store
that
data,
but
the
don't
mesh
team
are
doing
some
really
interesting
stuff
in
this
space.
B
I'm,
definitely
keen
to
see
what
they're
up
to,
but
those
are
my
kind
of
tips
in
betting,
where
you
are
in
your
team,
perhaps
where
to
focus
on
some
where
the
developer
experience
moving
on
to
more
the
year,
some
tooling
and
techniques
I
think
we're
not
too
bad
for
time,
and
what
I
would
say
is
you
know,
there's
definitely
a
pattern
emerging
for
communities
for
foot
ops.
Can
you
be
that
he's
is
pretty
much
becoming
the
sort
of
de
facto
container
Orchestrator
as
a
service
yeah.
A
B
I've
done
all
my
stuff
on
may
sauce
in
the
past,
I
use
Amazon
DCs
as
well,
but
kubernetes.
You
know
all
the
cloud
vendors
basically
are
coming
up
with
a
hosted
kubernetes,
offering
it's
kind
of
becoming
the
new
cloud
brokerage
platform
and
my
experience
works
and
if
you
have
brokerage
platforms
before
and
because
of
this
I
think
from
an
ops
perspective,
you've
got
a
lot
of
potential
to
to
impact
the
developer.
Experience.
Kubernetes
itself
is
highly
extensible,
the
team
that
initially
developed
kubernetes,
you
know
Craig
and
Joe,
and
the
team.
B
They
really
thought
about
the
primitives
from
the
API
design
and
I'm.
Seeing
more
and
more
teams
that
take
advantage
of
this
building
custom
controllers
using
the
operator
pattern
and
I
saw
Nico's
talk,
I
mentioned
it.
Lets
you
con
New,
York
Shopify
have
this
thing
called
Claire
buddies,
which
are
kind
of
like
and
custom
where
they
are
custom,
controllers
kind
of
like
operators,
but
what
they're
doing
what
they're
doing
is
they're
codifying
a
lot
of
their
knowledge
into
these
extension
points.
B
So
the
cloud
buddies
that
Nikko
talked
about
how
they
have
these
named
buddy,
where
it
automatically
sorts
out
all
the
DNS
and
registration
all
DNS
naming
they
had
a
redis
buddy,
an
elastic
search,
buddy
the
developers
rather
than
creating
all
this.
You
know
complex
and
communities.
Yeah
Mille
they
created
a
very
simple
kind
of
resource
definition
based
on
this
custom
controller
and
custom
resources,
and
it
spins
them
up
and
it
manages
their
reticences
for
them.
It
manages
you
know
their
elastic
search
and
interface.
B
So
do
please
check
out
operators
and
I
think
I'm
actually
got
an
A
and
blog
post
by
and
one
of
the
teams
I
think
that's
the
Admiralty
team
talked
about
how
they
explored
custom
resources
and
controllers,
and
so
forth.
I
think
is
a
platform
operator
has
a
platform
engineer.
You
can
really
add
a
lot
of
value
to
developers
by
by
potentially
creating
custom
resources,
custom
controllers.
B
From
a.m.
and
development
and
deployment
perspective
now,
apologies,
this
slide
is
a
bit
of
an
eye
chart,
but
there's
a
lot
of
info
here,
and
these
are
tools.
I've
got
a
link
to
the
blog
post.
I've
got
these
from,
but
these
are
the
tools
from
a
development
perspective.
I
think
is
super
interesting
and
worth
keeping
an
eye
on
in
terms
of
developer
experience,
and
so
this
draft,
which
is
coming
from
the
dev
team
at
Microsoft,
it's
automating
the
kind
of
inner
loop
of
build
push
and
deploy.
B
B
So
helm
is
a
really
nice
thing
to
look
at
case
on
it's
kind
of
similar
thing.
Defining
committees
manifests
in
something
called
JSON
it.
It
fundamentally
actually
create
sort
of
composable,
config
and
services.
There's
quite
a
nice
may
sort
of
reusability
point
of
view
from
a
packaging
of
your
application
for
deployment,
and
then
a
couple
of
sort
of
more
random
ones,
which
are
super
interesting
to
watch,
is
metal
particle.
So
Brandon
talked
about
that
at
Coopers
koukin
last
year
and
and
it's
a
kind
of
standard
library
for
cloud
native
apps,
but
its
language
specific.
B
So
there's
Java
bindings,
for
you
know
creating
a
cube,
Letty's
config,
there's
language
bindings
like
go
over,
creating
a
cube,
Nettie's
comping
yeah
thing.
So
this
is
it's
a
very
different
approach
to
probably
they're
the
other
approaches
here.
But
it's
very
interesting
to
watch
and
you
know:
Brandon
ops,
II,
super
clever
guy
always
pay
attention
to
what
he's
up
to
kind
of
similar.
This
is
a
language
called
ballerina
coming
this
one
in
Tokyo
a
while
ago,
it's
a
new
micro-services
programming.
Language
comes
in
the
wso
2
team,
and
you
can.
B
It's
got
some
ranged
in
primitive
around
developing
micro
services,
the
event-driven
micro
services,
but
it
also
provides
annotations
I've
seen
some
Java
examples.
A
little
play
around.
You
can
sort
of
do
the
kubernetes
annotations,
docker
annotations
and
it
will
create
all
the
communities
and
config
files
for
you
or
the
docker
config
files
for
you.
So
these
ancient
choices,
if
you're
a
developer
for
an
operator.
These
are
all
very
much
emerging
kind
of
better
for
experience
tools,
definitely
worth
a
look.
I
appreciate.
B
B
I
hope,
I,
think
I'm
gonna
miss
this
slider
when
I
share
the
slides,
I've
got
a
link
to
Shahid
and
Matt
fariñas,
blog
posts,
they're,
the
two
blog
post
and
actually
I've
got
a
lot
of
info
from
so
I
must
share
them
later
on
a
project
to
show
you
and
Matt's
I
haven't
forgotten
you
there,
but
I
must
delete
that
slide
accidentally,
but
one
pound
I
will
say
is
that,
in
addition
to
all
those
tools,
I
show
you
just
a
moment
ago.
Most
of
them
are
CLI
tools.
B
Most
of
my
command
line
tools
and
not
every
developer,
is
comfortable
working
at
the
command
line.
So
I've
noticed
that
Nico
when
he
talked
about
Shopify
they've
built
a
very
simple
UI
that
allows
developers
to
initialize
new
services,
initialize
new
products
and
do
everything
that
COO
cuttle
or
keep
CDR
lines
you
do,
but
they
do
it
by.
Oh
sorry,
they
do
it
by
a
UI
bar
an
API.
So
the
the
platform
team
at
Shopify
kind
of
control,
the
experience
provide
some
guide
rail
so
to
speak.
B
B
So
whether
you
use
Jenkins
Jenkins
X
is
super
interesting
in
the
community
space.
Are
we
use
circle
CI?
Quite
a
bit
Travis.
You
need
to
allow
you
developers
to
create
a
pipeline
for
their
service
or
perhaps
when
they
create
something
know
that
the
service,
when
they
initialize
service
the
pipeline
with
all
the
key
hooks
and
slots,
is
created
for
them.
At
the
same
time,
you
do
want
to
bacon
hooks
and
slots
for
things
like
testing
things
like
observability
I
mention
this
already.
B
You
want
to
make
it
super
easy
for
the
developer
to
do
the
right
thing.
Super
easy
to
expose
metrics
super
easy
to
dump
logs
in
the
correct
place,
super
easy
to
do.
Security
testing,
for
example,
and
testing
of
NFR,
so
I
would
say
non-functional
requirements
or
system.
Quality
attributes
is
really
really
important,
and
the
fact
that
we're
now
packaging
code
in
containers
and
you're,
deploying
that
onto
communities
and
deploying
that
under
cloud
adds
even
more
layers
of
abstraction
where
things
can
go
wrong.
B
You
know
more
protections,
makes
our
life
easier
in
terms
of
understandability,
of
course,
tractions,
but
it
can
provide
places
where
things
can
go
wrong.
So
you
definitely
I've
got
another
talk.
Actually
I've
linked
here
where
I've
gone
into
a
lot
more
details,
but
you
definitely
want
to
look
at
things
like
basic
code
scanning
sort
of
basic
and
vulnerability
scanning.
You
want
to
look
at
things
like
dependency
scanning,
so
Oh
wasp
have
got
a
very
nice
language,
agnostic,
a
tool
to
do
dependency
scanning.
It
kind
of
looks
up
against
the
national
vulnerability
database.
B
B
Many
of
the
bigger
companies
and
docker
and
korres
offer
and
static
image
scanning
and
there's
also
an
open
source
and
tool
called
Claire
came
from
the
Korres
team
and
awesome
gent
linked
in
the
slides
but
called
Armand
is
create
a
docker
container
to
build
Claire,
which
you
can
then
use
to
scan
other
containers.
So
there's
no
excuses
really
to
do
all
these
things.
You
should
be
scanning
your
code,
vulnerability
scanning
dependencies,
you're,
bringing
in
and
clearly
scanning
images.
B
Even
if
you
know
it's
not
your
image,
you
want
to
scan
it
because
you
want
to
know
what
you're
pushing
into
production
yeah.
These
things
are
super
important
security,
no-brainer,
highly
recommend,
testing
performance,
you're.
Looking
for
trends,
if
you,
you
know,
start
adding
more
functionality
to
a
service
and
the
performance
goes
down.
You
definitely
want
to
know
that's
kind
of
going
wrong
and
things
like
quality
I,
often
run
in
the
Java
world,
a
sonar
cube
and
in
Ruby
world
around
code
climate.
B
B
I
know
the
key
pattern
I'm
seeing
in
terms
of
developer
experience
is
what
I'm
calling
layer,
7
deployment
control
and
it
allows
basically
fine-grained
control
of
deployment.
So
kubernetes
you
can
do
rolling
upgrades.
You
can
do
kind
of
you
know
quite
nice
and
releases,
but
you
can't
easily
control
at
the
layer,
seven
at
the
app
level
how
you
want
to
divert
traffic.
B
Opening
up
now
are
taking
advantage
of
the
data
plane
of
envoy
they're,
providing
very
fine
or
the
envoys
providing
very
fine-grained
control.
So
we
can,
you
know,
divert
just
one
user,
for
example,
to
a
service
if
we're
doing
debugging
week
and
over
a
cohort
of
users
to
do
some
kind
of
canary
testing.
B
Just
finally,
it's
you
know
coming
kinds
of
time
there
so
I'm
going
to
some
too
much
detail,
but
in
terms
of
observability
it
is
an
essential
part
of
the
kind
of
the
feedback
loop
we're
coming
up
with
hypotheses.
We
need
to
test
it.
We
need
to
validate
both
from
a
tech
point
of
view
in
a
business
point
of
view,
so
monitoring
logging
and
tracing
in
my
mind
is
super
important
and
I'm.
B
Getting
them
in
early
to
a
project
is
really
valuable
and
I've
mentioned
it
before,
but
I'll
say
it
again
kind
of
if
you're
working
on
building
some
scaffolding
building
hooks
and
slots
to
make
it
super
easy
for
your
development
team
to
plug
in
to
what
you're
offering
at
the
platform
to
plug
into
prometheus,
to
plug
into
and
to
ELQ
stack
or
human
scale.
You
know
that
kind
of
thing
and
and
also
make
it
super
easy
to
get
the
data
for
the
username
right
and
dashboards.
B
A
services
select
another
service
that
it
talks
to,
and
you
can
look
at
all
the
kind
of
top-line
metrics
in
terms
of
latency
and
500
exceptions.
All
these
things,
and
it
was
really
nice
as
a
developer.
I,
could
really
see
value
out
of
these
dashboards.
I
can
get
a
global
overview,
but
I
can
drill
into
the
actual
individual
services,
which
is
very
powerful,
but
these
things
in
terms
of
developer
experience
need
to
be
thought
about.
B
Quite
early
on
my
experience,
Sara
Wells
from
the
FT
Financial
Times
comm
did
a
fantastic
talk
couple
years
ago,
I
think
now
it's
an
one
of
the
cons
around
observability
and
the
FT
have
migrated
to
a
bunch
of
lingo
and
JavaScript
services.
Micro
services
and
they've
really
put
a
lot
of
thought
into
this
observability
piece
and
and
they've
put
a
lot
of
thought
into
alerting
as
well.
So
if
you're
struggling
with
kind
of
you
know
things
falling
over
or
wanting
to
know
how
to
craft
alerts
really
recommend
and
Sara's
work
here.
B
Obviously,
Cindy
should
Horan's
I,
don't
have
got
Lincoln's
talk,
but
just
Google
City
should
hire
and
observability
her
and
charity.
Mages
are
doing
some
fantastic
thought
leader
in
this
space,
so
and
Cindy's
got
a
mini
book
out
and
I
Riley,
which
is
well
worth
a
read
on
the
fact.
I
may
even
put
seeing
these
book
in
before
I
publish
the
slides,
because
it
really
is
it's
a
good
read.
So
that's
pretty
much
wrapping
up
all
I
want
to
say
today.
I
appreciate
this
has
been
a
high-level
view.
B
We
built
a
few
platforms
on
they
sauce
and
on
kubernetes
and
how
we
constructed
the
platform,
massively
impacted
the
developer
experience
and
with
hindsight
it's
always
easy
to
say
this,
but
with
hindsight
I
wish
I'd
asked
a
few
of
the
questions.
I
asked
in
the
presentation
today
before
we
dive
in
and
started
playing
with
some
of
this
stuff.
B
We
started
working
on
these
things
so
hopefully,
even
though
I
haven't
given
you
all
solutions,
I've
at
least
given
you
a
few
thinking
points
if
you're
looking
in
this
space,
the
bottom
line
is
you
need
to
intentionally
curate
your
experience
of
a
bunch
of
things.
Whatever
role
you
play,
whether
it's
dev
QA,
you
know
ops
platform,
sre,
test
PM.
B
We
need
to
think
about
all
the
technical
components,
such
as
local
development
and
testing,
how
you
package
apps,
how
you
continuously
deliver
them,
how
you
control
the
deployment
and
how
you
observe
these
things
always
bear
in
mind
that
whatever
a
framework
you
build
around
your
application,
you
know
that
might
cost
you
in
terms
of
opportunity,
you're
spending
time,
building
a
path
rather
than
building
business
functionality.
There's
always
a
trade-off
there,
but
it's
one.
You
need
to
be
very
intentional
about
making
I
definitely
learned
a
lot
from
Nikko
and
Shopify.
B
They've
got
a
lot
of
value
out
of
their
past,
but
I've
also
worked
with
a
lot
of
companies.
They've
got
a
lot
of
value
things
like
open
chef
to
Naraku
because
they
simply
want
to
get
to
to
mark
it
as
fast
as
possible,
regardless
of
what
you
need
to
do,
regardless
of
what
you
want
to
do,
you
need
to
curate
the
experience
of
these
things.
That's
it
love
you,
thoughts
on
email
and
DB
at
Del
Oro.
B
You
can
hit
me
up
on
twitter
at
daniel
bryan
UK,
there's
a
kind
of
summary
of
this
and
presentation
on
DZ
on
already,
and
I
will
put
up
great
another
and
the
blog
post
as
well
after
this,
maybe
on
the
CNC
F
war
and
the
dinner
well
blog
and
so
forth.
But
at
that
point,
I
feel
a
thanks
a
lot
and
see
if
we've
got
any
questions.
A
Thanks
for
the
great
presentation
Daniel,
no,
we
have
some
time
for
some
questions.
If
you
have
a
question
that
you'd
like
to
ask,
please
drop
it
in
the
Q&A
tab
at
the
bottom
of
your
screen
and
we'll
get
to
as
many
as
we
have
time
for
dive
right
in
one.
This
may
not
be
the
best
forum,
but
they
are
interested
in
how
people
handle
exceptions
in
micro
servers
in
the
micro
services
world,
especially
an
event-driven
asynchronous
services
case.
B
B
Caching
frameworks
so
kind
of
bubbling
things
up,
but
not
showing
the
exceptions
to
users,
but
using
things
like
air
brake,
which
are
tools,
the
capture
exceptions,
and
then
you
can
kind
of
and
go
back
and
look
at
the
exceptions
as
of
late.
It's
that
is
more,
is
it
context,
is
key
I.
Think
in
this
one
you
always
want
to
prevent
the
exceptions
bubbling
up
and
experiencing
impacting
the
users,
but
with
things
like
events,
I
mean
events
are
fantastic
and
they
do
allow
you
to
replay
things.
B
So
you
can
often
say
replay
events
and
actually
understand
what
the
bug
was
cause.
Then
you
can
fix
the
bug
and
replay
the
events
to
watch
it,
and
but
it
also
creates
some
complexity
in
terms
of,
if
you
are
using,
say
an
event
store
and
everything's
immutable
and
you're
writing
events
to
sort
of
an
immutable
log.
You
can't
really
update
an
event.
You've
got
to
go
back
and
you
know
you've
got
to
put
a
new
event
in
and
sort
of
that
fixes
the
old
event.
B
So
I'll
be
honest
that
one,
you
know
feel
free
to
ping
me
on
on
Twitter.
I
can
probably
point
the
person
asking
the
question
into
some
other
articles.
People
are
following
this:
space
are
and
Jonah's
one
year
and
Chris
Richardson.
They
are
both
real
good
thinkers
in
the
eventing
space
and
I
think
I'd,
sort
of
point
people
to
those
articles
and
first
there.
First
of
all.
A
B
Yeah
I've
only
used
nomad,
for
example,
in
experimentation,
I've
not
used
it
in
production,
yeah
I'm,
a
massive
fan
of
hashing
open
to
be
lost
here,
isn't
hash.
You
got
decent
amazing
tools,
but
what
I've
seen
from
a
nomad?
It
was
an
even
simpler
kind
of
proposition
to
say,
kubernetes
and
again,
not
bad.
It's
purely
trade-offs,
and
so
one
of
the
key
advantages
will
say
nomad
that
you
can
run
static
binaries
rather
than
sort
of
you
know,
compiling
things
in
containers
and
there's
a
I
can
definitely
point
you
Alyssa
mentioning
articles
if
they
wanted
comparisons.
B
At
the
moment,
most
people
I'm
working
with
happened
to
be
kubernetes.
So
that's
where
my
kind
of
you
know,
expertise
at
the
moment
lies,
but
I
definitely
recommend
if
they
are,
if
people
are
sort
of
debating
and
do
some
research,
because
your
choice
of
nomad
versus,
say
kubernetes
will
have
a
longer
term
impact
I
had
a
similar
problem
when
I
was
looking
at
my
sauce
a
few
years
ago
about
three
or
four
years
ago,
we
worked
on
the
project.
B
Kubernetes
was
super
young
at
the
time,
so
we
went
with
may
sauce
and
but
it
that
doesn't
knock
on
effects
in
terms
of
you
know
how
you
operate
the
platform
and
so
forth,
but
I
think
you
know:
Nomad
communities,
Amazon
ECS,
for
example,
they're
all
fantastic
tools,
but
they
all
come
with
various
trade-offs
and
I.
Think
you
think
the
person
asking
the
question
identify
their
context,
identify
your
pain
points.
B
If
I
didn't
explain,
NFR
it's
a
non-functional
requirement
and
I
hate,
the
name
non-functional
other
people
who
sort
of
call
it
cross,
functional
requirements
or
the
traditional
term
was
system.
Quality
attribute
it's
things
that
we
don't
think
is
functional
requirements,
but
they
are
equally
critical.
There
are
things
like
security
things
like,
and
reliability,
and
things
like
extensibility.
B
A
B
That
is
a
good
question
and
again
my
expertise
and
this
one's
a
little
bit
limited.
So
I'm
gonna,
probably
caution
that
once
a
know
anything
better
to
educate
it.
I
keep
bumping
into
this,
but
I.
Just
the
photos.
I'm
working
on
haven't
led
me
down
to
explore
that
path
and
in
sort
of
full
and
in
full
depth.
Yet
so
I'll
hold
off,
maybe
write
a
blog
post
on
that
one
or
something
it's
good
question.
Actually,
nice.
A
B
There
isn't
really
a
comprehensive
guide
yet,
and
someone
actually
asked
me
for
a
book
and
they
could
recommend
I
recommend
and
at
the
kubernetes
book
by
by
Kelsey
and
Joe,
and
the
team
is
fantastic,
but
it
focuses
more
on
kubernetes,
as
opposed
to
creating
a
platform
and
the
honest
answer,
is
you
do
kind
of
have
to
knit
stuff
together,
I'm
sure
you
know
given
enough
time
to
three
years?
Whatever
will
either
see
the
playbook
being
out
there,
someone
will
write
a
playbook.
This
is
all
the
things
you
need
to
knit
together.
B
Maybe
someone
listening
to
the
webinar
could
actually
do
that
or
we
may
even
see
a
move.
You
know
serverless
and
things
like
that
big
buzz
word
service
is
becoming
very
popular.
Some
of
the
tooling
is
kind
of
maturing
around
that
as
well,
so
we
may
even
see
a
move
towards
not
building
their
own
platforms.
Maybe
more
of
will
actually
sort
of
see
more
offerings
around
kubernetes
or
offerings
around
the
cloud,
vendors
that
actually
remove
the
need
to
glue
some
of
these
things
that
we
do
need
to
glue
together
now.
A
B
A
B
So
it
is
it's
a
real
tricky
one.
I've
worked
with
some
companies,
there's
a
lot
of
stuff
going
on
in
the
Robo
buy
space
in
the
UK
and
a
lot
of
financial
companies
I'm
recommend
that
they
really
struggle
with
this
stuff,
because
obviously,
security
is
a
massive
massive
thing
to
them.
I
do
recommend
doing
things
like
value
stream
mapping
taking
a
step
back.
They
deploy
non-techie
the
value
stream
mapping.
B
B
So
if
your
developers
truly
can't
go
fast
enough,
well,
that's
something
to
focus
on
that's
more
than
the
security
where,
as
if
security
isn't
you
know
more
of
a
roadblock
if
you're
having
incidents,
for
example,
you
want
to
focus
more
on
security,
but
in
terms
of
if
you've
got
the
balanced
kind
of
right
and
in
terms
of
that
sort
of
you
know,
there's
no
issues
and
either
side.
It's
it's
gonna,
be
a
constant
friction
point
developers
in
general,
I'm,
more
fidella,
I,
guess
I
can
identify
with
this.
We
want
to
go
fast.
B
You
want
to
be
delivering
value,
but
I
also
totally
appreciate
the
need
to
be
stable.
So
it's
it's
really
having
those
conversations.
It's
you
know,
one
of
the
things
I
do
as
a
consultant
is
get
InfoSec
involved
in
a
project
early
on
as
possible.
I've
done
a
few
and
I've
gone
into
a
few
migration
projects
where
InfoSec
have
not
been
consulted
and
then,
if
we
do
try
and
pull
them
in
late,
quite
rightly,
they
get
annoyed
and
say
my
god.
You
know
this
stuff's
like
containers
that
I've
got
a
super
insecure
and
you
know.
B
A
B
B
B
The
the
clients
are
offering,
they
kind
of
automatic
canary
analysis
is
caught
a
few
who's
I
and
that
I
work
with
and
so
I
think
Spinnaker's
it
as
great
tool,
and
it
is,
it
guys,
got
trade-offs
in
terms
of
so
didn't
come
from
the
Netflix
model
and
it's
been
a
little
bit
sort
of
molded
towards
kubernetes
now,
but
some
of
the
primitives
and
more
towards
irons
and
so
forth.
So
yeah
I
hope.
B
That's
a
few
thinking
points
there
to
be
honest,
like
a
definitely
putting
people
at
a
few
blog
posts,
I've,
I,
read
and
I
died.
If
you're
gonna
make
a
choice,
pinning
something
like
Jenkins
and
spinnaker.
I
definitely
recommend
having
a
play.
I've
used,
many
things
over
the
years,
go
see,
Dee
and
Travis
and
stuff
and
they've
all
got
em
plus
and
minuses.
So
you
need
to
understand
your
context
and
map
it
to
what
the
offerings
are.
B
B
It
is
open
source,
though
so
it's
an
API
gateway,
so
we're
working
with
clients
to,
and
it's
a
kind
of,
kubernetes
native
API
gateway
that
supports
clearing
things
like
that
to
do
a
whole
bunch
of
work
with
a
bast
at
the
moment
and
lots
of
work
with
Sto
there's
a
kind
of
east-west
control,
plane
I
happen
to
just
accept.
My
back
in
is
mainly
Java,
so
I
do
a
whole
lot
of
stuff
with
Jenkins.
Jenkins
is
my
main
CI
CD
tool
that
we
are
using
circle
as
well.
B
B
The
kind
of
clients
I'm
working
with
a
lot
of
them
tend
to
be
more
and
just
in
the
moment,
more
start
to
be
more
leading-edge,
they're
happy
to
be
at
the
CL
I'm
happy
to
play
with
some
of
these
tools,
whereas
some
of
the
more
enterprising
bar
chat
and
more
high-level
consulting,
they
want
more
strict
guidelines,
so
there
I
see
more
things
like
the
Shopify
team,
their
buildings
in
their
own
tooling.
On
top
of
all
the
other
things.
A
B
B
He
talks
about
this
sort
of
non
associating
a
cloud
native
kind
of
model,
as
well
fact
that
he
was
saying
cloud
native
truly
is
something
like
service
offering
a
pure
you're
just
writing
code
in
deploying
into
a
platform
that
being
truly
cloud
native
but
I,
think
a
lot
of
the
principles
behind
the
12
factor
app
and
as
Kevin
Hoffman
did
15
factor
app.
So
you
can
have
a
Google
15
factors
is
a
little
mini
O'reilly
book,
you
know
more
factors
is
clearly
better
yeah.
B
We
will
think
that,
but
but
if
Kevin's
got
some
reading
to
the
observations
in
a
but
over
and
above
the
12
factor
app,
fundamentally,
though
you
know
Heroku
inspired,
they
were
one
of
the
original
passes
or
nearly
all
the
advice
stands.
The
test
of
time
with
the
12
factors
and-
and
you
can
literally
kind
of
you
know,
see
if
you're
building
stuff
at
docker
and
communities
you
can
list.
A
B
That's
a
great
question,
probably
to
be
honest,
more
and
context
required
if
they've
got
straight
containers
as
in
I'm,
not
sure
if
bessemer's
running
kubernetes,
for
example,
but
I
definitely
wouldn't
recommend
and
going
something
that
sto
unless
you've
got
kubernetes
I
mean
I've
never
played
with.
You
can
spend
a
BIST
you
on
its
own,
but
that
might
be
more
pain
than
it's
worth
and
I
kind
of
think.
With
the
tracing.
You
sometimes
have
to
go
all-in
or
pretty
much.
You
have
to
go
all-in
in
terms
of
propagating
the
header.
B
You
know
you
apply
a
correlation
idea
at
the
start.
You
propagate
they're
headed
down
through
the
the
apps,
so
the
apps
do
you
have
to
be
a
little
bit
aware
and
to
propagate
the
headers
to
get
the
full
traces
that
you
can
then
correlate
together
and
I
one
person
attractive.
We
try
to
retrofit
Zipkin
at
the
time
and
it
was
really
hard
so
putting
it
in
the
start
is
a
lot
easier.
I
guess,
but
I
think
if
you
were
I'd
recommend,
probably
experimenting.
I
think
SEO
is:
is
evolving
in
a
rapid
clip.
B
I
looked
at
a
Christian
poster
a
lot
of
my
kind
of
guidance
on
this
stuff
and
then
that
climb
and
Christians
actually
run
a
couple
of
books.
I
think
on
on
Sto
I
think
give
this
do
six
months
a
year
it's
gonna
be
even
further
advanced
and
I
know
trying
to
Yasmine
from
Google
around
this.
Ever
in
foq.
She
was
saying
that
the
goal
is
to
make
sto
ambient,
so
eventually
sto
kind
of
disappears
into
the
platform
disappears
into
the
kinetics
platform.
B
So
in
some
ways,
if
you're-
not
if
you
haven't
got
a
direct
pain
point
that
something
like
tracing
or
a
service
mesh
will
solve,
maybe
we're
waiting.
Six
months
a
year,
it'll
actually
be
easier
T
for
you
to
integrate
sto
into
your
stack,
which
is
fantastic,
but
it's
not
fully
production
ready
yet
and
don't
underestimate
the
effort
it
will
take
to
put
in
a
stack.
B
It's
by
Kelsey,
Hightower,
I,
think
Jo
as
well,
and
someone
else
or
he's
the
person
I've
forgotten
there
is
it
communities
up
and
running?
There
may
be
a
couple,
but
I
can
think
the
I'll
make
sure
I
put
the
link
in
the
slides
and
share
it.
I
mean
the
main
thing.
Is
it's
a
Kelsey
username
it
in
one
books?
If
you
search
for
Kelsey
Hightower,
it's
on
O'reilly
did.
A
B
Sorry,
yes,
I
used
to
fix
them
so
when
I
say
east-west
and
north-south,
so
north-south
traffic
is
typically
the
traffic
traffic,
so
I
coming
into
your
system,
it's
the
ingress
and
egress
of
the
the
service
better
and
your
system
boundary
it's
basically
where
the
traffic
where
your
user
traffic
comes
in.
So
we
call
that
north-south
and
the
east-west
traffic
it's
an
old
term
from
Denison.
Today's
is
you're
in
in
arcs
on
a
micro
service
world.
It's
the
service
to
service
traffic.
So
you
have.
B
You
know
when
a
service
wants
to
communicate
with
another
service
within
your
network
perimeter,
and
we
call
that
east-west
traffic
and
the
deal
with
ambassador
in
sto,
so
they
both
use
the
Envoy
proxy
to
do
all
the
kind
of
networking
magic
under
the
hood,
but
they're
two
different
control
planes.
So
ambassador
is
a
control
plane
for
the
API
gateway.
It
allows
you
to
write
annotations
in
your
kubernetes
config
and
you
can
control
everything
at
the
point
of
ingress.
Like
you
will
the
normal
API
gateway?
B
Do
rate-limiting
fault
tolerance,
all
that
good
stuff
service
discovery
routing,
whereas
SDO
is
more
at
the
moment
at
least
it's
more
east-west
service
to
service
comms.
You
can
set
up
to
the
Canarian
fault,
tolerance
and
everything
if
the
service,
the
service
communication
level,
there's
nothing
to
stop
you
and
I'm.
Actually
writing
a
blog
post
on
this.
For
now
nothing
to
stop
you
I'm
using
St,
I
think
as
ingress
and
I
think
there's
sort
of
some
blog
post
emerging
on
this
and
you
can
even
use
Ambassador
as
a
as
a
kind
of
east-west
thing
as
well.
B
If
you
want
and
glue
kind
of
similar
glue
is
offering
a
control
plane
over
envoy
as
well
so
hope
you
that
explained,
if
not
I'm
happy
to
like
get
on
Twitter
or
emails
to
make
it
a
bit
clearer.
I
think
I've
even
got
some
blog
post,
where
I
go
into
more
detail,
but
in
north-south-east-west,
but
that's
the
fundamental
differences.
Oh.
A
Well,
thank
you
for
the
great
presentation
see.
That
is
all
the
time
we
have
for
questions
today.
Thank
you
for
genic
joining
us
today
to
learn
about
creating
an
effective
developer
experience
on
committees.
You
in
our
recording
and
slides
will
be
online
later
today,
and
we
look
forward
to
seeing
you
at
a
future.
Cn
CF
webinar
have.