►
From YouTube: December 10, 2020 Ortelius Architecture Working Group
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).
B
D
Yeah
already,
I
actually
have
my
you
know,
like
my
engineering,
simply
at
the
team
at
7
30
a.m.
My
time
so
you
know
I
basically
like
wake
up
my
kids.
You
know
I
dress
them
up,
I'm
on
the
phone
and
then
I'm
driving
I'm
driving
them
to
their
daycare
and
we're
still
talking
you
know-
and
I
only
you
know
like
drop
off
the
call
right
before
you
know.
I
give
them
pieces
in
there
and
there
in
the
daycare.
E
B
C
E
E
Kind
of
do
it
as
I
go
here
so
on
the
discord
channel.
E
We
had,
I
would
say,
a
very
long
discussion,
but
we
need
to
have
a
discussion
about
notifications
with
discord
and
like
slack
and
what
that
means.
As
part
of.
E
E
There's
like
a
successful
and
a
successful
deployment,
template
and
failed
deployment
template,
and
if
you
get
into
the
setup
area,
you
can
set
up
these
notifier
templates
and
there's
a
bunch
of
different
types
that
you
can
use
as
part
of
the
notification
process.
E
Some
of
them
are
gonna,
be
like
slack
hipchat
email
text
messages.
So
what
ends
up
happening
is,
after
you
do
a
a
deployment.
That's
where
we're
going
to
go
ahead
and
do
that
notification
now.
There's
other
notifications
that
may
need
to
be
that
we
may
want
to
think
about.
This
is
all
post
deployment.
E
So
that's
one
thing:
we
should
do
some
investigation
around
whether
where
we
should
be
looking
at
notifications,
because
if
you
look
at
something
some
of
the
integrations
I've
seen
tools
do
especially
like
with
the
jira
or
servicenow,
where
they're,
using
like
jira
as
the
center
of
the
universe,
so
everything's
driven
by
ajura
ticket.
You
know
those
type
of
things
and
I
have
a
feeling
we're
moving
away
from
this
type
of
model
here,
but
you
would
have
a
juror
taker
that
say
this
is
ready
to
build.
E
You
go
and
change
a
status
to
build.
That
would
then
do
it
do
a
web
hook
that
will
go
ahead
and
trigger
the
build
and
then,
after
the
build's
done
you
go
ahead
and
update
jira,
say
the
build's
been
completed
now
we're
on
to
the
next
step
of
doing
the
deployment,
and
then
you
you'd
update
the
statuses.
So
this
this
like
status,
loop
thing
that
happens
in
the
orchestra
between
the
orchestration
tool
and
the
the
ticketing
system.
E
E
Like
I
said,
if
you're
looking
at
like
a
jenkins
pipeline,
this
is
one
one
example
that
I
threw
out
there:
a
jenkins
pipeline,
there's
slack
plug-ins,
there's
gonna
be
other
plug-ins
that
you
could
actually
put
in
your
pipeline.
So
before
you
do
your
build,
you
could
do
your
your
slack
notification
and
you
know
post
build
and
post
deployment.
You
could
do
another
notification
at
that
level.
E
So
put
your
devops
hats
on
and
think
about
what
type
of
information
and
what
type
of
notifications
we
should
be
looking
at
on
that
front.
Does
that
make
sense
to
everybody.
H
Yeah
totally
so
this
is
this
is
my
life.
You
know
this
is
what
I
do
every
day,
keeping
other
people's
running,
and
I
guess
I
shouldn't
say
that
on
the
recording,
but
the
you
know
the
the
build
part
of
this.
You
know,
starting
and
ending
you
know
interests
me
with
my
developer
hat
on.
H
You
know,
I've
seen
people
that
you
know
your
your
ci
pipeline
is
is
just
really
busy
and
so
you're
waiting
half
an
hour
before
your
build
starts,
so
that
you
can
see
if
what
you
changed
is
actually
doing
anything,
and
so
people
would
definitely
appreciate
being
notified
of
the
starting
and
ending
of
those
things.
But
with
my
devops
hat
on
you
know,
I'm
really
worried
about
the
deployment
side
of
things,
and
I
agree
with
you
for
that.
H
For
the
deployments,
I
don't
see
people
using
jira
as
much,
but
I
definitely
see
slack
being
used
to
keep
people
updated
with
you
know.
Oh
I'm
deploying
this
and
place
x
or
place
y,
and
that
sort
of
thing
one
place
that
I
worked
built
up
their
own
jenkins
to
slack
integration
and
part
of
that
was
being
able
to
dynamically
show
the
progress
on
the
deployment.
H
And
so
you
know,
if
you're
deploying
to
30
different
machines,
it
could
say:
okay,
I've
completed
one
of
32
of
33
of
30
and
you
could
actually
see
how
fast
that's
moving
along
and
it
dynamically
updated
on
the
slack
side.
So
it
was
just
like
there
was
one
slack
message
for
hey
we're
doing
this
deployment
and
then
the
little
bar
underneath
it
for
completion
changed
until
it
was
done.
H
Yeah
yeah,
I'm
not
sure
exactly
how
that
part
of
that
worked
honestly,
but
but
yeah
so
somehow
being
able
to
say,
okay,
you
know
we're
x
percentage
done
through
this
thing
and
I
think
the
other
beneficial
part
of
that
is
like
how
long
it's
been
going.
You
know
if
you're
50
through
and
it's
12
hours
later,
then
that's
probably
a
problem,
and-
and
you
know
somebody
would
probably
want
to
be
able
to
keep
track
of
that.
H
But
you
know
at
least
knowing
you
know
for
like
a
mvp
sort
of
thing
that
the
deployment
started
in
the
deployment
ended.
That
would
be
hugely
helpful
from
just
knowing
what's
currently
flying.
You
know
in
flight
sort
of
thing,
and
I
do
see
having
that
information
in
slack
is
beneficial
in
a
broader
context,
because
it
doesn't
just
get
consumed
by
the
sre
devops
type
folks.
It
also
ends
up
being
consumed
by
a
lot
by
the
users
and
so
they'll
be
like.
H
Oh,
this
is
down
because
it's
currently
under
a
deployment
and
so
I'll
come
back
and
try
an
hour
later,
and
so
it
cuts
out.
You
know
a
lot
of
the
you
know
people
having
to
ask
what's
up,
you
know:
why
is
this
down
sort
of
thing,
and
so
you
know
keeping
the
broader
set
of
people
aware
is
definitely
the
advantage
of
having
this
stuff
in
a
slack
room
that
everybody
can
go
to
and
see.
What's
going
on,.
E
Yeah,
I
the
I
just
updated
the
the
landscape
for
to
add
ortilius
in
remind
me
tracy.
We
gotta
approve
that
pr,
but
they
do
a.
E
They
have
a
slack
channel
that
the
whole
landscape
is
this
weird
back-end
process
that
does
a
bunch
of
reworking
and
creating
the
the
svg
on
the
fly
as
part
of
the
build
process,
and
they
have
a
slack
channel
that
lets.
You
know
that
it's
been
completed
because
it
takes
a
little
bit
to
do
so.
I
think
yeah
I
think
finding
out.
What's
up
is
a
big
question.
People
people
are
trying
to
find
out
when
they're
looking
at
statuses
of
of
deployments-
and
you
know
how
far
along
they
are.
H
Yeah
and
another
aspect
of
that
that
comes
up
a
lot
of
scene
is
that
people
don't
have
adequate
permissions,
and
so
you
know
the
the
the
build
is
going
off
to
some
cidc
platform
and
I'm
dealing
with
team
city
these
days.
So
I'm
just
going
to
say
team
city.
So
the
build
goes
off
team
city,
but
they
don't
have
a
log
in
on
team
city,
so
they
can
see
in
github
whether
their
build
succeeded
or
not,
but
having
some
other
avenue
for
people
to
be
able
to
see
that
information.
E
Right
and
the
other
thing
I
think,
with
with
this
type
of
notification,
it's
really
becoming
the
new
dashboard
before
we
used
to
have
dashboards
for
monitoring
this
stuff.
You
know,
and
that
was
kind
of
like
the
whole
blue
ocean
part
of
jenkins-
was
to
pull
in
a
dashboard,
so
you
can
kind
of
see
what's
happening
so,
okay.
H
I
mean
I
still
build
dashboards
for
people,
because
people
like
metrics-
and
I
like
that
stuff
for
investigation
purposes,
but
yeah
like
having
it
in
slack
means
I
can.
You
know
like
have
the
deployment
stuff
and
my
pager
duty
notifications
in
the
same
room.
So
it's
like.
Oh
this
deploy
actually
broke
something
because
I
can
see
at
the
same
point
in
time
and
it
sort
of
lets
you
coordinate
all
that
see
how
it
fits
together.
E
Well,
that
brings
us
brings
up
a
good
point.
The
should
we
be
associating
additional
metadata
to
the
application
and
components,
and
things
like
that,
for
example,
who
is
the
owner
of
this
microservice?
E
You
know.
So
if
I
need
to
go,
find
and
talk
to
somebody
what's
their
email
address
or
slack
handle
to
talk
to
them.
You
know
that
type
of
thing
I'm
wondering
if
we
should
look
at
adding
in
additional
metadata.
You
know,
what's
what's
the
page
of
duty,
you
know
contact
those
type
of
things
that
are
out
there
and
then,
when
we,
the
the
tricky
part
is,
though,
if
we
have
a
microservice
and
we
have
all
that
owner
information
and
that
metadata
about
you
know
like
who's.
E
The
lead
developer
is
where
the
github
repo
is,
but
when
we
roll
it
up
into
an
application
version,
what
that
there's
gonna
be
an
application
owner
as
well,
so
we'll
have
multiple
ownership
levels
or
notification
levels
that
we
need
to
look
at.
H
Yeah
this
this
actually
gets
really
close
to
one
of
the
things
that
I
most
cared
about
and
wanted
to
try
and
do
within
ortillius.
Eventually
is
something
along
the
you
know,
sei
maturity,
model
sort
of
thing.
You
know
you
can
have
a
micro
service,
but
if
it
doesn't
have
a
run
book,
then
it's
a
less
mature
microservice.
H
If
you
don't
have
a
monitoring
dashboard
that
you
can
link
somebody
to,
then
it's
not
quite
as
mature
and
having
that
ownership
stuff
defined,
you
know,
definitely
comes
as
part
of
that,
and
you
know
when
you
get
to
your
failure
notification.
All
of
this
is
stuff
that
is
great
to
have
built
into
that.
You
know.
Pager
duty
alert
or
whatever
the
you
know,
equivalent
is
in
somebody's
world
so
that
you're
not
having
to
go.
Look
all
that
stuff
up
and.
H
I
don't
know
how
hard
we
want
to
make
this
on
ourselves,
but,
like
some
of
this
stuff
changes
over
time,
and
so
like
you
know,
the
component
may
be
owned
by
person
b,
even
though
we
released
it
under
person
a
six
months
ago,
and
so
I
don't
know
if
we
want
to
worry
about
that
level
of
the
problem.
But
at
least
knowing
who
owned
it
six
months
ago
would
be
better
than
nothing.
E
E
Yeah,
I
know
when
you,
if
you
start
looking
at
the
scaling
problem
that
we're
dealing
with
and
you
get
into
you
know
a
couple
hundred
microservices
and
that's
spread
out
across
even
just
a
small
number
of
teams,
20
teams
that
trying
to
find
out
who
to
talk
to
when
something
breaks
it
could
be
challenging.
E
I
like
that,
I,
like
that
maturity
matrix,
I
think,
we'll
have
to
dive
into
exactly
what
metadata
that
we
want
to
associate
and
kind
of
slot
into
the
different
levels
of
maturity.
E
So
remind
me
that
we
need
to.
We
need
to
break
this
out.
H
E
Right,
I'm
gonna
change
over
to.
E
So
component
sets,
it
looks
like
one
of
the
first
things
that
we
need
to
really
address
is
basically
component.
Sex
are
a
collection
of
component.
E
And
this
comes
to,
I
know
chris
christopher
you
asked
for
a
like
a
database
schema
layout.
E
I
think
I've
been
thinking
about
this
one
and
instead
of
doing
a
a
more
traditional
like
table
schema
and
how
they're
related
related
through
the
foreign
keys,
I
think
I'm
gonna
put
together
one
that's
more
more
grammar-like
so
and
I'm
going
to
look
at
leveraging
some
of
the
grammar,
that's
in
the
spdx
terminology
that
they
use.
So,
for
example,
an
application
version
depends
upon
a
component
version.
E
E
The
reason
I
want
to
in
what
I'm
going
to
do
is
lay
that
laid
out
like
that
and
I'm
going
to
leave
out
some
of
the
pieces,
though,
because
it'll
just
get
too
confusing
initially
and
we
can
break
those
out
into
a
separate
one.
So
part
of
it
is
there's
two
levels.
E
One
is
tracking
relationships.
E
So
I'm
going
to
break
it
out
into
that
you
know,
so
we
can
actually
focus
on
those
two
distinct
things
that
orthelius
is
able
to
do
so
tracking
the
relationships
I'll
lay
out
the
grammar
around
all
the
the
how
components
related
to
an
application,
application
related
to
an
environment
and
so
on,
and
then
a
second
document
that
has
to
deal
with
doing
a
deployment.
E
You
know
what
actually
happens
in
doing
a
deployment
because
we
have
in
ortelius
actions
so
like
in
this
case
we
have
a
pre-action
for
resizing
a
cluster
at
this
level
and
sasha.
This
kind
of
brings
me
around
to
the
question
that
you
had
yesterday
on
discord
around
aws
regions.
E
Well,
it's
not!
It
really
isn't
because
we've,
depending
on
what
you're
doing
so
in
this
case
our
hipster
store,
is
running
on
gke
and
I
have
a
cron
job
that
goes
out
there
and
just
does
some
google
commands
to
size
the
cluster
to
zero,
but
when
we
go
out
and
deploy,
somebody
goes
out
and
deploys.
We
actually
run
a
pre-action
to
the
whole
deployment
that
goes
out
and
spins
up
the
cluster
size
at
that
level.
E
I
It's
in
here
somewhere,
I
just
want
to
see
it
yeah
we
use
we
use
terraform.
So
that's
that's
good
to
hear
because
terraform
to
do
that,
yeah.
E
H
E
That's
and
that's
what
I've
heard
as
well.
I
haven't
played
with
a
terraform
myself,
but
based
on
what
people,
I've
talked
to
it's
a
lot
less
wordy
and
it
has
a
lot
more
functionality
like
christopher
said,
because
it's
designed
to
deal
with
multiple
regions,
multiple,
even
cloud
providers.
E
You
know
it's
supposed
to
abstract
out
the
the
cloud
providers
as
well,
but,
like
I
said
we
would
have,
the
initial
pre-action
would
be
to
go
stand
up
the
the
cluster
and
then
the
part
of
that
for
that
process,
is
you
want
to
make
sure
that
it's
already
hasn't
been
already
provisioned?
E
E
Now
one
of
the
nice
things
with
artelias
is
depending
on
what
you
need
to
do:
sasha
for
the
different
regions,
if
you're
breaking
them
into
like
you
know:
west
u.s,
west,
u.s,
east,
maybe
japan,
or
something
like
that
as
another
region,
you
can
make
those
environments
and
you
can
deploy
to
the
u.s
west
environment
and
then
that
environment
is
going
to
contain
all
the
different
sub-regions
out
there
that
you
want
to
push
the
the
changes
to
the
other
way
you
could
do
it
is.
E
E
So
at
that
level
you
can
have
an
environment
for
qa1
that
is
going
to
run
in
us
west
and
then
qa5
is
going
to
run
into
japan,
data
center
for
aws,
and
when
you
deploy
you
deploy
to
the
environment
and
the
nice
thing
is
we
take
all
of
the
metadata,
and
this
is
the
information.
The
key
value
pairs
can
be
tied
to
the
environment
and
that
would
be
passed
into
the
terraform
as
the
overrides
file.
So
what
ends
up
happening
is
your
your
terraform.
E
Your
base,
terraform
file,
is
reusable
across
every
single
region
and
you
just
pass
in
the
different,
depending
on
where
you're
going
you
pass
in
the
additional
overrides
that
you
need
as
part
of
that
process.
E
So
just
to
give
you
that
that
heads
up
what
we
can
help
you
out
with
that
on
that
front,.
E
E
E
But
on
that
front
you
know
the
two
things
that
we
really
need
to
look
at
are
going
to
be
tracking
the
relationship
and
doing
deployments
like
I
said
what
we
just
talked
about
was
the
doing
deployment
part,
but
you
still
need
to
track
the
relationships
of
what
you're
going
to
to
deploy
as
part
of
that
process.
E
So
I'll
go
ahead
and
put
a
google
doc
out
there
and
let
everybody
know
when
it's
ready
to
look
at
I'm
going
to
first
start
with
the
tracking
relationships
at
this
level,
because
this
is
actually
kind
of
overlapping
with
what
is
the
it's.
The
the
sig
interoperability.
E
Yeah
they're
coming
up
right
after
this
one,
so
that
information
I'll
get
out
to
you
and
then
this
type
of
relationships.
I
was
talking
to
a
data.
We
were
talking
to
a
data
scientist
last
week
and
I
did
some.
He
was
big
into
graph
and
graph
using
graphs
in
ml
as
part
of
the
managing
relationships
and
graph
databases,
and
I
started
looking
at
what
is
out
there
and
how
it
could
fit
into
what
we're
doing
it's
a
great
idea.
I
think
what
we
need
to
do
for
component
sets.
E
It
may
be
too
much
of
a
heavy
lift
for
us
to
change.
Our
whole
database
schema
our
whole
database
implementation
from
a
postgres
over
to
like
a
neo
j
or
a
janus,
or
something
like
that.
But
I
think
we
can
still
do
do
the
relationships
that
we
want
in
the
in
the
postgres
database.
E
We're
not
talking
about
trillions
of
nodes
like
they
deal
with.
In
the
graph
databases
I
figured
if
we
have
5
000
microservices
and
the
number
of
relationships
between
the
5
000.
If
you
have
like
10
environments
or
that
you're
going
to
that's
only
50
000
in
relationships,
you
got
to
manage
instead
of
the
trillions.
Even
if
we
went
to
100
100
environments
that
were
managing
the
relationships
of
that
too
we're
only
at
500
000
relationships,
which
is
still
pretty
small
for
our
relational
database.
C
However,
I
think
it
might
be
good,
at
least
to
take
a
look
at
rebuilding
the
back-end
database.
We
should
at
least
research
it
and
determine
if
it's
worth
it.
E
Yeah,
it's
interesting.
C
And
I
don't
know
how
that
if
we
think
about
what
it
might
look
like,
because
the
tara
hernandez
is
pretty
amped
about
the
ideal
of
a
marketplace
and
if
we
go
to
that,
go
that
route
and
if
we
are
a
centralized,
become
a
centralized
marketplace.
As
this
conversation
is
supposed
to
be
around,
would
that
help
or
would
that
be
a
problem?
C
H
You
know
I'm
I'm
I'm
very
old
school.
I
really
like
to
have
the
you
know
database
with
all
the
data
in
it,
so
that
I
can
take
snapshots
and
there's
lots
of
tools
around
postgresql
being
able
to
manage
that
sort
of
thing
and
amazon
gives
you
rds,
and
so
that
really
makes
it
easy
to
build
large
stuff
and
not
have
to
worry
about
matching
it.
C
E
A
little
clarification,
so
graphql
is
not
a
graph
database.
They're
two
totally
separate
things,
so
a
graphql
is
a
replacement
for
a
restful
api
call
and
the
id,
but
github
uses
graph
ql
a
lot
on
their
their
transactions.
But
the
idea
is,
I
submit
one
request
and
then
that
request
is
broken
out
into
sub
requests
through
graphql.
E
On
the
back
end,
the
graphql
subrequests
can
be
hitting
a
relational
database,
that's
where
it
actually
started
so,
and
there
is
a
a
I
was
reading,
that
there
is
a
new
trend
to
merge
graphql
with
graph
databases
out
there.
H
C
E
Exactly
so
the
the
you
can,
so
we
could
take
our
existing
implementation,
which
is
based
on
rest,
a
restful
api
set
and
the
there's
a
database
layer
that
does
takes
the
request.
The
restful
api
request
says:
oh,
you
want
to
go,
get
a
user.
It
creates
the
sql
statement
to
go
grab.
The
user
hits
the
database.
The
postgres
comes
back,
puts
that
into
a
json
string
and
returns
that
transaction
back
to
the
requester
on
the
graphql
side.
E
If
we're
going
to
do
that,
you'd
have
a
graphql
transaction,
come
in,
we
go
ahead
and
do
the
same.
Postgres
sql
query
to
query
the
the
database
get
the
user
and
you
return
the
the
json
back
to
the
graphql
back
to
the
the
requester
now
on
a
graph
database.
E
What
ends
up
happening
is
it
can
either
be
a
graphql
or
a
restful.
Api
call
doesn't
really
matter
just
when
we
get
into
the
middle
layer.
What
we
do
is
when
we
go
to
make
our
our
connection
to
the
database.
We're
making
instead
of
sql
calls
we're
making
graph
syntax
called
one's
called
like
gremlin
like
gql
is
another
interface.
There's
a
couple.
Other
language
sets
they
haven't
really
standardized
on
them.
E
Yet,
but
basically,
there's
a
a
query
that
happens
and
it
goes
and
gets
the
data
from
the
the
graph
database
and
returns
it.
So
what
ends
up
happening
is
we
can
replace
the
postgres
database
with
a
graph
database
and
the
middle
layer
would
still
return
the
same
information
back
to
the
requester.
E
E
All
the
back
end
stuff
would
would
be
would
be
replaced
now.
The
advantage
of
the
graph
database
is
it's
designed
to
be
around
relationships
and
managing
relationships.
So
some
of
the
stats
I've
read
is,
if
you
have
a
table
of
100
million
rows
that
it's
sub.
Second,
for
you
to
do
a
query
and
get
your
relationships
out
of
100
million
rows.
E
Well,
just
because
of
the
way
that
the
data
stored
now
most
of
the
implementations,
I've
seen
they,
the
graph
databases
sit
on
top
of
another
database
or
a
some
sort
of
persistence
data
store,
depending
which
cloud
provider
you're
at
and
which
ones
that,
like
some
of
the
implementations,
use
google's
big
data.
Is
it
big
data
or
bigtable,
something
like
whatever
the
google
big
data?
One
is
as
a
back-end
data
store.
So
there's
that's
how
they
persisted
through
that
at
that
level.
E
It's
it's.
The
only
thing
that's
going
to
really
the
advantage
of
the
graph
database
is
the
speed
to
manage
the
relationships
and
the
size.
You
know,
I
think
the
the
amount
of
storage
I
was
going
to
take
up
is
going
to
be
less,
but
we
store
so
little
information.
We
don't
stor.
We
store
a
lot
of
little
information
instead
of
big
sets
of
data.
E
And
we're
not
even
over
a
gig
for
our
data
for
at
that
level,
so
that's
kind
of
what's
what's
happening.
Does
that
help
kind
of
give
you
the
distinction.
E
Yeah
I'm
wondering
if
there's
a
way
to
do
like
a
hybrid,
where
we
would
actually
be
using
both
at
the
same
time
and
kind
of
go
that
route
as
well,
so
where
we
needed
the
the
heavier
relational.
E
The
relationships
between
two
objects
that
we
can.
Maybe
you
know,
maybe
when
we,
when
the
wrestle
api
call
comes
in
it,
hits
the
middle
there
that
it
gets
saved
to
the
postgres
database
and
also
over
to
the
graph
database
as
well.
And
then,
if
you
need
to
do
some
fast
queries
or
something
like
that
around
the
relationships,
that
transaction
would
be
looking
directly
at
the
graph
database
and
not
the
relational
the
postgres
one.
C
E
Sets
yeah
and
for
us
to
implement
component
sets
in
the
postgres
database
is
not
going
to.
E
I
C
Basically,
what
where
we
first
heard
this
was
from
michael
galloway
at
netflix
and
they
have
created
microservices
that
should
not
be
loosely
coupled.
So
this.
C
Coupled
so
now
they
have
to
create
a
set
of
microservices
that
get
deployed
together,
even
though
they
have
nothing
to
do
with
an
actual
application
that
somebody
is
like
a
you
know.
If
you're
a
bank,
a
teller
application,
there
is
it's
a
it's
a
set
of
microservices
that
they've
created
that
have
to
have.
They
have
to
be
released
all
at
the
same
time.
C
They
could
have
put
them
in
the
same
container,
but
they
didn't,
and
apparently
intuit
has
had
the
same
issue.
E
Cool,
so
in
in
this
example,
each
one
of
these
is
a
component
version,
that's
being
consumed
by
the
application
version.
That's
in
the
middle
component
set
would
be
where
we
would
tie
like
shipping
and
checkout
service
together,
and
those
two
versions
would
be
tied
to
a
component
set
and
they'd
have
a
version
of
the
component
set
that
would
be
associated
to
the
application
version.
E
So,
instead
of
having
the
shipping
service
directly
related
to
the
application
and
the
checkout
service
directly
related
to
the
application,
you'd
have
the
set
related
to
the
application,
and
then
you
could
drill
into
the
set
to
see
what
the
the
versions
are
inside
of
that.
E
A
J
E
Netflix
and
who
is
argo
cd,
each
microservices
is
considered
an
application
this.
This
is
where
it
gets,
it
really
confusing.
E
So
they
look
at,
and
this
is
because
they
came
out
of
the
monolithic
world
and
dealing
with
like
vms,
and
things
like
that,
especially
with
netflix
that
a
microservice
is
a
an
application,
and
then
you
have
application
sets
which
in
our
world
is
just
application
version,
and
then
you
know
so
there's
this
this
terminology
thing
that
we're
going
to
have
to
battle
a
little
bit.
E
I
think
the
way
we
describe
it
is
a
little
bit
easier
to
understand,
breaking
out
a
component
versus
application
instead
of
having
an
application
set
of
an
application
set,
which
is
the
included
another
application
set.
You
know
what
do
you?
What
at
the
end
of
the
day,
what
do
you?
What
do
you
have?
You
know
an
application?
Well,
that's
that's
the
microservice.
You
know
so
they've.
I
think
those
companies
have
been
reusing.
The
same
same
terminology
too
much
the
other
way
I've
heard
about
it
would
be.
E
E
E
E
E
B
E
So
today
we
have
a
a
bunch
of
m,
ms
that
are
packaged
together
into
your
your
package,
of
that
you
get
and
get
to
open
and
stuff
like
that.
That's.
F
E
That's
the
the
description
today
that
we
have,
but
if
in
the
component
set
world
you
would
have
let's
say
for
christmas:
you
had
all
the
green
m,
ms
in
a
sub
package,
and
then
you
had
a
bunch
of
other
m
m's
and
you
opened
up
your
big
package.
You'd.
Have
you
find
a
bunch
of
m
ms
plus
a
green,
a
package
containing
only
green
ones?
E
Now
you
go
up
one
more
level
and
you
roll
it
up
to
the
release
which
we
don't
model
in.
That
would
either
be
a
box
or
you
know,
a
big
bag.
Yeah.
I
B
E
And
that's
where
I'm
going
to
break
out
the
grammar.
So
it's
easier
to
understand
the
relationships
and
at
that
level.
H
So
I've
got
a
couple
questions,
so
one
is,
are
component
sets
be
inside
of
component
sets.
H
This
this
gets
back
to
my
the
question
I
had
before,
which
I
didn't
ask
yet,
which
was
you
know
it
sounds
like
a
component
set,
is,
is
something
that
wishes
it
were
an
application
but
isn't
willing
to
call
itself
an
application
because
of
whatever
organization
or
cultural
reasons
and
so
yeah.
What?
If
what?
If
we
just
said?
Okay,
we
already
have
this
concept
of
an
application
and
we're
going
to
let
there
be
applications
inside
of
applications
inside
of
applications
and
then
the
next
time
somebody
comes
along
and
says:
oh,
we
need
another
level
of
abstraction.
E
Yeah
I've
thought
about
that,
and
that
is
that's
one.
We're
gonna
have
to
kick
around
and
look
at
if
we
wanna
to
do
it
that
way.
C
We
could
potentially
do
it
based
on
and
I
I
want
to
be
sure,
to
give
owen
some
time
to
talk
about
the
website
yeah,
but
we
could
potentially
think
about
it
in
terms
of
domains.
We
could
create
a
domain
set,
so
anything
that
you
want
to
package
together
could
be
everything
in
a
particular
domain.
H
He
asked
earlier
about
the
metadata
stuff
and
whether
we
should
duplicate
storing
that
inside
of
ortelius
or
whether
we
should
just
you
know,
connect
to
other
places
that
actually
have
that
information
available.
E
Connect
we
we
have
to
store
the
pointer
to
where
the
other
information
is
so
for
a
deeper
dive.
For
example,
a
if
we
have
a
component,
that's
based
on
a
docker
container.
We
point
we
have
a
pointer
to
the
docker
registry
and
the
sha
as
well
as
the
tag.
Now
we
don't
store
the
layers.
We
don't
store
any
information
about
the
layers
in
the
container
and
we
don't
store
anything
about
the
what's
in
the
container,
such
as,
let's
say,
if
it's
a
node.js
what
node.js
packages
are
installed.
E
E
Yeah,
the
only
thing
the
only
thing
I
on
that
would
be.
E
H
C
E
Right
but
how
high
up
do
you
go.
C
Well,
that's
what
I'm
saying
you'd
have
to
be
able
to
restrict
it.
So
like
we'll
we'll
we're
we're
going
too
deep
on
this.
Let's
let
before
we
we
need
to
talk
about
the
website.
I
C
Hey
owen,
you
want
to
chat
for
a
minute
he's
still
there
he's
just
on
mute.
C
K
So
yeah
so
very
quickly
on
the
website.
I
haven't
got
a
massive
update
since
the
last
time
we
spoke,
the
fever,
I
had
ended
up
running
an
extra
week
or
so,
and
then
I
had
the
farm
I
had
to
deal
with.
But
the
news
from
my
side
is
a
production
launch
of
the
company
I'm
currently
working
with
has
been
delayed
down
to
march,
so
I
have
next
few
days
after
today
and
weekend
and
next
week
off.
So
I
will
have
an
update
in
the
next
couple
of
days,
which
I'll
share
on
discord.
K
K
Access,
so
I
will
post
on
the
github
issue
once
I'm
back
with
the
laptop
in
front
of
me,
so
sorry
about
delays
on
this.
Just
lots
of
life,
stuff
kind
of
coincided,
no
worries.
E
And
just
let
me
let
us
know
if
you
need
help
on
any
of
this.
K
We're
we're
here
to
help
out
yeah
absolutely
will
do.
As
I
said
it's
a
bit
unfortunate
because
it
is
there.
K
I
just
need
to
actually
get
back
now
in
front
of
something
to
share
the
links
and
share
the
data
so
yeah
once
it's
been
shared,
that's
a
point
when
we
can
then
begin
iterating
on
it
quite
a
bit,
but
at
the
very
least,
if
I
don't
get
back
the
end
of
week
as
I'm
expecting,
I
can
still
share
links
to
the
public-facing
versions
of
it
which
I've
got
on
my
domain
and
then
I
can
share
the
pipeline
in
over
the
weekend.
Once
I'm
definitely
back.
E
Yeah
and
let
me
know
when
we
get
closer
or
you
know
if
you
need
a
new
repository
created
under
ortelius.
K
Yep
no
problem,
probably
we
can
probably
do
it
off
the
back
of
the
repository,
which
is
already
there,
which
is
the
initial
template
of
the
hugo
one,
which
is
what
I
forked
from
but
yeah
I'll
catch
up
on
everything
this
weekend
and
see
where
I'm
at
and
reach
out
to
folk
sounds
good.
Thank
you.
So
much.
C
And
then
I
think
to
just
again
I
think
we
have
to
go
back.
It
sounds
like
we
really
should
just
focus
on
getting
the
components
sorted
out,
and
I
really
think
that
to
really
answer.
Like
christopher's
pro
question,
we
need
to
get
somebody
from
netflix
and
somebody
from
intuit
on
the
call,
and
I
will
make
it
a
goal
to
get
that
done.
It
might
not
happen
until
january,
but
I.
C
It
from
both
of
those
both
that
the
this
from
the
spinnaker
and
the
argo
side,
what
they're
trying
to
solve.
So
I
will
I've
already
reached
out
and
I
will
make
that
happen.
E
Yeah,
if
we
have
to
understand
the
use
case
better.