►
From YouTube: Lightning Talk - DevOps @ Scale - The Challenge of Cloud Native Architecture- Tracy Ragan, DeployHub
Description
Lightning Talk - DevOps @ Scale - The Challenge of Cloud Native Architecture - Tracy Ragan, DeployHub
As we move away from monolithic practices and venture into cloud native architecture running Kubernetes and microservices, we find ourselves needing to push changes across the pipeline faster than ever before. Our DevOps practices will need to evolve and scale to support a much faster paced CD process supporting a continually changing run-time environment. This lighting talk will identify old habits and bottlenecks that prevent DevOps teams from achieving 100% business agility. What must be understood is that in this new world we no longer have the luxury of time to tweak brittle scripts, and sort through logs. Automation and visibility will be essential in the future Continuous Delivery pipeline and DevOps practice.
A
Welcome
to
a
cdcon
lightning
talk
devops
at
scale,
the
challenge
of
a
cloud
native
architecture,
a
lightning
talk
by
deploy
hub.
First,
let's
meet
me
tracy
reagan.
I
am
the
ceo
of
deploy
hub.
I
am
on
the
board
of
the
cd
foundation,
I'm
a
devops
institute
ambassador
and
I
love
to
ride
big
horses.
I
live
in
a
small
town
in
new
mexico
and
yes,
I
have
a
black
belt.
A
So
it
is
time
to
go
fast.
We
have
talked
about
10
minute,
builds
agile
practices,
sprints
scrum
and
continuous
development,
but
these
discussions
have
always
been
around
a
monolithic
approach
with
a
cicd
pipeline
that
has
been
built
on
static
scripts
for
every
single
workflow.
We
generally
have
lots
of
scripts
that
keep
it
together
cloud.
A
cloud
native
architecture
with
kubernetes
and
microservices
is
going
to
challenge
us
in
that
area,
and
it's
time
that
we
reimagine
how
we
architect
and
continuously
deliver
software
automation
is
key.
Static
processes
and
scripts
are
going
to
be
in
the
way.
A
So,
in
order
to
get
to
this
next
level,
we
really
have
to
reimagine
our
approach
to
a
continuous
delivery
pipeline,
one
that
can
meet
the
requirements
of
what
what
I
like
to
call
devops
at
scale
and
automation,
will
be
key.
Microservices
will
shift
how
we
think
about
the
continuous
delivery
pipeline
and
I'm
talking
about
when
I
talk
about
continuous
delivery,
a
process
that
moves
updates
through
the
pipeline
from
change
requests
to
back
all
the
way
around
to
delivering
updates
to
our
end
users.
A
So,
let's
just
think
about
what's
core
to
a
cloud
native
architecture
and
microservices,
while
we
can
create
a
a
container
and
put
our
monolithic
in
the
container
and
then
push
that
out
to
a
kubernetes
cluster
and
that's
a
great
way
to
start
the
way
we
really
start
building
business
agility
and
get
fast
about.
Pushing
new
changes
out
to
our
clusters
is
through
a
microservice
architecture,
but
that
changes
the
way
we
develop
software.
A
Instead,
we're
going
to
create
a
docker
image
register
it
and
it's
ready
to
go
and
that
docker
image
is
going
to
have
smaller
functions
in
it.
It's
not
going
to
have
a
monolithic
with
microservices
deployments
are
truly
continuous,
regardless,
if
you're
pushing
it
through
your
cd
pipeline,
you
may
be
trying
to
manage
them
manually
today
your
production
deployments
in
particular,
but
that's
going
to
be
a
challenge
with
with
microservices
they're
going
to
need
to
be
updated
on
a
frequent
basis.
A
You
can
continue
to
try
to
do
that
manually
at
the
production
level,
but
what
we
really
have
to
get
to
is
a
point
time
point
where
the
continuous
delivery
pipeline
is
going
to
push
things
across
the
the
pipeline
from
dev
through
production,
and
we
have
repeatability
and
we
have.
We
have
knowledge
about
what
we're
doing
and
what
we're
changing.
A
According
to
the
concept
of
a
microservice,
because
we
don't
have
a
big
build,
is
we
lose
the
application
version
and
that
kind
of
changes?
The
way
we
see
things
and
a
lot
of
workflows
are
going
to
be
around
because
every
microservice
is
going
to
have
its
own
workflow
and
workflows
should
really
be
templated
and
scripts
must
be
minimized.
A
You
know
only
15
of
companies
report
this
massive
success
with
microservices.
We
need
that
to
change
so
what's
lost
in
microservices.
That
is
different
from
monolithic
again.
The
application
version
schema,
that's
always
been
a
north
star
for
us
and
it
does
impact
things
like
testing
bug,
tracking
value
stream
management.
A
We
used
to
have
this
bill
of
material
report
that
we
we
we
trusted
to
show
us
exactly
what
was
in
our
build
and
that
determined
and
and
explained
to
us
how
our
application
was
configured,
how
it
was
what
what
libraries
were
linked,
what
source
code
we
use
that
goes
away
a
difference
report's
gone.
You
know
what
was
new,
what
changed
we
tuned
to
bomb
reports,
something
simple:
we
don't
have
that
anymore,
an
impact
analysis.
A
A
So
what
we
have
to
do
in
order
to
go
fast
in
a
microservice
environment
is
really
to
have
the
knowledge
of
what
we're
changing
and
part
of
that
is
putting
a
logical
version
of
the
application
back
into
a
microservice
architecture.
So
going
fast,
isn't
so
risky.
Remember
these
microservices
are
going
to
get
pushed
out
on
a
high
frequency
basis,
regardless
of
how
much
people
want
to
slow
that
down
they're
going
to
get
pushed
out.
That
is
the
core
of
microservices
and
that's
why
microservices
create
the
business
agility?
A
A
So
that
is
what
deploy
hub
is
deploy
hub
is
a
microservice
management
platform
for
site,
reliability,
engineers,
devops
engineers
and
release
teams.
It's
a
self-service,
sas
solution
that
allows
you
to
share
microservices
and
what's
called
a
domain
driven
design.
Don't
have
time
to
talk
about
that,
but
it's
important
you
should
read
about
it.
It
restores
that
logical
application
version
and
maps
microservice
dependencies.
A
Knowledge
is
power,
knowing
what
you're
changing
is
critical.
If
you
know
what
you're
changing
you
can
push
it
out,
if
you
don't
know
what
you're
changing
you
have
you
lack
confidence
in
doing
so
you
can
achieve
devops
scale
without
some
clear
visibility
about
what
you're
pushing
out
deploy
hub
produces
bill
of
material
reports
or
maps.
A
It
shows
that
for
each
application
version
what
microservices
that
that
application
version
is
consuming
and
the
versions
of
those
microservices
and
for
every
version
of
a
microservice,
it
shows
exactly
the
applications
that
it's
impacting
and
for
every
time
a
microservice
is
deployed
out
to
a
cluster.
It
shows
the
difference
report
between
the
last
time
that
application
was
running
and
now
with
the
new
microservice
out
there,
which
microservice
created
the
new
application
version.
A
So,
enhancing
that
ecosystem
to
be
able
to
confidently
deploy
services
all
day,
long
and
really
meet
devops
devops
at
scale
is
the
goal
of
deploy
hub
and
it
does
that
by
adding
some
important
configuration
management
features
into
your
cd
pipeline.
For
example,
it
establishes
that
logical
application
version.
It
provides
the
reports
that
we're
used
to
seeing
so
we
understand
what
we're
deploying
it
tracks.
A
Things
based
on
a
git
commit
a
a
registry,
shaw,
a
tag,
a
change
request
and
that's
what
it
uses
to
create
new
versions
of
microservices,
which
then
in
turn
creates
new
versions
of
applications,
and
then
it
it
does
something
very
important.
It
tracks
all
those
changes
across
all
the
clusters,
so
it
creates
a
central
repository
and
registry
of
everything
that's
running
across
all
your
clusters.
A
What
do
you
get
well?
First
of
all,
it
takes
the
guesswork
out
of
tracking
who's,
consuming
your
microservice
if
you're
a
microservice
developer,
and
it
saves
some
serious
time
when
it
comes
to
tracking
these
pieces
and
if
you're
doing
it
manually,
it's
going
to
slow
you
down
and
you're,
not
going
to
achieve
devops
at
scale.
A
A
A
domain
driven
design
will
help
you
solve
that
problem
and
that's
part
of
the
deployment
solution
and
deploy
hub
allows
you
to
confidently
deploy
microservice
across
clusters,
because
you
have
the
knowledge
to
make
some
serious
decisions
about
impact
even
before
they
land
on
in
a
microservice
and
start
creating
incident
reports-
and
I
hear
people
all
the
time
say
part
of
the
problem
is
we
have
to
wait
till
we
do
a
deployment,
and
then
we
get
the
incident
reports.
We
want
to
do
that.
The
other
direction.
A
We
want
to
stop
the
problems
before
they
happen
and
that
visibility
is
important
for
doing
that,
because
the
visibility
gives
site
reliability,
engineers,
the
knowledge
of
what's
happening
and
that
data
driven
and
that
data
is
what
gives
the
sres
the
data
driven
decision
making
power
to
know
when
a
microservice
is
ready
to
go
out
and
how
much
is
how
risky
it
is
deploy
hub
is
based
on
an
open
source
project
called
ortelius.
Ortilius
was
the
first
map
maker
he
created
known
to
be
the
first
person
to
create
a
world
atlas.
A
We
have
a
growing
and
very
diverse,
open
source
community
we're
and
we're
working
hard
together
to
really
reimagine
how
software
needs
to
be
delivered
for
this
cloud
native
environment
and
to
really
achieve
devops
at
scale
join
us
we,
we
would
love
for
you
to
help
us
go
fast,
and
I
think
that
knowledge
bringing
knowledge
together
from
people
of
all
different
kinds
of
technical
backgrounds.
To
really
take
this.
This
problem
on
and
solve
it
so
we
can
achieve
devops
at
scale,
is
exactly
what
we
need
today.
A
So
please
join
us,
and
the
good
news
is
deploy
hub
has
a
free
version.
There
are
some
differences
between
what
we
monetize
and
what
we
call
pro,
but
the
free
version.
You
can
have
unlimited
releases,
unlimited
users,
what
we
restrict
our
user
groups,
things
that's
going
to
be
more
appropriate
for
an
enterprise,
but
if
you're
a
team-
and
you
have
full
control
of
your
environment,
deploy
hub
will
take
you
a
deploy
of
team.
A
Will
take
you
quite
a
ways
so
sign
up
at
deployhub.com
and
let
me
know
what
you
think
and
here's
how
you
can
get
a
hold
of
me
and
we
thank
you
so
much
for
listening
to
this
lightning
talk
and
if
you
want
to
reach
out
to
me,
tracy
deployhub.com
is
the
easiest
way,
and
here
is
my
calendar
but
reach
out
to
me,
and
we
can.
We
can
chat
more
and
you
can
tell
me
your
your
experience
into
microservices.