Desired State Configuration Management

In this model of instructing the automation robot, instead of specifying steps to perform a job, we provide our desired end state of any element to be managed by the automation robot. For example: instead of telling the robot to pick up a red paint and paint the wall with it, we will say “I wish that you ensure this wall becomes red in color”. With that kind of instruction a robot can evaluate current color of the wall, decide if it is different from red, and then calculate what steps it needs to take to convert the wall to red color, and after calculation, executes the decided steps, after executing steps, it will revalidate if now the wall has indeed become red or not, and then confirm back to us that the wall is red. The one major takeaway from this approach is to understand what would have happened if the wall was already red. In that case, the robot would have found the wall to be already red and it would have just informed us that our wish is already fulfilled as it is red already. And then it would have continued to check every now and then, because we have asked it to ensure that it remains red. But it would have never tried to repaint the wall. Contrast that with the other instruction approach where we just ask it to pick up red color and paint the wall. It would not even bother if the wall was already red. It would still pick up the color and start painting even if it was already red. Also after painting once, it would never continue to check, because it has performed the instruction already and there is nothing in instruction for it to continue checking (no mention of ensure in instruction).


Similar to that, in IT automation there are procedural languages like ruby, python where you need to specify steps and the programming language executes the steps as it is. And then there are programming languages like puppet where you dont need to specify all steps but have to express your desire. Such as “I wish to have apache software installed on all my 1000 servers” or “I wish to ensure that all my 1000 servers will have ntp service enabled”. A tool like puppet can read such desired state instructions and ensure that all of your 1000 servers follow the same. In servers where ntp is already running, it will skip them. And on the ones, ntp is not running, it will start them. Had it been ruby/python, you had to specify all steps for all servers, and then these programs would have forced start of ntp even on servers where ntp would have been running already as the ruby/python coding languages do not have the inbuilt infrastructure management intelligence that can be seen in tools like puppet.

Leave a Reply

Your email address will not be published. Required fields are marked *

Skip to toolbar