Disclaimer
The following is a review of a presentation given at FLOSSUK Spring DevOps Conference. The event was held at Mary Ward House in London between 15th-17th March 2016. Although this is a description of a presentation with some dissection of what was discussed it is not a verbatim account and will contain personal impressions and interpretation. The content therefore does not reflect the quality of the original presentation and should be considered a review and personal opinion.
This is one of a series of reviews of the talks I saw at the event.
Promise Theory
Thom is an applications developer with Chef, his talk was focussed on how Chef works in regards to Promise Theory
Promise Theory, in the context of information science, is a model of voluntary cooperation between individual, autonomous actors or agents who publish their intentions to one another in the form of promises.
A promise is a declaration of intent whose purpose is to increase the recipient's certainty about a claim of past, present or future behaviour. For a promise to increase certainty, the recipient needs to trust the promiser, but trust can also be built on the verification that previous promises have been kept, thus trust plays a symbiotic relationship with promises. Each agent assesses its belief in the promise's outcome or intent. Thus Promise Theory is about the relativity of autonomous agents. Wikipedia
Thom at the start of his presentation
The way that Promise Theory is implemented in Chef underpins much of how it works as a configuration management system, the belief in Chef is that systems work well with Promise Theory. There are certain beginning precepts that must be understood:
- An obligation is a command
- A promise is a contract
- Allows statements of ability, concern and function and can be queried
In a configuration management promise we have:
- The Promise
- The Changes
- The Outcome
So in Chef this turns into:
- Node is a promise
- Node declares what it will be
- Node reports if it was successful and why (changes) that led to that success
In this way the whole of the configuration management promise is ‘data driven’
We now have the concept of ‘orchestration’ which is the interaction with nodes on an individual basis.
On millions of nodes is it implausible to directly control each one of them. Their has to be a level of stratification, but in massive systems there has to be the expectation of automation. Orchestration is synchronous, it uses a direct connection not APIs, this is an overhead and limits the number of simultaneous connections, so this needs scheduling. This is a complex system and relies on the use of central logic to control, the install code for everything is inside the orchestrator.
Actors are the instances and are synonymous in Chef with applications. An actor can:
- Receive a message
- Send a message
- Spawn new actors
- Change itself - which is to change the system and state by sending a message.
Orchestration allows the actors to be manipulated which is considered to be Choreography. In choreography there are a number of elements:
- A promise is made
- Agents are the ones to make a promise
- They can perform actions
- This delivers dynamic relationships between nodes
The use of Promise Theory to make a contract that the system performs using applications as actors that perform a specific routine (choreography) that is centrally directed (orchestration) and controlled makes for a very powerful system. It occurs to me that by using source control via repository and management it would serve as a change control system for the systems as well as a configuration management.
The fact that Thom was able to convey all of this understanding and information in such a clear manner is mark of how great his presentation was. It certainly makes for a good introduction to the conceptual working of Chef.
[Don't forget that you can join in this conversation by using the comments form or by tweeting at @shadowcat_mdk]
Notes
*
