New Book - Network Programmability and Automation

Several people have asked me what I thought the future of a network engineer looks like.

I didn't have a great answer for them, other than it would look different, but is still needed:  abusedbits: Modern Network Engineering

If you want to see how it'll be different, Jason Edelman, Scott S. Lowe, Matt Oswalt are authoring a book being published by O'Reilly called Network Programmability and Automation.

I've looked at this book and I believe it is a basis for the answer we're all looking for.

Network Programmability and Automation - O'Reilly Media

This book is currently Early Release, so there may be some rough edges yet.

I will comment more on it as time permits.

Episodic Intransience vs Immutable Infrastructure

Anytime you hear someone using the term Immutable Infrastructure, you are allowed to giggle, snork and/or laugh.  Servers, Networks and Storage are not immutable, they never will be.  If you write about, have recently presented on, or otherwise define, discuss or profess Immutable Infrastructure, my apologies.

Keep in mind, Immutable is the equivalent of Willie Wonka's Everlasting Gobstopper.

Immutable means that the device, construct or mechanism is unchanging or unable to change.  Abstract it as much as you like and some underlying subsystem is absolutely guaranteed to cause change.

With today's infrastructure, we are guaranteed it will physically change sometime within 7 years.  That's typical of equipment vendor product refresh.  Plus purchasing infrastructure equipment without the continuous improvement provided by product evolution cycle would result in some extremely old school equipment.  Not to mention that memory use is transient, storage is needfully consumed and the network bursts and caches as needed.  And, don't get me started on drivers.  The equipment infrastructure is not immutable.

The operating system is guaranteed to change much more rapidly, with patch release examples measured in days or weeks, the operating system infrastructure is not immutable.

Virtualization system, changes literally on demand, be it manual or automated.  So, not immutable. 

Some of the Docker aficionados talk about an immutability in the container delivery pattern.  This is tied to a repeatable, to the tune of possibly minutes,  application development process.  If it is immutable, why would it ever need to be repeatable (changing).  Just saying, it's not.

In this I tend to concur with John Willis, "no example in my 35 years of working with IT infrastructure of a system or infrastructure that is  completely immutable…"

So, what are we really talking about?  It's not immutability in any of the delivery patterns associated with modern application development.

What we are taking about is a level of intransience certainly.  The architectural pattern must be well defined, repeatable and largely inexhaustible.  It's more like Episodic Intransience, where change/improvement/SCRUM cycle delivery exist between durations of intransience.