Configuration Management Generation 3 - What is it and why do I need it?

Author by Nathan Lasnoski

When I first engaged in the IT Service Management and DevOps community I started going to local ITSMF meetings.  My first meeting was about configuration management, the title being, "maintaining your CMDB".  The presenter talked about how their 40,000+ user organization maintained its CMDB by (1) determining what configuration types they cared about and (2) manually maintaining those configuration values by enforcing change management.  Does this sound crazy?  It should, but at the time it was the norm for the industry, just starting to wrap controls around managing the operations of a technical datacenter.  This describes the first generation of "configuration management", being manual, controls based management of technical data.   The next generation moved from manual data capture to automated data synchronization.  The key selling point of "generation 2" configuration management is the reduction of manpower necessary to maintain a configuration management database(s) and the increased accuracy of the gathered data, due to the reduction of human error.  This value statement is what you'll hear in 99% of the IT Service Management conversations you'll have with process consultants and tooling vendors today.  To be true, it does provide a significant value.   We are now entering the third generation of configuration management.  This generation is not simply about gathering configuration, but more so defining what a configuration should be and applying it to a target system.  The intention of "generation 3" configuration management is not simply to discern the configuration of an environment, but to declare the configuration of an environment, which is why it is often called "declarative configuration management" or "desired state configuration".    Why is declarative configuration management powerful? The use of declarative configuration management combines the accuracy of automated configuration gathering with the assurance of automation and desired state.  In some cases it actually reverses the flow of configuration.  Whereas past configuration management attempts would deploy a configuration manually, or by a script, only to input that information into a CMDB later, declarative configuration management defines a state and "makes it so".  The ultimate goal is to use this technique with any aspect of the configuration "that matters", such that repeatability, integrity, and scalability are achieved.   How does declarative configuration management work? The declarative configuration management techniques are based on (1) determining the intended state of the target system(s) and (2) applying that configuration state through platform and tooling.  A recent platform that became available is PowerShell Desired State Configuration (DSC), which facilitates the application of configuration data to target systems based on pull or push methods.  The goal of Microsoft in this case was to make a system agnostic method for applying configuration data to Windows, Linux, network devices, and more.   How does declarative configuration management use a CMDB? The declarative configuration management technologies are still relatively young, but integration with CMDBs is growing.  We showed an integration between PowerShell DSC and a CMDB in System Center Service Manager at MMS 2014.  In our use case, the configuration data for DSC continued to be stored in its typical configuration files, but the CMDB maintained a list of the configurations, the servers they are applied to, and the  request offering to apply a configuration to a server(s) through self service.   What does this have to do with DevOps? The use of declarative configuration management in DevOps has often been called "configuration as code", such that configuration data can be normalized by developers and deployed along with code releases.  This facilitates improved testing scenarios as well as leads to higher reliability of the entire deployment.  I know of organizations that deploy releases every week by combining DSC with automated test scripts and deployment.   What does this have to do with IT Service Management? You'll find that your typical configuration management approach will be appropriate for one level of efficiency, but as you attempt to obtain higher levels of efficiency "generation 2" will be lacking.  The move to "generation 3" is intended to provide normalization that facilitates scale at lower costs because of the reduction of manual effort.  This is the conversation you should be having.  This is not the end of the IT Service Management conversation.  IT Service Management leverages capabilities of DevOps to facilitate the end-to-end lifecycle, weather it is done manually, or in an automated way.   How does it relate to complex configuration structures, such as application maps?  If you have been working on application maps / service maps then you can leverage that same information in applying configurations, vs. just monitoring them.  The use of a platform like PowerShell DSC provides the opportunity to apply a complex structure through automation, allowing it to scale and be maintained with high integrity.  The goal of service maps was to help us understand an environment or providing a mechanism for notifications, assuming it would assist in fixing broken services or notifying teams during a service outage.  Declarative configurations are applied continuously, meaning that service outages due to unexpected configuration will be significantly decreased.   How do I learn more about declarative configuration management? Here are some practical links to check out.   Cheers!   Nathan Lasnoski
Author

Nathan Lasnoski

Chief Technology Officer