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.
No comments:
Post a Comment