Skip to content
In a recent report, Ovum described Fugue as "a CMDB for APIs." A configuration management database (CMDB) is a single source of truth for configuration of complex systems. This is a crucial aspect of Fugue, one where running your operations with Fugue offers a lot of value to you.


Fugue's CMDB is an effect of our declarative model for configuration, built around our typesafe, compiled Ludwig language. The Fugue CMDB is not a proprietary store with a form-based interface; it is Ludwig code, managed in a VCS of your choice, like git or svn. That code is a declarative configuration of infrastructure (or other API) state. Once it is run as a process in Fugue, that declaration is made real and immutable with machine precision.


In this way, a well-managed body of Ludwig compositions and a Fugue runtime present a powerful CMDB. More precisely, it presents the inverse of a CMDB — declarative configuration control — which is far more powerful.


The Traditional CM Model


Configuration management (CM) is the process of tracking, detecting, and auditing changes made to components of an engineering system (configuration items, or CIs), in an effort to prevent configuration drift. Configuration drift is the accumulation of untracked or unwanted changes, and over time it results in wasted money, lost time, and lowered productivity.


If you've done work in a team responsible for some amount of configuration management, you are probably familiar with this most basic model of CM:


  1. Authorized people make changes to CIs
  2. The same people honestly and accurately report their changes in a CMDB
  3. Other maintainers & auditors trust the CMDB to reflect reality


The weak link in this chain is honesty and accuracy of human beings. Humans are famously non-deterministic in their honesty and accuracy. Moreover, they prove remarkably resistant to attempts to fix this. It is a problem which is both immeasurable and intractible, yet it plagues many organizations in their attempts to control configuration of the many things they own.


Declarative configurations, long practiced around operating systems, go some way to remedy the problem just by themselves. This model is more sophisticated:


  1. Authorized people devise configuration files for an OS CM system
  2. OS agents read the configuration files and make changes to OS CIs reliably
  3. Other maintainers & auditors trust the configuration files as an accurate CMDB


This is great. It has two shortcomings.


First, it is generally practiced around computer operating systems, and not so often with APIs, especially eventually consistent ones (like AWS). The latter are particularly difficult to impose a declarative configuration state on.


Second, the initial model with manual changes affixed to human accuracy often creeps in. As Chad Fowler put it:


[A]n old system inevitably grows warts. They start as one-time hacks during outages. A quick edit to a config file saves the day. “We’ll put it back into Chef later,” we say, as we finally head off to sleep after a marathon fire fighting session. [...] The system becomes a house of cards. You fear any change and you fear replacing it since you don’t know everything about how it works.


Fugue Inverts The Model


The problem becomes even more significant when your infrastructure is in the cloud. It's time-consuming to track CIs across so many different components at scale. It's often a manual process of tallying up routes and interrogating servers with a console or command line. The temptation is strong for ad-hoc fixes and piecemeal scripting. Complexity increases with each new tool added. Configuration drift plagues the system. Frustration plagues the team. That is something Fugue fixes.


The challenge with management and automation in the cloud is to make sure that the complexities and sheer volume of APIs can be managed and orchestrated. Fugue can be described as a cloud operating system, but Ovum prefers to describe it as a CMDB for APIs, where by using a declarative language the entire infrastructure can be codified.


Fugue's way is to think of infrastructure as code, use immutable infrastructure wherever possible, and then enforce it. The result is a much more powerful inversion of the traditional configuration management model. With Fugue, first you build the CMDB, and then the Conductor uses the CMDB to build your CIs.


  1. Authorized personnel devise a CMDB for a complete controlled system (a Fugue composition)
  2. The Conductor makes the configuration in the CMDB a reality (a Fugue process)
  3. Other maintainers & auditors can view the configuration directly through Ludwig composition code


There are several advantages to this approach. You really know what is going on with your infrastructure. Unlike humans, Fugue's Conductor is deterministic in its behavior, so in the rare event it exhibits flaws, we can find them and fix them.


Configurations in compositions are reproducible, making scaling or recovery much easier. Configuration is easily shared and recomposed into new configurations. What's more, it's easy. Your CMDB is just code. It's easy to explore and analyze.


In addition, Fugue's Ludwig language includes a number of ways to validate configurations at compile time. We ship Fugue with lots of common validations, like subnet sizing. We also have libraries that test compliance with regulatory regimes, like HIPAA. And you can build your own custom validations. All of these validations are applied to your Ludwig code when it is compiled, and compilation is a required step before committing any changes to a process.


When changes are required, Fugue doesn't default to modification of complex components like operating systems. The preferred method of update is replacement, which is the essence of immutable infrastructure. You can, of course, integrate tools that update instance operating systems into Fugue if you wish. Where replacement doesn't make sense — such as for security group rules — Fugue uses enforcement to ensure the CMDB and reality match. Constant monitoring of the configuration via API, and immediate correction of drift, ensures that your configuration is what you want it to be. All the time.


We think this is the future of configuration management in the cloud, where powerful APIs backed by automation make configuration management more challenging and complex than ever. Read more about how Fugue works to deliver this next-generation CMDB — and more — at our website. Be sure to join the next Fugue webinar on Nov. 16 to learn how Ludwig brings sanity to infrastructure operations with cloud-as-code. Register now!


Categorized Under