►
From YouTube: Community Stream #20: Greg Ferro
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).
A
A
Still
easy
as
ever
and
as
it's
ever
been
new
new
problems,
this
is
so
we
use
OBS
to
do
the
stream
and
for
people
who
are
watching
and
we
we
do
the
actual
conference
on
zoom
and
then
we
we
use
OBS
to
capture
and
stream
it
out
to
twitch
and
we
actually
record
on
both
twitch
and
on
zoom
and
every
single
time.
We
something
goes
wrong
with
one
of
those
components.
A
We're
gonna
have
to
come
up
with
a
better
solution
so
that
we
don't
have
to
fight
this
in
the
future,
but
usually
the
Zoom
audio
comes
out
pretty
nice
and
we'll,
if
that's
the
better
of
the
two,
that's
the
recording
that
we'll
put
up
later
today
on
YouTube.
So
with
that
disclaimer
out
of
the
way
welcome
to
our
stream.
This
is
the
NRE
live
stream
network,
reliability,
engineering,
I,
am
your
host
cloud
toad,
it
is
Xcover
7th
2019
and
we
have
on
the
show
with
us
today
are,
of
course,
our
co-host
Matt
awesome.
C
C
C
A
B
B
E
C
Was
a
problem
so
but
that's
a
start-up
like
you
start
off
going
in
every
direction
and
then,
as
time
goes
by,
you
start
to
focus
down
on
the
things
that
matter
and
the
things
that
work
so
I
think
you
know
your
project
would
be
the
same
you're
starting
to
work
out
what
you
start
off.
Thinking,
I'm
gonna
go
down
this
path
and
then
you
start
to
go.
Hang
on.
That's
not
what
we
need
to
go
down
this
path
that
so
what
you're
saying
darica.
B
It's
kind
of
funny
like
like
a
lot
of
the
folks
that
have
shown
interest.
Actually
we
we
were
thinking,
like
you
know,
one
of
the
biggest
things
that
people
would
get
driven
to
is
like
the
the
NRA
labs
curriculum
is
like
Network
automation,
learning
which
that's
true
to
an
extent,
but
we've
actually
had
quite
a
few
people
get
interested
in,
like
everything
other
than
that,
like
yeah.
C
So
I've
been
reading
up
on
this
Elizabeth
I.
Think
there's
two
things
that
we're
really
good
at
one
is
that
it
and
it's
in
the
hindbrain
it's
in
the
it's
in
the
lizard
brain
one
way,
you're
on
the
veldt
looking
across
and
all
of
a
sudden.
You
see
a
movement,
and
you
know
immediately
that
it's
a
line
without
actually
thinking
about
it
and
you
know
to
run
the
hell
away
right,
because
that
lion
is
dangerous
to
you
and.
E
C
Ability
to
sense
threats
at
a
distance
unconsciously
is
something
that's
there,
but
there's
a
there's
another
part
of
the
brain
that
I
like
to
think
of
which
is
the
forebrain,
which
is
the
science
brain
or
the
technology
brain,
and
that
can't
do
fast
pattern
recognition.
It
can't
just
look
at
something
and
go:
oh
yeah,
yeah,
it's
got
to
sit
there
and
think
about
it.
C
You've
got
to
you
know,
get
a
hammer
out
forge
the
pathways
through
the
neurons
until
you
get
it
sorted
out
and
I
think
there's
two
different
patterns
of
thinking
going
on
in
the
problem
with
multitasking.
Is
you
can
do
this
fast
pattern,
recognition
and
convince
yourself
that
you
can
multitask
and
then
all
of
a
sudden
you
go
like
actually
I
didn't
read:
I
just
spent
read
50
pages,
and
none
of
it
went
in
and
I've
got
to
go.
E
C
Think
there's
two
things
going
on.
You
know
you
can
fool
yourself
that
you
can
multitask
and
I
think
if
I
was
a
manager,
you
know
doing
something
really
easy
like
management.
Where
really
my
goal
is
to
do
fast
pattern.
Recognition
have
lots
of
direct
reports.
You
know
review
spreadsheets
and
look
at
pretty
pictures
all
day.
That's
not
so
hard!
A
No,
it
doesn't,
and
that's
one
of
the
things
with
with
technology
in
general.
Is
these
systems
are,
are
super,
complicated
and
and
there's
multiple
components
and
the
components
themselves
are,
can
sometimes
become
complicated,
so
like
just
you're
thinking
about
how
each
subsystem
works
so
that
you
can
get
an
idea
of
this
end-to-end
behavior
through
the
whole
system.
When
all
the
components
are
you
know,
dancing
together
to
make
make
the
effect
and
and
if
you're,
just
learning
how
to
how
to
understand
the
system
and
understand
how
it
works.
C
Any
one
of
those
sub
components
can
break
the
entire
system.
That's,
like
a
you
know,
a
direct
link,
jer
box.
You
know
all
the
gears
plug
into
each
other
you're
not
going
to
get
power
to
the
wheels
unless
all
the
gears
are
working
exactly
as
promised
and
again
this
comes
down
to
the
difference
between
you
know,
but
you
I've
got
a
big
bee
in
my
bonnet
this
week
about
the
difference
between
business
and
technology,
because
everybody
says
technologists
need
to
be
businesspeople.
You
need
to
speak
to
the
business
I'm
going
like
no
I'm,
a
technologist.
E
C
Do
and
that's
why
I'm
an
engineer,
it's
true
like
one
of
the
interesting
things
about
DevOps
and
this
plays
into
the
whole
automation
right,
DevOps
thing.
The
thing
about
DevOps.
Is
that
what
we
effectively
did
was
we
went
to
the
engineers
and
said
you
have
to
know
more
about
the
business.
You
have
to
take
more
responsibility
for
the
business.
You
have
to
take
responsibility
for
your
tool,
change.
You
have
to
take
responsibility
for
your
workflow
and
you
have
to
make
it
fit
the
business.
C
So
what
you've
just
done
is
told
an
engineer
that
you
need
to
understand
the
business,
and
so
the
engineers
go
off
and
learn
business,
and
now,
all
of
a
sudden,
you
don't
need
managers,
ok,
because
you're
making
your
own
decisions,
you
know
what
the
business
wants.
You
don't
need
a
project
manager,
you
don't
need
a
scrum
manager,
you
don't
need
an
agile
manager,
you
don't
need
a
business
manager
except
someone
to
interface
the
human
resources
and
to
do
the
budgets
every
quarter
and
then
you're
done
right.
A
A
The
we'll
call
it
the
platform
ranked
in
me:
it's
not
just
the
network,
it's
everything
right
all
those
systems
together,
we
buy
all
the
individual
components
and
what
we
learned
is
that
I'm
having
them
strictly
siloed
and
depending
entirely
upon
the
vendor,
to
to
do
the
integration
or
to
you,
know,
to
do
the
design
work
or
to
do
the
troubleshooting
within
the
you
know.
Ultimately,
that's
where
you
escalate
to
in
a
lot
of
places
is
a
really
terrible
idea.
You
end
up
with
a
system.
That's
almost
never
up.
It's
almost
always
has
a
problem
right.
A
C
I
made
this
therefore
I'm
responsible
for
it,
but
the
great
part
about
working
for
normal
companies
with
managers.
It's
not
my
problem,
I
just
do
what
I'm
told
and
then
walk
away
right,
loop,
it
out,
and
then
somebody
else's
problem
right
and
DevOps
is,
and
that's
that's
literally,
assuming
that
your
staff
are
incompetent
right.
The
only
reason
we
do
it
that
way
is
because
when
we
used
to
work
on
a
factory
floor
200
years
ago
and
they
invented
factory
production,
the
point
was:
are
the
people
who
are
coming
into
the
factory
were
not
very
skilled.
C
We're
required
to
understand
the
business
creatively
find
solutions,
work
in
a
team,
communicate,
sideways
up
down,
understand
the
market,
that's
around
us
and
what
we're
seeing
and
who's
doing
what
and
we
know
blah
blah
blah
as
well
as
take
responsibility
for
all
of
that.
Well,
all
of
a
sudden,
your
engineering
changes
you're,
not
you're,
starting
to
be
used
more
of
that
fast
pattern-recognition
stuff,
and
yet
you've
still
got
to
focus
on
things.
That's
where
the
multitasking
comes
unstuck.
C
B
Is
the
desired
outcome
for
like
if
you,
if
you
do
look
at
some
of
the
inspirations
behind
DevOps,
like
the
Toyota
kata
model,
and
things
like
that,
like?
Obviously,
if
you
take
that
crazy,
literally,
like
you're,
not
gonna,
have
a
good
time
because
humans
to
your
point,
humans
are
not
factory
components
like
there's,
there's,
there's,
definitely
there's.
C
If
that
is
a
chance,
but
the
thing
is
that
for
the
last
for
most
of
my
career,
that
wasn't
something
that
was
my
responsibility.
I
wasn't
encouraged
to
understand.
I
was
just
told
to
do
what
I
was
told.
I
would
have
managers
who
would
come
to
me
with
a
piece
of
paper
and
a
project
and
a
scope
of
works,
and
my
job
was
to
do
that.
So
I
was
not
allowed
to
be
creative
or
to
participate
in
the
business
or
to
understand
the
purpose
behind
this.
That
happened.
C
You
know
so
far
upstream
in
the
sewage
plant
that,
by
the
time
it
got
to
me,
there
was
no
way
I
could
understand
what
I
was
trying
to
achieve
right
and
I
still
believe
that
a
lot
of
this
net
ops,
DevOps
automation,
stuff,
is
comes
in
two
parts,
one.
First
of
all,
if
you're
automating,
you
have
to
understand
the
business
purpose
and
that's
new,
that's
very
new
and
that's
a
hard
skill
to
learn.
The
second
part
about
the
automation
is
that
we
have
to
learn
to
make
our
own
tools.
C
Ten
years
ago,
we
used
to
take
the
tools
the
vendor
gave
us,
which
was
usually
some
CLI
with
some
nominally
consistent.
Language
of
you
know
a
normally
consistent
interface,
and
you
know
that's
like
sending
every
carpenter
out
to
build
houses
with
a
hammer
and
a
chisel,
gradual
ations,
and
if
you
want
to
cut
a
piece
of
wood,
make
sure
you
use
a
chisel
because
that's
the
only
tool,
we're
gonna
give
you.
C
You
know
and
I
think
today
we're
seeing
a
much
different
sort
of
a
thing
where
we're
now
saying
with
automation
in
and
this
whole
DevOps
type
of
process
was
made-up
sorts
of
process.
I'm
now
allowed
to
invent
the
saw
or,
like
my
grandfather,
he
was
a
copter
when
he
was
alive
all
those
years
ago
and
he
used
to
make
like
physically
make
his
own
tools.
So
he
would
go
out
and
buy
chisels
and
then
get
them
custom-made
to
his
particular
shape
that
he
liked
to
use.
C
Or
if
you
were
a
woodsman,
two
or
three
hundred
years
ago,
out
chopping
down
trees.
It
was
actually
standard
for
them
to
actually
make
the
heads
to
exactly
the
way
that
they
wanted
to
make
them
there's
over.
Did
you
know,
there's
like
over
fifty
different
accents
and
the
only
reason
that
we
all
have
exactly
the
same
ax
head,
like
you
know,
there's
a
there's,
a
short
axe,
a
long
axe
right
and
there's
two
different
sizes
of
axe
head.
C
C
They're,
just
maybe
it
wasn't
even
the
right
axe,
and
so
so
much
of
what
I
see
about
automation
these
days
is
there's
a
flurry
of
invention
around.
What
is
the
right
tool?
Should
I
be
answerable?
Inc
should
I
be
terraforming,
should
I
be
using.
You
know
one
of
the
the
frameworks
which
framework
should
I
use.
Maybe
I
should
just
be
handwriting,
something
in
Python
whatever
it
is,
and
that
to
me
is
like
a
discovery
of
a
200
year
old
process
that
we
can
actually
have
any
tool.
We
want.
B
C
B
C
There's
two
sides
to
this:
just
because
you
can
make
your
own
tool
doesn't
mean
you're
going
to
make
the
best
tool.
Maybe
you
do
it's
a
bit
like
you
know.
The
thousand
monkeys
on
typewriters
will
eventually
produce
the
works
of
Shakespeare,
sometimes
the
axes
that
they
made
in
you
know
in
the
1600s
weren't
very
good
at
all,
but
that
might
be
because
they
didn't
actually
have
enough
metal
they
might
yeah.
Did
you
know
how
hard
it
was
to
put
to
our
mine,
steel
and
iron
back
in
the
16th
century?
C
You
just
just
very
difficult
to
get
uh-huh.
You
know.
250
grams
of
hardened
steel
in
in
one
place
like
making
a
sword
was
effectively.
You
know
getting
up
towards
the
same
price
as
gold,
because
finding
that
much
iron
and
forging
it
was
just
such
a
just,
so
rare
you
just
couldn't
find
that,
but
right
anyway,
that's
getting
off
the
top
book.
That
was
like
the
early
days
of
automation.
You
just
didn't
have
a
choice
of
tools.
C
There
was
only
one
you
know:
there's
only
a
couple
of
tools
that
you
had
I
think
that
the
challenge
here
is
most
for
most
people.
We
would
all
use
the
same
tool
and
for
most
of
us
we
can
all
use
the
same
tool
because
it's
good
enough,
but
for
some
specialists
or
for
some
specific
use
cases
it's
better
to
make
your
own
tool,
but
then
but
I.
If
you
know
what
you're
doing
right,
if
you've
educated
research
thought
about
it
and
you've
got
access
to
make
different
tools
to
get
it
wrong.
C
So
that's
where
we
took
a
lot
of
time
about
what
can
you
get
wrong
so
that
you
can
work
out
it's
the
wrong
thing.
So,
if
you're
in
the
16th
century
and
you
design
an
ax
I'd,
like
you
know,
with
three
blades
and
I,
you
know
whatever
that
might
be
pretty
dumb,
because
you
can't
reforge
that
into
something
else
very
easily.
So
yeah,
that's
not
a
very
good
metaphor,
but
I
get
the
idea.
A
No,
it's
a
great
metaphor:
I
mean
I
mean
this
automation
is
not
new.
I
mean
people
have
been
as
long
since
I've
been
around.
We've
been
running
batch
scripts
and
shell
scripts
to
do
stuff
that
automate
things
even
in
the
network
using
tickle
and
expect
that
necessarily
the
right
way,
but
we
were
doing
those
things
via
her
hand
crafting
that
stuff
back
in
the
late
90s
right,
so
expected,
I
mean
expect,
has
been
around
forever
yeah.
C
A
Did
actually
so
the
and
I
think
but
audit
because
of
DevOps
right
outside
of
networking?
Now
there's
been
like
intense
focus
on
well,
how
do
we
update
those
that
set
of
skills
and
apply
it
to
networking?
Because
networks
are
not
the
same
right?
You
can
have
yeah
a
thousand
servers.
Well,
those
servers
are
not
all
interconnected
and
expects
to
exhibit
a
uniform
cross
system.
Behavior
like
the
way
a
network.
Is
you
can't
just
make
individual
changes
to
a
router
and
say:
hey,
look
I
fix
this
router.
C
C
A
Changes
to
it,
you're
altering
a
living
thing
that
that
extends
to
all
places
in
your
in
your
organization.
So
we
can't
just
straight
up.
You
know,
lift
and
shift
on
this
stuff
that
people
are
doing
with
servers
and
apps
I'm
directly
on
top
of
the
network.
Just
and
there's
something
missing
there
right
and
so.
C
A
C
I
have
I
have
opinions
on
this
if
I
may
Kate,
so
the
fundamental
belief
that
I
have
is
I,
don't
see
ansible
as
a
very
long
term
answer
I
see
ansible
as
a
short
term,
and
it
just
it
covers
over
the
gap
between
where
we
are
and
when
we
get
to
Sdn
platforms.
Now
that
doesn't
mean
that
automation
isn't
going
to
happen.
Automation
will
happen
in
two
different
ways.
One
is
if
you
have
an
SDN
platform
like
contrail
or
app
stris
platform
or
glue,
wear
or
whatever.
It
is.
C
That's
automation,
right,
that's
a
different
type
of
automation.
It
might
be
a
chainsaw
compared
to
using
a
handheld
axe
like
I,
tend
to
think
of
instable
as
a
handheld
axe
chopping
down
a
tree
right.
Maybe
that's
a
bit,
maybe
even
you
know,
maybe
the
CLI
is
an
axe
chopping
down
a
tree
and
maybe
an
Sable's,
a
better
axe.
You
know,
or
it's
a
saw
with
two
men
on
the
other
side,
but
over
on
the
other
side.
C
What
you
really
want
is
a
chainsaw
just
stand
there
go
through
it
and
the
tree
falls
over
and
you're
done.
Right
and
I
tend
to
think
of
Sdn
platforms
in
that
sort
of
metaphor,
where
I
think
you're
much
better
doing
automation
against
an
SDN
platform
where
you're
doing
a
lot
less
work
and
the
tool
is
doing
a
lot
more
work
for
you,
then
I
do
think
that
in
the
long
term,
the
idea
of
you
know
using
an
axe
or
a
saw
with
two
men.
C
You
know
on
either
side
of
it
pulling
it
back
and
forth
chop
down
the
tree.
That's
only
going
to
be
a
short-term
fix
before
you
get
to
where
you
want
to
be,
which
is
just
I,
don't
want
to
be
spending
my
life
like
I
spent
years,
trying
to
learn,
Perl
and
working
how
to
do
SNMP
and
tickle
scripts
and
doing
stuff,
and
it
was
just
enormous,
ly,
frustrating
and
it's
not
something
that
I
want
to
go
back
and
do
again.
I'd
have
very
little
interest
in
learning,
Python
or
ansible
or
terraform
or
some
other.
C
A
Matt
is
that
what
we
want
I.
B
Don't
know
I
for
me,
like
the
the
the
the
the
analogy
of
you
know
finding
another
another
you
know
better
tool
to
chop
down.
The
tree
is
is
important
within
a
specific
domain.
I
think
you're
I
think
you're
correct
when
we
talk
about
very
specific
aspects
of
network
operations,
but
we
tend
to
ignore
90%
of
what
most
folks
do
on
a
day
to
day
basis,
I
mean
a
lot
of
network
engineers.
Don't
just
touch
one
particular
aspect
of
the
network
and
a
lot
of
them.
Don't
even
just
touch
the
network.
B
B
B
Let
the
the
the
phd's
in
that
field
build
products
and
abstractions,
which
everybody
does
in
every
discipline
and
then
use
those
abstractions
to
their
best
effect
within
that
domain.
That
does
not
get
you
off
the
hook
from
stitching
those
domains
together
yourself.
In
a
way,
that's
relevant
to
your
own
organization,
which
is
very
organizational
organization
specific
by
the
way
like
that
kind
of
stuff
is
not,
is
not
transferable.
The
way
that
your
particular
company
does
the
last
mile
you're
talking
about
the
last
mile
right,
exactly
right,
exactly
right
and
every
company
organization
has
them.
C
B
E
C
Know
a
lot
of
that
works
done
for
you
as
people
who
are
discovering
who
are
rolling
their
own
Linux
operating
system.
You
know
switches,
you
know
it's
apparently
it's!
You
still
need
to
be
something
of
an
expert,
but
it's
still
something
that
anybody
can
do
with
enough
time
and
energy.
You
know
year
or
so.
A
typical
engineer
could
come
up
to
speed
on
Linux
and
carving
your
own
Linux
distro
and
getting
the
tools
on
it.
But
that's
it.
C
You
know
who
wants
to
sit
around
for
a
year
and
do
that
unless
you're
getting
paid
for
it
you're
not
going
to
do
that
just
for
funsies.
Am
I
I
guess
my
point
would
be.
Is
that
my
long
term
view
say
over
a
5
to
10
year
horizon?
Is
that
the
long
term
point
of
automation
will
be
that
you'll
automate
on
top
of
an
SDN
controller?
C
Not
writing
your
stuff
directly
against
a
device,
because
the
SDN
controller
will
magnify
your
automation,
capabilities
and
present
you
with
stuff
at
the
end
of
the
day,
so
know
whether
that's
contrail
or
SD,
when
you
know
or
glue
where,
with
its
pattern
matching
system
its
intent
based
sort
of
general
type
of
templating
engine,
it
is
neither
here
nor
there
it's
going
to
be
a
question
of
which
one
works
for
you
and
your
situation
might
take
your
point,
though.
Derek
you're
talking
about
the
network
is
a
federated
system
that
always
runs.
C
A
That's
right,
and
that
makes
it
really
hard
to
do
the
right
thing
when
you're
automating.
This
is
what
I
thought
was.
One
of
the
problems
with
Sdn
I
was
very
enthused.
Everyone
was
when
stn
came
out
because
it
was
like
just
a
new
way
to
think
about
things
right
that
was
outside
of
this.
This
vert
it
was
like.
We
were
in
this
claustrophobic
space
and
networking
forever.
There
was
only
one
way
to
think
about
it,
and
so,
when
this
new
way
came
out,
it
became
and
I
think
Yvonne
really
led
the
charge
on
this.
A
When
he
was,
you
know
he
was
like
guys.
It's
way
harder
to
do
what
you,
what
it
is
you're
you
think
you're
gonna
do
like
you
know,
just
look
at
bgp,
it's
not
even
a
perfect
protocol,
but
that
thing
is
evolved
over
a
very
long
time
over
a
lot
of
trial
and
error,
with
a
lot
of
very
smart
people
to
make
that
to
make
that
work,
and
it
the
odds
that
you're
gonna
rethink.
All
of
that
and
magically
do
it
better.
Then
then,
some
of
this
is
is
kind
of
a
crazy
thought.
A
That's
it's
insane
because
most
people
know
that,
like
there's,
we
have
people
who,
who
are
experts
and
networking
who
have
not
a
clue.
Exactly
look
I
have
a
book
on
my
shelf
right
here
that
has
48
pages
written
about
ARP,
the
evolution
of
ARP.
You
would
think
you
would
think
that
would
be
the
simplest
dumbest
thing
in
the
world.
That
did
not
happen
overnight.
That
took
like
15
years
for
them
to
get
right.
Mm-Hmm.
B
B
C
C
You've
got
to
know
why
you're
firing
at
it
as
part
of
the
bigger
piece,
and
so
you
can't
just
be
an
engineer
anymore.
Who's
doing.
You
know
an
array
slice
through
a
Python
array
to
try
and
get
a
bunch
of
data.
That's
a
useful
skill,
but
it's
not
the
purpose.
It's
not
the
thing
that
gets
you
a
pay
rise.
Getting
a
pay
rise
is
that
you
were
able
to
automate
a
thing
and
get
your
fellow
colleague
sacked.
So
you
can
have
his
money
in
your
pay
packet
instead
of
them
right.
Yeah.
Sorry,
sorry
doesn't.
B
Think
I
think
that
should
have
always
been
the
case,
though
IIIi
don't
think
this
I.
Don't
think
this
is
new
I!
Think
if
you,
if
you
at
any
point
in
your
career,
have
have
thought
that
you
could
get
by
just
by
being
technical,
even
if
you
spend
most
of
your
time
being
technical,
if
you
thought
you
could
get
away
with
not
doing
like
I,
don't
know
having
a
general
idea
of
how
how
your
work
is
useful
I
mean.
That's
you.
That's
just
never,.
C
So
we've
been
doing
a
lot
of
work
on
packet
pushes
with
sty
and
software
to
find
where
and
one
of
the
stories.
So
we
chat
to
people
who
are
customers
in
in
on
shows,
and
we
also
chat
to
them
when
we
go
to
conferences
and
stuff
and
if
there's
one
consistent
theme
that
I've
spoken
to
the
people,
who've
done
successful,
sty
deployments
is
they've
done
it,
even
though
their
networking
teams
refuses
to
do
it
now.
This
is
still
an
early
adopter
thing
right.
C
It's
changing
now,
I,
remember
talking
to
one
guy
who
went
down,
he
was
the
CIO
and
he
went
down
to
his
networking
team
and
he
said
we
really
need
to
look
at
this
st
man
and
they
went
off
and
looked
at
it
and
came
back
and
said,
can't
work
and
he
said
it
can
work
and
we
are
going
to
do
it.
The
business
value
is
too
compelling
we're
going
to
pilot
it.
Are
you
gonna?
C
Six
months
later
they
had
a
pilot
up
and
then
six
months
after
that
a
year
end
they
had
30
sites
running,
and
these
networking
people
have
all
been
moved
out
of
the
door
because
they're
no
longer
needed
Yeah
right
in
I've
heard
that
story
in
various
forms.
It's
roughly
that's
the
pattern.
You
know
the
CIO
decides
or
somebody
who's
an
executive.
You
know
got
management,
responsibilities
gets
the
business
value
of
Sdn
and
then
basically
just
moves
these
people
who
refused
to
let
go
of
their
legacy.
C
Sorry,
when
I
say
legendary,
I
mean
legacy
I
like
to
try
to
be
positive,
I'm
being
upbeat
I'm
trying
to
be,
you
know,
feel
like
I'm,
enabling
all
the
people
out
there.
So
you
know
when
you've
got
your
legendary
clr
skills
and
that
you've
been
using,
for
you
know,
five
years,
that
you
learn
in
your
network,
professional
classroom.
You
know
you
did
like
a
whole
week
in
a
classroom
and
then
you
spend
a
whole
week
reading
a
textbook
to
pass
an
exam.
C
B
If
this
becomes
like
crazy
evident
to
me,
I
can't
tell
you
the
number
of
times.
I've
done
a
talk
and
and
somebody's
come
up
to
me
afterwards.
I
think
I've
talked
to
Derek,
Derek
I
think
you
have
the
same
experience
often,
and
it's
always
the
same
question.
In
fact,
I
just
gave
a
talk
last
week
and
this
happened
and
there's
always
the
question
at
the
end,
what
tool
should
I
use
for
X?
Like
that's?
B
That's
the
you
know
the
the
the
the
the
instinctive
answer
from
you
know:
sort
of
a
network
engineer
type
who's
been
in
the
industry
for
a
long
time
and
they're
hearing
about
all
this
automation
stuff,
and
so
they
want
me
somebody
who
they
feel
like
has
the
experience
to
to
just
boil
all
of
that
down
to
one
answer
and
say
like
use
this
tool
and
and
I
always
tell
them
the
same
thing.
I
said
I
said
well.
What
are
you
trying
to
do
and
I'm
like
I
I?
B
B
C
This
is
a
transition
we're
going
through
and
you
will
write
Python
and
it
will
be
a
valuable
learning
experience
for
you,
but
in
five
years,
you'll
be
working
in
some
Sdn
platform
and
doing
80%
of
your
work
by
pulling
the
lever
on
an
SDM
platform
and
you
might
have
plants
still,
we
use
your
pro
skills,
but
it'll
be
on
top
of
the
SDM
platform.
Yeah.
B
C
B
A
Yeah
I,
agree
and
I
think
that
statement
about
automating
against
automating
against
controllers
is
that
boils
down
to
the
last
mile
bit.
We
were
talking
about
earlier
I'm
at
some
point.
You
know
you
have
your
own
set
of
things
that
you're
using
and
you're
not
gonna
have
one
Sdn
one
SD
platform,
let's,
let's,
let's
get
rid
of
the
n
that
covers.
C
A
C
C
B
C
That's
as
much
work
as
you
can
reasonably
achieve,
you're
looking
for
a
company
outside
right,
you
need
a
vendor
to
handle
all
the
scut
work
underneath
I,
don't
want
to
be
watching
ansible
modules
or
you
know
any
of
the
other
frameworks,
logging
in
logging
out
and
wondering
whether
they're
working
for
this
release
a
firmware
anymore.
You
know
my
life's
just
too
short,
you
know
I'm
getting
older
and
I'm
getting
a
little
tired
of
being
in
that
rat
wheel
of
just
doing
this
same
old,
same
old,
same
old.
You
know
same
problems
day
in
day.
C
It's
getting
quite
disheartening
to
even
consider
that
we
would
still
be
doing
it.
So
I
would
like
to
think
that
people
are
thinking
themselves.
Yes,
I
definitely
need
Python
and,
like
you
said,
you
know,
terraform
or
and
you're
gonna
be
doing
something,
but
you're
probably
gonna
use
some
of
the
tool.
Like
a
chainsaw.
You
know
that's
powerful
and
does
a
lot
of
stuff
for
you
and
has
as
much
power
as
you
need
and
has
is
built
for
the
job.
C
That
is
at
hand
that,
and
you
need
to
bring
that
tool
in
as
part
of
a
toolbox
of
tools.
So
this
might
be
your
sty
and
controller
I
believe
that
you
know,
as
the
years
go
by
we're
gonna
see
one
Sdn
controller
just
for
the
whole
network.
There
won't
be
a
Wi-Fi
campus
when
data
center
it'll
just
be
one.
It's
it's
already
bundling
up
now,
if
you
I
don't
know
if
you've
looked
at
SD
when
lately
well,.
A
C
We're
seeing
with
SD
way
and
is
like
five
years
ago,
we
were
talking
about
path
dynamics.
The
ability
to
you
know,
load
balanced
across
multiple
paths.
At
the
same
time,
and
now,
five
years
later,
I'm
talking
about
two
companies
who
have
full-on
operational
security
operation
centers
who
sell
SD
when
so
the
real
feature
is
the
security
functionality
and
they're
doing
content,
inspection
threat,
management,
firewall,
they're,
doing
application
identified
identification
through
fingerprinting,
they're,
doing
automated
threat
response
and
they're
doing
full-on
active
threat
management.
C
Around
with
an
AC
and
then
all
of
a
sudden
one
night,
this
company
came
up
and
showed
us
some
ESD
way
and
I
was
like
wow.
My
mind
was
going
like
this.
Five
years
later
we
have
companies
folding
all
these
security
functions
into
it
and
the
SD
way
and
that
just
path
line
Amex,
that's
that's
that's
basic
features.
C
That's
like,
and
the
weird
part
about
this
is
is
that
that
whole
iteration
has
happened,
while
there's
people
out
there
still
doing
OSPF
in
a
branch
network
right
on
dedicated
circuits
that
whole
iteration
from
path
dynamics
to
zero
touch,
provisioning
to
cloud-based,
monitoring,
analytics
unattended
operations,
and
now
all
of
sudden
includes
all
this
purity
staff
has
all
happened
in
five
years.
Just.
C
Change
like
Anna
and
it's
all,
bundled
together,
it's
all
glommed,
into
a
single
glob
right.
This
isn't
you
know
the
old
days
of
security.
You
know,
firewalls
were
here
and
IDS's
were
here,
and
you
know,
content
loggers
were
here
and
DNS
is
here
and
load
balancers
and
blah
blah
blah.
This
is
blob,
it's
a
bundle
right
and
you
buy
your
SD
win
and
you
get
all
of
it
right,
as
well
as
as
standard
features
for
certain
products,
and
it's
just
you.
You.
A
Know
and
it's
it's
one
of
the
things
that
people
will
have
so
I
worked
for
a
lot
of
places
had
engineered
workloads,
meaning
they
they
knew
exactly
like
here's
a
job
and
this
job
is
gonna,
use,
X
amount
of
bandwidth
and
X
amount
of
CPU
and
X
amount
of
storage
as
it
moves
around
and
gets
completed,
and
one
of
the
and
and
so
there
are
some
places
that
will
probably
retain
dedicated
circuits.
For
you
know,
because,
because
of
measured,
you
know
performance.
C
C
A
C
My
point
is:
is
that
and
now
what's
happening,
is
we're
seeing
st
when
actually
get
remote
access
thrown
into
it?
Because
they've
got
a
cloud
platform
you
VPN
into
the
cloud
and
then
they
link
you
back
to
where
you
need
to
be
in
the
branch
network.
What
the
branch
a
network
happens
to
be
where
your
private
data
center
is
or
if
you
want
to
get
access
into
your
public
cloud
infrastructure.
C
C
So
that
is
not
that
that,
to
me
is
already
insight
and
will
probably
be
here
gut
feel
another
five
years
right
if
SD
Wang
can
go
from
where
it
was
in
2014
to
where
we
are
now
in
2019,
there's
no
reason
not
to
believe
that
by
2024
there'll
be
no
campus,
no
wireless,
no
branch
network
that
will
all
be
paved
over
into
one
software-defined
thing
and
now
that'll
be
the
early
adopters
and
that'll
be
the
new
generation
of
products.
It
won't
be
widespread
right,
but
that
to
me
is
like
that
strategy.
C
C
Right,
it's
good
as
st
win,
so
why
would
it
not
do
the
campus
and
the
wireless
as
well
from
a
single
controller?
Maybe
the
data
center
takes
a
while
to
catch
up,
because
it's
got
a
lot
of
Federation
going
on.
It
was
the
first
product
to
reach
market
and
he's
got
a
lot
of
Federation
going
on
horizontally
and
vertically,
so
it'll
take
a
while
for
that.
But
if
we
can
get
the
software-defined
Wayne
campus
branch
Wi-Fi
all
into
one
thing.
Certainly
this
is
where
wrist
is
headed
with
their
approach.
A
The
end
of
the
show
all
of
this,
even
even
if
you
have
one
thing,
though,
on
this
again,
you
know
we're
still
talking
just
about
the
network.
We
we're
still
going
to
have
multiple
API,
so
you
have
to
interface
with
and
and
we're
still
gonna
have
to
do
some
kind
of
automation
on
on
that
end
and
there's
one
thing
I've
seen
at
this.
A
All
of
this
is
making
everyone
a
generalist
in
general,
a
generalist
in
general
I
mean
across
the
population
right
I
mean
I,
I,
see
more
and
more
just
look
at
what
happened
and
away
Cisco
Cisco
might
have
when
they
came
out
with
the
ACR
with
UCS
they
I
felt
like
wow,
you
know,
network
engineers.
Are
they
already
do
these
things?
They
already
do
a
lot
of
these
things.
A
They're,
like
a
lot
of
in
a
lot
of
places,
they're
the
last
people
that
you
escalate
to,
even
if
it's
not
in
their
domain,
you
ask
late
to
them
and
and
right
away.
We
were
seeing
this
this
starting
this
generalization
of
what
network
engineers
do
starting
to
happen
with
UCS,
and
now
it
seems
like
it's
spreading
right.
More
and
more
and
in
the
end
it
might
be
networking.
You
said,
as
you
wrote
in
your
article
recently,
that
you
know
it
didn't
seem
like
automation,
would
be
a
full-time
job
for
for
network
engineers.
A
I
would
argue
based
on
what
first
is
what
we
talked
about.
This
episode
I
think
we
might
end
up
being
the
generalist
who,
as
a
full-time
job,
do
automation
and
it's
and
it's
an
a
and
we
might
have
a
lineage
back
into
networking.
But
at
some
point
we
wondered.
When
do
we
stop
saying
we're
network
engineers
and
start
saying
that
you
know
what
I
mean
yeah
yeah.
C
So
let
me
try
metaphor
there,
let's
say
you're
a
writer
and
you're
using
an
app
like
Microsoft
Word
to
do
the
writing.
Okay,
for
you,
it's
a
tool
to
help
you
get
going
now.
I
would
maintain
that
Microsoft
Word
is
a
tool
that
only
idiots
would
use
cuz
it's
awful,
but
let's
just
you
know,
let's
pretend
it's
actually
moderately
competent
if
you're,
right
or.
C
But
if
you're
writing,
you
know
60,000
words
as
a
writer
on
a
novel
in
Microsoft
Word,
you
need
to
know
something
about
Microsoft
Word
to
be
a
successful
writer.
You
need
to
understand
your
tooling
well
enough.
Now
that
doesn't
mean
you
have
to
be
an
expert
at
Microsoft
Word
to
be
able
to
do
that,
but
there's
a
very
big
difference
between
a
writer
writing
in
sixty
thousand
words,
and
somebody
who
writes
you
know
ten
letters
a
day.
That's
a
page
each
and
prints
them
out
and
post
them
off.
C
Are
you
the
person
who
pulls
levers
on
the
fact
predictor
'if
reduction,
mind
or
the
person
who
designs
the
production
line
and
that,
ultimately,
to
me,
is,
is
automation,
your
full-time
job,
I
think
for
most
people
it
won't
be
I,
think
they'll
be
inside
an
SDN
environment
and
just
doing
what
what
they
do,
but
there'll
be
a
certain
group
of
people
for
whom
automation
is
near
a
full-time
job,
but
it
won't
be
them
writing.
Python
code
it'll
be
doing
something
on
top
of
some
Sdn
tooling.
C
C
Yeah,
but
my
point
would
be:
is
that
over
time
they
won't,
they
will
all
be
they'll
only
be
one
domain,
but
they
do
a
lot
of
work
for
you,
so
you
don't
have
to
write
instead
of
relying
on
a
framework,
you
just
pull
the
Sdn
controller
in
as
a
tools
as
pioneer
tool
chain.
Why
wouldn't
you
do
that?
If
it's
gonna,
do
it
better
than
you
can
I.
B
Agree
with
the
last
part
of
that
for
sure
I,
just
the
it's
the
the
nature,
the
the.
So
this
might
not
be
a
perfect
analogy,
but
like
the
idea
of
jebin's
paradox
right,
the
more
efficient
a
system
becomes
the
more
the
higher
the
efficiency
of
the
utilization
of
those
resources
become
right.
We
saw
this
as
virtualization
like
every
time
a
new
and
new
you
know.
Technology
comes
out.
We
start
to
use
that
technology,
that
much
more.
B
That's
why
there's
like
a
billion
on
you
know
banded
VMs
in
public
cloud
right
now
that
are
costing
our
companies
a
lot
of
money,
because
we
just
used
this
stuff
a
lot
more
than
we
do,
and
it's
really
hard
when
you're,
when
you're
not
there.
Yet,
like
imagine
the
people
who,
back
to
your
that's
your
analogy
of
creating
swords
right.
C
B
B
Know
what
I
mean
so
like
the
thing
here
is
like
don't
get
wrapped
around
this.
The
manifestation
of
those
skill
sets
like
if
you
think
that
your
destiny
is
to
make
swords.
Yeah
you're
gonna
have
a
bad
time,
rather
focus
on
the
way
that
you
approach
problems
and
creatively
solve
those
problems
and
you,
as
you,
move
up
the
technology
tree
so
to
speak
in
gaming
in
gaming
parlance,
you're
gonna
find
more
uses
for
that.
It's
just
inevitably,
habits
happened
about
history's
yeah.
C
My
point
is:
don't
get
hooked
up
on
your
you
know
your
favorite
Python
framework
start
thinking
about
an
SDN
controller
as
a
framework
as
a
tool
to
be
used
in
the
chain,
so
that
when
you're,
that
automation
for
your
business
make
sure
you're
using
the
right
tool
for
the
job,
you
know
maybe
it's
an
axe.
Maybe
it's
a
handsaw,
maybe
it's
a
chainsaw
and
you
know,
make
sure
you're
thinking
flexibly
about
it.
C
Maybe
it's
the
right
decision
for
your
business
to
go
and
spend
you
know
three
quarters
of
a
million
on
an
SDN
controller
with
a
per
you
know,
device
license.
Maybe
it
is
maybe
hand
carving
at
all
from
nothing.
Is
the
right
way
to
go.
I
can't
answer
that
question,
and
but
I
can
tell
you
that
you
know
that
just
to
go
off
topic
here,
go
off
piste,
Viking
swords
in
the
16th
century,
the
16th
and
17th
century.
C
They
used
to
make
them
out
of
a
thing
called
Eastern
Steel,
and
this
was
a
special
type
of
Steel
that
used
to
come
out
of
northern
India,
which
was
in
Asia
at
the
time,
and
there
were
merchants
who
would
usually
bring
these
steel
ingots,
because
making
steel
was
incredibly
difficult
to
do
in
that
time
and
they
would
actually
bring
these
ingots
all
the
way
out
from
Asia
all
the
way
up
to
the
Icelandic
countries
where
they
would
then
Forge
them
into
swords
that
they
wanted.
I
mean
we
don't
that's
where
we
are
with
Sdn
controllers.
C
At
the
moment,
the
Sdn
controller
to
me
is
the
steel
and
you've.
Then,
as
an
engineer,
you've
got
to
forge
that
into
a
tool
that
you
that
solves
the
problems
for
the
business
that
you
have
and
the
good
part
about
Sdn
is
you'll,
spend
less
time
trying
to
do
a
slice
through
an
array
to
get
the
data
that
you
want
to
writing
a
sequel
query
or
whatever,
whatever
your
particular
torment,
is
and
spend
more
time
talking
to
the
business
and
here's
a
secret.
The
more
time
you
spend
talking
to
the
business.
B
True
there
cuz
I'm
in
absolutely
that's
exactly
what
I'm
saying.
That's
that's
the
whole
point.
That's
a
good
thing,
because
the
more
valuable
you
are,
the
obvious
leave
the
pie
at
the
pay
rise.
I
think
comes
with
that,
but
but
in
general,
like
that's
kind
of
my
point
like
if
you
like
right
now
we're
taking
on
this
the
job
of
mining,
the
iron
ore
right,
that's
what
we're
doing
right
now.
B
C
B
Static
entities-
we're
not
just
replaced
by
that.
What
we
do
is
we
move
up
the
stack
and
we
use
those
same
skills.
We're
going
to
continue
to
write,
Python
we're
going
to
continue
to
use
tools
like
ansible,
maybe
a
different
tool,
but
that
same
mindset
of
building
versus
just
buying
and
putting
something
in
place
will
still
be
there.
It'll
just
be
moved
up.
The
stack
I,
never.
A
D
B
B
C
If
you
get,
there
are
certain
periods
in
my
life
when
I
got
way
too
focused
on
the
bits
and
pieces
and
the
gears
and
the
cogs
and
all
that
stuff.
But
when
I
took
time
to
pull
back
and
focus
on,
how
do
I
make
more
money
out
of
this
and
started
to
get
really
cunning
and
evil
about
it?
The
answer
was
I
learned,
business
skills
and
I
got
smarter
than
my
manager
and
then
all
of
a
sudden
I
got
paid.
C
So
much
more
money
like
it
rained
out
of
the
sky
and
that's
the
advice
I
want
to
give.
You
is
think
about,
learn
enough
business
to
be
DevOps
and
net
ops,
but
do
the
things
that
it
gives
you
satisfaction,
which
is
probably
the
engineering
and
find
a
balance
between
the
two.
That's
my
last
word,
nice.
A
A
Right
everyone
thank
you
for
watching.
We
will
have
this
posted
on
our
YouTube
channel
by
the
end
of
the
day,
we'll
probably
use
the
zoom
recording
again
based
on
the
audio
issues
we
had
earlier.
I
am
cloud
towed
at
CLO,
UD
t
o
ad,
just
just
as
it
sounds
on
Twitter,
and
our
quote.
This
is
our
co-host
mad
at
M
ie,
our
m
@
m
IE
r
di
and
which
I
every
sort
of
every
single
show
I
choked
on
that
mirrored
in.
A
Please
follow
him,
of
course,
follow
energy
labs
at
enemy
labs
on
Twitter
and
follow
you
can
follow
Greg
on
Twitter
he's
quite
prolific.
He
creates
quite
a
bit
of
content
to
read
to
watch.
He
gets
into
fun
arguments
on
social
media
which
are
always
entertaining
he's
ethereal.
Mind
e
th,
er,
ei,
L,
M,
IND
and
we'll
put
links
to
all
this
and,
of
course,
in
the
description
and
on
the
YouTube
channel.
So
again,
thank
you
very
much
and
we'll
see
you
next
week.
Bye.