Stay updated with our latest articles, subscribe to our newsletter
Defining Configuration ManagementConfiguration Management (CM) is a fundamental engineering process that was quite well defined even before the DevOps term appeared in IT World. For example, it was documented in ITIL v2, which was introduced in the early 2000s. Since then, a lot has changed in the IT service management (ITSM) domain, but the importance of IT alignment with business needs has only been growing more and more.
DevOps engineers work with a variety of IT systems: huge computer systems like server and container farms, networks, data centers and various storage systems, applications, embedded network devices, etc., and the end goal is to bring those systems into a state that satisfies users’ needs – this end state can be defined as a desirable configuration. This configuration may change quite frequently as business nowadays must be agile, and IT must keep up with it.
Fig. 1. Defining Configuration Management
What’s Out There?
There are many Configuration Management (sometimes also referred to as Continuous configuration automation – CCA) software on the market that facilitates control over various parts of the IT landscape. You may use different systems based on the scope of configurations you need to manage. We will mention just some of the most popular and widely used tools, but the list is far from being exhaustive, and you might find the best CM tool for your specific tasks outside of this list:
- Ansible – mature and well-documented IT automation tool powered by RedHat
- Terraform – cloud & IT resource provisioning Swiss army knife by Hashicorp
- Puppet – model-driven client-server software configuration management tool
- Progress Chef – multifunctional server applications and utility configuration system
- CFEngine – one of the oldest multipurpose configuration automation software
- SALT – Python-based event-driven IT automation tool
All these configuration management tools are designed and built following different architectural approaches and paradigms. However, the core principles that DevOps engineers must adhere to are the same regardless of what type of software your team has chosen:
Clear responsibility model
We start with automation as it is one of the main advantages that DevOps brings to business. With automated configuration management, significantly much more work can be done by a smaller team in a shorter time. It can be compared to the Industrial Revolution when machines started to do most of the routine work while humans could focus on defining tasks for the machines instead of doing all the work themselves.
It is much more productive to prepare a template that must be reproduced by a machine than to craft the detail every time by yourself. This is what DevOps professionals define – the end state of the IT system or service that must be reproduced as many times as the business needs. This end product that must be manufactured based on the defined template can be a very simple atomic system (e.g. a new virtual machine of a certain size with specific software installed) or a huge and complex factory of various IT elements.
Repeatability is a byproduct of automation – once you create a script or template (sometimes referenced as a recipe or manifest), you can apply it again and again to build more replicas of your desired IT system. Here, it is important to understand the concept of idempotency – the property of a process whereby the end result of the process is the same every time when you launch it regardless of the initial state of the system it is applied to. In simple words – you expect that your IT systems and services will be configured in accordance with your end-state definition every time, even if your initial configuration is different each time.
The way how configurations are defined and applied may be different, as well as CM/CCA system architecture, a programming language used, licensing and mode of distribution. So, there are a lot of considerations and nuances you would need to keep in mind when choosing the right DevOps configuration management tool for your IT automation. We are going to list them down further in this article.
DevOps is always about teams; even if you are a single DevOps warrior in your organization – you shall keep in mind that your work must be well documented, comprehensive and shareable with another specialist; in the case of your unavailability – you would definitely prefer not to receive calls during your vacation.
Fig. 2. DevOps is all about collaboration
If you are a DevOps engineer – your configuration data, templates, and recipes must be structured, documented and stored in a shared environment, preferably an SCM (Source Code Management) system. Some might say that well-written code is self-documented; however, it is always a good idea to add comprehensive comments and proper documentation for your colleagues or for tomorrow yourself.
The code is usually written once and read many times, so you better make sure it is properly commented.
Clear responsibility model
It is important to define boundaries of responsibility of what your automation tools can change. Be aware that automation allows you to make massive mistakes with a single move of a finger. “To err is human, but to really foul things up, you need a computer.” (Paul R. Ehrlich). Separate your environments for different purposes (e.g. test and production environments) and follow the principle of least privilege when setting up grants and permissions for yourself and your automated jobs.
This is another cornerstone of DevOps – constant iterative improvement. Periodical internal & external audits and peer reviews of your configurations help identify potential problems, vulnerabilities and other imperfections. Complex configurations consist of multiple elements that must be updated and patched on a periodical and ad-hoc basis. Set preventive maintenance and audit intervals – it is better to prevent problems from happening than to fix their consequences.
Utilize your test/staging environments by testing various corner scenarios and try to break your set-up – by doing this, you will better understand possible points of failure and will be able to fix them before they hit your production.
Chaos engineering – is another cool concept that allows you to experiment with your IT automation and uncover potential configuration & application deployment issues; however, it may imply trying to stress and break your production environment. So, we would only recommend leveraging this approach only by advanced and quite experienced DevOps teams.
During provisioning & deployment, as well as after resource creation, it is crucial to track and monitor their state and health. Software configuration management tools have their own logging and reporting; however, it is usually not enough, so your DevOps toolbox must be equipped with observability solutions hooked up to your IT assets, services and applications (e.g. Dynatrace, Splunk, Datadog, Grafana, etc.). Observability is a big topic itself, and it’s hard to overestimate its importance for DevOps teams that usually must comply with very strict SLAs. It is always a good idea to visualize complex set-ups to better understand components’ composition, dependencies, connections and current health state.
DevOps is inextricably linked with business and users. DevOps teams serve as an internal service provider that supplies IT services that end-users utilize to fulfill some business purposes. It is extremely important to have a direct communication link between the users and the DevOps team to establish effective collaboration.
User requests shall be handled in a tool designed and built for it (e.g. Change request or ticketing system). It is also a good idea to connect or tag specific configurations (or their versions through a version control system) to the user request that initiated this change. So integration between, for example, Jira and Terraform code repositories may be a perfectly valid scenario.
In some cases, users might be even allowed to automatically provision and configure some resources on their own, but this process must be properly defined, tracked, documented and observed by DevOps or IT System Administrators team.
How to Choose The Right Configuration Management tool
Fig. 3. How to choose the right configuration management tool
Finally, after we have discussed the main DevOps principles applied to Configuration Automation, we can highlight some considerations to keep in mind when evaluating the pros and cons of a CM/CCA tool for your company.
Remember that there are no bad tools; there are tools that might just not fit your task.
- Define the scope of your current and potential future IT technologies and check if the configuration management tool supports all of them. Read reviews and official documentation to understand if the CM tool can be used for your scope and if there are pre-built templates, libraries, modules or recipes that might fit your tasks out of the box;
- We do not expect all your use cases will be supported out of the box, so explore how to learn the tool-specific language and what is the learning curve to get started with it;
- Understand how the CM tool works, if it pushes configurations or it requires an agent that will pull configurations from the centralized continuous integration server;
- Explore licensing model and mode of deployment – if it is a managed software or you must install and manage it on your infrastructure;
- Check levels of support available for the tool;
- Consider the maturity of the software and the size of its user community. The more users it has – the higher chances are that any problem you encounter has been raised, discussed and probably solved on Stackoverflow;
- Study what level of security the CM tool provides and if it is compliant with your company’s requirements.
These are the main considerations you shall have in mind when choosing a CM/CCA solution for your organization.
With the help of an automated configuration management system & the DevOps philosophy, you can create infrastructures, deploy applications and expose services of any complexity from pre-configured reusable templates in the form of configuration files that are managed, tracked, and tested the same way as software development source codes. This approach allows to minimize provisioning & deployment time, reduces effort in managing configuration data, eliminates possible human errors, and gives the ability to replicate the same infrastructure at any time.
Tell us about yourself...
Liked this article?
Stay updated with our latest articles, subscribe to our newsletter