►
Description
Network automation does not an automated network make. Today’s network engineers are frequently guilty of two indulgences. First, random acts of automation hacking. Second, pursuing aspirational visions of networking grandeur — complete with their literary adornments like “self-driving” and “intent-driven” — without a plan or a healthy automation practice to take them there.
Can a Middle Way be found, enabling engineers to set achievable goals, while attaining the broader vision of automated networks as code? Taking some inspiration from our software engineering brethren doing DevOps, I believe so.
Here we discuss how NOT to automate and set the groundwork for network reliability engineering (NRE) culture and behaviors of DevNetOps
Original article shared by:
https://thenewstack.io/end-network-automation-know-feel-fine/
Original blog:
https://jameskelly.net/blog/2017/7/25/its-the-end-of-network-automation-as-we-know-it-and-i-feel-fine
Date:
July 5, 2017
image credit Bell System telephone switchboard, circa 1943, from the U.S. National Archives.
A
Welcome
back
to
another
edition
of
my
blog,
this
is
James
Kelly,
it's
July
25th.
This
article
is
called
it's
the
end
of
network
automation,
as
we
know
it
and
I
feel
fine,
and
this
article
was
originally
posted
on
July
5th.
Actually,
on
the
new
stack,
you
can
visit
the
new
stack
at
the
new
stack
I.
Oh,
you
can
visit
the
article
directly
because
there's
a
direct
link
on
my
blog,
the
blog
posted
on
James
Kelly,
dotnet,
slash
blog
and,
of
course
that
means
that
I
need
to
give
a
big.
A
Thank
you
to
the
new
stack
for
posting
it
there
first.
As
always,
if
you
want
to
get
access
to
these
first,
you
can
also
just
follow
me
on
LinkedIn
right
away.
We
go
it's
the
end
of
network
automation
as
we
know
it
and
I
feel
fine
network
automation.
Does
not
an
automated
network
make
today's
network
engineers
are
frequently
guilty
of
two
indulgences.
First,
random
acts
of
automation:
hacking,
second,
pursuing
aspirational
visions
of
networking
grandeur
complete
with
their
literary
adornments
like
self-driving
and
intent,
driven
without
a
plan
or
healthy
automation,
practice
to
take
them.
A
There
can
a
middle
way
be
found
enabling
engineers
to
set
achievable
goals
while
attaining
the
broader
vision
of
automated
networks
as
code
taking
some
inspiration
from
our
software
engineering
brethren
doing
DevOps
I
believe
so
how
not
to
automate
yeah
there's
a
phrase
going
around
in
our
business.
To
err
is
human
to
propagate
errors.
Massively
at
scale
is
automation.
A
Automation
is
a
great
way
for
any
organization
to
speed
up
bad
practices
and
hashtag
fail
even
bigger.
Unfortunately,
when
your
business
is
network
ops,
the
desire
to
be
a
cool
ops,
kid
with
some
dev
chops,
as
opposed
to
just
a
CLI
jockey,
will
quickly
lead
you,
the
automation
road
that
road
might
not
lead
you
to
those
aspirational
goals,
although
it
certainly
could
expand
your
blast
radius
for
failures
before
we
further
contemplate,
self-driving
intent,
driven
networking
and
every
other
phrase.
A
That's
all
the
rage
today,
although
I'm
just
as
guilty
of
such
contemplation
as
anyone
else
at
Juniper,
we
should
take
the
time
to
define
what
we
mean
by
proper
in
the
phrase
building
an
automated
network
properly.
If
you
haven't
guessed
already,
it's
not
about
writing.
Python
scripts
programming
is
all
well
and
good,
but
20
minutes
of
design
often
really
does
save
about
two
weeks
of
coding.
In
other
words,
to
start
hacking
at
a
problem
right
away
is
probably
the
wrong
approach.
A
You
need
to
step
back
from
your
goals,
think
about
what
gives
them
meaning
and
apply
those
goals
to
the
broader
picture
and
plan
accordingly
to
see
what's
possible
with
automation,
we
should
look
at
successful
patterns
of
automation
outside
of
networking
and
the
reasons
behind
them.
So
we
may
avoid
the
known
bad
habits
and
the
anti
patterns
in
sidestep
those
avoidable
pitfalls
for
well
tested
patterns
of
automation.
We
needn't
look
any
further
than
the
wealth
of
knowledge
and
experience
in
the
area
of
DevOps.
A
Yes,
it
also
matters
what
we
call
things
for
better
or
worse,
a
name
focuses
the
mind,
the
overall
IT
strategy
to
improve
speed,
resilience,
quality
and
intelligence
of
our
apps,
and
our
software
is
not
called
automation.
It's
not
even
called
orchestration
now,
while
ITIL
volumes
steadily
make
their
march
into
the
museums.
The
new
strategy
to
enable
business,
speed
and
smarts
is
incontrovertible,
and
it's
called
DevOps
now
initially.
That
term
may
invoke
a
blank
page
or
even
a
transformation
conundrum,
but
you
can
learn
what
it
means
to
practice.
A
Successful,
DevOps
culture
processes
does
nine
tooling
and
coding.
Devops
can
refine
your
approach
to
the
network
and
that's
why
we
ought
not
promote
network
automation
which
could
focus
the
mine
on
the
wrong
objectives
and
instead
talk
about
dev
net
ops
as
the
application
of
patterns
of
DevOps
applied
to
networking
networks
as
code,
the
idea
of
infrastructure
is
code
has
been
around
for
a
while,
but
surprisingly
has
seldom
being
applied
to
networking
Juniper
Networks,
where
I
hang.
A
My
hat
and
other
networking
vendors
like
apps
tray,
have
made
some
efforts
over
the
years
to
move
folks
in
this
direction,
but
there's
still
a
lot
of
work
to
do.
For
example,
juniper
has
had
virtual
form
factors
of
most
series
of
hardware
systems.
They've
had
projects
like
Juno
sphere
for
network
modeling
in
the
cloud
many
of
us
now
use
Ravello
and
impressive
presentations
on
IAC
and
professional
services.
Consulting
juniper
senior
marketing
director
Mike
Bhushan,
formerly
with
plexi,
wrote
about
the
network
as
code,
even
all
the
way
back
in
2014,
IAC
or
infrastructure.
A
As
code
is
generally
well
applied
to
cloud
infrastructure,
but
it's
way
harder
to
apply
to
networking
and
things
like
bare
metal
for
evidence
of
this,
just
look
at
triple
o
kubernetes
on
kubernetes
or
kubernetes
on
OpenStack
on
kubernetes.
Oh,
my
that
bottom
metal
layer
is
quite
the
predicament
to
me.
This
means
in
networking
we
should
easily
be
applying
IAC
to
Software,
Defined,
Networking
or
Sdn,
but
can
we
apply
it
to
network
devices
and
to
manage
the
physical
network?
A
I
asked
Siri,
and
she
said
it
was
a
trick
question
as
an
armchair
architect,
myself,
I,
don't
have
all
the
answers,
but
as
I
see
it
here
are
some
under
considered
aspects
for
designing
networks
as
code
with
dev
net
ops,
one
tooling
in
tech,
everyone
loves
shiny
objects.
So,
let's
start
there.
Few
network
operators,
even
those
who
have
learned
some
programming,
are
knowledgeable
about
the
ecosystem
of
DevOps,
tooling,
and
few
consider
applying
those
same
tools
to
networking.
The
point
is
learning
Python
and
ansible
is
really
just
scratching
the
surface.
A
There's
a
vast
swath
of
DevOps
tools
for
CI,
CD
site
reliability,
engineering
and
at
scale
cloud
native
ops
to
chain
the
tool
chain.
A
pipeline
is
code
when
we
approach
the
network
as
code,
we
need
to
consider
network
elements
and
their
configurations
as
building
blocks
created
in
a
code
development
pipeline
of
dev
test
staging
production
phases
stringing
together
this
pipeline
shouldn't
be
a
manual
process.
It
should
be
mostly
coded
to
be
automatic,
just
as
with
software
engineering.
A
There
are
hardware
and
foundational
software
elements
with
network
engineering
such
as
operating
systems
that
the
operator
will
not
create
themselves,
but
rather
just
configure
and
extend.
So
these
configurations
and
extensions
with
their
underlying
dependencies
can
be
built
together,
versioned
tested
and
delivered
thinking
about
the
network
as
an
exercise
in
development.
Automation
should
start
in
the
development
infrastructure
itself.
A
Three
immutable
infrastructure,
virtualization
and
especially
containers
have
made
the
concept
of
baking
images
very
accessible
and
immutable
infrastructure
popular
while
there's
still
much
work
to
do
with
network
software,
disaggregation,
containerization
and
decoupling
of
services.
There
are
many
benefits
of
adopting
immutable
infrastructure
that
are
equally
applicable
to
networking.
Today's
network
devices
are
really
the
poster
children
for
config
drift.
I
have
to
call
them
snowflakes.
Well.
That
would
be
an
insult
to
actual
snowflakes,
applying
principles
of
immutable
infrastructure.
I.
A
Imagine
a
network
where
each
device
pixie
boots
into
a
minimal
OS
and
runs
signed
micro
service
building
blocks.
Each
device
has
declarative,
configs,
decoupled
secret
management
and
rotation
and
logging
and
other
monitoring
data
with
good
overall
audit
ability
and
traceability,
all
of
which
is
geared
to
take
the
network
and
its
data
off
the
box.
Asap.
A
A
You
can
only
do
that
in
maintenance
windows,
NT
pattern,
number
for
upgrades,
upgrades
to
network
software
and
even
firmware
micro
code
or
devices,
could
be
managed
automatically
by
means
of
canary
tests
and
rolling
upgrade
patterns.
To
do
this
on
a
per
box
or
per
port
basis,
or
at
finer
levels
of
flows
or
traffic
processing
components.
We
need
to
be
able
to
orchestrate
traffic
balancing
and
draining.
If
that
sounds
complex,
it
is
slightly.
A
We
can
make
things
simpler,
we
can
treat
devices
and
their
traffic
like
cattle
instead
of
pets
and
then
just
rely
on
their
resilience,
killing
and
then
resurrecting
a
component
would
restart
it,
but
with
a
new
version.
Now,
while
this
is
actually
suitable
for
many
in
some
software
applications,
treating
traffic
as
disposable
is
not
yet
desirable
for
all
network
applications
and
SLA
s,
but
still
it
would
go
a
long
way
toward
properly
designing
for
resilience,
which
brings
us
to
number
five
resilience.
A
One
implication
of
all
of
this
is
the
presence
of
redundancy
in
the
network
paths.
As
with
any
networking
component,
that's
very
important
for
resilience,
drawing
inspiration
from
scale
out
architectures
in
DevOps
and
the
micro-services
application
model.
Redundancy
and
scale
would
go
hand-in-hand
by
means
of
instance,
replication,
so
redundancy
would
neither
be
one-to-one
nor
active/passive.
A
We
should
always
be
skeptical
of
architectures
that
include
those
anti
patterns.
Good
design
would
tolerate
a
veritable
networking
chaos,
monkey
burning
down
network
software.
It
would
just
circuit
break
to
limit
failures,
killing
links
and
even
boxes.
We
would
quickly
reconverge,
as
we
often
do
today,
but
dead
boxes,
dead,
Sdn
functions
or
dead.
Virtual
network
functions
would
act
like
Phoenix
servers,
rising
back
up
or
staying
down
in
the
case
of
repeated
failures
or
detected
hardware
failures.
A
The
pattern
for
preventing
these
Black
Swan
event
failures
is
to
practice
forcing
these
failures
and
thus
practice
automating
around
them,
so
that
the
connectivity
or
other
network
service
and
its
performance
is
tolerant
and
acceptable.
Ira's
its
own
SLA
measuring
stick
whatever
the
meta
service
in
question
may
be
doing
dev
net
ops
in
each
one
of
these
above
topics
lies
much
more
complexity
than
I
will
dive
headfirst
into
here.
A
A
That's
the
sound
you're
likely
to
hear
from
your
own
forehead.
What's
the
obviousness
of
applying
DevOps
to
dev
net
ops
in
networking
hits
you
squarely
in
the
face,
just
as
the
hardest
part
of
adopting
DevOps
is
often
cited
actually
to
be
breaking
off
one
manageable
goal
at
a
time
and
then
focusing
on
just
that.
A
Don't
boil
the
ocean
I
think
we'll
find
the
same
as
true
of
dev
net
ops
before
we
even
get
there
in
networking
I
think
we
need
to
sculpt
the
transformation
properly
of
applying
dev
net
ops
to
the
challenges
and
design
of
networking,
especially
with
issues
of
basic
physical
connectivity
and
transport
while
quotes.
Network
automation
leads
the
mind
to
jump
to
things
like
applying
configuration,
management
and
programming.
Today's
manual
tasks
don't
jump
dev
net
ops.
A
It
should
remind
us
in
that
word
that
there
is
a
larger
scope
than
mere
automation
coding
and
that
scope
includes
culture,
processes,
design
and
tools.
Collectively
they
may
all
lead
us
to
a
happier
place
all
right.
That's
it
thanks
again
for
tuning
in
and
remember,
kids
always
look
both
ways
before
crossing
the
automation,
Avenue.