CFEngine

The CFEngine project began in 1993 as a way for author Mark Burgess (then a post-doctoral fellow of the Royal Society at Oslo University, Norway) to get his work done by automating the management of a small group of workstations in the Department of Theoretical Physics. Like many post-docs and PhD students, Burgess ended up with the task of managing Unix workstations, scripting and fixing problems for users manually. Scripting took too much time, the flavours of Unix were significantly different, and scripts had to be maintained for multiple platforms, drowning in exception logic.

After discussing the problems with a colleague, Burgess wrote the first version of CFEngine (the configuration engine) which was published as an internal report[3] and presented at the CERN computing conference. It gained significant attention from a wider community because it was able to hide platform differences using a domain-specific language.

A year later, Burgess finished his post-doc but decided to stay in Oslo and took a job lecturing at Oslo University College. Here he realized that there was little or no research being done into configuration management, and he set about applying the principles of scientific modelling to understanding computer systems. In a short space of time, he developed the notion of convergent operators, which remains a core of CFEngine.

In 1998 Burgess wrote "Computer Immunology", a paper at the USENIX/LISA98 conference.[4] It laid out a manifesto for creating self-healing systems, reiterated a few years later by IBM in their form of Autonomic Computing. This started a research effort which led to a major re-write, CFEngine 2, which added features for machine learning, anomaly detection and secure communications.

Between 1998 and 2004, CFEngine grew in adoption along with the popularity of Linux as a computing platform. During this time, Mark Burgess developed promise theory, a model of distributed cooperation for self-healing automation.[5]

In 2008, after more than five years of research, CFEngine 3 was introduced, which incorporated promise theory as "a way to make CFEngine both simpler and more powerful at the same time", according to Burgess. The most significant re-write of the project to date, CFEngine 3 also integrated knowledge management and discovery mechanisms—allowing configuration management to scale to automate enterprise-class infrastructure.

In June 2008 the company CFEngine AS was formed as a collaboration between author Mark Burgess, Oslo University College and the Oslo Innovation Centre in order to support users of CFEngine. In April 2009, the company launched the first commercial version of CFEngine - CFEngine Enterprise. The Enterprise version can be downloaded for free for up to 25 agents (clients). February 2011, the company received its first round of funding, from FERD Capital.[6] The company has offices in Oslo, Norway and Mountain View, California, USA.

In 2017, the company changed its name to Northern.tech, to reflect that it is working on multiple software products, not only CFEngine. [7]

CFEngine provides an operating system-independent interface to Unix-like host configuration. It requires some expert knowledge to deal with peculiarities of different operating systems, but has the power to perform maintenance actions across multiple hosts. CFEngine can be used on Windows hosts as well, and is widely used for managing large numbers of Unix hosts that run heterogeneous operating systems, e.g. Solaris, Linux, AIX, Tru64 and HP-UX.

Shortly after its inception, CFEngine inspired a field of research into automated configuration management. The CFEngine project claims to attempt to place the problem of configuration management in a scientific framework. Its author Mark Burgess has developed a range of theoretical tools and results to talk about the problem, and has written several text books and monographs explaining them.

One of the main ideas in CFEngine is that changes in computer configuration should be carried out in a convergent manner.[8][9] This means that each change operation made by the agent should have the character of a fixed point. Rather than describing the steps needed to make a change, CFEngine language describes the final state in which one wants to end up. The agent then ensures that the necessary steps are taken to end up in this "policy compliant state". Thus, CFEngine can be run again and again, whatever the initial state of a system, and it will end up with a predictable result. CFEngine supports the item of statistical compliance with policy, meaning that a system can never guarantee to be exactly in an ideal or desired state, rather one approaches (converges) towards the desired state by best-effort, at a rate that is determined by the ratio of the frequency of environmental change to the rate of CFEngine execution.[10]