Mark Burgess is one of the originals -- a long-time thought leader and key inventor in the field, as well as founder and CEO of CFEngine. Mark's also author of IMO the single finest academic treatment of Configuration Management around -- the vastly under-rated and important Analytical Network and System Administration: Managing Human-Computer Systems (Kindle version here).
Mark really used his own evolution with the product CFEngine as a way of illustrating and navigating the evolution of certain aspects of the industry in general. I’ve retained most of those mentions, although I’m usually pretty ruthless in editing product names out in this series, as some folks have mentioned to me. (That's because I want the conversations to be about the insights and the methods, not chest-thumping about the product names and propoganda about methods.)
His podcast is available here.
My excerpts are as follows:
And I had some additional questions for Mark after going through the podcast (and assembling the above excerpts).
[Special note: Jive is a very special platform where Jive has gone out of its way to make a generic standard as custom and Jive-specific in HTML as possible. Don't even bother looking for h1 tags. So, in the following my questions are in "jive quote" form and Mark's answers in-line. Check out the JIve-generated HTML, it's gross. I'm always surprised that developers don't feel embarrased when they implement this design-cruft.]
Anyway, here we go:
Do you have the article reference for the "computer immunology" paper you read in the 90s that forged some of your seminal thinking?
See here for many references http://cfengine.com/markburgess/sysadmin.html
Now that the evolution has moved beyond the second phase of just standing up herds of servers rather (than worrying about maintaining the health of the servers as in the first phase) and the new reality is having to worry about scaling up and scaling out -->> returning to the health of servers, even with virtualized or totally replaceable cattle servers -- is the state-of-the-art to return to a mindset around computing immunology?
I think so, with some modifications that would be a whole new podcast....
Many of the current sysadmin thinking focus on performance metrics in the form of UX-oriented goal lines and times. Yet DevOps has a focus on the end-to-end composition which also includes the app business production cycle itself. Do you have any thoughts about this and what we can expect to see?
This is the stuff of promise theory. I think that automation design needs to advance here. People are still thinking scripting, but should be thinking steady-state continuous delivery
"Pushing away configuration management" -- even as it becomes more important — in the way that we're no longer also mechanics to be car drivers -- is curiously a concept that comes up a lot in this series! [...] So, natural q: Will there be a point in time where it is as encapsulated (or abstracted for simplicity) as turning the tap on for running hot and cold water? Will that eliminate the need for DevOps thinking?
Yes, I said in an O'Reilly interview that I can see is being somewhat like the thermostat on your heating in the future. Most of the details will be hidden under the covers in standard methods, and only a few will actually design heating systems. Most people will just turn up the thermostat.
What will that next-gen tap-water generation of tooling look like? [...] will it bear little resemblance to today's CFE or Puppet or Chef or BladeLogics? And it would be about more than services as we currently employ the term?
More like a sound mixing desk, turn down the volume on Amazon, a bit more Joyent ... But then there will be a mission control for the cloud companies that will probably end up being generalized utilities for infrastructure.
Will the next gen change the interrelationship between configuration and/or deployment management (focus on required CI) and release automation (focus on workflow) or will those distinctions go away?
I think there will always be a difference between infrastructure and what is built on top of it, but that is a process of continuous evolution.
Hands-free automation vs. "autonomation" -- where autonomation is used as a boon for humans to manage complexity, rather than a replacement for the humans -- is a recurring theme in DevOps and often in your interview. Is there a statement about their relationship and DevOps that is important to consider?
I don't see these things as being very different. Things have to be hands-free to scale, but there will be different kinds of knobs to turn, more like autopilots, fly by wire etc. This is also the subject of a whole book....which I am thinking about(!)