Here's an interesting take on the notion of treating computers like people. I think it has been well established that it is a bad thing to treat individual machines like individuals (pets, works of art, etc...). But I just came to a realization that it may not be bad to treat systems of machines like communities of people. After listening to the Devops Cafe podcasts with Mark Burgess and Adam Jacob and hearing their thoughts on orchestrating activities in the datacenter and while I'm reading the excellent "Lean IT" these thoughts started to gel. Now I'm sure others have thought this and probably written about it, but it's a new idea for me and I haven't heard it put this way.
The basic idea is that the techniques used to manage teams of people may be analogous to the ways to effectively orchestrate systems. Adam is working hard on how to make the individual actors (machines) take a strong role in decision making. This is like the Lean philosophy of the "Gemba" where the people on the floor are most effective at solving problems, and the all-knowing manager is not as effective. The manager's job is to set The Standard and to keep tabs that The Standard is met, but ideally to dictate as little day-to-day action as possible.
The good/bad thing in this is that each actor is a computer with it's own set of outside influences. Just like people and a factory floor there are subject to random events. But these actors are also code where we can specify how they behave to certain stimuli. They aren't subject to moods like people, but they are limited by our ability to code their behaviors and responses. Here is where Mark Burgess's AI experience can make cfengine4 leapfrog the competition by making the best code-representation of an actor with the best decision-making capabilities.
What are your thoughts?
Honestly, I think Mark Bugress is spot on with his new Promise Theory (actually 8 yrs old now). His first idea, the new Infrastructure as code (IAC), is going to be 20 years old in 2013. It took over 10 years for people to understand the value of IAC and it will probably be another couple of years before people understand Promise Theory. He was dead on the first time so what makes us think he is wrong this time. In fact, I believe, he is not wrong. I have had to opportunity to hang out with Mark on a few occasions over the past year and here is my take on why not only Promise Theory is is the right answer.
ReplyDeleteIn an IT world that is growing in complexity and scale it is going to be extremely difficult to manage system in what Mark describes as "obligation management" model. Products like Chef and Puppet are primarily obligation management forms that are for the most part deterministic in nature. Puppet and Chef do support some forms of non determinism via convergence, Puppet with use of a directed graph and Chef using a search API. However, both are primary deterministic in nature. They define a desired state and obligate the agents to make it conform. Promise Theory provides an alternative approach to obligation management and it's primarily invoked as a cooperation form. In a cooperation model there is no top down mandate to obligate. With Promise Theory agents work in an autonomous automation system. The agents cooperate, that is they promise to get to a specific state. More importantly in complex systems they don’t guarantee their state and everyone else in the system should realize that. The handshake in a cooperative system is that at any given time it is probable, not deterministic, that everyone is living up to their promises. I would add that it is dangerous in complex IT infrastructure to assume any other model other than cooperative forms.
The primary idea is that as complexity and scale grow it is going to be extremely hard to obligate systems to a cooperate state; whereas systems will have to try their best and we will only be able to predict their results. What Mark is saying is that when we reach a certain level of scale and complexity our only hope of managing these systems will be through probability and cooperation. If you think he is crazy, think again, or better yet don't get on an airplane next time you plan on traveling. Modern day Jets are a great examples of a cooperative probability-driven model. Pilots interact with autonomous automation systems that provide predicable outcomes. The pilot relies on the planes autonomous automation to mask the inherent complexity of maintain safe air travel.
This is a long way to say I think you are spot on about “systems” becoming more like people (at least desirable devopsian lean practicing people).
Great stuff Botchagalupe. I'm not saying anything new and am in a way flipping what you said around and putting different words on it. I noticed that when you think of a computer as an actor you can apply some rules like they are people. Cooperation isn't enough. Why not turn "Continuous Improvement into code". and "Quality at the source" into code. Dare I say, turn "Culture" into code so that the systems all, in a way, know what is expected of them and want to meet the standard.
DeleteIn reading "Lean IT" I came across this in the chapter on Performance Management. "A sound performance measurement strategy is a critical foudation for successful and sustaining continuous improvement. Standardized work creates a stable process baseline for improvement, then measurements provide constant feedback on how well those standards are performing, helping the teams determine where best to focus the next round of improvement activity.
"A well-designed measurement system is also essential for an effective Lean management system. According to David Mann, 'Unlike managing in a results-focused system, process focus implies frequent measurement against expected *intermediate* outcomes. As necessary, interventions can be started before the end results are affected.'" Quotes from "Lean IT" by Bell and Orzen and "Creating a Lean culture: Tools to sustain Lean conversions" by David Mann.
I read that and thought "That's what we're trying to get the computers to do with orchestration at scale." And in reading "The Lean Manager" and other management books you take the ideas for getting a team to do something and replace the people with systems and turn the management techniques into code and Voila - Nirvanna. (Or something like that).
1) Read Lean Management Books
2) Turn Lean Management into Code
3) ????
4) Profit!