►
From YouTube: Welcome Ortelius! CDF's Newest Project
Description
Managing Microservices is the focus of the new CDF project - Ortelius. Learn from Steve Taylor, Community Manager, how Ortelius versions, tracks and builds dependency maps of microservices across all clusters. If you are moving to a microservice architecture, you will want to hear about this new solution that will make site reliability easier in a microservice implementation.
A
B
B
B
B
Some
of
the
other
trends
that
we're
seeing
is
92
percent
of
people
are
using
some
sort
of
container,
whether
it's
a
docker
container
or
a
like
in
production.
That's
up
84
from
last
year
and
also
up
300
from
just
four
years
ago.
Five
years
ago,
when
the
whole
container
kubernetes
world
started
out,
and
also
we
see
that
kubernetes
is
actually
starting
to
get
rolled
out
into
production.
B
B
They
were
starting
to
get
lost
on
what
versions
were
running
where
and
then
also
from
randy
heffner
from
forester.
He
said
that
microservice
development
will
fall
apart
without
coherent
and
discipline
management,
and
we
see
that
coming
across
as
well.
If
you
don't
put
management
around
your
microservices,
it
will
not
you'll
struggle
to
be
successful.
B
So,
let's
look
at
the
problem
of
why
this
is
happening.
You
know
whether
it's
really
coming
down
with
microservices
there's,
there's
a
loss
of
control
because
we
get
some
added
complexity
but
at
the
same
time
we're
getting
simplicity
in
our
code
base.
So
microservice
is
going
to
be
much
smaller,
much
fewer
lines
of
code.
We
don't
have
to
deal
with
complex,
branching,
emerging
issues
but
at
the
same
time
we're
going
to
be
pushing
some
of
this
complexity
down
the
pipeline.
B
B
Everything
is
all
linked
together
and
we
have
actually
what
we
can
think
of.
As
a
binary
or
a
version
of
a
binary
for
that
application,
sometimes
people
even
took
it
to
a
point
to
where
they're
creating
their
setup.exe
and
that
was
their
whole
set
up
in
msi,
installer
and
versioning.
That
is
part
of
the
process,
and
what
ended
up
happening
is
in
this
static,
compile,
link
process.
We
can
actually
have
a
version
of
the
of
a
binary
that
we
could
actually
manage.
We
can
move
it
around
copied
around.
B
B
Now?
When
we
would
take
this
binary,
we
could
move
it's
simply
by
copying
it
from
one
stage
to
the
pipeline
to
the
next,
because
it
was
all
bundled
together.
It
was
easy
to
move
through
the
from
dev
to
test
to
prod
and
also
keep
track
of
which
version
we
have.
We
knew
that
this
application
was
version
10
in
development
in
version
5
in
production.
B
Now,
with
microservices
microservices
are
designed
to
be
built
and
independently
deployed.
So
what
that
means
is,
if
you
have
10
microservices,
you
would
have
10
different
workflows
of
your
ci
pipeline.
That
would
be
independently
deploying
out
to
your
different
environments
as
part
of
the
process.
So
what
would
happen
in
in
the
microservices
world?
This
is
one
of
the
typical
use
cases
is
the
microservice
developer
is
going
to
write
their
their
api.
B
B
What
ends
up
happening
is
you
have
one
version,
that's
being
deployed
to
development,
another
version
being
deployed
to
test
and
another
version
being
deployed
to
prod.
One
of
the
things
with
containers
is
they're
immutable,
so
we
can't
go
in
there
and
change
a
parameter
and
edit
the
container
to
make
it
act
differently
for
test
versus
prod.
B
All
that
has
to
be
coming
in
from
outside
is
a
key
value
of
pairs
or
what
they
call
config
steps,
and
this
is
actually
replacing
the
monolithic
link
step
with
what's
happening
back
in
our
build
area,
I'm
just
gonna
pop
up.
It
looks
like
we
had
a
question.
Let
me
jump
over
there
and
the
question
jackie
is
for
you:
will
there
be
a
recording
of
this
webinar?
A
B
So
please,
please
share
this
webinar
with
your
coworkers,
so
back
to
what
we're
talking
about
with
microservices,
when
we,
because
we
have
these
independently
deployable
microservices
and
how
they're
traveling
across
the
pipeline
independently
and
at
different
speeds.
We
need
to
understand
what
a
microservices
blast
radius
is.
What
I
mean
by
that
is,
if,
if
a
microservice
breaks,
how
is
it
affecting
the
application
or
multiple
applications
and
other
microservices
that
it
may
be
dependent
upon
it?
B
Also,
the
next
problem
that
we
see
with
microservices
is
there's
no
really
real
concept
of
an
application
version
or
the
ability
to
get
a
bill,
a
material
report
or
a
difference
report
from
the
application
viewpoint.
We
can
obviously
look
at
the
changes
between
one
commit
and
the
next
commit
for
a
single
micro
service,
but
we
can't
look
at
that
from
a
higher
level
and
how
things
are
are
impacted.
B
If
we
have
the
ability
to
look
at
a
single
microservice
and
its
velocity
production
and
its
frequency,
it's
hard
to
determine
why
those
are
happening,
and
is
it
a
good
thing
or
is
it
a
bad
thing?
Are
the
developers
constantly
fixing
this
microservice
because
it's
broken
or
are
we
running
into
just
more
features
and
new
capabilities
being
added
to
that
microservice?
B
B
Then
the
next
we
have
is
increasing
the
cost
to
maintain
the
site
integrity,
because
we
have
many
more
services
that
are
running.
We
have
to
look
at
staffing
up
to
be
able
to
choose
who's,
gonna
be
looking
at
which
parts
and
it
gets
down
to
if
we
have
a
shared
microservice,
is
the
developer
that
wrote
that
responsible
for
site
integrity,
or
is
it
going
to
be
a
sre
from
that's
kind
of
shared
across
multiple
teams?
B
Or
is
there
going
to
be
application
teams
that
are
going
to
be
responsible
for
maintaining
that
microservice,
even
though
that
they
may
not
be
the
ones
able
to
change
the
code?
And
then,
finally,
we
have
business
agility.
You
know
the
the
the
promise
of
cloud
native
you
know,
cloud
native
being
the
holy
grail
of
of
where
problems
are
going
to
get
solved
doesn't
come
through
if
we
don't
manage
our
microservices
effectively.
B
B
So
the
goal
of
ortulius
is
to
improve
the
confidence,
eliminate
risk,
basically
knowing
what
your
blast
radius
is
and
knowing
what
your
blast
radius
is
before.
You
start
actually
running
your
application,
because
if
you
actually
start
just
throwing
things
into
your
clusters
and
without
knowing
the
impact
you're
gonna
be
in
a
reactionary
mode
and
reacting
to
problems
is
is
not
the
way
to
go.
B
You
want
to
understand
impact
before
you
make
a
change,
then
also
we're
going
to
look
at
reducing
the
cost
really
through
the
reuse
of
organ
microservice,
reorganization,
how
they
can
be
shared,
how
they
can
be
organized
into
domain,
driven
design
patterns
and
really
get
the
high
reuse
out
of
a
microservice
and
then
the
next.
We
look
at
restoring
control.
You
know
what
is
our
logical
application?
B
You
know
what
version
of
our
application
is
actually
running
in
our
different
environments
and
what
are
the
you
know,
change
tracking
issues
associated
with
it
when
somebody,
you
know,
if
you
have
an
end
user
and
they
report
a
problem
with
your
software,
they
don't
go.
You
know,
microservice
cart
version.
345
is
broken.
They
have
no
idea
of
how
your
application
is
put
together.
They
just
know
that
the
website's
not
working
and
that's
what
they're
going
to
report
in
is
that
there's
a
store.
B
The
website
store
is
not
working,
and
this
is
what
we're
reporting
into.
So
we
have
to
bring
the
logical
view
of
an
application
back
to
the
picture
and
then
also
finally,
adding
a
visibility.
You
know
what
versions
of
microservices
are
used
in
which
versions
of
the
clusters
we've
been
talking
to
companies
that
are
starting
to
roll
out
to
every
single
region
in
aws,
so
and
they're
running
multiple
clusters.
B
So
let's
take
a
look
at
how
the
whole
process
of
microservice
kind
of
changes.
When
we
talk
about
ortulius
in
the
picture,
so
one
of
the
things
in
our
ci
cd
processes,
we
we
do
it
a
basically
our
docker
build
and
then,
after
our
docker
build,
we
have
to
push
our
container
somewhere
our
image,
and
that
goes
up
to
a
a
container
registry.
B
Now,
one
of
the
things
that
happens,
it's
kind
of
like
a
chicken
versus
egg
thing
is
our
doctor.
Digest
does
not
exist
until
we
actually
push
into
a
registry
and
that's
where
ortulius
comes
into
once.
We
have
that
that
docker
digest.
We
know
what
that
immutable
shot
number
is
for
that
version
of
our
microservice
and
ortus
is
then
triggered
to
capture
that
information
about
what's
happened
on
the
get
side.
You
know
what
was
a
git
commit
that
triggered
the
whole
process.
B
Is
it
just
a
brand
new
one,
or
do
we
have
five
applications
actually
using
it,
and
what
is
the
impact?
And
when
we
get
a
new
version
of
a
microservice,
we're
going
to
create
new
versions
of
applications
automatically
and
keep
on
maintaining
those
those
relationships
as
part
of
an
automated
process
from
there,
ortulius
can
actually
has
a
deployment
engine,
so
you
can
actually
deploy
a
base
on
a
schedule
on
demand
or
through
your
ci
cd
pipeline
process.
B
That
will
then
actually
push
out
the
the
new
can
microservice
outdoor
kubernetes
cluster.
Now
one
of
the
other
modes
that
ortunis
can
execute
in
is,
if
you're,
using
your
own
deployment
process
instead
of
ortulius's,
we
can
be
inserted
in
there
to
track
what
your
deployment
is
doing.
Where
is
it
sending
the
containers
out
there
which
environments,
so
we
can
keep
a
full
inventory
of
what's
happening
from
the
developers,
change
all
the
out
to
where
the
new
microservices
was
released
and
all
the
impacts
that
occurred
along
the
way.
B
B
B
What
this
gives
us
is
the
capability
to
produce
a
bomb
report.
So
that's
the
one
on
the
left
there,
and
you
know
this
is
showing
what
is
what
am
I
consuming?
You
know
from
the
application
standpoint,
what
what
am
I
made
up
of
and
then
on
the
blast
radius
report
that
is
looking
at
a
a
microservice
and
who
is
it
going
to
affect
so
this
microservice
cart
service
is
affecting
three
versions
of
the
application.
B
B
What
the
differences
are
impact
analysis
reports
we'll
be
able
to
view
it
from
a
logical
application
view.
So
we
can
say
application
version.
5
is
in
test
and
version
3
is
in
production.
We
can
actually
get
that
view
and
and
see
what
is
under
the
covers
making
up
those
applications
from
a
microservice
perspective.
B
B
You
know
they
can
actually
see
what's
changing
to
their
production
environment
before
the
change
actually
happens,
because
everything
when
you
look
at
from
an
sre
perspective
is
around
if
something
breaks.
The
first
question
you
ask
is
what
has
changed
and
that's
where
ortulius
gives
them?
The
answers
to
that
question,
and
then
finally,
it
gives
the
ability
to
deliver
successful,
high
frequency
updates
achieving
the
business
agility,
because
one
thing
our
end
users
want
is
they
want
their
updates?
B
B
B
Let
me
zoom
in
one
and
in
our
our
hierarchy
here
in
the
store
services
domain,
we
have
a
set
of
additional
services
that
we
are
going
to
manage,
so
this
is
taking
it
from
a
viewpoint
from
the
microservice
or
api
developer.
How
can
they
organize
their
services
to
be
reused
grouped
together?
So
in
the
email
domain
we
may
end
up
with
you
know
five
or
six
different
services
that
deal
with
email.
B
B
B
B
So
I
brought
up
our
our
hipster
store,
we're
at
the
base
version,
so
this
is
kind
of
like
where
we
prime
the
pump.
We
need
a
starting
point
of
what
is
actually
in
production,
and
this
represents
our
our
baseline
of
what
we
have
running
in
our
production
cluster
and
in
this
case,
we've
actually
had
brought
in
version
49
of
our
card
service,
we'll
see
it
right
down
here
and
that
we
have
version
50,
that's
actually
been
built
by
a
developer,
but
we
haven't
consumed
it
yet
as
part
of
our
layout
here.
B
So
the
domain
hierarchy
allows
us
to
really
navigate
what's
happening,
whether
we're
going
to
be
needing
a
service
and
purchase
processing
or
if
we
want
to
bring
in
the
stress
testing
load
generator
that
allows
us
to
really
navigate
what's
available
to
us
now.
This
component
selector
will
also
extend
beyond
just
your
domains.
B
We've
created
it,
so
it
can
be
bring
in
components
from
other
outside
entities
as
well.
So
if
you
have
netflix,
for
example,
that
creates
a
a
service
that
you
want
to
use
for
browsing
some
data,
we
can
bring
that
in
as
a
microservice
into
the
hierarchy.
As
well,
the
the
whole
security
model
behind
the
the
domain
hierarchy
allows
us
to
be
consumers.
B
B
B
B
So
let's
go
ahead
and
take
a
look
at
the
components
that
are
being
used
to
create
that
that
version
of
the
application,
let's
go
into
our
cart
service,
and
we
can
see
that
our
cart
service,
I
clicked
on
150
instead
of
the
149,
and
we
can
see
that
it's
impacting
three
different
versions
of
our
applications,
so
this
is
our
blast
radius,
see
showing
us.
If
I
make
a
change
to
this,
this
breaks,
you
know
who's
going
to
be
impacted
which
applications
are
going
to
be
impacted
by
by
this
service.
B
If
I
need
to
break
backward
compatibility
who
which
application
teams,
I
have
to
go
talk
to
because
they're
consuming
it
now.
Some
of
the
information
like
I
said
when
we're
talking
about
the
cicd
process
is
we're
hooking
into
the
pipelines
to
track
what's
happening
in
this
case,
this
was
a
circle
ci
job
that
ran
it
was
179.
B
It
ended
up
creating
our
container
our
image
over
in
our
quail
repository.
This
is
the
digest
that
I
was
talking
about
that
we
needed
to
get.
This
is
our
immutable
number
our,
because
tags
can
be
changed.
This
one
will
never
change
as
part
of
the
design
of
the
images,
so
here's
our
tag
that
was
assigned
the
git
commit
that
triggered
the
whole
creation
of
this
new
version
of
the
of
our
cart
service
and
then
what
we
have
from
our
repo,
our
github
ripple
repo.
B
So
this
is
where
it
was
off
of
the
master
that
was
caused.
The
the
change
for
this
whole
whole
process
to
get
going,
and
then
we
can
have
key
value
pairs
at
the
component
level
as
well,
and
then
we
could
see
where
this
service
was
deployed.
So
this
service
is
actually
deployed
to
two
different
clusters.
Our
hipster
store
cluster,
as
well
as
our
cicd
test
cluster.
As
part
of
that
process,
we'll
go
back
and
take
one
more
look
at
our
application,
because
we
did
our
change
to
150.
B
B
So
remember
we
started
with
our
base
and,
as
our
ci
cd
process
was
coming
along,
we
created
a
new
microservice
for
the
cart
and
that
cart
service
was
what
created
this
new
version
of
our
application.
So
the
the
1291
is
what
was
created
automatically
out
of
the
ci
cd
pipeline
process,
and
we
can
see
that
this
one
was
deployed
to
our
hipster
store
cluster
and
the
only
thing
that
changed
was
as
part
of
that
deployment
was
just
the
cart
service.
The
150.
B
everything
else
was
the
same
and
that
allowed
us
to
incrementally
deploy
just
that
one
service.
Now
this
same
information
can
be
obtained
even
if
deploy
hub.
I'm
sorry,
ortelius
is
not
doing
the
deployment
and
if
you
have
a
an
existing
deployment
engine
under
the
covers
we'll
hook
into
that
and
record
what
it
did.
B
So
we
can
get
this
the
same
information
available
from
any
underlying
deployment
process
and
if
we
actually
look
at
the
logs,
this
actually
got
deployed
using
helm
out
to
our
gke
cluster
and
there's
some
pre
pre-configuration
steps
that
happen
to
allow
us
to
connect
up
to
the
right
cluster
and
because
we're
separating
data.
From
definition
with
ortilius,
I
can
repeat
this
same
deployment
against
any
cloud
provider
without
having
to
change
the
actual
the
deployment
process.
B
What
we'll
actually
get
as
part
of
the
the
initial
part
is
the
different
connection
steps.
If
I'm
connecting
up
to
azure
there's
a
you
have
to
do
a
z
login
to
connect
eks
has
a
different,
a
couple
different
steps,
but
at
the
end
of
the
day,
all
that
is
separated
out
from
the
actual
deployment
process,
and
that
gives
us
that
capability
to
look
exactly
what's
happened
from
development
through
testing
through
production.
B
B
B
B
B
If
you
look
at
the
other
side,
performance
monitoring
tools,
performance
monitoring
tools
will
be
sitting
in
the
clusters
themselves.
Ortilis
wants
to
show
you
potential
problems
before
they
arise.
So
that's
why
we
sit
outside
of
the
clusters
and
look
down
into
every
single
cluster
that
you
you've
deployed
to.
A
B
B
A
B
Yep,
let
me
bring
that
slide
back
up
so,
like
I
said,
ortelius.io
is
the
landing
page
and
the
easiest
either
go
to
the
github
repo
or
to
the
discord
channel.
Like
I
said
we
have
a
pretty
active
community
all
skill
levels.
We
have
people
that
have
never
touched
git
before
to
people
that
are
running
massive
kubernetes
clusters
in
azure,
so
we
have
a
full
range
of
skill
levels
as
part
of
our
project
and
there's
something
for
everybody
to
do
so.
A
B
B
So
it's
something
that
we're
starting
with
our
our
artillious
group,
and
we,
like,
I
said
the
topics
are
wide-ranging,
so
you
don't
have
to
be
specifically
contributing
to
the
artelius
codebase
to
participate
in
the
blogathon,
so
just
hit
up
the
oritelius.io
and
you'll
see
on
that
page.
The
links
to
the
basically
the
rules
for
the
blogathon.