►
From YouTube: The Network (The Podlets, Ep 15)
Description
There are two words that get the blame more often than not when a problem cannot be rooted: the network! Today, along with special guest, Scott Lowe, we try to dig into what the network actually means. We discover, through our discussion that the network is, in fact, a distributed system. This means that each component of the network has a degree of independence and the complexity of them makes it difficult to understand the true state of the network. We also look at some of the fascinating parallels between networks and other systems, such as the configuration patterns for distributed systems. A large portion of the show deals with infrastructure and networks, but we also look at how developers understand networks. In a changing space, despite self-service becoming more common, there is still generally a poor understanding of networks from the developers’ vantage point. We also cover other network- related topics, such as the future of the network engineer’s role, transferability of their skills and other similarities between network problem-solving and development problem-solving. Tune in today!
For the show notes and transcript: https://thepodlets.io/episodes/015-the-network/
Feedback and episode suggestions:
https://twitter.com/thepodlets
https://github.com/vmware-tanzu/thepodlets/issues
info@thepodlets.io
Special guest:
https://twitter.com/scott_lowe
Hosts
https://twitter.com/mauilion
https://twitter.com/apinick
https://twitter.com/joshrosso
B
Everybody
and
welcome
to
the
cubelets
podcast
show
in
which
we
explore.
You
know
some
of
the
many
many
things
that
make
up
kind
of
the
cloud
native
landscape
and
things
that
are
interesting
to
people
who
are
playing
with
distributed
systems.
In
this
episode.
We're
gonna
talk
about
the
network.
My
name
is
Duffy,
Cooley
and
I'll.
Be
the
lead
of
this
episode
and
with
me,
I
have
Nick.
D
C
Yes,
absolutely
so
in
my
previous
life,
before
being
a
true
Bernanke's
architect,
I
actually
used
my
networking
and
engineering
degree
to
be
a
network
administrator
for
the
boeing
company,
one
of
the
Boeing
Corporation
and
time
and
time
again,
someone
would
come
to
me
and
say
well,
this
isn't
working
the
network's
down
and
I'm
like
is
the
network
down
or
is
the
server
down?
Because
those
are
different
things
yep
turns
out
of
seizure
to
the
server
I.
D
B
I
figure,
we
really
tell
people
that
my
first
distributed
system
that
I
ever
became
that
I
ever
had
a
real
understanding
of
was
the
network.
You
know,
and
it's
interesting
because
it
kind
of
like
relies
on
some
of
the
premises
that,
like
I,
think
a
good
distributed
system
should,
in
that
there
is
some
autonomy
to
each
of
the
systems
right.
They
are
dependent
on
each
other
or
or
even
our
inter
communicate
with
each
other.
But
in
fundamentally
like
when
you
look
at
routers
and
and
things
like
that,
they
are
there.
B
D
Think
the
fact
that
the
network
is
a
distributed
system
and
I'm
glad
you
said
that
yeah
I
think
the
fact
the
network
is
a
distributed
system
is
is,
is
what
most
people
overlook
when
they
start
sort
of
blaming
the
network.
Right
I
mean
let's
face
it
in
the
diagrams
right,
the
network's,
always
just
this
blob
right
like
here's,
the
network
right.
D
So
even
routing
protocols
mean
their
entire
purpose
is
to
assemble
some
sort
of
common
understanding
of
what
the
state
of
the
network
is
melding
together,
not
just
you
know,
IP
addresses
which
of
these
abstract
concept,
but
physical
addresses
and
physical
connections,
and
and
trying
to
reason
to
make
decisions
about
that
and
how
we
send
traffic
across
it,
and
it's
far
more
complex
and
a
lot
of
people
understand
and
I.
Think
that's
why
it's
just
like.
Oh,
the
network
is
down
right
when
in
reality,
it's
probably
something
else
entirely.
Yeah.
C
Absolutely
another
good
point
to
bring
up
is
that
each
of
these
distributed
pieces
of
this
distributed
system-
art
in
themselves
like
just
basically
like
just
a
computer
and
like
a
lot
of
times,
I've
talked
to
people
and
they
were
like
well
the
route
or
something
special
I'm
like
not
really
technically,
a
Linux
box
could
just
be
a
router.
If
you
have
enough
ports
that
you
plug
into
it
or
it.
D
C
B
Good
interesting
parallel,
there
is
like
when
we
talk
about
like
routing
protocols
which
are
a
way
of
a
way
that
allow
configuration,
changes
to
particular
components
within
that
distributed
system
to
be
known
about
by
other
components
within
that
distributed
system
and
I.
Think
there's
an
interesting
parallel
here
between
the
way
that
works
in
the
way
that,
like
you,
know,
configuration
patterns
that
we
have
for
distributed
systems
work
right
like
if
you
wanted
to
make
a
configuration,
only
change
to
a
set
of
applications
that
make
up
some
distributed
system.
B
You
might
go
about
like
leveraging
ansible
or
one
of
the
one
of
the
many
other
configuration
models
for
this,
and
it's
interesting,
I
think
I.
Think
it's
interesting,
because
it
kind
of
represents
sort
of
an
evolution
of
that
same
idea
in
that
you're
making
it
so
that
each
of
the
components
is
responsible
for
informing
the
other
components
of
the
change
rather
than
taking.
The
outside
approach
of
my
job
is
to
actually
push
a
change.
B
D
Don't
know
I'm
not
sure,
like
I'd
have
to
process
that
for
a
bit,
but
I
mean.
Are
you
saying,
like
the
the
interesting
thought
here?
Is
that,
in
contrast
to
you
know
typical
systems
management
where
we
push
configuration
out
to
something
using
a
tool
like
advancable
or
whatever?
These
things
are
talking
amongst
themselves
to
determine
state
yeah,
I.
B
Right,
like
the
goal
being
that
you
make
these
systems,
you
give
the
systems
the
ability
to
inform
the
other
systems
in
some
distributed
system
of
the
changes
that
may
that
that
they
may
have
to
have
to
react
to
another
good
example
of
this.
One
which
I
think
is
interesting,
is
like
what
they
call
when
you,
when
you
want
to
when
you
have
put
a
feature
behind
a
flag
right
and
you
might
have
some
distributed
configuration
model
like
a
red
s,
cache
or
or
a
database
somewhere
that
you've
actually
let
you've
held
the.
B
Configuration
of
this
distributed
system
and
when
you've
want
to
turn
on
this
particular
feature
flag.
You
want
all
of
the
components
that
are
associated
with
that
feature
flag
to
enable
that
new
capability
and
some
of
the
patterns
for
that
are
pretty
darn
close
to
the
way
that
routing
protocol
models,
work,
yeah.
D
Like
we
talked
about
how
long
it
takes
to
a
routing
protocol
to
converge,
and
we
might
also
talk
about
how
long
it
takes
for
a
net
CD
cluster
to
converge
after
changing
the
number
of
members
in
the
cluster
or
something
of
that
nature,
the
point
at
which
everybody
in
that
distributed
system,
whether
it
be
the
network
or
at
CD
or
some
other
system,
comes
to
the
same.
Understanding
of
what
that
shared
state
is.
C
Yeah
I
think
that's
a
perfect
breakdown,
honestly
I'm
pretty
much
every
routing
technology.
That's
out
there,
like
you
know
if
you
take
a
network,
often
if
you
take
a
computer
off
the
numbered
it,
you
know
it
takes
a
while,
but
eventually
everyone
will
reconcile
to
the
fact
that
yeah
that
that
note
is
gone
now,
yeah.
B
As
that
we're
building
a
scale
frequently
we
we
can
make
use
of
things
like
eventual
consistency
in
which
it's
not
required
per
se,
for
the
for
for
a
transaction
to
be
persisted
across
all
of
the
components
that
it
would
affect
immediately,
just
that
they
eventually
converge
right,
whereas
with
the
network
not
so
much
right
like
so,
their
work
needs
to
be
right
right
now
and
every
time
and
and
there's
there's
no
really
like,
there's
not
really
a
model
for
eventually
consistent
networks.
Right,
there's.
D
You
know
most
organizations
relatively
simple
local
area
networks
right,
but
even
if
we
were
to
take
it
and
look
at
something
like
a
class
fabric
right
where
we
have
top-of-rack
switches
and
if
this
is
getting
too
deep
for
non-working
folks
that
we
know
right,
but
where
you
take
top-of-rack
switches
that
are
talking
layer,
2
to
the
servers
below
them
or
the
endpoints
below
them,
and
they're
talking
layer
3
across
a
multi-link
piece
up
to
the
up
to
the
top
right
to
the
spine
switches.
So
you
have
leaf
switches.
D
Talking,
abstract,
ridges,
they're
gonna
have
multiple
up
links.
One
of
those
up
links
goes
down.
It
doesn't
really
matter
if
the
rest
of
that
fabric
knows
that
that
link
is
down
because
we
have
this
equal
cost,
multi
pathing,
going
across
the
fabric
right
and
so
in
a
situation
like
that.
That
fabric
is
eventually
consistent
in
that
it's
okay,
if
you
know
me,
dropping
link
number
one
off
leaf.
A
up
to
you
know,
spine
a
is,
is
down
and
the
rest
of
the
system
doesn't
know
about
that
yet.
D
But
on
the
other
hand,
if
you
are
looking
at
network
designs
where
you
know,
convergence
is
is
being
handled
on
active
standby
links
or
something
of
that
nature,
or
there
aren't
enough
paths
to
get
from
point
A
to
point
B.
Until
convergence
happens,
then
yes,
you're
right
so
I
think
it
it
kind
of
comes
down
to
network
design
and
the
underlying
architecture,
and
there
are
so
many
factors
that
affect
and
and
so
many
designs
over
there
over
the
years
that
it's
it's
hard
to
I
would
agree
and
from
the
respective
have
like.
D
B
That
that
is
another
really
great
parallel
in
software
development
I
think
another
good.
Another
great
example
of
that
right
like
if
we,
if
we
consider
for
a
minute
like
the
circuit,
break-in
pattern
or
or
even
like
you
know,
most
load
mounds
or
patterns
right
in
which
you
have
some
way
of
understanding
a
list
of
healthy
endpoints
behind
the
load
balancer
and
were
able
to
react
when
certain
endpoints
are
no
longer
available.
I,
don't
necessarily
I.
Don't
consider
that
a
pattern
that
it
I
would
relate
to
specific.
B
Specifically,
they
can
sit
to
eventual
consistency,
because
I
feel,
like
that's
I,
feel
like
that
still
has
to
be
immediate
right,
like
we
have
to
be
able
to
not
send
the
new
transaction
to
the
dead
thing.
That
has
to
stop
immediately
right
and
it
does
in
most
routing
patterns
that
are
described
by
multipath.
There
is
a
very,
very
time-sensitive
mechanism
that
allows
for
the
the
Reedus
Percel
of
that
traffic
across
known
paths
that
are
still
good,
alright
and
and
the
work
the
amazing
amount.
D
B
That
that
protocol,
political
architects
and
network
engineers
go
through
to
understand
just
exactly
how
the
behaviors
of
those
systems
will
work
such
that
we
don't
see
traffic
black
hold
in
the
network
for
a
period
of
time
right.
So
we
don't
send.
We
don't
send
traffic
to
the
trash
when
we
know-
or
we
have
you
know
for
a
period
of
time,
while
things
converge,
it's
really
has
a
lot
code
for
it.
D
Yeah
I
would
agree,
I.
Think
the
interesting
thing
about
discussing
eventual
consistency
with
regards
the
networking
is
that
you
know,
even
if
we
take
a
relatively
simple
model
like
the
DoD
model,
or
we
only
have
four
layers
to
contend
with
right
and
we
don't
have
to
go
all
the
way
to
the
seven
layer
OSI
model,
but
even
if
we
take
a
simple
layer
like
the
the
DoD
four
layer
model
we
could
be
talking
about.
D
You
know
the
the
Rapid
Response
of
a
device
connected
at
layer
two,
but
the
less
than
rapid
response
of
something
operating
at
layer,
3
or
layer,
four
right,
yeah,
and
so
in
the
case
of
a
network
where
we
have
these
discrete
layers
that
are
intentionally
loosely
coupled,
which
is
another
topic.
We
could
talk
about
from
a
distribution
system
right.
D
B
C
Where,
like
I
recently
been
getting
more
and
more
development
practice
and
something
that
I
do
sometimes
is
I
like
draw
out
like
how
all
of
my
functions
and
all
my
methods
and
things
like
that
interact
with
each
other
across
a
you,
know,
consistent
code
base
and
lo
and
behold
when
I
draw
everything
out
dang,
it
sure
does
look
a
lot
like
a
network
diagram.
You
know
all
these
things
have
to
flow
together
in
a
very
specific
way,
and
you
expect
the
kind
of
returns
that
you're
looking
for
it
looks
exactly
the
same.
D
D
You
know,
as
you
were,
sitting
there
talking,
Duffy
and
I,
so
I
thought
back
to
you
Nick.
You
know
I
think
all
the
times
you
know,
I
have
a
personal
passion
for
helping
people
continue
to
grow
and
evolve
in
their
career
and
not
being
stuck
and
and
I
talked
to
a
lot
of
networking
folks,
probably
dating
because
of
my
involvement
with
you,
Duffy
back
in
in
the
NSX
team
right,
but
folks
being
like.
D
Oh
I'm,
you
know
I'm
just
a
network
engineer:
I,
don't
you
know
I,
there's
so
much
for
me
to
learn
if
I
have
to
go.
Learn
kubernetes,
like
I,
wouldn't
even
know
where
to
start,
but
like
this
discussion
to
me
underscores
the
fact
that
if
you
understand
how
a
network
is
a
distributed
system
and
how
these
theories
apply
to
a
network,
then
you
can
extrapolate
those
concepts
and
apply
them
to
something
like
kubernetes
or
other
distributed
systems
right
and
immediately
begin
to
understand.
Oh
okay!
D
C
That
path
like
the
control
plane
of
your
cluster,
is
just
like
your
central
routing
backbone
and
then
the
cubelets
themselves
are
just
your
edge
switches
going
to
each
of
your
individual,
like
smaller
network
and
then
the
pods
themselves
are
the
nodes
inside
of
the
network
right,
you
can
easily
look
at
that
holy
crap.
It
looks
exactly
the
same.
That's.
B
A
good
point,
I
mean
I,
think.
Another
interesting
part
is
like
when
you
think
about
like
how
we
characterize
systems
like
where
we
learn
that,
like
what
what
that,
where
that
skills
that
comes
from
I,
think
you
raise
a
very
good
point.
I'm,
like
I,
think
I
think
it's
important
to
I
think
it's
an
easier,
maybe
slightly
easier
thing,
to
learn
inside
of
networking
how
to
characterize
that
particular
distributed
system.
Because
of
the
way
the
components
themselves
are
laid
out
and
in
such
a
common
way.
Right,
whereas
like
when
we
start
looking
at
different
applications.
B
We
find
a
myriad
of
different
patterns
with
with
particular
components
that
may
behave
slightly
differently
depending
right,
like
their.
There
are
different.
There
are
different
patterns
within
software
like
almost
on
a
per
application
basis,
whereas
like
with
networks,
they're
pretty
much
they're,
pretty
consistent,
consistently
applied
right
and
every
once
in
a
while
they'll,
be
kind
of
like
a
new
pattern
that
emerges
that
that
just
changes
the
behavior
a
little
bit
right
or
or
changes
the
behavior
like
a
lot.
B
C
Agree
so
I'm
actually
kind
of
curious.
We,
the
three
of
us,
have
been
talking
quite
a
bit
about
networking
from
the
perspective
that
we
have,
which
is
more
infrastructure
focused,
but
Josh.
You
have
more
of
a
developer
focus
background.
What's
your
interaction
and
understanding
of
the
network
and
how
it
plays
yeah,
I've.
A
Always
been
a
consumer
of
the
network,
it's
something
that
is
set
behind
an
API
in
some
library,
right,
I
call
out
to
something
that
makes
a
TCP
connection
or
an
HTTP
interaction,
and
then
things
just
happen
and
I
think.
What's
really
interesting
hearing
you
all
talk,
and
especially
the
point
about
network
engineers
getting
into
the
distributed
system
space.
A
Is
that
I
really
think
that,
as
we
started
to
put
infrastructure
behind
api's
and
made
it
more
and
more
accessible
to
people
like
myself,
app
developers
and
programmers
we
started
and
by
we,
you
know
I'm,
obviously
generalizing
here,
but
we
started
owning
more
and
more
of
the
infrastructure.
So
when
I
go
into
teams
that
are
doing
big
kubernetes
deployments,
it's
pretty
rare,
that
is,
a
conventional
applicants,
are
e.
The
infrastructure
and
networking
teams
that
are
standing
up
distributed
systems
kubernetes
are
not
right.
A
It's
a
lot
of
times
a
bunch
of
app
developers
who
have
maybe
what
we
call
DevOps
whatever
that
means,
but
they
have
an
application
development.
They
understand
how
to
interact
with
api's,
how
to
write
code,
that
it
respects
or
interacts
with
their
infrastructure
and
they're
standing
up
these
systems
and
I
think
one
of
the
gaps
that
that
really
creates.
A
It
is
a
lot
of
people,
including
myself,
just
hearing
you
all
talk
like
we
don't
understand
networking
at
that
level
and
when
stuff
falls
over
and
it's
either
truly
the
network
or
it's
getting
blamed
on
the
network,
it's
oftentimes
just
because
we
truly
truly
don't
understand
a
lot
of
these
things.
Right,
encapsulation,
you
know
meshes
well
whatever
it
might
be.
A
We
just
don't
understand
these
concepts
at
a
deep
level
and
I
think
if
we
had
a
lot
more
people
with
network
engineering
backgrounds
shifting
into
the
distributed
system
space,
it
would
alleviate
a
bit
of
that
right,
bringing
more
understanding
into
this.
The
space
that
we
work
in
nowadays.
I
wonder.
C
Maybe
you
also
would
be
a
benefit
to
have
like
more
cross
discussions
kind
of
like
this
one
between
developers
and
infrastructure,
kind
of
focused
people
because
we're
starting
to
see
like
as
we're
crossing
boundaries.
We
see
that
the
same
things
that
we're
doing
on
the
infrastructure
side,
you're
also
doing
in
the
developers
side
like
cap
theorem,
as
Scott
mentioned,
which
is
the
idea
that
you
can
have
two
out
of
three
of
consistency,
availability
and
partitioning.
C
That
also
applies
to
networking
in
a
lot
of
ways
like
you
can
only
have
a
network
that
is
either
like
consistent
or
available,
but
it
can't
handle
partitioning
or
it
can
be
consistent
and
handle
partitioning.
But
it's
not
always
going
to
be
available.
That
sort
of
thing
these
things
that
apply
in
from
a
software
perspective
also
apply
to
us,
but
we
think
about
them
as
being
so
completely
different.
C
A
Know
yeah
I,
totally
agree,
I
mean
I,
I,
really
think
like
on
the
app
side
a
couple
years
ago.
You
know
I
really
just
didn't
care
anything
outside
of
the
JVM,
like
my
stuff,
ran
in
the
JVM
and
if
it
got
out
to
the
network
layer
of
the
host,
like
just
didn't
care,
no
need
to
know
about
that
at
all.
But
ever
since
cloud
computing
and
distributed
systems
and
everything
became
more
prevalent
it.
The
overlap
has
become
extremely
obvious
right
and
in
all
these
different
concepts,
and
it's
been
really
interesting
to
try
to
ramp
up.
B
Yeah
and
I
think
you
know
Scott
and
I
both
both
do
this
I
think
this
I
imagine.
Actually.
This
is
true
of
all
four
of
us
to
be
honest,
but
I
think
that
it's
really
interesting
when
you
are
out
there
talking
to
people
who
do
feel
like
they're,
stuck
in
some
particular
role
like
they're,
that
they're
specialists
in
some
particular
area,
and
we
end
up
having
the
same
discussion
with
them
over
and
over
again.
You
know
like
like
look.
B
B
D
And
so
this
idea
of
like
what
does
the
future
of
of
the
you
know
the
folks
that
are
kind
of
like
in
our
space.
What
is
it?
What
does
that?
Look
like
like?
How
much
longer
does
a
network
engineer
really
need
to
be
deeply
versed
in
all
the
different
layers,
because
everything's
been
abstracted
away
by
some
other
type
of
thing?
Whether
it's
weak
pcs
or
as
your
V
Nets
or
you
know,
whatever
the
case
is
right-
I
mean
you've,
got
companies
bringing
the
V
PC
model
to
on-premises
networks,
right
and
and
so
I.
D
You
know
it's
like,
as
API
is
become
more
prevalent
as
everything
gets
sort
of
abstracted
away.
What
does
the
future
look
like?
What
does
what?
What
are
the
most
important
skills
and-
and
it
seems
to
me
that
it's
it's
these
concepts
that
we're
talking
about
right,
this
idea
of
distributed
systems
and
our
distributed
systems
behave
and
how
the
components
react
to
one
another
and
understanding
during
things
like
the
cap,
theorem
that
are
going
to
be
most
applicable
rather
than
the
details
of
troubleshooting,
bgp
or
understanding.
C
I
think
there's
always
gonna
be
a
place
for
the
people
who
know
how
things
are
running
under
the
hood.
From
the
like
a
physical
layer
perspective,
that's
sort
of
thing,
there's
always
gonna,
be
the
need
for
the
Greybeards
right.
Even
in
software
development,
we
still
have
the
people
who
are
slinging
kernel
code
in
C,
and
you
know
they're
the
best.
We
salute
you,
but
that
is
not
something
that
I'm
interested
in
doing
for
sure.
C
We
always
need
someone
there
to
pick
up
the
pieces
as
it
were,
but
I
think
that
yeah
having
just
being
like
I'm
a
Cisco
guy
I'm,
a
juniper
guy,
you
know
I
know
how
to
tell
me
a
telnet
or
RS
agent
to
the
switch
and
execute
these
commands
and
suddenly
I've
got
this
port
is
now
you
know
shrunk
to
this
V
net
crap
I
was
like
Nick.
Remember,
remember
your
training,
you
know
how
to
issue
those
commands.
A
Yeah
I
mean
unfortunately,
I
feel
like
a
lot
of
times.
It
just
ends
up
being
trial
by
fire,
and
it
probably
shouldn't
be
that,
but
the
amount
of
times
that
I've
seen
a
deployment
of
some
technology
fall
over
because
we
overlapped
a
cider
range
or
something
like
that
is
crazy,
because
we
just
didn't
think
about
it
or
really
understand
it.
A
It's
been
rough,
I
guess.
My
my
perspective
is
that
the
technology
has
gotten
better
overall
and
I'm,
mostly
obviously
in
the
kubernetes
space,
is
speaking
to
the
technologies
around
a
lot
of
the
container
networking
solutions,
but
I'm
sure
this
is
true.
Overall,
it
seems
like
a
lot
of
the
sharp
edges,
have
been
buffed
out
quite
a
bit
and
I
have
less
of
an
opportunity
to
do
things
terribly
wrong
and
I've
also
noticed
for
what
it's
worth
a
lot
of
folks
that
have.
A
My
kind
of
background
are
going
out
to
like
the
AWS
as
the
azores
of
the
world
and
they're,
using
all
these
like
abstracted
networking
technologies
that
allow
them
to
do
really
cool
stuff
without
really
having
to
understand
how
it
works
and
they're
oftentimes
going
back
to
their
networking
team
on-prem
when
they
have
on-prem
requirements
and
being
like.
It
should
be
this
easy
or
XY,
and
Z,
and
they're
almost
like
pushing
the
networking
team
to
modernize
that
and
make
things
simpler,
based
on
experiences
they're.
Having
with
these
cloud
providers,
yeah.
C
D
C
B
Yeah,
especially
when
you're
in
the
plumbing
you
know
like,
if
you
you
know
like,
if
you're
gonna
do,
if
you're
gonna
create
a
load
balancer
with
an
API.
Well,
then
what
API
do?
Does
the
a
load
balancer
use
to
understand
where
to
send
that
traffic,
when
it's
being
balanced
right
like
how
do
you
handle
discovery
like
how
do
you
know,
like
obviously,
yeah
there's,
no
there's
no
shorter
easier.
B
When
you
want
to
work
there,
yeah
yeah,
that's
a
really
good
point:
I
mean
III
I
think
you
know
sometimes
like
sometimes
it's
easy
for
me
to
think
about
some
of
these
API
driven
networking
models
and
and
and
the
costs
that
come
with
them,
the
hidden
costs
that
come
with
them.
An
example
of
this
is
if
you're
in
AWS,
and
you
have
connectivity
between
two
availability
zones,
or
it
actually
could
be
any
cloud.
B
You
have
to
be
able
to
to
provide
the
consumers
of
any
service
whether
that
service
is
plumbing,
whether
it's
networking,
whether
it's,
whether
it's
your
application
that
you've
developed
that
represents
a
set
of
micro
services.
You
have
to
provide
everybody
a
weight
or
you
know
you
have
to
provide
the
people
who
are
you
know,
gonna
answer
the
phone
at
2:00
in
the
morning
or
even
the
robots
that
are
gonna
answer
the
phone
at
2:00
in
the
morning.
B
You
have
to
provide
them
some
mechanism
by
which
to
observe
those
systems
as
they
as
they
are
in
use
and
I
and
I.
Don't
know,
I'm,
not
convinced
that
that
very
many
of
the
cloud
providers
do
that
terribly
well
today,
you
know,
like
I
I
feel,
like
I've
been
burned
in
the
past,
without
actually
having
an
understanding
of
the
state
that
we're
in
and
so
it's
interesting.
Maybe
the
software
development
team
can
actually
start
pushing
that
down
toward
the
networking.
The
networking
vendors
of
their
of.
C
The
world
yeah
that
would
be
great
I,
mean
there
I've
been
recently
using
a
managed
kubernetes
service
I've
been
kicking
the
tires
on
it.
A
little
bit
and
yeah
there's
been
a
couple
times
where
I've
just
been
got
by
networking
issues:
I'm
not
gonna,
get
into
what
a
C&I
a
container,
a
network
interface
or
any
of
the
technologies
around
that
we're
gonna
talk
about
that
another
time,
but
the
cni
that
I'm
using
in
this
managed
service.
It
was
just
so
wonky
and
weird,
and
it
was
failing
from
a
network
standpoint.
B
This
could
happen
in
a
database.
Right
like
this
could
happen
in
a
cache
of
information.
This
could
happen,
like
you
know,
in
in
pretty
much
this
same
pattern
that
you're
describing
is
absolutely
relevant
in
in
in
in
both
of
these
fields.
Right
like
and
that's
the
fascinating
thing
about
this
is
that
you
know
when
we
I
think
when
we,
when
we
talk
about
the
network
generally
in
these
nebulous
terms,
and
that
it
is
like
a
black
box
and
I,
don't
want
to
know
anything
about
it.
I
don't
want
to
learn
about
it.
B
I
don't
want
to
understand
it.
I
just
want
to
be
able
to
consume
it
via
an
API
and
and
I
want
to
have
the
expectation
that
everything
will
work.
The
way
it's
supposed
to
I
think
it's
fascinating.
That,
like
you
know,
on
the
other
side
of
the
API,
are
people
maybe
just
like
you
who
are
who
you
and
their
level
best
to
provide.
B
C
The
same
principles
exist
like
we've
been
saying,
but
just
to
kind
of
elucidate
on
it
a
little
bit
more.
It's
like
on
one
side
you
have
like
I
need
to
make
sure
that
these
etsy
D
nodes
communicate
with
each
other
and
that
the
data
is
consistent
across
the
other
one.
So
we
use
a
protocol
called
raft
right
and
so
that's
a
eventually
consistent
tool,
then
that
information
gets
sent
onto
a
network
which
is
probably
using
OSPF,
which
is
open,
shortest
path.
C
First,
routing
protocol
to
become
eventually
consistent
on
the
data
getting
from
one
point
to
the
other
by
opening
the
shortest
path
possible,
and
so
these
two
things
are
very
similar
they're.
Both
these
communication
protocols,
which
is
I,
mean
that's
what
protocol
means
right
a
standard
for
communication
but
they're
just
so
like
different
layers,
obviously
of
the
OSI
model.
C
B
Another
another
really
interesting
one
right
like
another
galaxy
brain
moment:
I
think
that
is
interesting.
It's
like,
if
you
think
about
so,
let's
break
them
down
like
TCP
and
UDP.
These
are.
These
are
interesting
patterns
that
actually
do
totally
really
again
just
in
software
patterns
right
like
in
TCP.
B
Another
example
is
like
UDP,
where
it's
like.
Basically,
there
are
no
repeats.
You
either
got
the
packet
or
you
didn't,
which
sounds
a
lot
like
a
kind
of
an
event
stream
to
me
in
some
ways.
Right
like
it's,
it's
very
interesting,
like
you
just
figure
like
I
put
it
on
the
line.
You
didn't
get
it
it's.
Okay,
I'll
put
another
one
on
line
here
in
a
minute.
You
can
react
to
that.
One
right
like
it's!
It's
it's
kind
of
it's
kind
of
an
interesting
overlap.
B
D
The
comparison
to
event,
streams
or
or
message
queues
right,
it's
an
interesting
one
that
I
hadn't
I
hadn't
considered
before
but
yeah.
There
are
certainly
parallels
between
you
know,
saying:
okay,
I'm,
gonna,
I'm
gonna
put
this
on
the
message,
queue
and
wait
for
the
acknowledgement
that
somebody
has
you
know
taking
it
and
taking
ownership
of
it
as
opposed
to
an
event
stream
where
it's
like
this
happened.
I
omit
this
event.
D
C
I'm
gonna
go
down
a
kind
of
a
weird
topic
kind
of
associated
with
what
we're
just
talking
about,
but
I'm
gonna
get
a
little
bit
more
into
the
weeds
of
networking,
and
this
is
actually
kind
of
directed
at
Josh
in
a
way.
So
talking
about
like
the
kind
of
parallels
between
networking
and
development
in
networking,
at
least
with
TCP
networking,
there
is
a
there's
something
called
csma/cd
which
is
carrier
sense,
multi,
I,
hope
carry
since
multi
I
can't
read
the
a
stands
for
and
then
the.
B
C
A
C
B
C
B
I
mean
satellite
stuff
too
right,
it's
not
just
it
mean
it's
actually
any
any
shared
media
upon.
You
have
to
you,
get
you
where,
where,
if,
if
the
signals
overlap
there
you're
not
going
to
be
able
to
make
it
work
right,
and
so
I
mean
it
is
interesting,
it's
actually.
It
is
an
interesting
parallel,
I'm
struggling
because
think
of
a
to
think
of
an
example
of
this
as
well.
I
mean,
like
my
brain,
is
kind
of
going
towards
circuit
breaking,
but
I.
B
A
Where
my
head
was
kind
of
going
with
it,
but
I
think
it's
I
think
it's
pretty
off
is
like,
unlike
in
like
a
low-level
piece
of
code
like
maybe
something
you
write
and
Siri,
implement
your
own
cue
in
memory
and
then
like
multiple
threads
are
firing
off
at
the
same
time
and
there's
no
like
lock
system
or
mechanism.
If
two
threads
contend
to
put
something
in
the
same
memory
space
that
that
cue
represents
that's
really
going
down
the
rabbit
hole.
D
The
other
thing
that
came
to
mind
to
me
was
like
some
sort
of
session
multiplexing
right
where
you're
running
multiple
application,
layer
sessions
inside
a
single
sort
of
network
connection
and
those
Network
sessions
getting
commingled
in
some
fashion,
whether
through
identifiers
or
sequence,
numbers
or
something
else
of
that
nature,
and
therefore
you
know
garbling
the
the
ultimate
communication.
That's
trying
to
be
yes,
sent.
B
D
B
Can
you
think
of
a
software
pattern?
Can
anybody
here
think
of
a
software
pattern
that
maybe
doesn't
what
doesn't
come
across
that
way
right
when
you're
thinking
about
some
of
the
patterns
that
you
that
you
see
today
in
in
cloud
native
applications?
Is
there
it's
not
like
a
counter
example,
something
that
the
network
does
not
do
at
all
or
you
know.
C
B
D
B
They
do
it
in
some
pretty
interesting
ways
like
I
mean
if
you,
if
you
were
to
consider
like
what
we
call
it
spanning
tree
right.
The
idea
that
the
idea
that
there
can
really
only
be
one
path
through
a
series
of
broadcast
domains,
because
if
you
have
multiple
paths
and
obviously
you're
gonna
get
duplicity
and
the
things
are
gonna
get
bad
because
you're
gonna
have
packets
that
are
address
to
the
same
things
across
and
you're
gonna
have
all
kinds
of
bad
behaviors,
switching
loops
and
custom
broadcast
storms
and
all
kinds
of
stuff
like
that.
B
The
challenge,
of
course,
is
a
is
that
there's
a
transition
period
in
which
we
didn't
in
which
we
can't
in
which
we
lose
traffic,
because
we
haven't
been
able
to
open
one
of
those
other
paths
fast
enough
right,
and
so
it's
it's
not.
It
is
interesting
to
think
about
how
the
network
is
trying
to
solve
the
product
that
the
same
set
of
problems
that's
described
by
the
cap
theorem,
but
that
we
that
we,
you
know
that
we
see
people
trying
to
solve.
What's
not
working
I.
D
Mean
I
totally
agree
and
in
a
case
like
spanning
tree,
you
know
you
are.
You
are
sacrificing
availability
essentially
right
for
consistency
and
partition.
Tolerance
in
that,
when
the
network
achieve
consistency
then
will
be
restored
so
and
there's
other
ways
of
doing
that.
So
as
we
move
into
systems
like
you
know,
I
mentioned
cloth
fabrics
earlier
right.
D
You
know
a
cloth
fabric
is
a
different
way
of
establishing
establishing
a
solution
to
that,
and
that
is
saying
you
know,
add
layer,
two
I,
don't
I,
don't
I'll,
have
you
know
sort
of
multiple
connections,
but
I
will
I
will
wait.
Those
connections
using
a
higher
level
protocol
and
I
will
sacrifice
consistency
in
terms
of
how
the
routes
are
exchanged
to
get
across
that
fabric
in
exchange
for
every
the
ability
of
partition
tolerance.
D
B
Also
find
it
kind
of
kind
of
I
personally
find
it
kind
of
funny
that,
like
you
know
in
the
calf
theorem,
there
is
no
at
no
point
do
we
mentioned
complexity
right
like
we
just
we're
just
trying
to
get
all
three
and
we
don't
care
if
complex'
we
just
like,
and
it's
the
same
time
like
as
a
consumer
over
all
of
these
systems.
You
you
care
a
lot
about
the
complexity.
I
hear
it
all.
B
B
I'm
busy,
trying
to
figure
out
how
to
make
my
application
work
right,
like
a
cognitive
load
is
a
thing
right,
like
I,
can
only
really
focus
on
so
many
things
that
at
a
time
where
am
I
going
to
spend
my
time
am
I
gonna
spend
it
learning
how
to
do
plumbing
or
am
I
gonna
spend
it
actually
trying
to
write
an
application
that
solves
my
business
problem.
Right,
it's
it's!
It's
an
interesting,
interesting
thing.
C
So
something
that
a
little
bit
ago
and
I
wanted
to
come
back
to
as
we're
kind
of
wrapping
up.
So
we
mentioned
sup
for
Defined
Networking,
which
is
pretty
well
defined.
It's.
How
do
you
define
how
your
network
wants
to
look
via
whatever
software?
It
is
that
you're
using?
How
do
we
think
that
suffer
Defined
Networking
played
into
the
rise
of
cloud
like
cloud
technologies
altogether.
C
B
Think
it's
actually
one
of
the
more
interesting
overlaps
in
the
in
the
in
the
space,
because
I
think
josh
is
born
again
like
this
is
where
we,
this
is
where
we
were
taking
me
like
I
worked
for
I
worked
for
a
company
called
nice
here
in
which
we
were
met.
We
were
virtualizing
the
network,
and
this
was
fascinating
because
effectively
we're
looking
at
this
as
a
network
as
a
software
service
that
we
had
to
bring
up
and
build
and
build
reliably
and
and
scalable
or
reliably
and
consistently.
B
If
there's
a
huge
amount
of
crossover
here
like
this
is
actually
where
I
think
the
waters
meet,
you
know
like
between
the
develop
the
the
way
that
developers
think
about,
though
the
the
problem
and
the
way
that
network
engineers
think
about
the
problem.
But
it's
been
a
rough
road.
I
will
say:
I'll
say
that
Sdn
I
think
is
actually
has
definitely
thrown
a
lot
of
network
engineers
under
their
heels.
B
You
know,
because
they're
like
wait,
wait,
but
that's
not
a
network,
and
you
know,
because,
like
I
can't
actually
I
can't
I
can't
look
at
it
and
characterize
it
in
the
way
that
I
am
I
am
accustomed
to
looking
at
and
care
characterizing,
the
the
other
networks
that
I
play
with
and
then
from
the
software
side.
You're
like,
but
maybe
that's,
okay
right
like
maybe
that's
enough.
B
D
Not
even
knowing-
and
you
know-
maybe
you
guys
all
do
know
but
like
I'll,
even
know
that,
aside
from
a
few
tidbits
here
and
there,
that
AWS
is
even
kind
of
divulged,
the
details
of
how
things
work
under
the
covers
for
VP
C's
right
but
I
I
can't
imagine
that
any
modern
cloud
networking
solution
can,
whether
it
be
VP,
C's
or
V
Nets
or
whatever
doesn't
have
a
significant
software-defined
aspect
to
it.
You
know
we
don't
need
to
get
into
the
definitions
of
you
know
what
Sdn
is
or
isn't.
That
was
a
big
discussion.
D
Duffy
and
I
had
you
know
six
years
ago,
right,
yeah,
but
but
there
there
has
to
be
some
part
of
it
that
that
is
taking
and
and
using
the
concepts
that
are
common
in
Sdn
right
and
applying
that,
just
just
as
the
same
way
as
that,
the
cloud
vendors
are
using
the
concepts
from
from
compute
virtualization
to
enable
what
they're
doing
I
mean
like
the
reality
is
that
you
know
the
work
that
was
done
by
you
know.
The
Cambridge
folks
on
Zen
mm-hmm
was
a
massive,
a
neighborhood
for
AWS
right.
D
A
And
on
that
latter
point,
you
know
as
a
consumer
of
this
new
software-defined
nature
of
networking
like
it's
amazing,
the
amount
of
I
don't
start
to
use
like
a
blanket
marketing
term
here,
but
agility
that
it's
added
right,
because
it's
turned
all
these
constructs
that
I
used
to
file
a
ticket
and
follow
up
with
people
into
self-service
things
that,
when
I
need
to
poke
holes
in
the
network.
Hopefully
you
know
the
rights
are
locked
down,
so
I
can't
just
open
it
all
up,
but
assuming
I
know
what
I'm
doing
and
the
rights
are
correct.
A
It's
totally
self-service
for
me:
I
go
into
AWS,
I
change,
a
security
group
role
and
boom
the
ports
have
changed,
and
it
never
looked
like
that.
Prior
to
you
know
this
full
takeover
of
what
I
believe
is.
You
know
Sdn
almost
end-to-end
in
the
case
of
AWS
and
so
on.
So
it's
really
just
not
only
has
it
made.
People
like
myself
have
to
understand
more
about
networking,
but
it's
allowed
us
to
self-service
a
lot
of
the
things
that
I
would
imagine.
Most
network
engineers
were
probably
tired
of
doing
anyways.
A
C
I
can
speak
from
experience
and
I
think
a
lot
of
network
engineers
kind
of
get
into
that
field
because
they
really
love
control,
so
they
want.
You
know
they
want
to
know
what
these
ports
are,
that
are
opening,
and
it
is
kind
of
scary
to
be
like
this
person
has
opened
up
these
ports.
Wait.
What
like,
without
them
even
totally
know
I
was
generalizing.
I
was
more
speaking
to
myself.
I
was
being
self-deprecating,
it.
A
Does
not
I
mean
it
is
a
really
interesting
point,
I
mean:
do
you
think
it
makes
the
networking
people
or
network
engineers,
maybe
a
little
bit
more
into
the
realm
of
observability
and
like
knowing
when
to
trigger
when
something
has
gone
wrong
you
know,
does
it
make
them
more
reactive
in
their
role,
I,
guess
or
maybe
self-service
is
not
as
common
as
I
think
it
is
it
just
from
my
point
of
view,
it
seems
like
with
SD
ends
the
ability
to
modify
the
network.
More
power
has
been
put
in
the
developers.
B
You
could
quickly
provision
those
10
servers
on
behalf
of
that
developer
and
head
them
right
back
right.
You
wouldn't
have
to
go
out
and
get
10
new
machines
and
put
them
into
a
rack
power
them
and
provision
them
and
go
through
that
whole
process
that
you
could
actually
just
stamp
those
things
out
right,
and
that
is
absolutely
a
parallel
to
the
network
piece
of
well,
you
know
as
well
I
mean
if
there's
nothing
else
that
Sdn
did
bring
to
the
fore.
B
Is
that
right
that
you've
been
that
you
can
get
that
same
capability
of
just
stamping
out
virtual
machines,
but
with
networks
right
that
that
that
the
API
is
important
in
almost
everything
we
do,
whether
it's
a
service
that
you
were
developing
or
whether
it
is
a
whether
it's
the
network
itself,
whether
it's
the
firewall
but
like?
We
need
to
do
these
things.
Programmatically
I,.
D
Would
I
agree
with
you
defi,
although
I
would
contend
that
the
one
area
that
and
I'll
call
it
on-premises
Sdn?
Shall
we
say
right,
which
is
you
know
the
people
on
putting
in
Sdn
solutions,
I'd
say
the
one
area,
at
least
in
my
observation
that
that
they
haven't
done
well?
Is
that
self-service
model
like
in
the
cloud
self
services
is
paramount
right
to
Josh's
point
like
they
can
go
out
there?
They
can
create
their
own
B
pcs,
create
their
own
subnets
create
their
own.
D
You
know
nat
gateways,
Internet
gateways,
their
own
security
groups,
load
balancers,
blah
blah
all
that
right,
but
it
still
seems
to
me
that,
even
though
we
are
probably
you
know,
ninety
ninety-five
percent
of
the
way
we
there
may
be
farther
in
terms
of
on-premises
Sdn
solutions
right
that
you
still
typically
don't
see,
self-service
being
pushed
out
in
the
same
way,
you
would
the
public
cloud
right,
like
that's.
That's
almost
of
the
final
piece
that
is
needed
to
bring
that
cloud
experience
to
the
on-premises
environment
and.
B
It's
a
problem
to
solve
in
that
space
right,
so
I'm
going
to
look
at
things
like
OpenStack
and
things
like
AWS
and
things
like
G
key
or
none
cheeky,
but
GCE,
and
in
areas
like
that,
it
is
a
requirement
that
if
you're
gonna
provide
infrastructure
as
a
service
that
you
provide
some
capability
around
networking.
But
at
the
same
time,
if
we
look
at
some
of
the
platforms
that
are
used
for
things
like
cloud
native
applications,
things
like
kubernetes,
what's
fascinating
about
that
is
it
like.
We
have
kind
of
a.
B
We
have
agreed
on
a
least
common
that
we
we
agreed
on
a
an
abstraction
of
networking,
as
that
is
maybe
I,
don't
know,
might
be
a
little
more
pretty
cooked.
You
know
I
mean
like
in
the
assumption,
within
like
most
of
the
platforms
as
a
service
that
I've
seen.
The
assumption
is
that,
when
I
create,
when
I
deploy
a
container
or
I
deploy
a
pod
or
I
deploy,
some,
you
know
function
as
a
service,
or
any
of
these
things
that
the
networking
is
going
to
be
handled.
B
For
me,
like
I,
shouldn't,
have
to
think
about
whether
it's
being
routed
to
the
internet
or
not,
or
routed
back
and
forth
between
these
domains.
I
should,
if
anything,
only
I
have
to
actually
give
you
intent,
be
able
to
describe
to
you
the
intent
of
what
of
what
could
be
connected
to
this
and
what
and
what
ports
I'm
actually
going
to
be
exposing
and
that
and
that
the
platform
actually
hides
all
of
the
flex
appeal
that
network
away
from
me,
which
is
which
is
an
interesting
ground
strike.
D
So
this
is
like
one
of
my
favorite
favorite
favorite
things
like
one
of
my
favorite
distinctions
to
make
right,
and
that
is
like
this
is.
This
is
the
two
worlds
that
we've
been
talking
about:
applications
and
infrastructure,
right
and
and
and
and
the
perfect
example
of
these
different
perspectives.
And
you
even
said
it
in
in
your
in
your
in
your
talk
to
Duffy
like
from
an
ayahs
perspective.
D
But
when
you
look
at
the
abstractions
that
have
been
created
in
the
cloud
data
space
like
within
kubernetes,
they
are
application,
centric
right
and
so
we're
talking
about
infrastructure,
artifacts
versus
application,
artifacts
right
and
and
they
end
up
meeting.
But
they
are
coming
at
this
from
two
different,
very
different
perspectives.
Yeah.
B
Yeah
green
all
right.
Well,
that
was
a
great
discussion.
I
imagine
that
we're
probably
going
to
get
into
I
at
least
have
a
couple
of
different
networking
discussions
that
I
wanted
I
wanted
to
dig
into,
and
this
conversation
I
hope
that
we've
we've
we've
helped
kind
of
draw
some
parallels
back
and
forth
between
the
way
that
I
mean
both
there's
there's
some
empathy
to
spend
here
rightly
I
mean
like
the
people
who
are
providing
the
service
of
networking
to
you
in
your
cloud
environments
and
in
your
in
your
data.
B
Centers
are
solving
almost
exactly
the
same
sorts
of
availability,
problems
and
capabilities
that
you
are
trying
to
solve
with
your
own
software
and
I
think
that
itself
is
a
really
interesting
takeaway.
Another
one
is
that,
like
again,
there's
nothing
new
Under.
The
Sun,
like
the
problems
that
we're
trying
to
solve
in
networking
are
not
different
than
the
problems
that
you're
trying
to
solve
in
applications.