►
From YouTube: DevOps 101: A History of Package Management
Description
Speaker: Kat Cosgrove
Sometimes, it feels like DevOps has been around forever. Sometimes it feels like it's brand new. The truth is somewhere in the middle -- we've had pieces of it for a very long time, and the term itself has existed for around a decade, but the exact way we implement it has changed quite a bit over the years. Continuous Integration has been around since the 90s, but it isn't the same today as it was when Grady Booch first coined the term in 1991. Package management has changed a lot, too, and having context for the history of it not only helps us to see how far we've come, but makes it easier for new people to adapt. Join me on a journey through time, from package management as it began to what it looks like today.
A
So,
thank
you
all
for
joining
me.
This
is
going
to
be
devops
101,
a
history
of
package
management,
because
this
is
a
101,
I'm
not
going
to
go
into.
Like
super
deep
technical
detail
on
any
one
particular
subject,
I
don't
find
that
that's
typically
helpful
for
a
101.
If
you
have
super
deep
technical
questions,
I'll
be
happy
to
try
to
answer
them,
but
if
it
goes
like
too
far
into
the
weeds,
I
will
say
this
is
a
conversation
we
should
have
privately.
Please
email
me
because
I
don't.
A
I
don't
want
to
create
confusion
for
any
newbies
that
are
listening.
So
here
we
go
first
I'll
introduce
myself.
My
name
is
kat
cosgrove
that
cat
is
espresso.
You
will
probably
hear
her
at
some
point.
She
really
really
does
not
like
being
left
out
of
the
action,
and
I
am
a
developer
advocate
at
jfrog
before
that.
I
was
an
engineer
also
at
jfrog
on
the
iot
team.
A
However,
I
didn't
get
where
I
am
through,
like
strictly
traditional
means.
I
was
a
freelance
web
developer
for
a
while,
but
I
have
also
worked
as
a
bartender
and
a
waitress
and
teacher
and
the
resident
horror
expert
at
an
independent
video
store.
So
if
you
would
like
to
ask
me
questions
about
horror
movies,
that's
fine
too.
A
It
let
me
see
the
tech
industry
from
a
lot
of
different
angles
and
have
a
lot
of
different
struggles
that
it
turns
out
are
fairly
universal,
regardless
of
where
you
came
from,
like
the
fact
that
somebody
has
a
computer
science
degree
isn't
necessarily
going
to
prevent
them
from
having
some
of
the
same
problems
I
had,
and
we
aren't
really
addressing
these
problems,
so
I
I
would
like
to
to
address
that
problem.
One
of
the
biggest
issues,
I
think,
is
not
giving
new
people
context
and
history
for
the
tools
we
use.
A
We
don't
understand
why
we
aren't.
We
aren't
ever
taught
or
explicitly
told
why
this
thing
is
useful
and,
like
what
pain
point
caused
us
to
be
using
this
tool
now,
so
you
just
you,
you
can
just
use
it.
You
don't
need
that
to
be
functional,
but
it
it
helps
and
it
makes
it
easier
to
adopt
those
tools.
So
that's
the
point
of
this
series
of
talks
to
try
to
eliminate
that.
A
If
you
would
like
to
get
a
hold
of
me
later,
you
can
do
that.
You
can
find
me
on
twitter
at
dixie3flatline,
and
you
can
also
email
me
at
cat
c
at
jfrog.com,
though
fair
warning,
I'm
not
really
great
at
responding
to
my
emails,
so
I
do
respond
eventually.
It
just
takes
me
longer
than
it
takes
me
to
respond
to
like
a
twitter
dm.
If
you
have
questions
while
I'm
talking,
please
put
them
in
the
q
a
box
not
in
the
chat
box.
A
A
So
when
you're
new
to
an
industry
and
you're
encountering
a
lot
of
new
concepts,
it
can
make
it
really
difficult
to
get
your
feet
underneath
you
it's
it's
an
unfamiliar
landscape.
We
have
quite
a
lot
of
jargon
and
even
though
devops
has
been
a
thing
since
I
think
most
people
credit
the
beginning
of
devops
to
the
first
devops
days
in
ghent,
which
was
11
years
ago,
people
still
disagree
about
what
devops
means
is
it
a
methodology?
Is
it
a
tool
set?
Is
it
a
culture?
A
Is
it
just
a
buzzword
and
a
lot
of
the
documentation
out?
There
assumes
that
you
already
have
some
additional
context
and
experience
or
you're
already
proficient
in
some
related
tooling,
like
a
precursor
to
the
thing
that
you're
trying
to
use-
and
the
amount
of
jargon
we
have
is
is
is
outrageous.
It's
there's
abbreviations
and
abstractions
abound,
and
sometimes
it's
hard
to
define
a
term
satisfactorily
without
using
two
more
pieces
of
jargon
that
you
also
have
to
define
and
we're
missing
all
of
this
historical
context.
A
So
I
want
to
give
you
some
of
that
context
and
on
the
subject
of
jargon,
if
I
use
a
word
that
you're
not
familiar
with,
please
also
put
that
in
the
q
a
box,
and
I
will
define
it
for
you
or
at
least
define
it
as
I
meant
it,
because
some
of
this
stuff
is
still
kind
of
in
flux.
A
bit
I'm
going
to
start
by
defining
devops.
A
As
what
I
mean
in
this
talk,
devops
is
the
term
for
the
union
of
the
development
team
and
the
I.t
operations
team,
through
the
use
of
a
specific
set
of
practices
and
tool
chains.
So,
rather
than
having
the
development
and
operations
team
handle
their
own
specific
responsibilities
independently
of
one
another,
the
two
teams
should
work
together.
A
This
is
both
a
cultural
change
and
a
technology
change
with
the
ultimate
goal
of
drastically
reducing
the
amount
of
time
it
takes.
The
team
to
deliver
software
sounds
good
right,
so
the
result
is
more
frequent.
Software
deployments
deploying
bad
updates
less
frequently,
which
is
really
what
we
want
and
being
able
to
recover
from
those
bad
updates
faster,
because,
no
matter
how
good
you
are
and
no
matter
how
good
your
your
pipeline
is,
you
are
absolutely
going
to
deploy
a
bad
update
eventually,
except
that
now
it's
it's
just
it's
going
to
happen.
A
So
in
order
for
devops
to
work,
we
need
both
tools
and
a
culture
shift.
This
is
an
established
fact,
but
it's
still
the
topic
of
a
lot
of
conference
talks
about
devops,
while
more
companies
move
away
from
like
older
methodologies
and
over
to
hours,
I'm
not
going
to
go
into
this
a
ton
because
more
qualified
people
than
me
give
outstanding
talks
on
this
subject,
and
you
should
go
like
listen
to
them,
but
it's
it's
worth
noting
that
it's
kind
of
still
in
flux
a
bit.
A
Ultimately,
the
goal
is
to
merge
with
your
source
repository
and
pull
from
main
often
like
multiple
times.
A
day
you
should
be
making
much
smaller
changes
every
single
time.
Building
unit
tests
need
to
run
with
every
single
commit
and
that
whole
thing
has
to
be
automated,
and
there
are.
There
are
a
bunch
of
tools
that
make
this
automation
work,
but,
ultimately
developers
don't
exist
in
a
silo
anymore
right.
A
The
point
I'm
trying
to
make
here
is
that
an
understanding
of
devops
practices
and
all
of
the
tooling
that
goes
with
it
from
like
ci
servers
to
package
managers
is
no
longer
the
exclusive
domain
of
people
with
the
word
devops
in
their
job
title.
It
is
everyone
who
touches
either
side
of
the
equation,
or
else
it
doesn't
work.
So
it's
not
just
devops
engineers
or
sres,
or
release
managers.
It's
everywhere.
A
A
lot
of
the
things
we
think
of
as
being
devops
or
being
cloud
native
or
whatever
is
pretty
new
in
the
grand
scheme
of
things,
for
instance,
the
first
commercially
successful
serverless
platform
was
aws
lambda
in
2014,
and
now
there's
more
of
them
than
you
can
shake
a
stick
at
it's.
It's
a
lot
at
this
point,
plus
some
serverless
databases
just
like
for
fun
sprinkle,
some
on
there,
it's
kind
of
mind-boggling.
A
When
you
look
at
like
the
the
timeline
of
how
we
got
where
we
are
now,
the
technology
evolves
very,
very
fast,
and
we
are
just
throwing
like
layers
and
layers
of
abstraction
between
us
and
our
code
and,
as
a
result,
more
and
more
teams
across
an
organization
have
to
be
familiar
with
these
things.
It
happens
so
fast.
A
Some
of
these
things
that
feel
really
new,
though,
are
actually
super
old.
Like
continuous
integration,
for
example,
here's
a
question
in
the
q
a
how
is
it
different
than
continuous
full
stack
development?
The
two
are
not
full
stack
development
is
it
means
building
both
like
the
front
and
back
end
of
an
application.
A
If
you,
if
you
call
yourself
a
full
stack
developer,
you're
proficient
in
the
front
end
and
the
back
end
of
the
development
stack
continuous,
just
as
a
modifier,
there
just
probably
means
that
they're
engaging
in
continuous
integration
practices
as
a
full
stack
developer
would
be
my
guess.
I've
I've
honestly
never
heard
the
that
phrase.
Continuous
full
stack
development
as
a
whole.
That's
my
guess
at
what
it
means,
though
there
we
go
so
back
to
the
history
lesson
continuous
integration.
A
It
was
first
proposed
way
longer
ago
than
a
lot
of
people
realize
in
1991
by
a
man
named
grady
booch
in
his
book,
object-oriented
analysis
and
design
with
applications.
So
it's
old,
the
booch
method
advocated
for
more
frequent
uses
of
like
classes
and
objects
in
programming
which
simplified
design
and
then
in
1997.
A
We
got
extreme
programming
as
a
thing
it
built
on
the
booch
method.
By
advocating
for
now
releasing
multiple
times
a
day.
Booch
didn't
recommend
that
I
know
the
name
sounds
like
really
really
ridiculous.
Now
it
kind
of
gives
you
like
a
90s
x
game
kind
of
like
edge
lord
vibe,
but
that's
not
what
it
meant
it
didn't.
It
didn't
actually
mean
to
sound
like
edgy
product
marketing
from
the
90s.
A
What
it
meant
is
taking
concepts
and
paradigms
that
were
already
accepted
parts
of
writing
and
releasing
software
and
then
taking
them
way
further
to
the
extreme.
So,
instead
of
just
code
review,
do
it
constantly
by
pair
programming
unit
and
acceptance
tests
became
a
thing
and
ultimately,
what
we
wanted
here
was
to
make
it
easier
to
write,
clearer,
higher
quality
code
and
get
it
to
the
users
faster.
A
A
Let's
talk
about
what
a
package
manager
is
first
from
wikipedia
a
package
manager
or
package
management
system
is
a
collection
of
software
tools
that
automates
the
process
of
installing
upgrading
configuring
and
removing
computer
programs
for
a
computer's
operating
system
in
a
consistent
manner.
The
consistency
is
what's
key
here,
so
if
you're,
a
developer,
you've
probably
used.
One
of
these,
like
almost
certainly
you've,
used
one
of
these,
for
instance,
if
you're
writing
node.js
you're,
probably
using
npm.
A
That's
a
package
manager
if
you're
using
linux
and
you've
ever
installed,
something
with
apt-get.
That's
a
package
manager.
So
in
plain
english,
a
package
manager
is
what
handles
the
heavy
lifting
involved
in
installing
something,
including
that
thing's
dependencies
also
important
validating
that
it
is
what
it
says.
It
is
to
an
extent,
usually
by
validating
checksums,
keeping
track
of
versions,
upgrades
and
handling
the
uninstall
for
you.
If
you
want
to
install
it.
This
is
accomplished
in
part
through
the
use
of
a
very
large
amount
of
metadata,
which
is
just
defining
characteristics
about
a
particular
package.
A
Alongside
the
actual
application,
binary
modern
package
managers
are
why
you
can
reliably
run
like
I
don't
know:
pip
install
django
at
version
1.3.3
and
be
pretty
sure
that
you
are
getting
version
1.3.3
of
django
or
you
can
just
run
pip
install
django
and
it'll.
Give
you
whatever
is
the
most
recent
stable
version.
A
A
So
debian
introduced
the
first
one
with
dpkg.
Some
some
of
you
will
say
debian.
I've
heard
that
debian
is
absolutely
correct,
because
if
who
the
distribution
was
named
after,
but
I
you
know,
I
say
it
both
ways.
It
doesn't
matter
so
that
was
introduced
in
1994
and
then
red
hat's
rpm
was
introduced
in
1997..
A
So
continuous
integration
predates
package
managers
by
several
years
and
both
of
these
are
actually
still
in
use
today.
They
they
are
much
improved
since
then,
but
they
are
still
both
in
use
before
those
and
until
package
management
really
took
off.
We
had
to
do
a
lot
of
things
manually
and
we
had
way
less
information
about
the
things
we
were
installing
it
was
slow.
It
was
tedious,
it
was
irritating
and
it
was
very
much
prone
to
failure.
A
So
here's
how
it
would
work.
You
would
get
a
compressed
directory,
usually
in
the
form
of
like
a
tar
file,
decompress
it
and
you
would
find
a
readme
with
some
instructions
to
follow.
Some
kind
of
config
script
would
be
there,
which
would
when
you
would
run
it
would
tell
your
c
compiler
what
to
do
where
new
binaries
should
go,
what
application
dependencies
to
look
for
and
where
and
on
and
on
and
on.
A
A
A
It
was
rarely
actually
easy
to
do
things
that
way,
though,
and
updates
were
just
as
involved,
if
not
more
so.
Obviously,
this
is
a
time-consuming
process
right.
Imagine
having
to
do
that
for
every
piece
of
software
on
your
computer
and
every
piece
of
software
required
to
run
all
of
that
software
dependencies
were
not
installed
automatically
like
they
often
are
now,
and
a
lot
of
things
could
go
wrong
on
your
journey
from
downloading
a
tar
file
to
actually
getting
the
thing
installed.
A
A
So,
understandably,
everyone
thought
this
was
exhausting,
like
I
think
it's
exhausting
when
I
still
have
to
do
this
on
like
an
iot
device,
and
so
the
release
of
the
first
package
managers
for
linux
was
a
really
big
deal.
It
was
like
capital
a
big
deal.
It
immediately
changed
computing
and
application
development
for
the
better
forever.
A
So
like
it
was
like
a
really
pretty
sunrise
right,
the
day
was
bright,
love
it,
but
those
early
package
managers
pretty
much
just
gave
you
install
update
and
uninstall.
They
were
not
that
smart
over
time.
However,
package
managers
have
bundled
all
of
that
work
and
more
into
simpler
and
simpler
commands.
A
This
introduced
a
whole
new
problem,
though,
since
applications
are
easier
to
install
and
update
and
manage,
we
start
building
more
complex
applications
and
with
continuous
integration
becoming
popular
in
the
90s,
we
start
releasing
more
often
too
polyglot
applications,
meaning
software
made
up
of
components.
Written
in
multiple
languages
become
more
and
more
common,
forcing
us
to
deal
with
multiple
package
managers
for
one
application,
organizing
and
keeping
track
of
all
these
packages,
kind
of
becomes
a
lot
of
labor.
A
We've
replaced
one
problem
with
another:
we
start
to
care
about
security
more
too,
with
a
lot
of
dependencies
being
pulled
from
public
repositories.
This
is
where
a
binary
repository
manager
enters
the
playing
field.
Now
we
have
another
thing
we
have
to
deal
with,
so
a
binary
repository
manager
is
there
to
manage
all
of
those
binaries.
We
now
have
into
a
system
of
repositories,
some
of
them
support
just
one
or
two
package
types
for
very
specialized
applications,
but
the
one
I'm
going
to
talk
about
supports
27.
A
there.
This
is
not
the
same
thing
as
source
control
to
be
clear,
just
to
avoid
confusion.
There,
source
control
is
where
your
code
lives,
but
this
is
more
like
an
extension
of
it.
So
while
your
code
might
live
in
a
repository
on
github
or
bitbucket,
or
wherever
the
result
of
that
code
being
built
or
compiled,
your
your
artifacts,
those
should
live
in
a
binary
repository
manager
like
artifactory,
so
for
devops
to
really
work.
This
is
an
important
part
of
the
equation.
A
It
sounds
miserable
right
I
mean
do.
I
have
some
abandoned
side
projects
that
aren't
versioned
with
git
that
are
just
hanging
out
in
like
projects
2019
for
real.
This
time
experimenting
yes,
but
it's
a
side
project,
not
production
code,
right,
it's!
Okay!
If
I
abandon
my
stuff,
like
that,
it's
not
okay!
To
do
that!
For
your
code,
it's
the
same
for
binaries
and
a
binary
repository
manager,
especially
on
teams
that
have
multiple
languages
in
one
house
that
it
could.
A
So
artifactory
in
particular,
works
by
breaking
up
the
repositories
into
three
different
classes.
We
have
local,
remote
and
virtual
repositories.
Local
repositories
are
what
they
sound
like.
These
are
repositories
for
your
packages,
resulting
from
local
code
that
exists
on
your
machine.
Your
stuff,
remote
repositories,
are
also
fairly
self-explanatory.
They
contain
remote,
build
artifacts
like
your
project's
dependencies.
A
This
one
functions
kind
of
like
a
cache
so
that
after
the
first
download,
your
project
pulls
its
dependencies
from
the
associated
remote
repository
rather
than
from
the
actual
remote
source
like
npm
or
pi
pi,
if
you're
using
docker.
This
is
particularly
helpful
since
it
limits
the
number
of
polls
you
need
to
make
against
docker
hub,
and
you
won't
hit
the
cap
they
set
as
quickly.
A
If
you
are
using
jfrog
artifactory
sas
you,
you
are
actually
exempt
from
docker's
rate
limits,
which
is
pretty
cool.
Virtual
repositories
are
a
little
bit
weirder.
They
create
a
kind
of
like
envelope
around
the
local
and
remote
repositories
for
your
projects
and
tools
like
this.
Allow
you
to
keep
your
binaries
dependencies
and
any
build
artifacts
well
organized,
regardless
of
the
number
of
languages
involved.
A
A
A
I'm
going
to
tell
you
about
an
exploit
that
most
of
you
are
probably
familiar
with,
but
you
might
not
be
aware
of
exactly
what
happened
and
how
bad
it
was.
So
this
is
the
story
of
the
equifax
breach
in
september
of
2017
equifax
announced
that
a
serious
breach
had
occurred
between
may
and
july
of
that
year.
A
A
The
hackers
that
exploited
cve,
2017
5638
a
vulnerability
in
a
very
commonly
used
web
framework,
called
apache
struts
talking
about
how
that
vulnerability
actually
worked,
is
is
way
out
of
scope
for
this
webinar,
but
the
gist
is
that
it
would
allow
an
attacker
to
remotely
execute
commands
with
whatever
authority
the
web
server
itself
had,
and
this
was
not
a
vulnerability
that
flew
under
the
radar
at
all.
Even
before
the
breach,
this
cve
was
big
news
in
the
security
world.
A
It
was
classed
as
a
critical
vulnerability,
something
that
absolutely
had
to
be
taken
seriously
and
corrected
immediately.
Really
it
was.
It
was
a
big
deal.
They
should
have
known
this.
Vulnerability
was
disclosed
and
published
in
march
months
before
equifax
was
breached
once
they
discovered
the
breach.
It
took
them
two
full
months
to
find
and
upgrade
all
usages
of
the
vulnerable
version
of
struts
and
hackers
had
spent
134
days
undetected
in
equifax's
systems,
lawsuits
were
filed,
resulting
in
a
575
million
dollar
settlement
with
ftc,
as
well
as
payments
and
credit
monitoring
for
those
affected.
A
Unfortunately,
the
number
of
people
affected
by
the
breach
was
so
large
that,
after
attorney's
fees,
most
people
got
nothing
but
a
lifetime
of
being
paranoid
about
their
credit.
This
was
caused
by
a
lack
of
vulnerability
detection.
It
was
also
caused
by
a
lack
of
an
ability
to
update
quickly
and
just
generally,
not
knowing
what
was
going
on
inside
of
their
builds.
They
didn't
know
what
these
packages
had
in
them.
A
A
So
as
complexity
increases,
which
is
what
package
managers
gave
us,
the
security
concerns
get
larger
and
larger,
and
we
we
need
tools
to
keep
all
of
these
different
packages
organized
so
that
we
know
what's
going
on.
We
have
to
know
what's
going
on
in
these
tools
or
we're
exposing
ourselves
to
attack,
and
we
don't
want
that
right.
A
They
go
further
than
just
automating
the
steps
we
used
to
have
to
take
manually
with
config
scripts
and
make
files,
by
also
now
installing
your
dependencies
for
you
and
managing
a
bunch
of
extra
metadata
that
we
didn't
have
clear
access
to
before.
Eventually,
this
revolution
caused
a
rapid
increase
in
application
complexity.
A
The
invention
of
the
package
manager
is
possibly
one
of
the
most
important
innovations
in
computing.
In
decades
and
a
binary
repository
manager
is
one
of
the
most
important
parts
of
a
functional
devops
pipeline.
We
have
come
a
very,
very
long
way
from
doing
all
of
this
manually
and
not
having
ci
to
now.
A
It's
astonishing
how
fast
we
can
do
things
that
used
to
be
so
tedious,
and
I
I
think
we
take
that
for
granted,
sometimes
how
how
quickly
and
easily
we
can
accomplish
some
of
these
things.
Now
you
know
it's.
It
may
not
actually
be
easy,
but
compared
to
the
way
we
were
doing
things
20
and
30
years
ago.
It
it
is,
or
at
least
it's
less
difficult
to
pick
it
up.
It's
less
difficult
to
figure
out
what
went
wrong
when
something
failed.
A
Just
because
we
have
more
information
and
package
managers
is
ultimately
what
gave
us
more
information.
Ci
may
have
made
it
easier
to
automate
all
of
these
things,
but
where
would
we
be
with
figuring
out
what's
wrong
when
something
goes
wrong?
Because
something
will
it's
not
an
if
if
we
didn't
have
package
managers
and
all
the
metadata
that
comes
with
them,
if
you
want
more
devops
swamp
up
is
coming
soon
and
the
conference
days
are
free
like
free
free,
not
free,
isn't
beer
free,
isn't
actually
free?
A
We
are
running
it
twice,
may
25th
to
the
27th
for
the
americas
and
june
1st
through
3rd
for
europe
there's
also
a
full
day
of
training
available
as
an
add-on
for
your
ticket
from
intermediate
to
advanced
courses.
I
will
be
speaking
there
and
so
will
a
bunch
of
other
really
smart
rad
people
who
are
both
smarter
and
radder
than
me
so
check
it
out.
A
I
hope
I've
helped.
You
understand
what
a
package
manager
is
and
how
we
got
here
and
what
the
natural
extension
from
there
is
if
you're
still
confused,
that
is
okay.
This
is
kind
of
a
big
thing
and,
like
I
said
in
the
beginning,
some
of
it
is
still
in
flux.
Devops
changes
very
very,
very
rapidly,
and
even
the
definitions
of
some
of
these
things
have
changed.
A
little
bit
feel
free
to
get
in
touch
with
me
on
twitter
at
dixie3flatline.
A
Factory
jargon:
artifactory
is
a
universal
binary,
repository
manager,
so
it's
a
tool
that
allows
you
to
deal
with
all
of
the
different
package
types
we
have
now.
So
it
lets
you
organize
everything
into
one
tool,
rather
than
going
out
to
like
five
or
six
different
tools.
If
you're
building
an
application
out
of
multiple
languages.
A
A
A
What's
an
artifact,
an
artifact
is
anything
that
is
the
result
of
building
your
application.
So
it
could
be
your
actual.
Just
your
compiled
binary
of
your
application.
It
could
be
a
docker
image.
It
could
be
metadata
about
your
build,
but
broadly
it
means
any
anything
that
is
the
result
of
building
your
application
up
to
and
including
the
actual
compiled
binary.
A
A
B
A
A
It
depends
on
what
you're
doing
in
devops.
You
know.
So
it's
such
a
new
thing
like
I
know
we
say.
Oh
it's
been
around
for
11
years,
but
in
that's.
That's
actually
not
that
long
in
the
like
grand
scheme
of
things
right.
So
it
depends
on
what
you
mean
by
a
devops
role.
I
don't
to
some
extent
you
need
to
be
able
to
like
write
and
understand
code,
but
I
don't
think
you
need
to
have
spent
like
multiple
years
working
as
a
software
engineer.
A
A
A
Similar
question:
is
it
easier
to
move
up
from
software
development
to
devops,
rather
than
it
operations
to
devops?
I
don't
think
so.
So,
like
somebody
who
works
as
a
devops
engineer
is
ideally
going
to
be,
you
know,
half
dev,
half
ops,
so
no.
I
think
they
will
have
the
same
level
of
like
ease
or
difficulty
in
moving
over
to
a
devops
type
of
role.
I
I
wouldn't
consider
one
of
them
to
be
more
valuable
than
the
other.
That's
that's
the
whole
thing
about
devops.
A
It's
supposed
to
be
a
collaborative
culture,
so
like
dev,
is
not
better
than
ops.
Ops
is
not
better
than
dev.
We
have
to
work
together.
We
have
to
be
like
vaguely
familiar
with
what
the
other
side
is
doing.
So
no,
I
think
I
think,
you're
in
a
good
position,
regardless
of
which
one
you're
coming
from.
A
Have
you
considered
the
implications
of
managing
machine
learning
assets
as
a
part
of
this
suite
of
problems?
Personally,
not
not
specifically,
so
I'm
not
a
machine
learning
expert.
I
have
like
a
very,
very
small
amount
of
experience
with
machine
learning
and,
frankly,
I'm
not
super
qualified
to
answer
whether
or
not
machine
learning
has
implications
that
would
make
this
problematic
in
some
way.
I'm
sorry,
but
if
you
email
me
or
dm
me
on
twitter,
my
contact
info
is
on
the
slide.