►
From YouTube: Webinar: Building a Cloud-Native Technology Stack That Supports Full Cycle Development
Description
Kubernetes can unlock rapid development cycles and increased feature velocity. Kubernetes also disrupts your software development lifecycle. Organizations that have successfully embraced cloud-native technologies like Kubernetes have invested heavily in creating a self-service application platform to enable Full Cycle Development.
How can you make sure your developers are empowered and your organization is getting all the benefits a technology like Kubernetes has to offer?
In this webinar, we will discuss the four capabilities that are essential to Full Cycle Development: container management, progressive delivery, edge management, and observability:
– Container Management with Kubernetes. Manage and run container-based applications at scale and on a variety of infrastructures.
– Progressive Delivery with Continuous Delivery Pipelines. Support the creation of pipelines that enable the automated build, verification, deployment, release, and observability of applications by developers.
– Edge Management with a Self-Service API Gateway. Enable developers to release new functionality in a self-service manner.
– Observability with an Observability Stack. Allow developers and platform teams to collect and analyze end-user and application feedback.
Join this webinar will talk through the requirements for these technologies as well as discuss common antipatterns and how to avoid them
Presenter:
Daniel Bryant, Product Architect @Ambassador Labs (Previously Datawire)
A
Okay,
let's
get
started
hello.
Everyone.
Thank
you
very
much
for
joining
us
this
morning
for
today's
cncf
webinar
building
a
cloud
native
technology
stack
that
supports
full
cycle
development,
I'm
jerry,
fallon
and
I'll
be
moderating
today's
webinar.
I
would
like
to
welcome
our
presenter
today,
daniel
bryant
product
architect,
from
ambassador
labs
or
formerly
known
as
datawire
just
a
few
housekeeping
items.
Before
we
get
started
during
the
webinar,
you
are
not
able
to
talk
as
an
attendee.
There
is
a
q,
a
box
at
the
bottom
of
your
screen.
A
Please
feel
free
to
drop
your
questions
in
there
and
we'll
get
to
as
many
as
we
can.
At
the
end.
This
is
an
official
webinar
of
the
cncf
and,
as
such
is
subject
to
the
cncf
code
of
conduct.
Please
do
not
add
anything
to
the
chat
or
questions
that
would
be
in
violation
of
the
code
of
conduct.
Please
be
respectful
of
your
fellow
participants
and
presenters.
B
Thanks
jerry,
I
appreciate
that
so
welcome
everyone
to
building
a
cloud
native
technology
stack
that
supports
full
cycle
development.
Now,
as
I
was
rereading
the
title
today,
I
was
thinking
wow.
I've
picked
way
too
many
buzzwords
there.
So,
let's
start
the
talk
by
unpacking
a
few
of
the
things
I'm
talking
about
today
with
a
kind
of
high
level
takeaways
high
level
tldr,
I'm
hoping
many
of
you
on
the
webinar
you
know
are
realizing
that
being
cloud
native
is
a
good
thing.
B
Cloud
native
is
a
slightly
nebulous
term,
we'll
look
at
in
a
second,
but
it's
not
just
about
the
tech.
It's
about
the
culture.
It's
about
the
workflows
and
in
particular,
I
think,
workflows
are
essential
in
terms
of
how
we,
as
developers
and
operators,
interact
with
the
platform
and
creating
a
supporting
cloud
platform,
and
many
of
us
are
choosing
kubernetes
our
foundation
here.
But
what
you
level
on
top
of
these
things
is
super
super
important
for
how
we
use
the
platform
to
deliver
applications
and
ultimately
deliver
value
to
our
customers.
B
B
B
I
have
sort
of
come
from
the
java
days
and
your
monolith
vms,
and
I
really
had
to
update
my
mental
model
when
moving
towards
cloud
and
the
platform
was
a
big
part
of
that.
I
built
some
platforms
on
mesos
before
sort
of
kubernetes
was
locked
in
and
I
made
some
mistakes
being
candid,
my
team,
you
know
we
made
a
bunch
of
mistakes.
B
This
is
me
at
daniel
bryant,
on
most
of
the
interwebs.
You
can
find
me
there
on
linkedin
github
twitter,
I'm
quite
active
on
twitter,
so
I'd
love
to
get
involved
with
tweets.
I
work
as
a
product,
architect,
datawire
or
ambassador
labs.
Now,
we've
literally
just
rebranded,
and
there
we
have
the
telepresence
cncf
project
we
stu
at
that,
and
we
also
have
the
ambassador
api
gateway,
which
we've
just
submitted
to
the
cncf2,
not
confirmed
yet,
but
we
have
submitted
ambassador
api
gateway
to
be
a
cncf
project
too.
B
B
Let's
look
at
a
quick
primer
at
cloud
native
right.
I'm
thinking
most
folks
on
this
webinar
are
sort
of
all
in
that
cloud
is
a
good
thing
right.
It
does
offer
many
benefits,
mainly
in
terms
of
speed
to
market
innovation.
We
can
take
advantage
of
cloud
text
like
machine
learning,
that
kind
of
thing
and
there's
lots
of
other
benefits
to
scaling,
for
example,
but
it
does
require
changes.
The
technology
is
the
obvious
one
and
as
a
techie
myself
like
I
get
the
most
excited
about
this.
B
Sometimes
you
know
when
docker
came
out,
I
was
docker
crazy
when
kubernetes
came
out
likely
likely
same
thing
as
well,
but
appropriate
culture
is
really
important,
not
just
the
tech.
It's
how
we
sort
of
interact
as
a
team
to
get
the
most
out
of
these
cloud
native
texts,
and
this
is
all
about
new
workflows.
In
my
mind,
the
old
days
of
me
as
a
developer,
just
committing
code
and
walking
away
to
some
degree,
is
clearly
changed
now
you
know
devops
kind
of
changed
that,
but
even
more
so
in
the
world
of
kubernetes.
B
Successful
cloud
native
organizations,
I've
worked
with
both
my
role
as
a
consultant,
so
if
you
know
10
or
so
years
ago,
now
or
5
10
years
ago,
and
my
work
I'm
doing
ambassador
labs
and
also
the
stuff
I
see
in
the
in
the
sort
of
kubecon
presentations
in
the
literature.
The
two
things
that
successful
cloud
native
organizations
have
one
is
a
self-service
application
platform.
Kubernetes
is
fantastic,
but
more
often
than
not
it's
a
foundation
which
we
build
stuff
on
top
and
folks
have
also
adopted
new
tools
and
full
cycle
developer
workflows.
B
Now,
when
I'll
go
into
full
cycle
a
bit
more
depth,
now
it's
an
interesting
concept.
It
actually
popped
out
of.
I
think
it
was
originally
netflix
on
definitely
netflix
have
kind
of
made
it
popular.
I
should
say
a
fantastic
blog
post
here.
I've
linked
off
the
netflix
blog
they've
talked
about
how
they've
set
up
many
of
their
teams,
not
all
but
many
of
their
product
teams
to
be
fully
self-sufficient.
B
They're
developers,
they
have
the
business
ideas
work
with
business
folks,
they
code
test
design
release,
do
everything
via
self-service
apis
they're,
not
necessarily
spinning
up
bits
of
the
platform.
The
platform
team
have
already
curated
that
and
they
expose
it
to
developers
via
uis
clies
apis,
all
that
good
stuff-
and
you
know
even
the
non-netflix
companies,
because
we're
not
all
netflix
right,
but
even
the
net,
the
non-netflix
companies.
B
This
has
really
been
codified
nicely
by
a
couple
of
london.
Buddies
of
mine,
matthew,
skelton,
emmanuel
pace
talked
a
lot
about
this
team
topologies
and
it's
kind
of
grown,
I
guess
hand
in
hand
with
with
the
full
cycle
development.
I
know
they've
been
working
on
this
for
many
years,
but
this
book
it's
only
a
short
read.
I've
literally
got
it
on
the
desk
behind
me
here.
I
recommend
it
all
the
time
to
folks
because
it
really
breaks
down
the
relationship
between
say
stream
aligned
teams
as
they
call
them.
B
Often,
product
teams
are
here
as
well
with
other
teams
and
the
two
that
I
think
are
most
interesting
for
us
in
this
sort
of
audience.
This
kind
of
context
is
the
stream
align
team,
which
is
the
product
teams
and
the
platform
teams,
and
they
talk
about
the
relationship,
how
those
teams
all
interact
and
what
I
think
super
interesting
is.
The
platform
team
often
interacts
with
the
product
teams
and
the
other
teams
as
a
service.
This
is
the
classic
almost
platform
as
a
service
heroku
cloud
foundry
that
kind
of
good
stuff
there's
all
you
know.
B
B
The
four
things
I've
identified
in
very
broad
categories
here,
but
is
the
container
management
pretty
much
a
no-brainer
right?
We're
shipping,
mostly
apps
and
containers
these
days,
maybe
functions,
but
even
a
lot
of
functions
are
running
in
containers.
Behind
the
scenes
too,
you
clearly
do
need
progressive
delivery.
This
is
kind
of
continuous
delivery.
James
governor
the
redmonk
team
have
talked
a
bit
more
about
continuous
delivery
and
progressive
delivery.
Very
similar.
I
really
like
the
concepts
behind
progressive
delivery.
It's
about
delivering
value
as
fast
as
you
can
and
as
safely
as
you
can
to
customers.
B
Also
edge
management
is
a
key
thing
here
as
well.
You
need
to
be
able
to
control
what's
released
at
the
edge
to
various
users.
You
want
to
do
canary,
releasing
experimenting
that
kind
of
thing
and
finally
observability.
You
know
the
edge
management
and
the
observability
go
hand
in
hand
with
progressive
delivery.
We
want
to
separate,
deploy
and
release.
B
We
want
to
deploy
as
much
as
we
like
have
maybe
two
versions
or
more
of
the
app
running
in
production,
but
we
control
the
release
by
the
edge
99
traffic
going
here,
for
example,
one
percent
to
our
experiment,
and
we
observe
the
results
both
from
a
business
and
a
operational
perspective,
kpis
slis,
which
I'll
talk
a
bit
more
about
later,
if
you're
more
into
visuals.
This
is
kind
of
like
some
someone
on
the
team
very
kindly
drew
this
up.
B
For
me,
my
drawing
is
really
not
very
good,
but
this
is
kind
of
the
visual
representation
of
those
four
things.
We're
coding
our
apps
here
we're
packaging
them
in
containers
and
deploying
them
onto
a
container
management
platform.
This
handles
the
scheduling
for
us.
If
hardware
disappears,
you
know
on
we're
going
to
scale
out,
for
example,
the
container
management
handles
all
of
that.
B
B
You
also
want
to
expose
stuff
in
a
controlled
manner
to
users
yeah,
you
know
maybe
running
experiments
and
so
forth,
but
the
users
are,
you
know,
the
edge
is
where
the
users
meet
your
backend
services
and
tying
it
all
together
is
observability.
We
need
to
understand
the
apps.
We
need
to
understand
the
container
management,
the
edge
you
know.
Definitely
the
pipeline
I've
seen
a
lot
of
the.
I
think
it's
the
honeycomb
folks
talk
a
lot
about
observing
the
pipeline,
even
which
is
super
interesting
too.
B
That's
the
kind
of
primer
on
this
notion
of
full
cycle.
If
you
want
to
know
more
details,
I've
put
together
some
blog
posts
team
at
the
ambassador
labs
have
done
some
more
work
on
this
as
well.
You
can
go
into
more
detail.
We
link
off
to
all
the
netflix
posts
and
team
topologies
too.
But
again,
I
want
to
remind
you
that
successful
cloud
native
organizations
have
really
thought
about
creating
a
self-service
platform.
B
They're,
not
just
saying
hey
developers,
here's
kubernetes,
they're
sort
of
putting
more
things
on
top
and
they've
adopted
new
tools
to
kind
of
promote
this
notion
of
full
cycle
development,
and
I
appreciate
it
is
a
bit
of
a
buzzword,
but
I
like
the
ideas
around
full
cycle
development
early
in
my
career.
I
was
raising
too
many
tickets
as
a
developer.
Can
you
create
this
manifest?
Can
you
you
know,
expose
this
route
on
the
edge
that's
gone
now
we
need
to
move
faster
than
that.
B
I
mentioned
I've
found
about
anti-patterns.
I've
definitely
done
a
few
of
these
myself,
so
I
wanted
to
call
out
a
few
things.
I've
seen
a
few
things.
I've
read
about
as
well
when
you're
building
a
platform
be
really
careful
about
centralized
control
platform.
Ops
sysadmins
clearly
want
and
need
centralized
control.
This
is
important
in
terms
of
guard
rails
and
governance
and
security
and
things,
but
I've
seen
all
too
often
platform
teams
be
too
kind
of
constraining
and
not
realize
really
that
developers
are
their
customers.
B
B
On
the
flip
side,
I've
seen
a
bunch
of
dev
teams,
and
I've
done
this
myself,
where
we
fragmented
the
platform
implementation.
We
were
working
on
some
ruby
apps
for
spring
apps.
It
was
a
microservice
system
and
we
had
a
java
version
of
service
discovery.
We
had
a
ruby
version
of
service
discovery,
then
we
bought
some
go
in
the
mix
and
we
had
to
go
version
of
service
discovery.
This
is
back,
you
know
five
or
so
years
ago,
but
we
soon
realized.
B
Now
I've
worked
too
many
again
too
many
companies
there's
only
a
handful,
but
too
many,
in
my
opinion,
where
it
was
all
good
intentions,
the
platform
teams
we're
trying
to
do
this
economies
of
scale.
You
know
we
build
a
platform
once
we
build
the
ci
pipelines
once
and
our
developers
can
just
use
those.
But
too
often
the
ops
teams
were
not
working
closely
with
developers.
It
was
a
big
company
in
the
uk.
B
I
can't
mention
their
name,
but
I
went
in
there
as
a
consultant
and
built
a
fantastic
platform,
but
no
one
was
using
it
and
I
realized
very
quickly
that
the
reason
was
none
of
the
ops
team
who
built
the
platform
had
ever
talked
to
the
developers,
so
it
didn't
meet
their
needs.
So
it's
really
important
to
increase
that
collaboration
of
ops
and
dev.
B
It's
also
tempting
again,
you
know
devs
we're
incentivized
to
push
out
functionality
to
deliver
business
value
as
fast
as
possible.
Ops
are
incentivized
to
you
know
not
have
security
incidents
not
fall
over
it's
a
little
bit:
cats
and
dogs.
Sometimes
there
is
a
kind
of
you
know.
A
little
bit
of
animosity
there
healthy
tension,
I
think
is,
is
a
good
thing
actually,
but
we
need
to
be
careful.
B
We
need
to
work
together
as
a
as
an
organization
to
recognize
where
the
guard
rails
are
needed
and
recognize
where
we
can
override
some
things:
big,
one
modification
being
ticket
driven
I've
bumped
into
this
quite
a
bit.
Even
you
know
a
few
years
ago,
when
I
was
working
on
some
projects
to
expose
new
routes
or
configure
new
edge
config,
we
had
to
raise
tickets
with
it
with
the
central
it
facility
and
they
approved.
B
You
know
we
had
web
sockets
we're
allowing
protocol
upgrades
we're
exposing
this
port
or
whatever,
and
we
had
to
factor
in
their
slas.
I
think
they
were
turning
around
tickets
like
within
48
hours.
Of
course,
if
we
need
to
release
an
app,
we
had
to
factor
in
the
sla
to
make
sure
we
synced
up
with
these
things.
So
that's
it's
not
a
good
look
when
you're
trying
to
go
as
fast
as
possible,
you're
trying
to
go
faster
than
your
competitor.
B
I
mentioned
about
fragmented
platform
implementation
and
this
really
crystallized
for
me.
I
was
actually
doing
it
pretty
much
at
the
time.
I
saw
a
presentation
by
steven
tilkoff
and
stephen
talked
a
lot
about
microservices
being
a
great
pattern.
I've
linked
the
presentation
there
for
you.
I
think
it
was
about
two
or
three
years
ago.
Now:
love
microservices,
bounded
context,
hard
network
boundary.
The
temptation,
though,
sometimes
is
to
build
these
micro
platforms,
and,
like
I
mentioned
already,
I
worked
in
a
project
where
we
literally
built
java
service
discovery
java
rate
limiting.
B
You
know,
ruby
service
discovery,
ruby
rate
limiting
and
there
were
subtle
bugs
in
different
implementations.
Updating
them
was
challenging.
Ops
didn't
have
visibility,
they
were
complaining,
they
couldn't
understand
what
we
were
doing.
Quite
rightly,
we
were
at
fault
in
some
ways
in
that
one,
so
this
is
kind
of
the
dev
version
of
you
know,
trying
to
be
freelance
trying
to
go
as
fast
as
possible
and
actually
causing
more
headaches
than
we
intended.
B
Final
anti-pattern
is
the
slow
development
loops
and
mitch.
Denney
did
a
fantastic
blog
post.
I've
linked
there
talking
about
kind
of
the
inner
dev
loop
and
the
outer
dev
loop,
the
inner
one
being
that
really
fast
sort
of
you
know
almost
like
unit
test
style,
tdd
kind
of
feedback,
maybe
a
bit
deeper
in
that
sort
of
integration
testing,
but
getting
really
fast
feedback,
and
he
talked
about
the
commit
tax
in
that
you
know
coding,
building
and
sort
of
inspecting
all
part
of
the
job,
but
in
some
ways
committing
the
code
to
repo.
B
Clearly
it's
part
of
the
job,
but
it's
a
bit
of
a
tax.
You
know
you're
constantly
doing
sort
of
get
push
and
creating
branches
and
things,
and
then
he
extended
it.
But
we
extended
it
further
on
saying:
if
you're
building
code
in
containers,
the
tax
gates
are
even
bigger,
you
know
you're
used
to
doing
that
sort
of
build
hit,
reload
and
then
see
their
results.
Well
that
that
works
fine,
particularly
if
you're
using
mocks
and
stubs
or
you're.
B
You
know
doing
stuff
locally,
but
as
soon
as
you
need
to
engage
with
or
work
with
other
dependencies.
In
your
system,
suddenly
you're
building
the
container
and
then
pushing
that
container
up
to
remote
registry,
which
can
really
add
a
lot
of
time
worked
on
a
couple
of
projects
where
builds
were
taking
four
minutes
and
you
imagine
as
a
developer.
That
was
really
hard
to
keep
your
context
going
when
you're
trying
to
do
these
fast
iterations.
B
I've
got
some
tools
that
can
help
you
on
that.
One,
though
right,
let's
explore
the
platform
capabilities
keeping
in
mind,
you
know
full
cycle
good
stuff,
go
fast,
the
bunch
of
anti-patterns
we
want
to
avoid.
Now.
How
can
we
do
this?
If
we're
looking
at
our
four
capabilities,
say
your
tasks
or
you're
working
on
a
team
that
is
tasked
with
building
out
a
platform
on
top
of
kubernetes?
B
And
what
things
do
you
need
to
think
about
now?
This
will
be
a
whistle
stop
tour
of
some
other
kind
of
you
know
the
goals
I
see
of
each
or
the
team,
and
I
see
of
each
of
these
four
things
and
I'm
going
to
pick
out
some
key
decision
points
and
some
key
challenges.
I've
bumped
into
over
the
years
too
first
step
is
container
management.
Like
I
say
back
five
years
ago,
maybe
kubernetes
hadn't
sort
of
won
the
battle
yet.
But
now
I
think
you
know
kubernetes
is
fantastic
and
it's
it's
in
there.
B
But
so
if
we
take
a
step
back
really
container
management
is
all
about
running
container-based
apps
at
scale
and
on
a
variety
of
infrastructures.
Maybe
we're
on-prem
a
bit,
maybe
we're
in
the
cloud
from
a
dev
perspective.
We
want
self-service
interactions.
We
don't
want
to
be
raising
tickets
for
an
operations
person
to
say,
create
kubernetes
yaml
for
us.
Maybe
we
developers
don't
want
to
know
kubernetes
yaml,
because
we're
just
about
pushing
code,
but
we
shouldn't
be
raising
tickets.
B
That's
going
to
slow
us
down
from
an
ops
perspective,
it's
all
about
setting
those
kind
of
guard
rails
appropriately
access
control,
auditability
who's,
doing
what
these
kind
of
things
is.
It
constant
trade-off
with
sort
of
kubernetes
at
the
foundation
here,
devs
wanting
to
go
fast,
ops
being
responsible
for
sort
of
uptime
of
the
platform.
B
Kubernetes
decisions,
so
one
of
the
biggest
ones
is
the
self-host
or
not.
I
think
this
kind
of
you
know
again.
I
definitely
recommend
platform
teams
work
with
the
devs
teams
to
really
understand
what
the
requirements
are.
I
think
too
often
not
temptation
when
I
did
a
more
of
an
obviously
role.
I
thought
the
company
I
worked
with
was
special
and
we
sort
of
custom
built
some
mesos
stuff,
and
I
look
back
and
I
think
you
know
we
could
have
got
away
with
cloud
foundry.
B
To
be
honest,
you
know
we
thought
we
were
more
special
than
perhaps
we
were.
If
you
are
going
to
self-host
cops
cuba
adm
great
stuff,
I
advise
a
lot
of
clients.
I
work
with.
You
know,
ambassador
labs,
to
go
host.
If
you
can
go
with
something
on
a
cloud
love
rancher.
The
ranch
folks
are
awesome,
chat
to
them
a
lot.
If
you
want
to
get
that
sort
of
cross
and
cloud
thing
going
on
a
lot
of
folks,
I
know
running
open
shift.
They
tend
to
be
more
enterprisey
you're,
buying
into
deeper
abstractions.
B
When
you
go
open
shift,
it's
kind
of
a
bit
of
almost
a
choice
of
sort
of
different
distros.
If
you
like
different
distributions
of
kubernetes
and
you
get
a
lot
of
benefits
by
buying
into
the
openshift
abstractions,
but
they
are
sort
of
on
top
of
kubernetes
as
well
so
you're
kind
of
buying
into
the
platform.
If
you
like,
there
also
need
to
work
with
developers
to
think
about
you
know,
should
we
go
all
in
on
the
cloud?
B
There
is
definite
advantages
with
you
know
going
all
in
on
a
cloud
vendor
and
you
can
leverage
even
in
kubernetes
world,
you
can
leverage
a
lot
of
these
machine
learning
services
or
these
storage
options.
These
queuing
systems,
these
kind
of
things.
You
know
fantastic
work
by
say,
corey
quinn
in
the
team
talking
about
multi-cloud,
you
know,
maybe
not
being
realistic.
Many
of
us
are
working
in
multi-cloud.
We
certainly
do
ambassador
labs.
But
again,
this
is
all
a
conversation
for
ops
and
dev.
B
To
have
ops
should
say
you
know
what
kind
of
stuff
do
you
use
developers
need
get
qa
involved
in
the
mix
too,
in
terms
of
what
kind
of
how
do
we
need
to
provision
environments
for
testing
these
kind
of
things?
These
are
all
discussions
where
I
don't
think
op
should
dominate
it's.
It's
a
it's,
a
collaboration
between
all
the
all
the
functions,
ops,
dev
and
qa
from
a
sort
of
purely
challenges.
Point
of
view.
B
As
a
developer,
I
think
kubernetes
is
sort
of
a
foundation
for
a
path
like
experience
now
I
know
many
development
teams
that
do
simply
write
yaml.
You
know
we
do
mostly
ambassador
labs
devs.
We
write
gamma
and
package
it
alongside
our
our
applications.
No
biggie,
but
not
every
developer-
wants
to
do
that,
and
I've
bumped
into
a
couple
of
really
successful
companies
recently
that
rely
more
on
helm
and
helm
file.
B
So
all
developers
do
actually
is
they
they've
got
like
a
custom
tool,
for
example,
they
might
do
you
know
init
project
and
it
spins
up
a
github
repo.
It's
you
know,
git
repo,
it
spins
up
all
the
kind
of
structure
of
like
a
standard,
rest
type,
application,
a
standard
web
app
using
helm,
and
then
the
helm
file
is
used
for
developers
like
they
literally
fill
in
like
a
values.yaml
file
for
for
all
the
config
options
they
want.
They
don't
have
to
learn
how
the
kubernetes
deployment
descriptor
looks
like
or
the
kubernetes
service.
B
You
know
object
looks
like
the
helm
file.
Values
will
literally
be
something
like
amount
of
cpu
mounted
memory.
Do
you
want
auth
on
this
tls?
What
dependencies
as
this
service
should
be
able
to
talk
to
over
the
wire
these
kind
of
things,
and
then
the
developers
often
just
run
a
cli
tool
and
behind
the
scenes
the
platform
team
have
set
up
this
machinery
that
takes
those
values
in
the
yaml
file
and
then
weaves
them
into
helm
file,
helm
and
pushes
it
down
a
pipeline
and
deploys
the
app
into
a
target
environment.
B
Developer
productivity.
So
on
a
similar
note,
I
I
struggled
definitely
when
I
was
sort
of
getting
into
mesos
and
kubernetes
back
in
the
day
of
you
know,
sometimes
I
needed
to
do
that
fast
kind
of
dev
loop,
but
I
had
this
remote
cluster.
I
was
pushing
my
my
app
to
it's
basically
local
to
remote,
dev
and
test.
Thankfully,
these
days
are
some
fantastic
tools
out
there.
Obviously,
I'm
biased,
telepresence
data
wire
master
labs
tool.
It
is
a
cncf,
hosted
open
source
tool,
but
we're
building
on
top
of
that
one
garden.
Folks
are
awesome.
B
Tilt
folks
are
awesome.
Casings
useful
bumping,
a
bunch
of
folks
in
the
kubernetes
slack
using
scaffold
these
days
as
well
and
scaffold
is
super.
Interesting.
Don't
suffer
like
that.
There
are
tools
out
there
to
make
this
part
of
the
experience
better.
I
work
with
some
teams-
they're,
not
realizing
this
and
they're
stuck
in
these
long
dev
loops
of
you
know,
pushing
up
a
container
waiting
for
it
to
deploy
then
running
some
smoke
tests
and
then
iterating
on
their
code.
These
tools
are
fantastic.
You
know
to
kind
of
shortcut
that
dev
loop.
B
Moving
on
to
progressive
delivery
pipelines,
this
is
really
delivery,
pipelines
really
sort
of
think
about
delivery
pipelines.
The
goal
is
supporting
the
creation
of
pipelines
that
enable
automated
you
know,
build
verification,
deployment,
release
and
observability
is
key
here.
I
think
that's
some
of
the
differences
of
aggressive
delivery
than
say
continuous
delivery
is
the
ability
to
sort
of
experiment
more,
do
more
controlled
releases
on
on
the
actual
functionality,
you're,
releasing
feature
flags,
canarying,
dark,
launching
all
that
kind
of
thing
and
being
able
to
observe
the
results
and
feed
it
back
into
the
continuous
delivery.
B
Progressive
delivery
life
cycle.
This
is
really
really
powerful
when
you
get
it
done
well
from
a
dev
perspective,
same
deal
right,
it's
all
about
automation,
apis,
sdks,
clies,
all
the
toolings.
We
need
to
make
it
as
easy
as
possible
without
raising
tickets
for
our
for
our
ops
team.
You
know
we
want
to
just
consume
the
the
services
they're
running
from
a
platform
team
perspective.
B
It
is
about
the
centralized
verification
of
quality
and
security.
You
know
it's
I've.
Definitely
my
sort
of
fair
share
time
as
a
developer,
not
always
fully
thought
about
some
of
the
security
stuff.
You
know
oh
wasp,
we
haven't
bumped
into
oh
wasp,
well
worth
a
read
about
the
o
wasp
I've.
I've
learned
a
lot
about
threat
modeling
over
the
years,
so
they
got
more
senior
in
my
role,
but
definitely
at
the
start.
B
I
wasn't
always
thinking
about
securities,
probably
as
much
as
I
should
have
been,
and
you
can
now
plug
tools
into
your
pipeline,
such
as
you
know,
I
know
aqua
do
a
scanning
sneak.
Do
dependency,
checking
scanning
of
containers.
You
really
need
to
think
about
scanning
your
code
scanning
the
dependencies
you're
bringing
in
for
vulnerabilities
and
scanning
container
images
you're
using
there's
three
tools
out
there:
oh
wasp
again
hat
tip
to
them
commercial,
tooling.
I've
mentioned
a
couple
names
already.
B
You
can
do
your
sort
of
research
out
there,
but
these
are
things
to
think
about
the
key
goal
with
continuous
delivery.
Progressive
delivery
is
rapid
and
safe
delivery
of
value,
and
it's
context
specific
rapid
and
safe
means
different
things
to
an
e-commerce
site
versus
a
nuclear
reactor.
Do
I
mean
I'm
thinking
nuclear
reactor
we're
going
to
be
optimizing
for
safety,
e-commerce
speed,
because
I
want
to
beat
them
my
competitor,
but
we
need
to
understand,
like,
as
I
can
work
as
a
team.
B
Biz
dev
qaops
come
together
and
understand,
what's
our
definition
of
rapid
and
safe
and
then
once
we've
got
that
thinking
about
pipeline
practices,
I'm
increasingly
seeing
organizations
say
not
being
so
controlled
about
ci,
so
different
teams,
maybe
even
using
circle,
ci
jenkins
or
whatever,
but
coordinating
the
deployment
and
the
orchestration
of
all
these
deployments
using
something
like
harness
or
something
like
spinnaker,
for
example,
I
see
quite
a
bit
your
mileage
may
vary
here.
We
work
with
argo
a
lot
at
ambassador
labs.
B
B
It
often
is,
you
know,
think
about
your
problems
and
then
it's
matched
the
technology
as
appropriate.
There's
a
lot
of
cool
tools:
the
cncf
cdf
we're
doing
a
lot
of
work
in
this
space
and
well
worth
the
researching
and
matching
your
requirements
with
what
technologies
are
out
there
and
again,
your
kind
of
build
versus
by
comfort
level,
too
hot
tip
to
brian
lyles.
I
always
learn
stuff
when
I
chat
to
brian
larsen
very
lucky
on
a
couple
of
podcasts
chat
to
him,
but
he
did
a
fantastic
talk.
B
I
can
be
the
name
of
the
conference
there,
but
one
of
my
friends,
my
colleagues
info
cue,
wrote
up
brian's
talk
and
he
talked
a
lot
about
the
future
of
ci
cd
being
about
composability,
and
I
I
really
buy
into
this
kind
of
thing.
That's
why
I
do
like
argo.
For
that
reason,
you
know
techton
under
the
hood
kind
of
thing
being
able
to
compose
different
bits
of
the
of
the
process.
B
I
really
like
what
the
weave
team
are
doing,
so
we've
got
flux
now
they're,
creating
a
git
ops,
toolkit
kind
of
as
the
next
gen
of
flux,
and
it's
all
about
composability.
Here's
how
you
pull
in
the
source.
Here's
a
d,
your
build!
Here's!
How
you
do
your
integration
tests?
I
really
like
that.
It's
something
I
saw
well
when
I
was
doing
sorry,
I
saw
was
worked
very
well
when
I
was
doing
a
lot
of
work
with
things
like
jenkins.
We
were
always
putting
the
plugins
in
making
our
deployment
pipelines
composable.
B
So
progressive
delivery
challenges.
It's
all
about
that
collaboration.
You
really
have
to
work
hard
to
make
sure
within
boundaries.
Of
course,
you
can't
be
collaborating
all
day
and
just
talking
about
stuff,
you
need
to
do
stuff
too,
but
it's
about
recognizing
the
platform
team.
The
customers
are
qa
and
dev.
B
Getting
that
collaboration,
understanding
requirements,
understanding
the
best
way
of
working
starting
small
and
iterating
from
there.
That's
the
key
thing
you've
got
to
balance
that
one
size
fits
all.
It's
very
tempting.
When
I
was
on
ops,
we
did
you
know
we
like
the
one
size
fits
all
because
it
was
much
easier
to
operate,
but
you
don't,
if
you,
oh
I've,
seen
a
couple
of
projects
where
it
was
just
chaos,
because
the
ops
thing
we
were
too
constricting
and
the
dev
teams
pushed
back
and
we're
doing
like
shadow
I.t.
B
You
know
spinning
up
drones,
spinning
up
circle,
ci
and
doing
their
own
thing,
so
there's
a
definite
balance
on
these
kind
of
things,
but
make
it
easy
to
do
the
right
thing.
I
think
that's
a
motto
for
life
to
be
honest,
but
I
definitely
think
it's
a
motto
in
it
in
that.
If
you,
if
you
value
security
and
yeah,
who
doesn't
that
security
is
really
important,
make
it
super
easy
for
that
pipeline
to
do
the
verification
checks
scan
the
code
scan
dependency
scan
the
the
container,
which
is
super
easy.
B
B
Now
the
edge
is
all
about
this
sort
of
self-service
notion
of
releasing
functionality
by
develop
by
developers
while
maintaining
safety
and
stability.
So
as
devs,
we
want
to
be
able
to
release
new
code
experiment,
try
things
out,
but
we
don't
want
to
expose
things
we
shouldn't.
We
don't
want
to.
You
know,
fall
victim
to
ddos
or
all
these
kind
of
things
too,
as
developers.
It
is
all
about
decentralized
traffic
management.
We
want
to
be
able
individual
product
teams
go
at
their
own
speed.
B
Yes,
if
I'm
working
on
a
team
and
you're
working
on
a
team,
we
may
have
to
coordinate
in
terms
of
our
dependencies,
but
we
shouldn't
have
to
coordinate
our
releases
necessarily
yeah.
We
should
be
free
to
release,
have
our
own
kind
of
release,
trains,
our
own
release
and
times
outside
of
that
coordination
needed.
B
We
also
want
to
support
different
cross-functional
non-functional
requirements
so
off
requirements
on
different
services,
some
retries,
like
some
transactional
stuff-
maybe
you
don't
want
network
retries,
but
other
non-transactional
stuff
having
a
few
retries
at
the
network
level
can
mask
a
bunch
of
intermittent
problems,
sometimes
definitely
be
careful
with
that.
One
from
knob's
point
of
view
platform,
point
of
view
centralized
configuration
of
same
defaults,
I've
learned
a
lot
from
matt
klein
creator
of
envoy
on
this
and
that
I
know
at
lyft.
B
They
do
a
lot
of
interesting
stuff
with
with
envoy
about
constraining
behavior
of
new
services
that
are
deployed
in
the.
If
it
kind
of
goes
and
makes
lots
of
requests
to
things
it
almost
gets
quarantined.
I've
seen
other
companies
do
that
kind
of
same
defaults
and
then
allow
us
as
engineers
to
override
or
have
a
conversation
and
override
as
appropriately
as
appropriate.
B
Definitely,
I
think,
from
platform
team.
I
chat
a
lot
of
folks
in
my
work
at
ambassador
labs
around
you
know,
tls
authnz
ray
limiting
ddos
again
at
the
edge.
This
is
the
first
contact
with
not
only
your
users
but
bad
actors
too.
So
we
have
a
lot
of
chats
of
folks
and
tls.
These
days
is
pretty
much
table
stakes,
but
authentication
integration
with
idps
like
all
zero
key
cloak
otka.
B
All
that
good
stuff
and
platform
teams
are
often
thinking
about
that
and
they
need
to
make
it
as
easy
as
possible
for
developers
to
consume
key
cloak
is
a
fantastic
bit
of
tech,
takes
a
bit
of
setup
behind
the
scenes,
but
we,
as
developers
should
just
be
able
to
really
you
know,
almost
put
a
flag
in
our
config.
Yes,
I
want
you
know
key
cloak
auth
on
my
my
service
in
terms
of
edge
stack
decisions,
so
edge
technologies
envoy,
I
think,
is
becoming
the
de
facto
standard.
B
I
put
a
question
mark
there
because
I'm
sure
the
nginx
folks
aj
proxy
trey
fit
the
folks
who
wouldn't
agree
with
that,
and
I
respect
them
all
a
lot.
We're
seeing
a
lot
you
know.
Obviously
ambassador
is
based
on
envoy.
We
see
a
lot
of
folks
say:
ebay,
building
their
gateways
based
on
envoy
technology.
All
the
clouds
are
investing
in
envoy,
aws,
app
mesh.
Google,
I
think
just
yesterday
came
out
with
an
api
gateway
based
on
envoy
for
serverless,
like
envoys
everywhere
lyft
bootstrapped.
In
a
fantastic
project,
google
committing
a
lot
of
code.
B
The
community
around
envoy
is
just
fantastic
as
well,
so
I'm
very
bullish.
You
know
I
own
my
bias,
but
I'm
very
bullish
on
envoy
at
the
edge
the
xds
apis
are
super
interesting.
So
kelsey
hightower
talking
a
lot
about
this
in
relation
to
what
they're
doing
at
google
around
grpc
and
traffic
director.
So
that's
more
of
a
east
west
service,
mesh
type
thing
envoy.
The
sds
apis
are
how
you
control
onboard
effectively
and
now
grpc
support
some
of
those
things.
B
B
Think
about
deploy,
release
workflows
again,
if
you're
picking
an
edge
stack
like
an
api
gateway
proxy
at
the
edge
and
really
the
config
should
support
all
the
good
stuff.
You
know
and
love
in
the
kubernetes
world
things
like
declarative,
config,
crd,
a
custom
resource
definition
config.
We
want
to
be
able
to
push
our
routing
our
api
config,
then
the
same
pipeline
as
our
app
code.
We're
deploying
you
know:
kubernetes
services
managed
by
helm,
for
example,
like
we
really
want
to
be
controlling
our
edge.
B
Now
you
know
same
thing
with
that,
if
you're
using
say
a
service
mesh,
you
want
to
be
controlling
that
using
the
same
pipeline
that
you're
in
the
same
verification
as
your
as
your
app
code
needs
to
be
self-service
again.
Whatever
your
comfort
level
is
developers
whether
you're
writing,
yaml
or
using
some
kind
of
thin
facade
or
adapter.
On
top,
it
needs
to
be
self-service
for
us
developers
to
you
know,
just
go
as
fast
as
possible:
oops
yeah!
So
in
terms
of
challenges,
I've
done
a
whole
presentation
on
this.
B
B
It's
a
lot
more
dynamic
at
the
back
end
now,
there's
more
microservices,
typically
being
built
versus
the
monolith
like
it's
just
more
challenging
for
devnops
to
work
close
together
to
to
scale
how
you
interact
with
the
edge
as
a
developer.
I
want
to
release
this.
I
want
these
all
things.
These
are
rate
limiting
configs.
B
Now
this
you
know
is
a
no-brainer
over
my
career.
We
know
about
metrics
and
logging.
I
think
this
is
very
much
being
talked
about
in
the
concept
of
observability.
Now
I've
realized
more
and
more.
The
value
of
this,
both
from
a
tech
perspective
and
a
business
perspective
too
observability,
is
all
about
supporting
the
collection
and
analysis
of
the
end
user
and
app
feedback,
and
it
should
be
configurable
by
both
developers
and
the
platform
team.
Often
they
have
different
goals
here.
I
think
my
dev
point
of
view.
B
B
Ops
team,
I
think,
is
more
focused
around
service
level
objectives.
Slos,
there's
the
core
kind
of
you
know
golden
signals,
red,
metrics
and
so
forth
and
use
the
popular
one.
We
talk
about
usability
utilization,
saturation
error
rate,
these
kind
of
things
platform
teams
tend
to
be
a
bit
more
focused
on
below
the
app
and
the
platform
itself
and
the
infrastructure
itself,
and
but
we've
got
the
same
goals.
You
know
we
don't
want.
B
B
Decision
wise,
a
lot
of
mission,
tech
out
there
be
careful
and
start
small
and
go
big.
It's
tempting,
I
think,
when
folks
bump
into
all
these
cool
cncf
hosted
techs
all
the
commercial
techs
out
there.
You
can
kind
of
monitor
all
the
things
and
I
think
in
some
ways
the
more
things
you
monitor
the
more
confusing
the
picture
is
so
my
advice
is,
you
know,
start
small
and
expand
out.
These
things
do
think
about
standards
when
you're
making
technology
selection
at
a
fantastic
podcast.
You
can
check
it
out
on
the
ambassador.
B
Labs
podcast,
with
dave
cydia
from
go
spot
check
and
dave
talked
a
lot
about
how
he
invested
a
lot
of
time.
Thinking
about
the
adoption
of
standards
for
observability,
so
that
you
know
he
at
the
start,
he
could
just
use
a
hosted
solution
for
spitting
his
metrics
out
and
then,
when
he,
you
know,
if
you
scaled
out,
for
example,
he
could
maybe
run
his
own
prometheus
cluster,
these
kind
of
things-
and
it
was
really
interesting
hearing
his
decision
points
and
one
of
the
key
points.
B
He
was
really
pleased
that
he
and
his
team
made
was
that
they'd
invested
in
this
standards
as
a
kind
of
adapter
facade
that
they
could.
Then
you
know
over
time,
not
have
to
modify
their
code,
but
they
could
change
the
back
ends
as
the
scaling
requirements
changed
as
the
cost
requirements
changed
all
these
good
things
so
again,
hot
tip
to
the
cncf.
B
The
hardest
thing,
I
think,
is
joining
the
dots,
and
this
is
why
fantastic
work
by
honeycomb
and
lightstep.
You
know
really
thinking
about
detecting
errors,
detecting
issues
like
sort
of
bad
performing
slis,
for
example,
locating
where
they
may
be,
and
helping
us
as
engineers
to
zoom
in
and
figure
out
exactly
what's
going
wrong.
This
is
something
to
really
sort
of
invest
in
really
think
about.
I'm
happy
to
pay
money
for
a
lot
of
these
things.
For
us,
I'm
not
going
to
be
building
my
own
observability
dashboard.
B
I
don't
think
in
my
team,
we're
happy
to
pay
money
for
other
folks.
Do
this,
for
us
do
make
it
so
that
it's
easy
to
do
self-service,
config
and
dashboards.
This
is
a
key
thing
again.
I
worked
with
some
fantastic
teams
recently
where,
as
part
of
the
tooling
I
mentioned
earlier,
where
a
developer
just
says,
initialize
me
a
project.
B
I
think
jaeger,
open
zipkin,
that
kind
of
thing-
and
this
is
really
cool
because,
like
from
day
one,
I
literally
get
like
sort
of
a
full
scale,
full
scale
dashboard
for
me
to
understand
my
app
at
a
very
basic
level,
and
I
can
add
more
metrics
and
so
forth
into
the
actual
application.
As
I
go
along
more
kpis,
I
literally
code
it
in
using
a
standard
interface
and
that
gets
spat
out
to
my
metrics
collection.
B
Be
careful
about
you
know
increasing
signal
to
noise,
it's
very
easy
to
start,
recording
all
the
things
and
again
I
think
that's
a
where
devs
are
often.
I
find
I
learn
a
lot
from
chatting
to
the
ops
team.
Here
I
say:
hey
you
know
what
kind
of
things
do
you
think
would
be
interesting
signal:
q,
depth?
You
know
latencies
these
kind
of
things
and
you're
always
looking
you're,
not
just
looking
to
collect
metrics
for
the
sake
of
it,
not
pokemon.
B
As
the
joke
goes
and
I've
I've
made
that
mistake
myself
right,
I
monitored
stuff,
because
I
could
I
thought
it
might
be
useful
and
and
yeah.
I
didn't
really
think
about
how
I'm
going
to
use
that
fault.
Location
is
a
key
thing
again.
I
probably
I'll,
I
think,
a
massive
hat
tip
here
to
folks
like
charity,
mages,
cindy
shuttering
and
ben
siegelman,
for
example,
and
they
have
thought
about
this
stuff
in
a
lot
more
depth
than
I
have.
I
know,
like
probably
charity.
I
was
just
thinking
as
I
was
saying.
B
I
probably
argue
that
you
should
collect
all
the
metrics.
Maybe
you
know
don't
look
at
them
until
you
need
to,
but
this
stuff
is
really
important
like
distributed
tracing.
I'm
working
a
lot
with
the
ambassador
labs
steven
moment
around
this
because
distributed
tracing
if
you're,
building
these
deep
systems
you're
building
these
micro
server
systems
that
go
two
or
three
layers
deep,
and
even
if
you
sort
of
roughly
know
where
the
problem
is,
you
often
need
something
like
distributed
tracing
to
figure
out
exactly
where
the
problem
is.
B
B
So
wrapping
up,
hopefully
today
it's
been
a
whistle
stop
tour.
You
know,
being
cloud
native
requires
new
tech
and
workflows.
I
really
like
this
notion
of
full
cycle
development
from
netflix.
For
me,
it's
it's
codifying
putting
a
label
on
stuff.
I've
seen
work
really
well
in
all
manner
of
companies
from
startups
to
sm.
B
You
know
sme
says
smbs
to
the
likes
of
your
unicorns
like
netflix,
we're
not
all
netflix,
but
I
think
there's
many
things
to
be
learned
from
this:
the
separation
of
platform,
team
and
and
dev
team
in
terms
of
the
interfaces,
but
also
increasing
collaboration
between
devon
and
ops-
and
you
know,
qa,
I
think
it's
you
know
this.
This
is
really
powerful.
The
team
topologies
book
I'm
going
to
promote
it
again.
B
I
it's
really
helped
me
codify
how
everyone
and
team
should
work
together
to
deliver
as
most
deliver
the
most
valued
customers
as
fast
and
as
safe
as
they
can
do
think
about
the
platform
in
terms
of
container
orchestration.
Think
about
it
in
terms
of
progressive
delivery.
How
do
you
get
your
apps
on
the
platform
think
about
it?
An
edge
management?
How
do
you
expose
the
functionality
to
your
users
and
how
do
we
figure
out?
B
I've
definitely
accidentally
built
platforms
along
the
way,
but
I
think
these
days
the
technology
is
out
there
again
hot
tip
to
cncf
for
sort
of
curating
and
helping
along
a
lot
of
these
projects.
It's
really
a
case
of
mixing
and
matching
building
buying
appropriately,
but
do
think
about
your
requirements.
Think
about
the
anti-bands
work
well
as
a
team
and
then
create
the
platform
that
you
you
need.
B
I
mentioned
the
start.
We've
got
this
free
tool.
No
registration
required
pop
along
app
dot,
get
ambassador
dot.
Io
ask
a
bunch
of
questions
as
in
you
know,
if
you
want
to
spin
up
an
application,
ready,
kubernetes
cluster
where's,
your
cluster
say
in
amazon.
What
load
balance
have
you
got?
Ask
you
about
ingress,
progressive
delivery.
We've
got
some
prometheus
and
we've
got
some
distributed
tracing
with
jager
in
there.
Now
you
answer
a
bunch
of
really
simple
questions.
B
Like
five
steps
on
a
web
ui
out
pops,
some
custom
yaml
at
the
end
in
a
zip
file,
the
ammo
is
all
integrated
and
all
wired
up.
So,
depending
on
the
options
you
select
it's
it's
customized
for
you.
You
literally
then
follow
the
simple
instructions
of
cubecuttle.
You
know
apply
and
you
can
go
through
and
it's
kind
of
like
a
playground.
If
you
look
on
the
left,
I
just
think.
Two
weeks
ago
I
published
an
article.
B
The
new
stack
talking
about
like
some
of
this
tech
is
quite
complicated
at
first
glance,
so
we
need
a
playground
to
start
poking
and
prodding,
and
particularly
you
know
if
you're
gonna
build
something
to
a
poc
around
the
four
elements
of
the
platform
I
mentioned
there.
Getting
up
and
running
as
quick
as
possible
is
really
beneficial,
so
free
tool
we're
out
there
we're
offering
advice
around
this.
You
know
we
work
with
a
lot
of
customers
that
just
want
to
get
started
as
quick
as
possible.
Hence
why
we've
created
this
tool?
B
We'd
love
your
feedback,
it's
the
team
and
I've
only
just
spun
this
one
up
recently.
So
we're
definitely
looking
for
for
feedback
on
that.
After
that,
I've
dumped
a
bunch,
more
thoughts,
the
team
and
I
have
done
some
podcasts-
we've
done
some
white
papers
and
things
on
this
building
and
kubernetes
platform.
I'm
not
saying
we're
100
right,
but
we've
learned
a
bunch
of
stuff
over
the
years.
B
B
It's
I
like
it
a
lot,
it's
very
interesting,
so
I've
worked
with
the
we
folks
or
chatted
with
the
we
folks
for
many
years
now,
they're
sort
of
come
up
on
the
london
tech
scene,
similar
to
me,
and
I've
watched
a
sort
of
the
ideas
develop.
I
know
there's
been
some
really
interesting,
chats
on
twitter
of
late
the
container
solutions.
B
Folks,
I
think
it
was
jamie
and
opinion
a
bunch
of
other
folks
chatting
online
debating
around
the
benefits
of
get
ops,
and
so
you
can
definitely
pop
onto
twitter
and
get
some
of
the
latest
thoughts
around
there.
They've
blogged
about
it.
Discussion
on
twitter,
too.
My
personal
thoughts
is,
it
aligns
with
a
lot
of
the
things
I
like
around
kubernetes,
this
notion
of
a
single
source
of
truth.
Dev
ops
were
all
committing
to
a
repo,
some
kind
of
control
loop
saying
you
know
this
is
our
required
version
or
desired
version
of
the
world.
B
Git
ops,
you
know
something
like
flux
in
the
middle
there,
reconciling
reconciling
our
desired
view
of
the
world
with
the
actual
view
in
production
and
again
that
just
jams
nicely
with
a
lot
of
things.
I've
done
over
the
years.
I've
done
a
lot
of
work
using
things
like
you
know,
chef
and
puppet
and
and
all
of
them
had
some
notion
of
a
control
loop
going
in
there
and
reconciliation,
and
I
think
kubernetes
now
is
really
embracing
this
notion
of
that
control
loop.
B
We
just
defined
declaratively
what
we
want,
and
it
happens
so
personally,
big
fan
of
gitops
really
like
what
the
weaveworks
team
are
doing
with
git
ops
toolkit.
If
you
haven't
bumped
into
github's
toolkit,
I
did
a
podcast
with
stefan
prodan
on
info
cue
a
couple
of
weeks
ago,
pop
along
to
info
cue
and
check
out
the
podcast
with
stefan.
I
learned
a
lot
from
stefan
and
he
gave
us
a
sneak
peek
on
some
of
the
github's
toolkit
stuff.
B
B
Oh
interesting,
so
when
I'm
assuming
person,
they're,
saying
edge
devices,
sort
of
iot
devices,
mobile
and
so
forth
and
yeah,
that's
an
interesting
one,
there's
a
bunch
of
interesting
protocols
and
not
particularly
my
my
wheelhouse,
but
and
where
you
can
buffer
things.
So
I've
worked
a
lot
with
the
or
chatted
with
a
lot.
B
I
should
say
with
the
r
socket
folks
and
we
have
folks
using
ambassador
with
mqtt
different
and
mobile
protocol,
often
it's
sort
of
either
on
device,
batching
up
of
stats
and
then,
as
soon
as
you
get
connectivity,
you
you
push
those
stats
up.
I
know
all
the
cloud
vendors
are
doing
tool
kits,
particularly
with
this.
This
kind
of
thing
in
mind
that
spotty
connectivity
so
yeah,
I
definitely
say,
have
a
look
at
the
options
out.
There
have
a
look
at
the
different
protocols
out
there
have
a
look
at
the
different
cloud
offerings.
B
I
even
know
envoy
mobile
is
doing
some
interesting
stuff
in
this
space
as
well.
I
remember
chatting
to
matt
and
the
team
I've
gone,
who
I
was
chanting
now
and
they
were
talking
a
lot
about
how
on
the
onboard
mobile
setup
does
kind
of
you
know
almost
buffer
these
things.
When
there's
bad
connection,
then
you
know
sends
it
up.
So
there's
lots
of
options
out
there.
Definitely
a
known
problem,
I
think,
at
the
edge-
and
there
is
a
few
solutions
you
can.
You
can
pick
from.
A
B
Yeah
great
question
so
I
always
say
stay
local
as
much
as
you
can.
So
you
know
even
back
from
like
my
sort
of
fundamental
software
debate
days,
you
want
to
mock
stub
and
virtualize
as
much
stuff
as
you
can
locally
because
locally.
You
know
where
we
can
do
the
the
fastest
iteration
and
the
reality
is
that
when
you're,
using
kubernetes
and
developing
bigger
micro
server
systems,
there
is
some
notion
sometimes
that
you,
you
can't
easily
mock
and
stub
dependencies
or
you
don't
want
to,
because
you
want
to
get
a
more
realistic
environment
for
testing.
B
So
I
say
yes,
stay
local
as
much
as
possible
as
soon
as
you
need
to
get
that
dev
loop,
going
on
with
a
remote
cluster
involved.
You
know,
obviously,
I'm
biased
work
on
tele
presence,
but
telepresence
is
a
fantastic
tool.
It
allows
me
to
effectively
put
my
laptop
in
the
cluster
and
I
can
do
you
know
all.
Like
my
cli
commands,
like
dig
on
the
namespace
ns
lookup,
I
can
curl
kubernetes
services
locally,
as
if
I
was
in
the
cluster.
So
it's
great
for
testing
kind
of
locally.
B
I
can
spin
up
a
debugger
on
my
and
run
my
service
locally
put
traffic
in
the
you
know,
remote
cluster.
Have
it
come
down
to
my
local
machine,
debug
it
and
send
it
back
up
to
the
remote
machine.
So
my
colleague
abbe
saksana,
did
a
fantastic
talk
at
the
recent
kubecon.
So
if
you
all
the
coupon
videos
narrow
the
virtual
kubecon,
are
on
youtube.
I
had
looked
last
night,
so
if
you,
google,
abbey
sana
or
telepresence,
he
talks
a
lot
about
how
he
was
doing
this
like
remote,
dev
workflow.
B
Yeah
yeah,
that
is
true,
so
I
had
a
fascinating
chat
with.
I
can't
mention
the
person's
name
actually,
but
someone.
The
big
uk
company,
asked
me
the
same
question
the
other
day,
so
it
is
tricky
because
not
all
developers
do
want
to
care
about
platform
and
that's
cool
right.
They
just
want
to
write
cool
stuff
code
and
they
want
to
deliver
value
to
customers
and
that's
what
they
should
be
able
to
do.
B
What
I
found
in
my
experience,
running
dev
team
sort
of
pre,
what
I'm
doing
now
at
ambassador
labs
was,
I
looked
for.
There
was
always
like
one
person
on
a
team
or
maybe
a
couple
that
were
you,
know,
developers,
but
they
had
a
kind
of
opsy
mindset.
They
were
fascinated
by
chef
fascinated
by
terraform
fascinated
by
kubernetes
and
I
would
pick
their
brains.
B
I
almost
had
them
as
champions
within
the
team
and
like
one
project,
I
worked
on
called
not
on
the
high
street
myself
and
nick
jackson
from
hashicorp
worked
on
that
project
about
five
or
six
years
ago.
Now
we
kind
of
had
these
platform
champions
in
each
team
where
those
the
folks
that
deliberately
and
wanted
to
learn
about
the
tech
they
sort
of
we
assembled
and
we,
the
ops
team,
picked
their
brains
said
as
customers
like.
What
do
you
need
from
the
platform?
Do
you
like?
B
You
know
they
wanted
some
new
way
of
spinning
up
dev
environments
on
demand,
so
the
platform
team
built
that
for
them
and
these
kind
of
champions
were
the
ones
that
you
know
with
a
bridge
between
the
developers
that
were
just
doing
business
code
and
the
platform
team
somewhat.
Now
it's
blurring
into
site,
reliability,
engineering,
sre!
I
do
bump
into
some
sre
teams
that
are
kind
of
doing
that,
role
that
they're
notionally
developers
but
they're
champions
for
ops
concerns
in
the
development
area.
B
B
Oh,
this
is
yeah
almost
tabs
versus
spaces
right.
I
do
a
lot
more
helm
stuff,
I
would
say,
and
I'm
really
enjoying
the
helm
files
approach.
At
the
moment
I've
seen
some
ranging
chat
on
twitter
around
customized
and
customize
is
built
into
a
lot
of
the
tools.
So
that's
a
kind
of
you
know
that's
kind
of
a
good
thing.
I
guess
I
yeah
I'm
going
to
say.
I
think
they
both
have
their
advantages.
C
A
B
On
the
get
strategy,
so
I'm
guessing
this
might
be
a
question
sort
of
relation
related
to
like
mono
repo
versus
multi
repo.
I
again,
I
think
it
does
depend
on
on
requirements.
I
know
many
teams
have
got
very
successful
deliveries
with
mono
repos
and
then
just
doing
a
kind
of
you
know
typical
and
get
workflow.
B
You
will
notice
that
tools
that
google
famously
do
this,
but
they
have
a
lot
of
internal
tooling,
like
basil,
basil
and
built
to
support
the
mono
repo.
So
my
default
recommendation
is
to
go
well
yeah.
This
is
a
very
anecdotal
thing,
so
it
does
depend
on
your
requirements,
but
my
default
is
to
go
with
individual
repos
per
service.
I
just
find
that
easier
to
get
started
and
then
I
do
a
standard.
You
know
git
model
of
doing
branches,
pull
requests.
I,
like
the
idea
of
you,
know
main
the
main
line
trunk
based
delivery.
B
I
think
it
kind
of
makes
sense
from
a
continuous
delivery
point
of
view.
When
I'm
working
with
the
monolith,
I
will
use
something
like
git
flow.
Occasionally,
I
think
git
flow
is
a
really
nice
pattern,
but
it's
it's
only
really
appropriate
for
the
release,
trains,
monolithic
things.
So,
on
the
other
projects
I
mentioned
later
on
that
not
on
the
high
street,
we
were
using
git
flow
for
our
monolith.
Doing
the
kind
of
following
the
the
pattern
is
well
documented
pattern,
git
flow,
but
we
were
just
using
standard
git
practices
for
our
micro
services.
B
B
We
had
a
few
folks
doing
pull
requests
on
branches
and
so
forth,
so
I
do
think
there's
plenty
of
material
around
there
and
have
it
as
weathering
a
read
online
sort
of
weighing
up
your
options:
mono,
repo
microrepos,
multi,
repos
and
again
I
everything
that
comes
from
sort
of
the
pre-cloud
world
like
git
flow,
do
be
a
little
bit
suspicious
about
its
application
in
the
cloud
world.
I
do
when
I've
seen
a
few
folks
do.
Micro
services
with
git
flow
for
each
repo
and
for
me
that
feels
a
bit
heavy
weight.
A
Excellent
well,
thank
you
very
much
daniel
for
your
time
today
and
thank
you
to
all
of
our
attendees
for
joining
us
this
morning.
As
I
said
earlier,
today's
slides
and
recording
will
be
available
on
the
cncf
website
at
cncf
dot,
io
webinars.
Thank
you
all
very
much
for
your
time
today
have
a
wonderful
rest
of
your
day.
Thank
you
again.
Daniel
thanks.