Monad Manifesto

Why Snover developed Monad

Snover joined Microsoft in 1999 as the divisional architect for the Management and Services Division. Prior to that, he worked at other companies where he developed a deep background in Unix systems management.

Snover wanted to use Unix management tools for Windows due to the limited automation options in Microsoft's operating systems. Snover found the GUI-based approach was not efficient for administrators who wanted to handle tasks with a script they could reuse rather than clicking through multiple menus.  He also felt the existing command line tools were not powerful enough for advanced functions. Administrators who could not solve a problem with either the GUI or the command line would resort to writing code in VBScript or JavaScript. Snover sought a new automation tool to fill this gap and give administrators an easier way to solve their problems.

Jeffrey Snover

Snover found the fundamental difference between the operating systems -- Unix is based on documents that you manage by editing text files and Windows is based on application program interfaces (APIs) and you manage it by manipulating objects -- would not allow him to use Unix tools on Windows, so he petitioned to develop one that emulated Unix-style management for Windows.

Concepts behind the Monad Manifesto

Snover came upon the term monad from philosopher Gottfried Wilhelm Leibniz in his book "Monadology." Leibniz described a monad as a fundamental unit that joins other monads to complete a task, similar how the Unix pipeline works.

Snover wished to improve on the traditional Unix management model by using piping to bind several steps into one step but eliminate the need to parse text to get the desired results. Snover wanted Monad give the administrators exactly what they were looking for without any guesswork.

In a 2011 blog, Snover said he had been working on Monad for more than a year but needed to produce comprehensive documentation about the Monad concept because the distributed development model with a team in India and another in Redmond, Wash., made it difficult to keep the project on track.

"The Monad Manifesto forced me to be clear about what problem I was addressing, what my principles were, how I intended to address the problem and then who would benefit and why," wrote Snover.

Snover took the name monad for the project because it was similar to the concept behind PowerShell, which consists of thousands of commands called cmdlets and a pipeline, which joins multiple cmdlets to execute complicated jobs involving objects. An object is some form of structured data, such as a file or a process.  By using pipelines of objects rather than parsed text, administrators could do their work more efficiently.

Snover relied on organizational theorist Geoffrey Moore's concept of value propositions to clarify the purpose of Monad and used it to determine which features were essential and which ones could be dropped during the development process.

"[The Monad Manifesto] also set the overall tone for the project -- we are going to succeed based upon delivering compelling value to customers.  It is all about the customer, it is not about us, not about technology, not about Microsoft, it is all about customers with real problems and our ability to deliver real value to those customers because we have a clear understanding of those problems and a unique and powerful approach to addressing them," Snover wrote. 

Features in Monad

The Monad Manifesto describes the five components of Monad: the Monad Automaton Model, Monad Shell, Monad Management Model, Monad Remote Scripting, and the Monad Management Console.

The Monad Automaton Model is based on the .NET framework to build cmdlets. The Automaton Model appeared in PowerShell 1.0. Cmdlets are similar to CLI commands but are not standalone executables.

The Monad Shell came out with PowerShell 1.0 and consists of both the .NET runtime environment that uses cmdlets as APIs and the interactive command line interface.

Monad Remote Scripting arrived with PowerShell 2.0 and defines the remote architecture. Monad Remote Scripting was a web service that allowed scripts to be executed on remote multiple machines.

Microsoft released the Monad Management Console in PowerShell 3.0. The console allowed users to produce custom management GUIs on Monad Shell.

Monad Management Models came with PowerShell 4.0 to provide the functionality and tools to define Desired State Configuration for automated adjustments to servers that drift from specific settings.