►
From YouTube: Containing your microservice sprawl
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
The
first
a
little
bit
about
me,
my
name
is
tracy
reagan.
I
am
somewhat
of
a
microservice
evangelist.
You
probably
have
seen
me
around
at
some
of
these
conferences.
I'm
passionate
about
configuration
management
have
done
it
all
of
my
life.
I
am
the
co-founder
and
ceo
of
deploy
hub.
I
am
the
community
director
of
an
open
source
project.
A
Under
this,
the
cdf
it's
incubating
under
the
cdf,
I
was
recognized
as
a
tech
beacon
or
a
top
devops
visionary
by
the
tech
vegan
folks,
I'm
a
founding
member
of
the
eclipse
foundation
way
back
when
and
I'm
also
a
founding
member
of
the
cd
foundation.
A
I
am
hanging
out
around
the
devops
institute,
often,
and
I
have
probably
about
20
plus
years
of
devops
experience,
even
though
we
didn't
always
call
this
devops
and
if
you
ever
like
to
chat,
you
can
reach
me
on
linkedin
at
tracy
reagan,
dash
oms,
so
just
a
little
bit
about
artelias
our
open
source
project
under
the
cd
foundation.
I'm
super
excited
to
be
part
of
the
cd
foundation
was
super
happy
to
be
able
to
contribute
our
code
base
around
this
particular
problem
area.
So
artelias
is
a
microservice
management
platform.
A
So,
as
you
probably
know,
since
this
is
a
cncf
webinar,
but
I'm
going
to
cover
it,
anyways
a
service,
oriented
architecture
and
a
microservice
architecture
are
sometimes
interchanged,
but
there
are
some
subtle
differences.
A
A
service
oriented
to
architecture
was
still
monolithic
and
an
soa
uses
apis
and
as
a
a
way
to
build
out
your
architecture,
but
also
uses
a
service
bus
for
those
apis
to
connect.
A
microservice
architecture
is
truly
truly
a
decomposed
architecture
and
the
concept
of
an
application
goes
away
and
you
become
ma.
You
start
managing
microservices
instead
of
an
application,
but
the
application
is
still
there.
A
Microservices
have
really
shown
a
increase
in
usage
over
the
course
of
the
last
few
years.
The
market
itself
is
growing
pretty
fast,
particularly
around
this
concept
of
a
service
catalog
or
a
way
to
manage
microservices
themselves.
A
This
is
also
kind
of
converging
with
continuous
delivery
and
get
ops,
and
these
this
these
kind
of
progressive
delivery
markets
because
they
are
low
code
they're.
Once
you
really
build
your
microservice
architecture,
it
really
provides
the
business
agility
that
you
need
not
only
taking
advantage
of
the
benefits
of
kubernetes
like
fault,
tolerance
and
auto
scaling,
but
just
the
ability
to
build
out
a
foundational,
a
collection
of
microservices
and
then
have
everybody
reuse
them.
A
According
to
the
cncf's
recent
survey,
92
percent
claim
that
they
use
containers
in
production
and
they
also
are
using
kubernetes
in
production.
Now
microservices
follows
that
trend.
People
normally
start
with
a
containerized
application,
and
then
they
move
into
decomposing
that
into
individual
microservices.
A
A
This
was
early
on
in
the
kind
of
the
micro
service
adoption
she
was
quoted
in
sd
times
as
saying
what
would
happen
is
we
would
release
an
update
to
a
library
and
then
one
service
would
use
a
new
service,
and
now,
all
of
a
sudden,
these
other
servers
were
using
older
versions.
We
had
to
keep
track,
of
which
service
was
using,
which
version
of
the
library
she's
talking
there
about
drift,
where
multiple
clusters
are
using
different
versions
of
the
same
service
and
as
rap
randy
hefner
states.
A
Multiple
services
are
written
by
multiple
teams
that
do
the
same
function.
Bad,
if
you
have
everybody
writing
their
own
login,
routine,
you're.
Not
doing
it
right
not
only
that
you
might
have
somebody
who
does
that
job
really
really
well
and
somebody
who
doesn't
do
it
so
well
and
you
want
to
add
some
security
functions
around
that
now,
where
are
all
those
login
routines,
so
that
is
a
symptom
of
a
lack
of
ownership
or
I'm
sorry.
A
lack
of
organization.
A
A
A
They
may
have
used
a
domain-driven
design
approach
on
paper,
but
then,
when
they
start
to
implement
it
one
of
the
ways
they
could
do,
that
is
maybe
a
naming
standard
where
they,
you
know,
put
the
domain
in
the
name
or
the
app
or
the
team
that
might
have
developed
the
microservice.
But
it's
pretty
obscured
and
a
domain
driven
design
is
super
super
important
in
in
sorting
out
how
to
organize
your
microservices.
A
So
we're
talking
today
about
deploy
hub
and
how
deploy
have
solved
some
of
these
problems
again
deploy
hub.
We
contributed
about
80
of
the
code
base
to
the
ortilius
project.
So
if
the
ortillius
doesn't
do
that
function,
I'll,
let
you
know
most
of
the
code
base
is
available
as
an
open
source,
so
that
is
through
the
ortilius
project,
and
a
domain
driven
design
is
one
of
those
features
that
we
did
contribute
to
the
open
source
project.
A
The
second
problem
that
we
identify
here
is
ownership.
A
service
catalog
would
tell
you
who
is
who
owns
the
microservice,
but
there's
also
a
profile
of
that
microservice.
It's
not
just
about
ownership
or
the
microservices
workflow
that
it
went
through
so
deploy
hub
and
artillius
has
a
back-end
database
that
tracks
microservices
based
on
this
domain-driven
design
catalog,
but
we
also
added
a
version
control
engine
to
it.
So
now
we
have
a
version
control
platform
for
managing
these
microservices
that
has
depth
to
it.
A
It
solves
questions
or
answers.
Questions
like
who
created
this,
who
created
the
service
who
uses
the
service
which
speaks
to
the
blast
radius,
which
we're
going
to
get
to
what
versions
of
the
service
is
running
where
this
addresses
the
drift,
and
obviously
you
want
to
be
able
to
manage
your
drift.
So,
if
you're
going
to
deploy
a
microservice,
you
want
to
be
able
to
deploy
it
to
everywhere.
That's
it's
running
whether
it
be
multiple
clusters
or
in
multiple
namespaces,
and
what
is
the
deployment
metadata?
A
How
many
times
have
I
heard
people
say?
Well,
we
have
a.
We
have
problems
because
we'll
have
a
we'll
have
a
container
which
has
our
microservice,
but
everybody
writes
their
own
helm,
chart
and
deploys
it
in
different
ways,
with
different
parameters
no
place
to
manage
in
a
better
in
a
clean
way,
key
value
pairs,
sure
they
may
be
stored.
Someplace.
A
However,
everybody
can
store
their
own
key
value
pairs
in
in
in
a
central
location,
they're
just
different
people
using
different
key
value
pairs.
So
creating
this
a
service
catalog
around
microservice
and
tracking
that
what
I
call
its
profile
as
well
as
its
ownership,
helps
simplify
microservices
and
eliminates
some
of
the
drift
in
terms
of
how
they're
they're
used
and
deployed.
A
So
I've
been
talking
about
a
service
catalog
and
that's
the
essence
of
what
deploy
hub
and
artelius
is
it's
a
service,
catalog
and
a
logical,
logical
collection
of
microservices
and
how
they
relate
to
their
applications
that
are
consuming
them.
Now
I
talk
about
the
logical
application
because
it's
still
important,
it
is
still
a
piece
of
the
of
the
overall
puzzle
that
we
have
to
understand.
A
A
Well,
we
have
your
microservice
developers
or
api
developers
register
their
microservice
and
when
they
register
their
microservice
they're,
going
to
they're
going
to
register
it
to
a
particular
domain
they're
going
to
define
who
they
are
they're
going
to
indicate
what
count
chart
they
use
or
what
deployment
solution
that
they're
using
for
deploying
this
they're
going
to
manage
the
key
value,
pairs
and
they're
going
to
indicate
what
what
workflow,
what
ci
cd
workflow,
if
you're
using
one,
is
pushing
it.
A
A
A
It
may
just
be
a
release
candidate
and
when
you
think
about
that
think
about
how
we
did
continuous
integration
and
we
triggered
a
build,
a
bill
compiled
a
new
binary
and
now
we
had
a
release
candidate
sitting
there
waiting
to
be
deployed,
there's
always
arguments
about
where
the
release
candidate
actually
starts,
whether
it
be
at
point
check-in
of
the
source
code.
That's
the
release
candidate,
but
when
we
talk
about
continuous
integration,
we
did
that
to
continuously
build
and
and
have
a
viable
release
candidate
that
could
be
pushed
across
the
test.
A
We
are
sort
of
taking
those
concepts
and
reusing
them
and
we're
reusing
them
here.
By
saying
we
have
a
new
release
candidate
that
was
just
registered.
The
image
was
just
registered
the
container
registry
it's
available
to
use.
This
is
what
it
looks
like
this
is
its
home
chart
or
whatever
process
you're
going
to
use
to
to
deploy
it.
And
now
we
have
a
new
version
of
it
and
we're
going
to
track
it.
Based
on
that
that.
A
A
A
That
visibility
can
be
super
super
critical.
It
can
be
used
for
many
things,
not
just
deploying
but
who
to
test
so
before
you
ever
release
a
microservice.
You
really
should
understand
who's
consuming
it
and
what
needs
to
be
done
with
it
and
deploy
hub
can
tell
you
those
can
tell
you
who's
consuming
it
and
again,
I'm
often
asked
how
do
you
do
that,
but
just
think
about
it
as
a
relational
database
with
a
versioning
engine
built
on
top
of
it.
A
A
A
So
how
do
we
do
this?
So
from
the
from
an
application
team's
perspective,
they
are
still
doing
and
building
out
applications
and
they're
still
building
out
applications
and
understanding
them
based
on
a
package
so
within
artillios
and
deploy
hub.
We
provide
them
a
a
packaging
blueprint
where
they
can
select
the
microservices
they're
going
to
use.
We
call
this
their
base
version,
so
we
prime
the
pump
by
defining
a
logical
application
based
on
what
services
it
consumes
and
that
base
version.
Information
then,
is
like
checking
in
your
first
piece
of
source
code.
A
A
So,
like
I
said,
the
way
deploy
hub
is,
is,
is
configured
or
is
built
out.
Is
we
get
triggered
on
a
push
to
a
container
registry
as
soon
as
a
new
image
is
created?
We
want
to
know
about
it
and
we
grab
it
that
triggers
us
to
do
the
to
grab
the
show
information
to
the
the
digest
and
the
tag
and
create
that
new
version
of
that
microservice.
A
It
also
tells
us
that
we
have
to
do
all
of
our
automated
configuration
management.
So
at
that
point
in
time
we
build
out
the
maps
we
update
the
application
versions
that
are
that
are
that
are
consuming
that
microservice.
So
everybody
has
that
information
right
there
right
in
their
face.
Basically,
now,
if
it
gets
deployed,
we
can,
we
can
be
triggered
by
your
cd
pipeline
to
go
ahead
and
say
whatever
that
component.
A
However,
that
component's
been
defined
whatever
whatever
tool
is
used,
is
being
used
for
that
component,
whether
it
be
helm
or
it's
being
pushed
out
by
something
else
to
go
ahead
and
trigger
that
deployment,
and
then
we
listen
and
get
that
information
back.
Well,
what
do
we
do
with
that
information?
We
start
tracking
what,
where
it's
been
deployed,
and
with
that
information
we
can
tell
you
where
you
need
to
deploy
it
again.
A
So,
as
I
mentioned,
we
are
really
doing
automated
configuration
management
and,
at
the
end
of
the
day,
we're
providing
data
not
only
to
microservice
developers
who
are
writing
these
services
and
working
very
hard
to
maintain
them
and
provide
new
features
to
them,
but
we're
also
providing
information
for
application
teams.
A
A
Yet,
but
it's
out
there
and
it's
a
release
candidate
and
the
results-
are
these
types
of
maps,
a
bill
of
material
report,
we're
doing
work
now
even
to
drive
down
and
to
do
bond
reports
for
the
individual
microservices,
which
we
could
then
expand
to
a
bond
report
for
the
entire
all
the
way
down
from
the
from
the
micro
service
to
the
application
and
the
and
the
microservices
consuming.
So
we're
rebuilt
we're
putting
that
that
that
bomb
logic
back
into
a
microservice
architecture.
A
We
show
you
the
blast
radius.
We
show
you
a
consuming
application,
in
this
case
the
orange
box
or
I'm
sorry,
the
pink
boxes
and
the
and
the
microservices
that
was
changed
that
caused
the
new
versions
of
the
of
the
applications
and
the
applications
that
it
impacts
and
super
super
important
for
everybody
is
a
difference
report.
A
What
changed
this
was
running
to
yesterday
and
now
I
get
a
call
and
it's
not
running,
we
didn't
do
anything
as
an
application
team,
what
changed
and
with
with
both
ortillius
and
deploy
hub.
You
can
look
at
your
difference
report
and
you
can
say
this
change
the
cart
service
change,
and
now
you
can
you
with
our
ownership
information.
You
not
only
know
that
the
cart
service
changed,
but
what
version
of
it
and
who
owns
it?
A
Now
I
told
you
I'd,
tell
you
the
differences
between
the
two
deploy
hub
pro
goes
a
bit
a
step
farther
in
these
in
these
comparisons,
and
we
provide
comparison
reports
for
environments
showing
any
between
any
two
clusters.
What
may
have
changed
in
the
cluster,
and
we
also
show
that
same
report
based
on
applications,
and
we
do
it
based
on
the
component,
so
anytime
anytime,
we
do
do
something
has
been
pushed
out
to
an
environment.
A
So,
just
to
summarize,
what
we're
delivering
between
with
ortillius
and
deploy
hub
is
microservices
without
complexity,
we're
helping
you
control
the
sp
the
sprawl
and
have
a
central
catalog
of
microservices,
their
ownership,
the
who,
what
and
where
the
of
the
microservices
so
that
you
can
improve
your
confidence
and
eliminate
risk.
A
A
The
results
from
our
early
adopters.
They
tell
us
we're
saving
them
about
50
of
reduced
coding
in
redundant
coding
and
sprawl
as
well
as
drift.
Drift
is
just
as
big
as
a
problem.
When
you
have
sprawl,
you
tend
to
have
drift.
A
Where
thinking
about
doing
a
deployment
isn't
a
scary
thing.
It
is
a
common
thing
just
to
kind
of
view
what
the
the
pricing
is
around
deploy
hub.
Of
course,
we
have
a
free
version.
We
have
taken
the
ortillius
code
base
and
we
do
have
a
sas
version
of
it,
so
you
can
sign
up
for
it
in
with
deploy
hub
team,
go
to
deployhub.com
you'll,
see
a
site
up
for
deploy
hub
team
and
you
can
start
playing
with
it
playing
with
it.
A
Please
give
us
feedback,
and
let
us
know
what
data
we
love
to
hoard
data.
What
are
we
missing
and
deploy
hub
pro?
We
take
we
charge
based
on
an
application.
We
don't
charge
based
on
end
points
in
some
cases,
we're
not
we're
not
even
doing
the
deployment
we
check
we
charge
based
on
the
mapping
based
on
an
application.
A
A
Some
of
the
differences
most
of
the
differences
between
artillius
and
the
pro
version
have
to
do
with
what
an
enterprise
would
really
really
need.
Enterprise
level
support,
secured
security
around
your
user
groups
and
the
ability
to
have
more
granular
user
groups
in
the
ortilius
version.
You
have
an
admin,
fun
group
and
you
have
a
user
group
in
the
pro
version.
You
can
build
your
own
groups
and
those
groups
can
have
security
around
particular
levels
of
domains.
A
As
I
said,
additional
domain
modeling
for
really
for
defining
how
your
organizational
structure
looks.
We
do
add
more
security
around
the
deployments
to
endpoints
comparison
reports.
I
showed
you
those.
We
also
have
something
called
smart
calendars.
A
So
if
you're,
a
testing
team
or
you're
an
operations
team-
and
you
don't
want
that
microservice-
to
be
updated
into
your
cluster-
you
can
block
your
cl.
Your
your
environment
out
and
deploy
hub
will
take
a
look
at
it
and
say:
hey!
Is
this
cluster
open
for
business
if
it
is
cool?
If
it's
not
we're
going
to
block
the
deployment
and
the
next
time
the
deployment
happens,
we
will
get
that
cluster
back
up
to
its
correct
state
and
we
also
have
something
called
release:
train
management.