The way we have created IT systems over the years has been very linear with each individual component being statically configured. If a human makes an error in any one of the many configurations, then the whole system breaks down. Over the years, IT systems have become increasingly complex with multiple layers of abstraction and virtualization making it difficult to enforce stability and gain scalability. Promise theory provides a new way to think about how IT systems rely on each other to form an entire system that businesses can depend. This article will cover the foundation concept of promise theory and give examples of how it is used.
Introduction to Promise Theory:
As we all know, a promise is a commitment often made between people to do or not do something. If you check Wikipedia, you will see this simple definition “Promise theory is a model of voluntary cooperation between individual, autonomous actors or agents who publish their intentions to one another in the form of promises.”
In promise theory, promises are the statements of a request of a desired behavior to be performed by an agent. Promises are made between agents and those promises are not transient or transferable. The agent is asked to fulfil a promise which is a broadcast declaration of intent that contains a body, a quality/quantity, trust, and other characteristics of the desired state.
Accepting the promise is the easy part, keeping the promise is the hard part. One distinction that we should keep in mind is that “the promise” is very different than “the obligation”. Intention is also different than a promise; a commitment is actually a subset of intentions and intention is a promise that has been scoped and documented and broadcast to the set of agents. The set of promises is essentially the executable documentation of intent. The concept is that intent leads to distributed build and repair system which will provide stability and eventually freedom of deployment.
Certainly trust is essential in this cooperative model. Just like with people, trust increases as agents build up a history of reliability in their fulfillment of promises. The historical record of kept promises give an indication of how future promises will be negotiated.
The use of promise theory can create an obligation-based IT management system that creates policy-based configurations. We are often concerned about how we really know the configurations of all our IT infrastructure at any given time. Imagine how all the autonomous independent elements in an IT environment could be talking with one another in a loosely coupled configuration. Through promises, they form expectations of each other’s behavior for cooperation and building a complete end-to-end working system.
Mark Burgess started out as a physicist and received a PhD in Theoretical Physics in 1990. His interest shifted to computers, networks, and system administration. He started working on his promise theory research when he was professor of Network and System Administration at Oslo University College from 1994 to 2011. Promise theory was first proposed by Mark Burgess in 2004.
Mark’s has written many papers and books on computer systems, networking, and system administration. His book titled “In Search of Certainty: The science of our information infrastructure” was published in 2013. His most recent book, Promise Theory: Principles and Applications, by Mark Burgess and Jan A Bergstra was published just a few months ago (2014). Mark was coauthor of the recently-published paper titled “A Promise Theory Perspective on Data Networks” (May 2014). As you can see, Mark Burgess is a very busy man.
If you are curious to learn more and would prefer to not read academic papers, there is a set of three easy to understand YouTube videos of Mark Burgess describing “Promise Theory: The Future of Config Mgmt” (video 1, video 2, video 3).
Promise theory has evolved since Mark’s original research on the topic and it is now being used in many different computing and networking administration systems.
Mark Burgess wrote an open source configuration management software package called CFEngine in the 1993 to 1994 timeframe. He actually wrote CFEngine before he formally developed the concept of promise theory. The CFEngine version 3.X now incorporates the concepts of promise theory. Now, Mark Burgess is the CTO and Founder of the CFEngine company. CFEngine is under very active development and the latest CFEngine Enterprise version 3.6.0 was released just a few weeks ago.
The CFengine software allows the IT administrator to define configuration promises that help form the state of a complex IT environment. CFEngine uses a declarative language to create the desired configuration state. The promises contain several pieces of information that are vital for the agent to fully understand the promise (type of promise, when and where does this apply, what is the affected element, why is this request being made, how will the promise be upheld). Promises can be combined to form structures and groups for entire configuration requirements.
CFEngine is similar to many popular configuration management utilities (Puppet, Chef, Ansible, and Salt) that are being used by organizations deploying cloud infrastructures. CFEngine is really targeted at configuring large-scale computer systems, servers, end-nodes, and some embedded network devices. However, its sweet spot is not configuration of physical or logical network devices.
Cisco Application Centric Infrastructure (ACI):
Networks can benefit from improved scalability of complex policy-based configurations. Today, networks are loose collections of distributed independent manually-configured switches and routers. Eventual forwarding consistency is created after the manually configured routing protocols converge to a single best path. Promise theory can provide automation, scalability, and flexibility benefits to modern network topologies. Promise theory is now being applied to the world of Software Defined Networking (SDN).
Cisco’s relatively new Application Centric Infrastructure (ACI) is a holistic architecture for centralized automation of policy-driven application profiles. ACI’s goal is to create software flexibility, configuration agility, application-driven policy, centralized visibility, and scalability on high-performance hardware platforms for data center networks.
The ACI model is essentially a declarative model based on the concept of promise theory. The Application Network Profile abstractly describes how an application should function. In ACI, the End Point Group (EPG) is a set of hosts or networks and ACI “Contracts” are a set of rules governing communications between EPGs. The configuration and centralized policy management is performed on the Cisco Application Policy Infrastructure Controller (APIC). There are many Cisco whitepapers on ACI that describe how this architecture supports the promise theory concept. This document in particular “Principles of Application Centric Infrastructure” reviews the promise theory approach and the ACI object model. There were also many more details of ACI revealed at this year’s Cisco Live.
Cisco has also introduced the OpFlex protocol for consideration for IETF standardization as a southbound interface that the APIC or another controller, such as OpenDaylight (ODL), can use to connect to network devices. Cisco has partnered with a host of software vendors to help create an ecosystem of cooperating companies to develop interoperable networks using OpFlex. Cisco intends for the OpFlex protocol to exhibit the same promise theory information model as ACI.
Abraham Lincoln had something to say about promises, “We must not promise what we ought not, lest we be called on to perform what we cannot.” However, promise theory is a powerful concept in the new age of IT virtualization. To achieve scalability and management efficiencies, we need to have configuration management systems that allow for flexibility while striving for consistency and predictability. There are many laws of IT and promise theory will appear more and more in the coming years as our business continue to make more requirements on the underlying infrastructure.