►
Description
Speaker: Tracy Ragan, CEO of DeployHub
As you migrate to microservice you will quickly begin to see that your CD pipeline needs some tweaking. With microservices you shift your focus to pushing loosely coupled and independently deployed services to your cluster versus installing a complete software application. You no longer have a broad packaging step that defines an application version in the same way as you do in traditional methods. Tracking your application versions is still critical to the overall health of your CD pipeline from tracking change requests to making data-driven decisions about new releases. In this webinar, we will review how you can use DeployHub to map and version the logical view of your application even when it has been decoupled. We will show how DeployHub evolves your CD pipeline to support a microservice implementation while still tracking your application’s complete configuration.
A
Let's
get
started,
thank
you,
everyone
for
joining
the
first
CDF
webinar.
Today
we
are
joined
by
tracy
regan.
She
is
CEO
and
of
deploy
hub
and
governing
board
member
of
the
cdf,
and
today
we
are
going
to
be
talking
about
evolving
your
pipeline.
Oh
you,
sorry,
evolving!
Your
pipeline
for
micro
services
with
deploy
hub,
welcome.
B
Tracy
so
I'm
gonna
tell
you
a
little
bit
about
myself.
Well,
we
have
some
folks
joining
I
am
a
huge
fan
of
micro
services.
I
think
this
is
a
super
exciting
time
to
be
in
software
and
I'm,
not
new
to
open
source
I
was
a
founding
member
of
the
Eclipse
Foundation,
which
was
a
very
interesting
experience
and
was
recruited
by
Tracy
Miranda
about
two
years
ago,
when
they
first
started.
B
Thinking
about
creating
the
CD
foundation
and
I
was
honored
to
be
recruited
by
them
and
I'm
working
very
hard
for
the
CD
foundation
these
days,
because
it's
a
very,
very
important
aspect
of
micro
services,
believe
it
or
not-
and
you
know
in
terms
of
who
I
am
I
live
in
this
beautiful
state
of
New.
Mexico
that
right
hand
side
down.
There
is
the
road
to
my
house.
I
have
horses
I
spend
my
time
doing
things
for
my
communities
same
as
I
do
for
the
open-source
communities
I
run
the
kids
Halloween
party
every
year.
B
Yes,
that's
me
dressed
as
Einstein,
and
that
is
my
horse.
His
name
is
Dakota
and
I.
Now
I'm
making
masks
so
I
spend
a
lot
of
time.
Sewing
I've
never
sewn
before
and
decided.
It
was
time
for
me
to
learn
to
sew
and
so
now
I
make
masks
for
my
community
some
of
the
takeaways
that
we're
gonna
I
want
you
to
think
about
as
we
as
we
go
through.
This
is
micro.
Services
themselves
are
really
important,
but
they
do
break
our
traditional
model
of
software
delivery.
B
What
we
used
to
call
software
configuration
management
or
SEM
has
actually
shifted
from
what
you
used
to
do
in
your
build
to
run
time.
That
is
a
critical
shift.
Also
is
we've
lost
the
logical
view
of
the
application,
which
is
another
really
big
shift,
and
we're
going
to
talk
a
little
bit
about
deploy
hub
and
ortelius,
which
is
an
open-source
project
that
is
the
core
of
deploy
hub
that
solves
some
of
these.
These
issues,
so
the
basically
the
way
we
put
software
together
now
is
broken.
B
B
What
version
of
the
library
now
in
some
ways,
kubernetes
tries
to
solve
that,
but
in
the
way
it
solves
it
can
be
a
problem
and
as
Randi
Hefner
from
Forrester
points
out
is
that
microservice
development
completely
falls
apart
without
a
coherent
disciplined
management
approach.
So
what
happens
when
you
move
from
a
traditional
method
to
micro
services,
as
developers
start
struggling
with
finding
and
sharing
micro
services,
they're
pushed
out
to
a
cluster
I've.
B
Devops
teams
themselves
could
only
see
us
some
small
part
of
the
picture
because
now
they're
thinking
about
pushing
micro
services
out
to
a
cluster
or
out
of
your
production
environment,
which
may
have
impact
on
multiple
applications,
even
though
we
don't
know
what
the
application
is
anymore
because
it's
gone
and
what
happens?
Is
this
business
agility
that
we've
been
promised
in
the
world
of
micro
services
is
actually
broken
as
we
get
more
and
more
more
complexity,
around
moving
things
to
production
and,
if
and
a
function-based
architecture.
B
So
the
first
place
I
like
to
start
in
describing
this
this
particular
problem
set
and
what
you're
going
to
be
facing
as
you,
your
your
CD
pipeline
starts
to
evolve
is
the
build
we
all
have
to
remember.
Where
we
came
from,
we
came
from
the
build
CI
CD
is
still
talked
about.
We
we
talked
about
continuous
delivery,
seldom
without
saying
CI
CD
continuous
integration
was
the
process
of
doing
a
source
code
check
in
and
automatically
checking
it
out
and
kicking
off
our
compile
process.
Now.
Why
did
we
do
that?
B
B
There
were
days
that
when
we
would
compile
it
would
we
I
worked
on
projects
where
we
would
submit
our
code
and
we
had
a
poor
person
sitting
in
the
corner,
who
worried
about
builds
once
a
month
and
they
would
have
to
pull
it
all
together.
Continuous
integration
changed
that
and
at
that
point
in
time
you
made
really
important
decisions
about
what
went
into
your
build
with
microservices
we
lose
that
concept
builds,
are
small,
sometimes
they're
written
in
Python
Python
isn't
compiled,
it's
it's
a
function
based
and
there
is
no
linking.
B
So
if
you
think
about
what
that
looks
like
you
have
this
traditional
method
where
we
would
create
a
package
and
that
package
included
all
of
the
link.
Although
the
libraries
we
would
use
something
like
an
artifact
turi
to
do
transitive
dependency
scanning
to
understand
what
we
needed
to
pull
in
and
what
we
needed
to
link
and
compile
and
create
our
big
fat
binary,
all
of
that
was
done
it
at
the
earliest
stage
of
development.
It
was
the
first
thing
we
did
in
our
continuous
delivery
journey.
B
We
first
did
CI
now
now
that's
gone
and
anumana
in
a
modern
architecture
with
micro
services.
You
push
a
single
service
across
the
pipeline,
it's
linked
at
runtime,
so
that
really
smart
person
in
the
corner,
who
used
to
keep
track
of
all
of
the
stuff
that
we
needed
to
put
in
our
binary
they're
not
doing
that
anymore.
That's
linked
at
runtime
now
is
now
done
and
what's
generally
called
a
a
kubernetes,
a
deployment
file
or
a
helm
file.
You
try
to
keep
track
of
it
in
that
in
that
at
that
level.
B
So
the
results
is
like.
We
take
a
wineglass
and
we
take
a
hammer
to
it
and
we
break
it
into
small
pieces.
We
have
a
pile
of
glass
in
front
of
us,
but
what
is
it?
Is
it
a
wineglass?
Still
it
is
it's
still
there,
it's
just
in
pieces,
and
we
have
to
think
about
how
we
keep
track
of
that
application,
because
the
application
is
the
basis
for
everything
we
do.
I
mean
I'm
sure
that
nobody
has
had
a
user.
B
That's
in
the
micro
service
architecture
has
had
an
end-user
call
up
and
say
I'm
having
a
problem
with
my
micro
service,
they're,
gonna,
call
and
say
I'm
having
a
problem
with
the
application
and
generally.
What
the
first
thing
is
you
want
to
know
is
what
version
of
the
application
are
you
running?
Well
with?
How
do
you
do
that?
In
a
micro
service
environment?
It
can
be
tricky,
so
solving
the
problem
includes.
You
know,
four
basic
steps.
We
have
to
replace
this.
B
What
I
call
critical
configuration
management
lost
at
the
compile
step
that
has
to
be
replaced?
We
still
want
our
traditional
BOM
reports.
We
still
need
to
be
able
to
do
impact
analysis.
We
are
still
delivering
an
application
to
our
end
users,
even
though
it's
made
up
of
a
number
of
micro
services
I've
been
doing
a
lot
of
talking
to
people
if
I've
been
reaching
out
to
folks
to
really
find
out
this.
This
problem
set
and
generally
most
people,
are
telling
me
that
their
applications
built
around
micro
service
includes
somewhere
between
60
and
150
micro
services.
B
So
that's
the
level
of
complexity,
I've
had
bigger
ones,
I've
heard
people
say
300
so
being
able
to
track.
The
logical
view
of
the
application
with
versioning
is
important
because
we
don't
want
to
throw
the
baby
out
with
the
bathwater.
We
need
to
be
able
to
map
the
dependency
relations
of
ships
of
micro
services
back
to
the
logical
applicant
nation,
and
we
still
need
to
be
able
to
say
for
this
micro
service.
B
These
applications
are
consuming
it
and
the
reason
why
we
need
to
do
that
is
because,
if
this
micro
service
changes
it
has
an
impact
on
multiple
applications
which
changes
what
we
have
to
do
in
the
CD
pipeline.
So,
for
example,
if
you
have
a
security,
a
high-risk
security
micro
service
that
everybody
in
your
organization
is
using
for
their
application
that
gets
updated,
I'm
guessing
most
application
teams
would
probably
like
to
retest
their
application.
How
do
we
filter
that
through
the
pipeline?
How
do
we
say
this
change
in
this
micro?
B
Service
has
impacted
all
of
these
applications
and
then
there's
a
problem
with
cataloging
and
sharing
services.
As
I've
pointed
out,
some
people
tell
me
that
they
use
a
micro
service
registry,
but
that's
after
the
fact,
so
it
has
to
be
written
and
then
pushed
out
to
the
cluster,
and
then
you
might
be
able
to
find
that
it
exists.
But
it's
right,
you
only
recognize
it
based
because
somebody
may
have
told
you
the
name
of
it.
It
doesn't
have
good
information
about
the
problem
space
that
it
solves.
B
So
it
can
be
difficult
to
know
what
micro
services
that
you
have
available
to
you
if
you're,
depending
only
on
what
was
pushed
out
to
the
cluster,
so
we're
going
to
talk
a
little
bit
about
deploy
hub
and
our
ortelius
open
source
project,
which
is
the
core
of
deploy
hub.
We
have
in
terms
of
what
deploy
hub
does
most
of
it,
isn't
in
in
the
ortelius
open
source.
It's
the
SAS
base
hub
for
sharing
and
managing
and
releasing
micro
services
it
tracks
and
shows
this
logical
application
map
to
simplify
the
complexity
of
the
micro
services.
B
So
you
can
actually
achieve
that
agility
that
you're
shooting
for
and
it
supports
a
domain
driven
design.
So
it's
easy
to
find
and
share
micro
services
and
best,
yet
it
it
pumps
right
into
your
CD
pipeline
so
that
you
can
do
continuous
configuration
management.
So
you
always
know
if
a
micro
service
changes
that
you
have
a
new
version
of
your
application
that
you
might
want
to
test
so
think
about
it.
In
this
way,
this
is
a
small
application.
It's
a
hipster
store.
We
use
it
as
an
example
in
are
in
our
free
version.
B
That's
the
art,
alias
based
version.
These
pink
boxes
are
the
different
versions
of
the
store,
there's
four
different
versions
out
here
and
each
one
of
these
uses
different
micro-services.
So
this
is
a
holistic
view
of
the
application.
At
the
end,
it's
versions
as
well
as
the
micro
services
that
it's
using
you
can
drive
down
and
just
look
at
one
version
and
see
what
it
consumes
and
you
can
do
dips
so
think
about
what
we're
delivering
here
from
an
open
source
perspective
as
we're
delivering
your
diffic
quart
and
your
BOM
report
your
bill
of
material
report.
B
It
still
is
essential
today,
as
it
was
in
the
traditional
model,
because
that's
what
we
do
all
of
our
impact
analysis,
all
of
our
user
management
and
that's
how
we
see
our
application
so
to
evolve
the
pipeline.
What
you're
going
to
need
to
be
able
to
do
is
each
micro
service
is
going
to
be
an
independently
deployable,
which
means
it
should
have
its
own
workflow.
A
monolithic
would
put
everything
into
that
workflow
and
push
it
across.
So
all
the
components
will
be
pushed
across
altogether,
and
you
really
can't
do
that
in
micro
services.
B
So
you,
in
order
to
sort
of
fix
some
of
those
problems
you
can
add,
deploy
hub
to
the
workflow
and
to
perform
the
tracking
and
the
mapping.
So,
every
time
your
workflow
pushes
a
new
micro
service
across
the
CD
pipeline,
you
can
automatically
have
you
called,
or
the
employee
have
more
of
the
ortelius
core
to
auto
increment
the
micro
service,
and
then
it
auto
increments
the
application,
and
then
it
provides
you
some
clean
dashboards.
B
So
you
can
see
your
diff
and
you
can
see
your
BOM
and
you
can
see
your
logs
and
in
terms
of
doing
that,
actual
deployment.
It
uses
the
stuff
that
everybody
is
comfortable
with,
such
as
how
AM
or
ansible
to
do
the
actual
push.
Our
core
service,
though,
is
tracking
the
metadata
associated
to
a
micro
service
tracking
the
relationships
it
has
with
the
application
and
then
pushing
it
out
to
helm
or
ansible
to
do
the
push
you
can
think
of
it
as
a
internal
marketplace
for
microservices,
so
how
it
works.
B
So
the
API
developer
publishes
their
micro
service
to
the
domain
catalog.
This
allows
anybody
who's
at
the
application
level
to
find
it
based
on
solution
spaces
such
as
security,
or
you
know,
cart
tools
or,
if
your
online
store
or
in
end-user
data
being
able
to
get
end-user
information.
That
could
be
just
a
set
of
my
micro
services
that
have
already
got
all
the
sequel
in
it
and
all
the
metadata
about
that
micro
service
is
collected.
Things
like
they
get
commit.
B
The
SHA
number
of
the
the
container
registry
there's
like
there's
a
whole
host
of
low
level
details.
That's
needed
to
redeploy
it,
including,
like
the
version
of
the
hound
chart
that
was
used
when
application
developers
first
interact
with
Mike
with
deploy
hub,
they
define
their
application
based
on
the
micro
services.
We
call
that
the
base
version
of
the
of
the
application
after
that
base
version
is
collected,
deploy
hub
does
its
versioning
and
engine
and
his
deploy
observer.
B
B
So
what
your
pipeline
ends
up.
Looking
like
from
a
you
know,
a
high-level
view
is
instead
of
this
a
CI
step
here.
Your
CI
step
is
basically
building
your
container
image
and
again
there
may
be
a
compile
step
to
it.
You
might
be
using
go,
you
still
might
be
using
Java
you
but
you're
fusing
JavaScript.
B
Some
some
companies
are
using
I
could
like
an
internal
sauna
type
to
track
their
binaries
I've
even
heard
some
people
checking
it
in
to
get
which
is
a
viable
place,
but
some
of
the
container
registries
are
actually
specific
for
for
registering
containers
and
if
you
haven't
looked
at
one,
you
should
definitely
take
a
look
at
some
of
those
container
registries
I
like
way
that
spelled
qu
a
way
once
that's
done.
Your
city
pipeline
needs
to
start
tracking
your
service
to
application
configurations.
That's
where
the
critical
piece
is
for
the
SEM.
B
Now
I've
left
out
some
of
the
other
stuff
like
security
scanning
and
testing.
There
are
other
steps
that
are
in
here,
but
this
little
picture
could
get
really
confusing
and
we're
just
going
to
talk
about
the
SCM
part
of
it
and
they
how
you
register
your
your-your-your
docker
container,
so
once
you've
once
deploy,
has
done
that
tracking
for
you,
it's
ready
to
go
and
be
pushed
out
to
your
cluster
dev
test.
Prod
and
most
companies
have
literally
lots
of
clusters.
I've
I've
heard
people
saying
that
they
have
each
development
team
has
a
cluster.
B
Sometimes
they
say
each
developer
has
a
cluster
they're
managing
their
own
cluster
to
do
the
testing?
Well,
that's
even
more
reason
why
we,
you
need
something
like
to
deploy
hub
to
centralize
the
container
so
that
anytime,
that
deployments
done.
That
deployments
done
exactly
the
same.
So
it's
done
regardless.
It's
moving
into
dev
tests
or
prod
or
some
other
collection
of
clusters
that
people
are
using.
Then
we
collect
feedback.
B
You
know
we
might
have
problem
tickets
opened
against
your
application
running
now
as
a
result
of
these
micro
services
being
deployed,
and
you
do
the
you
use,
deploy
hub
to
do
that,
configuration
reporting
and
being
able
to
identify
the
impact.
So,
for
example,
if
you
have
an
application,
that's
running
out
there
and
you've
borrowed
a
stack
of
micro
services
from
external
teams.
The
API
development
teams
and
that
gets
pushed
across
and
you
don't
know
it
and
your
application
stops
working
you
can
use
deploy,
have
to
see
what
changed
before
the
deployment
actually
even
occurred.
B
So
you
could
actually
do
impact
analysis
and
understand
that
it's
being
pushed
out
before
it
actually
goes
yeah.
You
also
have
a
way
to
subscribe,
so
you
could
subscribe
to
a
set
of
Micra
services
and
know
beforehand
that
they're
starting
to
move
across
the
pipeline
so
think
about
it
in
this
way.
Okay,
so
now
you
have
we're
going
to
just
talk
about
this
little
hipster
store
and
break
it
into
from
a
monolithic
to
micro-services,
and
this
example
your
current
CD
process.
This
could
be
a
circle,
see
I
could
be
a
Jenkins.
B
It
could
be
a
Jenkins
X
or
a
spinnaker,
your
circle,
your
your
repost,
though,
are
going
to
be
broken
out.
You're
no
longer
going
to
have
one
big
workflow
that
manages
all
of
them,
and
we
certainly
we
can
talk
about
that.
If
anybody
asked
questions
on
it,
but
there's
a
good
reason
for
it,
and
the
main
core
reason
is
because
these
microservices
are
deployed
independently.
We're
not
talking
about
taking
that
old
package
that
box
that
had
everything
in
it
and
pushing
it
out
together.
Each
little
function
is
going
to
go
out
independently.
B
So
what
deploy
hub
does
before
it
goes
out
to
these
your
clusters?
Is
it
aggregates
that
information
back
showing
you
what
the
what
the
application
looks
like
based
on
an
application
version,
and
it
actually
does
the
versioning
for
you
anytime?
Let's
say
the
front-end
repo
goes
out
and
that's
probably
the
most
common
thing
to
be
pushed
out
and
that's
what
the
application
team
would
be
working
on
and
they're
going
to
know
what
what's
in
it,
and
what
what
they've,
what
they've
changed
for
the
most
part?
B
But
if
something
at
the
payment
service
or
the
security,
repo
changes
and
they're
borrowing,
those
micro
services,
they
still
are
going
to
have
the
visibility
about
what
happened,
and
that
is
probably
the
most
important
concept
to
kind
of
put
your
brain
around
is:
how
do
you
see
what's
happening
not
just
at
the
at
the
kubernetes
cluster
level,
but
actually
what's
happening
at
your
application
level,
because
these
are
many
moving
parts
now
being
pushed
out
to
the
cluster
on
a
high
frequency
basis?
And
how
do
you
keep
track
of
that?
B
B
Hybrid,
a
hybrid
environment
is
a
really
good
place
to
start,
and
what
that
means
is
you
containerize
your
monolithic
application
and
you
stick
with
your
pretty
much
traditional
model
of
CC
ICD
and
you
put
everything
in
the
container
and
you
push
it
out
to
your
your
your
new
modern
architecture
as
a
containerized
application
that
gets.
You
started
with
understanding
how
to
use
containers
and
it
gets
you
started
and
along
the
the
journey
of
kubernetes.
B
Other
companies
take
a
more
direct
approach.
Instead
of
just
container
izing
their
application.
They
begin
to
look
at
how
to
break
up
their
applications
into
problem
spaces
or
domains,
and
that
really
helps
facilitate
reuse
of
Micra
services
and
achieves
that
low
code
that
we're
trying
to
accomplish
by
having
reusable
services
by
breaking
your
application
down
into
domains.
B
If
you're,
not
managing
the
micro
services
itself,
so
deploy
have
streamlines
that
micro
service
adoption
journey
by
providing
a
way
to
do
both
traditional
and
containerized
and
micro
service
deployments.
It
has
a
domain
structure
so
that
you
can.
You
can
start
publishing
and
cataloging
those
micro
services
for
reuse,
it
does
the
versioning
and
it
it
records
the
deployments
now.
Just
a
point
of
just
a
note.
It
does
have
its
own
deployment
engine
for
doing
database
updates
and
the
reason
why
it's
out
there
is
so
that
you
can
do
easy
rollback.
B
B
So
your
sres
have
the
ability
to
make
strong
data-driven
decisions,
and
even
you
can,
as
an
application
team,
decide
if
you
want
to
push
some
of
this
stuff
across
or
if
you
want
to
accept
it,
and
that
is
a
different
whole
different
webinar
on
how
we
start
managing
these
moving
these
these
micro
services
moving
across
and
deciding
what
part
of
the
see
what
what
CD
workflow
that
they
should
go
through.
I
like
the
idea
of
truth
tables
and
maybe
someday,
we
will
do
it
another
webinar
on
truth
tables.
B
So
just
so
you
know
the
pricing
around
it.
Our
ortelius
version
has
been
recompiled
and
lives
in
our
SAS
environment
and
you
can
be
used
for
absolute
free
kind
of
like
me
sitting
there
making
masks
the
idea
of
democratizing
these
kinds
of
tools
is
the
core
reason
why
we
have
open
source
and
it's
incredibly
important
for
companies
who
are
starting
out
down
this
journey
and
struggling
that
they
have
open-source
tools
that
can
solve
the
problems
as
fast
as
possible.
B
The
pro
version
is
based
on
what
I
call
an
application,
which
is
a
collection
of
micro
services
of
your
bank.
It's
a
teller
application
and
it's
$2,500
per
project
per
year.
Now
we
do
have
an
enterprise
account,
and
that
is
when
you
get
up
to
30
projects.
We
consider
you
an
enterprise,
the
difference
between
the
team
and
the
and
the
free
version,
and
the
paid
version
is
secure
deployments
using
a
user
group
and
access
privileges.
B
That
is
the
main
differences,
but
it
to
be
honest
if
you're
already
using
something
like
a
Jenkins
pipeline
or
even
a
circle,
CI
there's
way
to
restrict
that
and
you
can
go
ahead
and
use
the
free
version
without
having
a
doc
to
adopt
our
user
groups
and
access
privileges.
There
is
a
full
domain
hierarchy
in
this
version,
so
if
your
enterprise,
you
may
want
to
have
sub
domains
and
subdomains
have
subdomains
and
with
the
pro
version,
you
can
have
very
low
level
or
nested
subdomains
and
put
security
around
those
as
well.
B
So
sign
up
give
us
a
sum.
There's
two
ways:
there's
the
SAS
version,
which
is
a
the
sign
up,
but
free
sign
up
and
you
can
get
there
from
deploy
hub
com
or
if
you
need
to
do
an
on-prem,
we
have
a
container
registry
registered
at
the
Red
Hat
with
Red
Hat
container,
so
you
can
pull
it
down
from
there.
I
want
to
talk
to
you
I
want
to
hear
more
about
what
you're
doing
what
some
of
your
struggles
are.
B
Anything
that
I
hear
we
put
on
the
roadmap
and
we
put
it
in
the
ortelius
open
source
core
base.
It's
super
important
for
us
to
build
a
solution
that
is
not
in
a
bubble.
We
want
to
hear
from
anybody
who
is
working
in
microcircuit
problems
and
wants
to
talk
about
how
we
could
help
to
solve
it.
So
there's
my
contact,
information
and
I'm
going
to
leave
it
up
there
for
just
a
minute.
My
coffee,
chats
are
fun
I'm
having
a
lot
of
fun
chatting
with
people
and
hearing
about
their
journey
and
micro
services.
B
I've
talked
to
people
who
are
from
the
testing
perspective
from
the
sre
perspective
from
the
api
developer
perspective
from
the
application
team
perspective
and
a
sort
of
like
listening
to
the
story
about
the
elephant.
How
the
blind
man
and
the
elephant
is
exactly
that.
That
is
why
visibility
is
needed
inside
this
process
and
I
think
you're
going
to
hear
more
about
the
term
observability,
and
that
has
to
do
with
what's
running
in
your
cluster
I
like
just
to
call
it
visibility,
we're
providing
you
visibility
at
the
application
level
so
who?
B
Why
did
we
call
it
ortelius?
Abraham
ortelius
was
the
first
person
who
to
create
a
world
atlas
and
what
better
name
to
use
for
an
open-source
project
than
the
person
who's
created.
The
first
atlas,
if
you
have
ever
looked
at
a
go
out
on
Google,
that's
fine
and
look
at
the
Netflix
Deathstar
you'll
get
an
idea
of
what
we're
mapping
it.
B
Is
this
massive
ball
with
thousands
of
points
in
it
and
in
those
thousands
of
points,
our
constellations
and
those
constellations
are
your
applications
and
that's
what
art
ileus
and
deploy
hub
is
giving
you
it's
allowing
you
to
map
what
those
constellations
look
like.
We
need
your
help.
Everyone
does
see
a
different
part
of
the
landscape
for
this
mapping.
A
B
It
does
not
do
that;
it
doesn't
do
routing
like
an
sto
would
it
happens
before
it
even
goes
out
to
the
cluster.
So
what
we're
doing
in
the
same
way
is
when
you
built
your
ran
your
compile
process
in
your
in
your
monolithic
way.
You
created
a
bill
of
material
report
that
showed
everything
that
went
into
your
binary.
That
way,
when
you
did
another
one,
you
could
do
a
different
port
and
see
what
changed
that
slick
level
of
information
that
we're
working
with
its
before
it
goes
out
to
the
production,
environment
or
any
environment.
B
Yeah,
that's
a
great
question,
so
the
folks
that
we
have
spoken
to
what
they're
trying
to
do
before
they're,
using
something
like
a
ortelius
or
a
deploy
hub
as
they
try
to
look
at
the
registry
and
they
try
to
figure
out
how
many,
for
example,
microservices
have
been
deployed
to
repeat
to
do
this
same
function.
So
is
each
team
writing
their
own
security
routines
as
each
team
writing
their
own
customer
account
information
routines
and
that's
how
they
begin
building
out
domain.
B
So
your
the
question
that
you
asked
and
often
times
be
the
answer
to
what
domains
you
need
to
build.
So
what
you
start
finding
is
up
the
once
they're
deployed
and
they're
they're
labeled
and
your
kubernetes
cluster.
Are
they
how
many
micro
services
are
actually
being
reused
if
they're
not
being
reused?
A
B
B
B
No,
we
have
not
I've
not
used
that,
but
I
we
have
played
with
sto
quite
a
bit
and
there's
some
interesting
things
that
are
happening
with
sto
that
we
believe
we're
going
to
be
able
to
help
solve,
and
let
me
just
blow
everybody's
mind
for
a
minute,
because
I
say
this
and
I'm
in
person.
People
look
at
me
like
I'm
green.
So
in
the
end
the
idea
of
kubernetes
you
have
a
cluster
and
anything
that
this
is
deployed
to
the
cluster
is
immutable,
meaning
it
doesn't
get
deleted.
B
It
doesn't
get
deprecated
until
somebody
goes
out
and
does
that
and
our
monolithic
we
always
copied
over
what
we
had
a
jar
file.
We
copied
over
the
jar
file
that
doesn't
happen
in
this
world,
so
there
is
an
opportunity
for
something
like
sto
to
manage
our
dev
test,
Pradhan
vironment,
because
think
about
as
routing
so,
for
example,
you
could
have
a
cluster
that
supports
dev
and
test
and
when
ADEA
dev
pushes
it
out
it
routes
it
to
dev
personas.
B
At
the
same
time,
testing
could
be
could
be
running
in
it
and
actually,
at
the
same
time,
production
could
be
running
in
it.
I
know
that's
a
scary
thought
but
I
believe
that
companies
are
going
to
come
to
this.
Now
we
did
have
meet
up
with
a
company
called
decart
labs.
They
presented
how
they
were
using
spinnaker,
and
they
came
to
this
conclusion.
They
had
literally
they
said
they
had
so
many
clusters.
B
They
were
really
getting
confused
about
who
was
using
the
cluster
and
they
started
pushing
internally
the
sres
to
push
the
dev
and
test
cluster
to
just
one,
and
they
got
a
lot
of
pushback.
They
built
out
some
work
with
spinnaker
to
try
to
track
the
kind
of
application
tracking
that
we're
doing,
and
they
got
it
to
a
point
where
they
were
just
managing
dev
and
test
in
one
in
a
single
cluster.
That
is
a
huge
cost
saving
and
it's
a
huge
headache,
save
for
any
SRA
who's
trying
to
manage
clusters
now.
B
The
reason
why
I
bring
this
up
is
because,
with
app
with
deploy
hubs,
ability
to
verge
an
application
and
understand
which
microservices
it
use
we're
doing
some
testing
now
at
with
a
beta
customer
to
be
able
to
say,
take
this
application
and
route
it
to
these
individuals,
because
we
know
which
micro
services
that
should
be
consumed
by
that
particular
application
version.
So
we
could
have
a
version
5
could
be
hit
by
the
testers
and
version
10
could
be
hit
by
the
development
teams.
A
B
No
so
there
is,
there
are
tools
like
spring
boot
has
a
micro
service
registry,
where
you
can
go.
Look
in
the
registry
itself
to
see
what's
running
in
your
cluster.
We're
we're
not
necessarily
registering
micro
services
in
in
in
our
world
a
micro
service,
there's
no
reason
to
deploy
a
micro
service
if
nobody's
consuming
it
right.
B
Think
of
it
as
a
marketplace
where
you're
able
to
think
about
a
bit
Namie
bitNami
is
a
a
central
location
that
you
can
go
and
download
these
packages.
You
can
download
Jenkins,
for
example,
microservices
have
the
same
need,
but
their
organizational
specific
they're,
not
complete
packages.
There
are
reusable
functions.
So
what
we're
doing
is
we're
creating
like
a
bit
Nami
for
internal
micro
services
so
that
you
can
publish,
share
and
track
them
before
they
get
deployed
once
they're
deployed.
B
Then
the
registry
will
acknowledge
that
they're
there
but
you're
going
to
know
the
relationships
along
before
it
ever
gets
to
the
registry
and
the
registry
doesn't
do
the
actual
relationship
tracking
that
you
have
to
do
through
a
log
tool.
That's
actually
tracking
that
API
connections
and
the
transactions
between
them.
A
B
So
the
context
and
usages
is
what
the
domain
is
about,
so
a
microphone
and
it
should
belong
to
a
problem
space.
The
best
article
is
the
best
information
on
understanding
their
context
and
usages
and
how
to
organize
that
into
domains
is
go
to
a
site
called
micro
services,
dot
IO
and
they
have
that's
Chris
Richardson
of
the
Cloud
Foundry
Fame.
He
is
it's
an
amazing
site
on
implementation
of
micro
services
and
he
has
quite
a
bit
of
information
about
how
to
manage
this
in
a
domain
structure.
B
I
highly
recommend
doing
that,
because
you
are
absolutely
right,
it
becomes
a
hairball
and
it's
really
hard
to
understand
what
a
particular
micro
services
function
was
written
for
in
the
first
place.
This
is
part
of
what
we
built
around
the
domain
structure
for
ortelius
this,
so
that
you
could
publish
them
to
that.
A
domain
structure
with
all
of
its
deployment
deployment
data
and
any
application
team
could
reuse
it,
but
check
out
the
the
microservices
io
and
read
about
domain
driven
design.
B
B
What's
been
checked
in
so
when
I
talk
about
versioning
micro-services
I'm
talking
about
versioning
the
content,
not
necessarily
the
content,
but
the
configuration
of
a
particular
container
understanding
what
was
what's
in
the
container
and
understanding
they
get
commits
that
put
it
in
the
container.
That's
one
one
of
the
metadata
points,
understanding
what
container
registry
is
coming
from,
but
the
SHA
number
is
understanding
some
of
the
low
level
variables
that
are
needed
to
actually
deploy
it
when
it's
there
settings
are
and
how
it
interacts
with
the
cluster.
B
So
there
is
a
there
are
for
deploying
microservice
there's
a
set
of
there's
a
set
of
data
that
we
track,
because
that's
what
we
want
to
make
sure
a
standard
across
any
cluster
that
if
microservices
pushed
to-
and
we
version
that
now
on.
On
top
of
that,
we
version
applications
that
are
consuming
them,
so
once
an
application
teams
decides
to
create
what
looks
like
a
package
or
a
logical
representation
of
their
application.
B
We
can
then
version
that
as
well,
so
we're
reversion
the
application
that
consumes
the
microservices
because
that's
a
configuration
and
then
we're
driving
down
into
each
micro
service
and
saying
this
is
what's
needed
to
deploy
it
and
we
version
that.
So
let's
say
how
much
are
gets
updated.
We're
going
to
know
that
we're
going
to
version
that
I
hope
that
answers
that
question,
because
it's
a
good
question.
A
B
Now
you
could,
you
could
argue
well
it's
out
there
it's
running
in
the
cluster
and
we
could
look
at
log
transactions
and
see
the
transactions
between
micro
services,
but
that
doesn't
give
you
help
if
you're
an
application
team
and
your
application
suddenly
stops
working,
and
you
have
no
reason,
no
idea.
Why,
especially,
if
you
didn't
even
do
a
new
release,
so
new
micro
service
came
along
and
you
didn't,
you
have
no
idea
why
your
application
is
broken.
How
do
you
find
that
information
out?
B
Yeah,
wouldn't
that
be
cool
yeah,
it
needs
to
be
psychic
to
do
it.
I'm
afraid,
I
think
that
we
could
probably
we
have
been
looking
at
that
we
can
probably
do
it
depending
on
how
clean
the
the
backward
auto
discovery
would
be.
How
clean
it
is,
how
well
the
labels
are
managed
and
the
kubernetes
cluster
to
be
able
to
do
that.
But
when
we
do
it
that
way,
we
could
they
create
the
base
version
of
the
application.
But
there's
gonna
be
stuff-
that's
not
out
there
in
the
cluster
that
we
don't
have.
B
Frustrating
right,
because
if
you
do
that,
you're
going
to
end
up
being
monolithic,
because
what
happens
in
a
workflow
is
everything's
everything's
kind
of
done
for
everything
in
that
in
that
monolithic.
So,
let's
say
you're,
you
know
a
single
repository
and
you
have
all
these
different
micro
services
that
you're
trying
to
manage.
If
you
have
one
workflow
they're
all
going
to
be
pushed
out.
B
At
the
same
time,
and
let's
say
you
have
a
hundred
micro
services
in
that
you're,
going
to
end,
you
have
one
workflow
you're,
going
to
always
push
out
the
hundred
micro
services
as
a
monolithic.
So
the
only
way
to
break
your
habit
from
doing
a
monolithic
deployment
is
to
break
it
up
into
single
workflows
so
that
every
micro
service
can
go
out
independently,
and
that
is
the
goal.
The
goal
is
to
have
mini
moving
parts
to
be
truly
agile.
A
B
There
is
I,
don't
know,
I
wouldn't
be
able
to
tell
you,
but
there
there
are
standards
in
which
is
I'm
going
to
ended
it
there.
There
are
definitely
standards,
we
generate
standard
files,
you
know
standard
gamma
files,
that
kubernetes
is
expecting
there's
other
tools
that
are
starting
to
do
a
level
of
generation
on
the
back
end,
that
might
have
their
own
syntax,
but
there
is
a
standard,
and
most
of
that
can
be
found
at
the
CN
CF.
B
A
A
And
I
also
just
wanted
to
remind
folks
that
we
are,
we
are
doing
webinar
series
now
this
will
we're
trying
to
have
it
on
a
weekly
cadence.
It
will
depend
on
content
if
folks
sign
up
to
to
volunteer
to
teach
these
webinars.
Our
upcoming
one
is
taught
by
our
cdf
ambassador,
garima
and
she's,
going
to
be
covering
I
believe
it
is.
A
Let
me
see
what
it
is
called.
It
is
called
continuous
product
oriented
practice,
so
she's
going
to
be
covering
that
and
that's
on
June
2nd
I
just
dropped
in
the
registration
for
anybody.
That's
interested.
We
welcome
you
to
join
and
if
anybody
has
any
more
questions,
I
think
I
saw
one
puff
up
in
the
key
here
we
go.
Oh
okay,
thank
you
for
answering
my
questions.
You're
welcome,
Brooks.
We
appreciate
your
time.
I'll.