►
From YouTube: Ortelius TOC Nov 2021
Description
November 2021 Ortelius TOC Board Meeting
A
A
A
A
lot
quite
a
bit
has
happened
since
the
last
board
meeting,
which
is
a
good
thing.
Let
me
just
go
through
I'm
going
to
what
I'm
going
to
do.
Is
I'm
going
to
go
through
some
of
the
what
we've
done,
what
we've
accomplished
and
then
I'm
going
to
hand
the
road
map
over
to
steve,
just
hey,
jeremy,
there
you
are
I'm
going
to
have
the
hand
the
road
map
part
of
it
over
to
steve
and
just
to
let
everybody
know
steve,
probably
hasn't
seen
all
these
screens.
A
A
I
don't
see
him
on
today
to
hank
who
I
bugged,
at
a
from
a
linkedin
connection
to
tara
and
phil
and
phil
has
been
super
involved
in
the
project
from
the
years
back
tim,
kelton
and
doug
orr.
We
still
keep
in
contact
with
them.
They
we
keep
updated.
They
we
update
them
on
what
we're
doing
on
a
regular
basis.
They
were
the
first
two
people
on
the
toc
and
then
of
course,
bill
pertelli,
our
distinguished
coach
and
board
advisor
and
then
jerry,
jeremy,
davis,
from
red
hat
and,
of
course,
steve.
A
So
what
we
have
done,
we've
been
busy
we
have
had.
We
now
have
about
194
members
in
our
google
group
community.
These
individuals
sometimes
become
committers.
Sometimes
they
become
contributors
to
blogs
or
maybe
do
they
might
speak.
A
We
we
started
from
zero
and
siddharth
parikh,
who
is
running
our
ambassadors
at
the
time
bugged
me
to
create
a
linkedin
group
for
ortillius
and
that
quickly
jumped
to
292
members
in
a
very
short
period
of
time.
We
started
that
linkedin
group,
I
think
maybe
siddharth.
When
do
you
think
we
did
that
in
august.
B
Well,
yes,
somewhere
in
end
of
quarter,
two
and
starting
off
quarter
three
somewhere
around
quickly.
A
Yeah
we
now
have
about
50
active
committers
and
we're
doing
about
an
average
number
of
approved,
pull
requests.
We
do
about
14
and
we've
had
we're,
have
we're
having
our
second
visionary
summit
coming
up
in
december,
our
visionary
summit?
A
What
we
do
with
this
is
we
you
know
we
we
have
an
approach
of
educating
education
in
general
in
this
open
source
community
and
one
of
the
areas
that
I
perceive
to
be
a
problem
for
a
lot
of
people
who
want
to
further
their
careers
is
the
ability
to
get
an
opportunity
to
speak
at
a
conference
it's
hard
to
get
into
these
conferences.
A
So
what
we've
done
is
we've
created
our
own
conference.
We
host
it
on
twitch.
We
do
not
try
to
get.
We
don't
sell
it
like
a
regular
conference,
we're
sort
of
disrupting
that
we
don't
try
to
get
sponsors.
We
don't
try
to
drive,
lead
generation
or
anything
like
that.
We
simply
have
a
lot
of
fun
and
we
educate
and
we
give
our
contributors
an
opportunity
to
speak
for
the
first
time
at
a
conference
we
host
it
on
twitch,
I
I
call
it
the
campiest
conference.
A
You
could
ever
go
to,
we
laugh
a
lot,
we
have
fun
and
we
play
some
really
fun.
You
know
we
do
old-fashioned
sci-fi
movies
during
the
breaks
and
we
we're
going
to
have
some
games
this
time.
A
This
conference,
we
we
are
having
a
keynote
on
crew
kumar,
who,
who
is
gonna,
give
us
a
perspective
of
microservices
from
an
end
user.
He
is
not
a
contributor,
he
is
an
end
user
and
has
stepped
up
to
be
our
keynote
to
really
talk
about
what
an
end
user
has
to
experience.
A
We
participated
in
hacktoberfest.
This
was
a
weird
year
for
hacktoberfest.
They
did
not
digitalocean
didn't
start
pushing
that
they
were
going
to
have
a
hacktoberfest
until
like
the
second
week
of
october,
or
maybe
even
later,
we
kept
trying
to
reach
out
and
saying
hey.
Is
there
a
hacktoberfest
happening?
And
finally,
a
new
website
was
put
out
there.
We
did
end
up
with
27
accepted,
pull
requests,
which
is
it
kind
of
doubles.
What
we
normally
do
so
that
that
was
exciting.
A
We
have
been
in
the
conference
scene
this
year.
We
were
at
get
ops,
con,
north
america,
talking
about
ortillius
and
some
of
our
vision
for
what
we're
going
to
do
in
our
roadmap.
We
had
several
speakers
at
cdcon,
including
a
couple
of
people
who
are
not
contributors
but
have
found
the
product
and
done
some
kind
of
analysis
of
it
and
presented
it
adidagawal.
A
She
was
one
of
our
may
20th
presenters.
She
did
a
presentation
on
domain
driven
design.
She
did
a
great
job.
It
was
her
first
presentation
during
our
visionary
summit
and
we
asked
her
to
submit
that
to
devops
world,
since
it
was
virtual
and
made
it
easy
for
her
to
do
and
she
got
accepted.
We
were
super
excited
and
I
was
able
to
do
a
presentation
specifically
around
how
ortillius
tracks
microservices
so
we're
getting
some
exposure
out
in
the
in
the
general
world
we
have
opened
up.
We
have
started
our
first,
a
proper
governing
board.
A
In
order
for
us
to
be
an
incubating,
go
beyond
being
an
incubating
project,
we
have
to
have
a
governing
board
and
we
need
history
around
how
that
governing
board
operates.
We
built
out
new
bylaws
for
the
governing
board.
We
had
elections.
Actually
the
elections
are
still
running,
but
we
needed
to
we
needed
to
add
a
full
governing
board.
So
what
we
did
was
in
the
governing
board.
A
Steve
taylor
has
a
and
we
copied
this
from
jenkins
steve
taylor
has
a
permanent
position
on
the
board
and
there'll
be
six
additional
board
members
and
we
will
elect
three
new
ones
every
year.
So
it's
a
rotating.
Normally
it
would
be
a
two-year
term,
but
the
first
year
three
people
will
have
a
one-year
term.
So
next
year
we
will
have
an
election.
So
we
have
some
new
people
coming
in
every
year,
but
we
have
some
stability.
A
So
after
this
year
the
roles
will
be
will
be
continued
to
be
two-year
rolls
so
we'll
have
three
of
them:
roll
off
in
2023
and
three
of
them:
roll
off
in
2024,
etc.
A
Brian
dawson,
from
the
linux
foundation,
through
in
his
hat
and
as
well
as
ann
marie
fred
from
red
hat
siddharth,
actually
recruited
her
for
us
siddharth,
has
been
our
ambassador
lead
over
the
course
of
the
last
18
months,
and
then
we
have
added
aisha,
khalik
and
sasha
wharton
and
sergio
canales.
So
we're
excited
to
see
how
this
new
governing
board
works
and
they'll
be
meeting
about
four
times
a
year
or
if
they
need
to
to
make
any
other
kind
of
voting
decisions.
C
A
Syme
will
be
our
new
ambassador
chair.
We
do
have
a
an
election
currently
running
for
the
champions
chair.
There's
four
people
running
for
that.
C
A
So
we
will
know
that
after
they
close
on
november
27th
and
we'll
be
announcing,
who
is
the
new
champions
chair
on
the
20
on
the
on
december,
8th,
okay,
and
on
that
note,
I'm
going
to
pass
it
over
to
steve
to
go
over
the
road
map
discussion.
We
have
quite
a
few
things
in
the
pipeline.
We
have
a
lot
of
work
that
we
now
understand
that
we
need
to
do
and
just
to
get
us
started.
We
initially
when
we
first
started
as
deploy
hub
and
before
we
created
the
open
source
project.
A
The
only
the
only
thing
that
really
competed
against
us
that
we
could
see
in
the
open
source
world
was
backstage.
Now,
if
you
have
had
any
experience
with
backstage
you'll
understand
that
backstage
is
a
a
microservice
registration
catalog
but
they're,
not
managing
versions.
We
are
adding
the
version
and
the
dependency
mapping
and
the
bom
reporting
to
a
catalog.
A
There
are
other
tools
that
are
out
there.
There's
one
I
haven't
even
listed
on
here
called
noble9,
so
they're
starting
to
get
they're
starting
to
have
they're
starting
money,
is
starting
to
be
put
into
this
area.
You
know
we
started
with
a
just
talking
about
it
and
having
a
dream
to
build
out
this
catalog
and,
as
you
can
see,
we
have
quite
a
few
now
new
entries
into
the
marketplace.
C
Just
stay
there
right
there
go
back
so
one
of
the
things
the
service
service
dependencies,
that
is
on
the
roadmap.
So
we
will
be
getting
that
check
mark
here
soon,
so
yeah.
C
A
So
we
talked
about
doing
this
than
the
last
one.
It
is
pretty
much
ready
to
go.
We
have
a
dev
environment
that
the
team
is
finally
doing
final
testing
and
documentation
on,
but
we
did
add
to
the
component.
We
added
license
consumption.
We
added
it's
it's
what
license
it's,
that
service
uses,
as
well
as
its
readme
information.
A
We
added
swagger
information
and
we
added
integrations
to
things
like
pagerduty
and
slack.
This
speaks
to
service
level
objectives.
This
is
probably
one
of
the
areas
that
gets
the
most
attention
in
the
commercial
market
and
in
fact,
a
lot
of
the
the
tools
that
I
had
on.
The
previous
slide
are
really
just
focused
on
ownership
and
production
and
providing
a
catalog.
So
anybody
who
wants
to
who
needs
to
support
a
microservice
knows
who
to
call
in
from
a
production
support
standpoint.
C
And
on
this
one
of
the
things
that
we
do
differently
than
everybody
else
is
this
information
is
versioned
with
the
component
version.
So
what
that
means
is,
if
you
have
a
version
of
your
microservice
running
in
production
and
you
have
a
new
one
in
qa,
you
don't
want
to
see
or
in
development.
You
want
to
see
how
the
the
swagger
information
has
has
changed.
Maybe
they've
added
another
parameter
or
something
like
that.
We
have
the
data
there
to
be
able
to
do
that
that
difference
report
as
part
of
that
process.
C
Also
on
the
cves
part
we
can
see
if
cves
are
being
fixed
and
resolved,
comparing
what's
coming
down
the
pipeline
from
development
into
production,
so
the
cve
box,
you
know
your
goal
is
to
have
it
empty
and
that's
some
of
this.
This
service
catalog
information,
that
is
that
we're
collecting,
is
going
to
be
really
important
when
we
start
doing
some
more
investigative
work
and
analysis
of
that
data
and
how
it
compares
to
what's
in
in
development
compared
to
what's
in
production
and
through
the
pipeline.
C
So
on
the
the
roadmap,
I
had
a
a
request
from
the
deploy
hub
side
about
service
to
service
dependency
maps,
and
we've-
we've
talked
about
this
in
the
past
around
component
sets.
C
How
do
we
deal
with
tightly
coupled
components
or
microservices
that
need
to
go
together
and
part
of
that
equation
is
knowing
how
a
service
depends
upon
another
service
and
one
of
the
things
that
we'll
be
bringing
in
from
the
deploy
hub
side
is
this
ability
to
map
service
to
service
relationships
when
we're
looking
at
this
mapping,
we're
looking
at
it
from
the
perspective
of
the
developers,
so
we're
not
looking
at
telemetry
data
or
prometheus
logs.
C
You
know,
after
the
fact
we're
looking
at
it
at
basically
at
compile
time
when
you
build
your
microservice,
what
is
it
dependent
upon
and
what
is
it
providing
basically,
the
way,
we've
kind
of
implemented
it
and
is
basically
a
couple
json
files
and
the
idea
being
is
we
have
a
a
microservice
will
produce
certain
endpoints
or
in
the
pub
sub
world,
they'll,
publish
certain
topics
and
then
it
may
or
may
not
consume
additional
endpoints
or
consume.
You
know
subscribe
to
certain
topics
once
we
have
this
mapping
at
the
component
level.
C
We
can
then
start
building
these
relationships
up.
So
we
can
see
that
a
depends
upon
b
b
depends
upon
c
and
c
may
depend
upon.
You
know
x,
so
those
relationships
will
be
able
to
be
discovered
through
this
mapping
mechanism
and
part
of
that
is
gonna.
Allow
us
to
really
look
at
a
a
version
of
an
application
and
be
able
to
look
at
how
all
the
transactions
relate
to
each
other,
it's
more
of
an
in-depth
type
of
bomb
report.
C
So
it's
going
to
be
really
being
able
to
take
these
low-level
relationships
at
the
component
level
and
roll
those
up
into
application
versions
and
so
on.
So
it
will
really
give
us
a
nice
view
into
what's
happening
between
at
application
level.
You
know
what
it's
consuming
now
one
of
the
things
down
the
road
is.
C
We
can
look
at
applying
telemetry
data
to
that
and
really
looking
at
where,
where
the
developers
think
a
transaction
going
is
going
and
where
it
actually
is
going
at
that
level
and
also
being
able
to
repair
report
errors
and
things
like
that
and
roll
up
log
data
and
metrics
from
that
side.
But
for
now
we
are
going
to
be
one
of
the
things
on.
The
roadmap
is
service
to
service
dependency
maps.
C
Up
go
back
if
you're,
one
of
the
ways
we're
going
to
going
to
visualize
this,
it's
called
a
hierarchical
edge
bundle
that
we'll
be
able
to
do
the
graphical
representation
of
the
servers
and
service
maps
that
javascript
library
comes
out
out
of
the
d3
open
source
project.
C
So
if
you
want
to
see
what
one
looks
like
just
a
google
hierarchical
edge
bundle
and
you
can
play
with
some
data
there,
one
of
the
things
I
like
about
that
that
visualization
is
it'll
deal
with
circular
dependencies,
even
though
developers
aren't
supposed
to
do
it,
they
do
it
anyways.
So
you
have
a
depends
upon
b.
B
depends
upon
c
and
c
depends
upon
a
for
some
reason.
They
do
it.
It's
not
the
best
programming
perspective,
but
that's
one
of
the
things
that
the
edge
bundling
will
allow
us
to
map
out.
C
Okay
go
to
the
next
one,
so
this
this
project's
actually
in
flight,
but
more
on
the
discovery
phase.
This
is
coming
out
of
the
our
australian
architecture
working
group,
so
brad
mccoy,
I'm
at
ben.
I
think
utkarsh
is
involved
in
a
few
other
people.
I
may
be
missing
on
on
that
level.
Sasha,
but
what
basically,
what
we're
looking
at
is:
how
does
artillus
fit
into
the
get
ops
model,
and
what
does
that
mean?
As
as
far
as
you
know,
where
do
we
get?
C
Where
do
we
start
something?
Where
do
we
end
something?
The
tools
that
we're
looking
at
at
this
level
are
kept
ortulius
and
argo,
and
obviously
we're
going
to
be
using
github
as
part
of
that
process?
The
cloud
native
part
for
our
kind
of
our
playground
is
azure
doesn't
really
matter,
but
that
just
happens
to
be
where
we
are
setting
up
our
development
and
test
our
playground
areas
up
in
our
our
zoor
cluster.
C
One
of
the
things
that
we've
found
on
our
get
ops
integration
is
get
ops
is
really
complicated.
There's
a
lot
of
steps
that
have
to
happen
in
order
to
make
it
work
and
ortilius's
goal
is
to
simplify
that
process,
especially
when
you're
looking
at
microservices.
That
involves
several
hundred.
C
You
know
an
application.
That's
made
up
of
several
hundred
microservices
they're,
all
moving
at
different
speeds
through
their
pipelines,
and
things
like
that.
So
this
is
kind
of
the
the
transition
flow.
That
is,
you
know
when
you
check
something
in
what
happens
in
each
part
of
the
the
process.
C
C
Of
course,
we
have
our
our
our
developers
there
with
their
fish
sticks
and
hot
dogs
and
their
beers,
because
that's
the
way
we
envision
developers
doing
their
commit
into
github
triggering
off
the
whole
process.
I'm
not
going
to
walk
through
every
single
step,
that's
happening
here,
but
basically
the
next
step
as
part
of
the
road
roadmap
is
to
actually
start
coding.
C
C
So
another
part
that
we
have
is
we've
been
slowly
moving
our
monolith
over
to
microservices.
C
So
one
of
the
things
that
the
servers
catalog
project
did
was
we,
instead
of
going
into
our
monolith
and
adding
to
it
and
making
it
larger?
We
actually
split
out.
I
think
we're
ending
up
like
at
nine
microservices
to
have
ortillius
run
and
that's
actually
caused
some
additional
challenges.
C
One
of
them
being
is
dealing
with
the
get
ops
model
across
multiple
repos.
So
we
ended
up
being
a
great
use
case
for
ourselves
around
git
ups,
and
what
I
foresee
is
new
changes.
Moving
forward
will
be
done
in
the
microservices
architecture
world.
C
We
did
have
way
back
when
we
were
doing
our
microservices
we're
actually
using
flask
python
flask
as
our
underlying
microservices
framework,
and
when
we
went
to
roll
that
out,
we've
realized
that
it
wasn't
gonna
work,
so
we
actually
did
a
pivot
over
to
fast
api
for
python,
and
thanks
to
karam
and
a
few
other
folks,
ukarsh
we've
been
able
to
figure
out
how
to
make
those
resilient
ron
and
a
kubernetes
cluster.
Really
nice
deal
with
recoveries
and
scaling
very
easily
so
going
forward.
C
We
ortilius
will
still
be
a
hybrid
but
we'll
be
going
through
this
whole
process
of
moving
things
out
of
the
monolith
and
into
microservices
as
part
of
the
process.
C
With
that
being
said,
one
of
the
things
that
we'll
also
be
adding
is
taking
our
istio
environment
and
allowing
us
to
expand
that
into
a
process
where
we
can
actually
have
some
of
our
microservices
in
in
the
dev
environment
and
the
rest
coming
from
our
prod
environment
as
part
of
that
process.
So
most
of
our
stuff
is
read
only
that
we're
we're
doing
so.
C
We
don't
have
a
lot
of
exposure
to
corrupting
any
data
and
if
we
do
have
to
do
any
like
inserts
or
updates
to
our
database,
that
can
be
done
in
a
controlled
manner
under
associating
things
to
certain
user,
ids
and
stuff
like
that.
C
But
our
process
is
going
to
be
really.
Nice
is
part
of
the
the
the
migration
of
the
cc
plus
pieces.
Now,
one
of
the
other
things
that
we
have
that
our
deployment
engine
is
in
cc
plus,
and
that
is
on
the
consideration
of
moving
over
to
a
python
world.
C
The
deployment
engine
actually
has
like
its
own
language,
it's
called
dm
script
and
moving
away
from
that
to
using
native
python
is
something
else
that
we're
also
looking
at
that's
a
bigger
bite,
and
we
just
have
to
be
a
prioritizing
when
we
focus
on
that.
A
Schedule
and
goal
for
completion
of
this
micro,
this
architecture,
is
it
going
to
be.
Are
we
doing
that,
starting
that,
after
the
get
ops
and
the
service
to
service
dependencies?
What's
what's
what
is
the
team
thinking?
I
know
that
some
of
this
stuff
has
to
be
decided
by
the
governance
board,
but
in
terms
of
how
they're
going
to
run
that,
what's
the
thought.
C
So
initially
the
thought
is,
we
just
have
to
wrap
up
our
service
catalog
and
get
that
released.
We
are
on
that
part
we're
actually
focusing
on
the
very
last
step,
which
is
the
installation
piece
we
wanted
to
have.
It
came
out
from
the
community
that
we
should
have
a
a
single
line,
install
of
ortulius
into
your
kubernetes
cluster.
C
Previously
ortilius
could
run
in
docker
as
a
stock,
a
standalone
monolith
container,
but
now
that
we're
in
this
hybrid
mode
with
additional
microservices
one
of
the
requirements
is
that
we're
going
to
run
in
kubernetes
and
to
do
that
we're
going
to
be
using
helm
and
artifact
hub
as
a
way
to
host
our
helm
charts
and
do
this
single
line
install
of
ortulius
into
kubernetes.
C
With
that
being
said,
when
we
get
into
the
get
ops
the
get
ops
piece
most
of
those
changes,
we
may
have
one
or
two
microservices
that
we
need
to
add
for
the
get
ops
piece,
but
most
of
that's
going
to
be
on
creating
like
a
kept
in
events,
listener
and
event
trigger
dealing
with
interfacing
into
github
and
git
for
pull
requests,
updating
values,
files
for
the
helm,
charts.
C
A
C
C
We
have
to
write
260
microservices
to
migrate
off
of
our
existing
monolith
and
just
not
a
practical
way
to
address
something
where,
when
we
need
to
have
new
functionality,
we'll
add
a
new
functionality
as
microservices
and
be
in
this
hybrid
mode.
I
suspect
the
hybrid
mode
will
be
around
for
several
years.
C
So
some
of
the
things
that,
as
usual
microservices
come
out
looking
at
how
our
database
is
going
to
change.
One
of
the
things
that
we
did
do
over
the
last
six
months
is
expand
our
database
to
be
a
support,
managed
databases,
so
a
postgres
managed
database
not
only
on
google,
but
also
on
azure
and
aws.
C
So
that's
one
of
the
things
that
we
allowed
for
the
configuration
and
also
we
brought
in
a
container
a
docker
container
that
would
actually
run
pro
stress
locally
for
developers.
So,
basically
you
can
just
start
up
a
container.
You
don't
have
to
worry
about
installing
postgres
or
anything
like
that,
so
the
developers
have
a
way
to
have
access
to
the
database
with
some
pre-loaded
data
to
work
with.
So
that's
some
of
the
things
that
we've
done
in
the
in
the
past.
C
The
graph
database
may
come
into
play
when
we
look
at
expanding
the
service
and
service
relationships
as
part
of
the
process.
The
more
like
tracy
calls
it
we're
data
hoarding
and
it
may
make
sense
to
move
to
a
graph
database
just
for
speed
to
navigate
the
relationships.
Also,
the
graph
database
may
come
into
play
with
machine
learning
that
we
may
need
to
do.
C
C
The
like,
I
said,
going
forward
microservices
and
with
the
microservices
we
will
be
implementing
istio
to
do
some
service
level
routing,
so
you
can
have
a
dev
service
being
hit
based
on
your
your
login
and
the
developers
can
hit
that
service
and
the
other
services
would
come
from
production,
so
we'll
be
doing
some
more
work
around
istio.
C
A
A
The
sooner
that
will
happen
and
we're
using
we're
using
artillious
as
a
test
case
for
this,
and
what
needs
to
be
done
to
make
sure
that
you
can
separate
data
between
those
clusters
and
be
able
to
route
a
single
new
service
to
a
group
of
users.
So
we're
we're
using
artillios
as
a
bit
of
a
test
case
around
that.
C
And
just
to
point
out
some
other
things
that
we've
done,
even
though
this
was
a
slide
about
just
some
links,
the
ortelius.io
we've.
Actually,
that
is
fully
implemented
as
a
hugo
server
that
runs
in
our
cluster
and
is
being
deployed
by
deploy
hub
and
artelias,
so
we're
actually
using
artelias
and
deploy
hub
to
deploy
our
stuff
to
our
azure
cluster.
C
All
of
our
docks
are
we've
combined
our
contributor
guide
and
our
end
user
guide
under
a
another
hugo
server,
so
you
can
have
the
website
being
updated
through
a
pr
and
our
documentation
being
updated
through
a
pr,
as
well
all
of
its
automated
notifications
over
to
our
discord
channel
we're
trying
to
simplify
everything
as
much
as
possible.
A
I
forgot
to
even
know
you
know
indicate
that
we
had
rebuilt
the
the
website
this
year
too.
So
it's
been
a
busy
year.
We've
gotten
a
lot
done,
and
it's
because
of
the
open
source
community.
C
And-
and
I
know
on
the
deploy
up
side,
we
have
an
seo
person
working
on
that,
but
one
of
the
funny
things
is
when
we
look
at
our
seo
around
microservices
ortelius
is
coming
up
like
in
the
first
three
on
on
page
one,
I
think
their
number
or
two.
This
is
number
three
on
the
list.
C
So
it's
it's
pretty
impressive.
What
what
the
the
group
has
been
able
to
do
and
we're
very
excited
to
keep
moving
along,
keep
adding
in
new
new
information
that
is
needed
around
the
microservices
and
the
new
version
of
applications?
C
C
How
old
is
your
version
of
a
package
compared
to
the
current
version?
Are
you
running
a
version
of
a
module?
That's
three
years
old.
You
know
because
that
could
affect
how
something's
running
in
production
you're
so
far
behind
that's
overlaid
on
top
of
the
cves
and
vulnerabilities
and
then
also
there's
some
new
projects,
starting
out
of
the
open
source
security
foundation.
C
Having
to
do
with
signed
and
trusted
packages
we'll
be
able
to
bring
that
information
as
well,
then,
of
course,
where
tracy
talks
about
her
risk
score
and
how
that
can
fit
into
you
know,
once
we
get
all
this
data,
how
we
can
do
some
ml
and
ai
against
our
relationships
and
our
data
to
help
people
make
better
decisions.
A
C
C
Git
ops,
the
design
process
is
wrapping
up
and
then
we'll
go
into
the
information
implementation
phase,
and
we
have
kubecon
coming
up
cubecam
in
spain
that
will
probably
try
to
target
at
least
a
a
poc
around
at
that
level
for
kubecon,
spain.
I
think
that's
in
may
so
that's
kind
of
like
the
short
term
roadmap
that
we
have
going
on.
B
Needed
no,
I
have
one
question.
I
want
to
go
back
to
the
data
model,
I'm
not
a
super.
B
Yeah,
so
the
thing
that
I
worry
about
that
I
I'll
admit,
I
don't
have
a
ton
of
personal
familiarity
with
this,
but
you
know
the
first
thing
that
comes
to
mind
is
maintaining
integrity
in
a
multi-faceted
system.
So
what
are
your
thoughts
like?
Is
there?
Are
there
like
known
best
practices
around
us
that
you're
following
or
are
you
like
breaking
new
trail
with
with
what
you're
doing
here.
C
Right
now
we
are
sticking
with
the
single
monolith
database
until
we
understand
better
around
the
poly
and
how
how
our
transactions
can
fit
into
it.
It's
going
to
be
really
transaction
specific,
driven
and
not
necessarily
we're
going
to
take
our
whole
database
and
blow
it
into
a
poly
database.
That's
just
not
going
to
be
something,
that's
practical!
C
If
we
were
going
to
take
the
database
and
blow
it
out,
we'd
probably
go
right
to
a
graph
database,
but,
like
I
said,
we
have
like
135
tables
that
we
have
to
deal
with.
So
it's
not
a
small
effort.
C
Things
like
when
you
look
at
gathering
pieces
from
like
the
the
telemetry
side
and
prometheus
that
it
may
make
sense
for
those
pieces
to
go
into
a
separate
database
instead
of
going
right
into
our
monolith.
So
when
we
start
collecting
metric
data,
that
may
make
sense
where
we
put
that
as
part
of
it,
because
if
we
lose
integrity,
it's
not,
as
you
know,
we're
not
going
to
shoot
ourselves
in
the
foot.
A
A
Like
like
a
bomb
report
for
a
particular,
you
know,
just
a
bomb
report
table
that
we're
storing
bigger
pieces
of
information-
that's
not
part
of
our
existing
database
today,
as
we
start
moving
out
with
these
individual
microservices,
where
we
can
potentially
create
or
look
to
see
how
we
could
use
a
graph
database.
B
B
C
Exactly
especially
when
you
look
at
the
graph
databases,
there's
there's
about
a
half
dozen
of
them,
and
some
of
them
are
very
language
specific.
So
if
you're
writing
in
java,
there's
going
to
be
one
that
that's
tailored
to
work
with
java,
really
nice
there's
other
ones
that
are
tailored
to
go
around
the
go
link.
You
know
so
it
it's
one
of
those
that
we're
looking
at.
C
A
We
really
what
we
really
need
as
part
of
our
open
source
community,
and
I
continue
to
look
for
it
is
we.
We
have
plenty
of
university
students
who
are
really
interested
in
machine
learning
and
data
science,
but
we
don't
have
a
good
mentor.
So
if
anybody
out
there
knows
a
good
mentor
in
this
area,
we
have
so
much
data.
A
We
really
believe
that
we
could
do
a
lot
of
predictive
reporting
and
we
can
start
doing
the
things
that
I
keep
talking
about
around
risk
analysis
based
on
the
data
that
we
have
and
there's
probably
things,
I'm
not
thinking
about.
So
we
have
a
lot
of
college
students
out
there
who
are
interested
in
data
science
and
machine
learning,
it's
kind
of
what
they're
they're
where
their
head
is,
but
we've
not
I've
not
identified
a
good
mentor
who
can
kind
of
take
the
side
of
the
the
technology
on
and
give
us
some
clear
direction
on.
A
What's
the
best
direct
direction
for
building
out,
you
know
some
machine
learning
around
the
data
that
we
do
have,
and
what
do
we
need
to
have
to
do
that?
Is
it
graph
databases
or
poly
databases,
or
should
we
stick
with
our
monolith
and
I
kind
of
think
it's
going
to
be
a
graph
database.
C
And
one
of
the
things
when
we
look
at
the
data
science
viewpoint,
the
interesting
part
with
artelias
and
the
information
that
we're
reporting
is
we're
not
in
the
terabytes
of
data
that
you
have
to
comb
through
and
look
for
patterns.
C
So
you
know
something:
that's
running
in
development
versus
something
that's
run
in
production
would
have
a
different
weight
to
it
and
traversing
these
relationships
is
and
and
kind
of
understanding
them
is
going
to
be
where
the
data
science
is
going
to
come
into
play.
So
it
may
not
be
ml
cruising
through
terabytes
of
data,
but
it
may
more
be
on
the
ai
side
trying
to
understand
how
to
make
better
decisions
around.
A
The
data
even
from
a
pattern
matching
perspective,
and
we
we
literally
could
go
in
as
steve
pointed
out,
we're
going
to
be
tracking
cbes.
We
could
be
able
to.
Potentially
we
could
use
the
data
and
say
you
know
what
this
cve
has
been.
This
has
been
repaired
and
we're
seeing
it
in
other
microservices
and
provide
an
entire
report
for
your
entire
enterprise.
It
says
these
are
the
microservices
that
still
have
these
vulnerabilities
that
we
that
you're
not
haven't
addressed
yet
so
again.
A
D
I
think
I
might
know
somebody
that
is
good
in
that
space.
This
is
hank
by
the
way
he
actually
works
as
a
data
scientist
at
bp,
but
he
also
teaches
robotics
stuff
and
some
data
science
classes
as
well.
So
he
does
mentoring.
A
That
would
be
great.
That's
exactly.
We've
got,
we've
got
a
couple
of
kids
from
india.
We've
got
a
couple
of
kids
from
turkey
who
are
super
excited
about
it.
We
just
don't
have
a
mentor.
So
if
he's
interested
I'd
love
to
chat
with
him.
D
A
Thank
you,
hank
yeah,
absolutely
and
I'm
glad
tara.
I
thank
you
for
bringing
up
the
database
part
because
data
is
what
we're
in
the
business
of
of
grabbing
and
doing
something
with
so
it's
it's
really
a
quarter
the
discussion
and
bringing
additional
value
to
the
to
this
open
source
project
and
making
it
more
relevant
in
terms
of
this
discussion.
A
That's
happening
right
now
around
supply
chain,
because
if
you
think
what
we're
really
doing
is
we
are
doing
a
very
detailed
job
of
tracking
microservices
supply
chain
for
an
organization
and
potentially-
and
we've
always
talked
about
this-
we
want
to
be
able
to
do
it
even
at
an
open
source,
microservice
level.
So
if
we
were
hosting
this
in
a
in
a
way
that
we
could
right
now,
we
have
it
in
at
the
deploy
hub
level.
A
We
have
a
sas
environment
that
we
keep
looking
at
starting
to
add
open
source
microservices
that
people
can
consume,
because
we
know
that
they're
coming
they're
going
to
be
there,
but
once
we
start
doing
that,
we
can
then
report
on
everybody
who's
anybody
in
the
world
who's
using
a
particular
microservice.
I
know
that
sounds
lofty,
but
it's
just
data,
it's
very
possible
for
us
to
do.
We
could
show
every
microservice
that
has
a
vulnerability,
that's
that
needs
to
be
corrected
and
provide
that
kind
of
reporting.
C
And
part
of
the
the
vision
I
have
is
if
an
open
source
project,
like
a
node.js
project,
ends
up
doing
a
security
fix
that
all
these
companies
that
are
have
docker
images
that
are
consuming,
that
the
old
version
of
that
node.js
module
that
they
need
to
just
maybe
just
as
simple
as
rebuilding
the
base
image
and
running
through
some
test
cases.
A
Any
other
questions
about
the
the
road
map
or
what
we've
been
up
to
or.
E
Yeah
kind
of
this
is
hank.
I'm
going
to
take
a
different
approach.
I'm
going
to
take
a
bottoms-up
approach.
Kind
of
my
my
daily
week
is
infrastructure
right.
So
one
of
the
things
we're
looking
at
in
and
you
look
at
a
lot
of
people
that
are
not
circuit
cloud
plates
that
have
brick
and
mortar
that
have
on-prem
assets
that
have
data
right
or
you
have
edge
devices.
You
can
call
it
another
data
center
devices.
E
Looking
at
that
hybrid
model,
one
of
the
things
that
we're
looking
at
is
how
do
we
simplify
that
and
there's
a
few
platforms
out
there
that
we've
done
some
analysis
on,
but
it
speaks
to
mapping
and
micromicroservices
dependency
mapping
and
how
we
track
all
those
things.
So
one
is
they're
platform.
Nine,
another
one's
spectro
and
tanza
came
up
with
with
a
system
called
tap
which
changed
the
application
platform.
E
I
think
it's
called
anyway,
but
they're
they're
platforms
that
tie
directly
into
kubernetes
environment,
more
spectro
and
platform
and
tenzu
and
tap
do
platform.
E
9
takes
a
get
ops
approach
to
deploying
infrastructure
as
a
whole
and
couples
that,
together
with
the
application
stack
into
the
infrastructure,
stack
deploying
it
to
a
containerized
environment,
whether
that's
a
bare
metal,
an
aks
cluster
ets
cluster,
whatever
it
looks
like
so
I'd,
be
curious
to
see
where
this
goes
with
it
with,
I
guess,
with
the
lens
that
there's
there's
always
going
to
be
some
sort
of
hybrid
model
on
how
you
manage
those
edge
data
center
to
cloud
computing
workloads
consistently
across
dependencies
and
stuff.
So
anyway,
just
putting
that
out.
E
C
Yeah,
so
one
of
the
things
in
the
artillious
world
is
a
component
can
be
as
can
pretty
much
represent
anything
it
could
be.
You
know
a
two
gigabyte
websphere
ear
file,
or
it
could
be
a
docker
image
or
it
could
be
a
test
case.
It
also
can
be
a
terraform
to
stand
up
the
the
cluster
so
for
us,
infrastructure
is
just
seen
as
another
component
that
we
need
to
bring
into
the
picture
of
what
is
needed
for
this
application.
This
version
of
the
application
to
run.
C
We
know
we
need
this
infrastructure
in
place.
We
know
we
need
this
app
layer.
We
know
we
need
this
database.
We
know
that
we
need
this.
These
test
cases,
these
you
know
those
pieces
and
we
kind
of
we're
ortiz
is
designed
to
be
at
the
50
000
view
foot
view.
C
Looking
over
all
your
your
whole
data
center,
not
only
physical,
that
may
be
on-prem
cloud
kubernetes
or
you
know
plain
old
servers,
running
tomcat
or
websphere,
we're
that's
where
we're
looking
across
all
that
from
development
out
to
production
throughout
the
whole
pipeline.
C
So
that's
the
one
of
the
goals
that
we're
trying
to
bring
into
play
is
that
that
viewpoint
like,
like
you,
said
that
lens
of
of
where
we're
viewing
the
data
from
now
because
of
the
relationships
that
artelias
has,
you
can
look
at
it
from
the
developer's
point
of
view.
You
know
my
blast
radius,
I'm
I'm
breaking
this
component.
Who
else
am
I
going
to
affect
to
the
sre
view?
I
have
this
this
new
version
of
the
application.
C
What's
in
it
and
then
from
operations
point
of
views,
I
have
to
manage
these
environments
and
what
what's
in
them?
So
that's
what
kind
of
like
where
these
these
dependency
relationships
lead
us
to
so
bringing
in
infrastructure,
as
part
of
that
is
just
an
easy
extension
to
ortelius.
A
A
Now
the
way
we
position
ortilius
we
we
have
to
you
know
we
have
to
pick
a
poison
so
to
speak,
and
we
felt
that
microservices
was
the
best
thing
to
to
to
position
it
around.
But
it's
truly
it
can
it's
just
parts
or
parts,
it's
simply
managing
parts
in
their
relationship.
So
it
doesn't
matter
what
the
parts
really
are.
If
you
really
boil
it
down
to
you
know
what
it
can
do,
but
that's
so
broad
it'd
be
hard
for
people
to
understand.
Until
you
have
asked
those
questions
like
hank
just
asked.
C
Just
just
one
last
thing
I
I
just
want
to
you
know
just
shout
out
to
you
know
all
of
our
members
that
are
part
of
the
artelius
project.
C
They've
put
a
lot
of
hard
work
in
extra
time
time
at
weird
hours,
and
we
really
appreciate
everybody.
That's
been
contributing
and
making
the
the
project
move
forward.
We
have
like,
like
we,
you
saw
on
the
roadmap.
We
have
some
fun
stuff
coming
up,
but
that's
not
the
only
thing.
So
if
you
have
new
ideas,
please
bring
it
to
the
working
group
meetings.
A
And
december
8th,
if
you
have
time
check
out
our
twitch
channel
and
watch
some
of
our
newbies
do
presentations
and
I'm
looking
forward
to
hearing
from
ankar
who
is
our
keynote
as
an
end
user,
who
has
helped
implement
microservices
for
some
large
organizations.
B
A
A
A
B
A
C
Well,
thank
you
everybody
for
coming
today
and
please
come
to
the
visionary
summit
and
then
we'll
schedule,
another
tlc
in
first
quarter
or
spring
time.
Yeah
put
it
that
way.