CFEngine, Puppet, Chef… and Ansible, Salt… and many others. We have loved them and we have hated them. It’s time we take a picture, because they may be gone in a few years time. This is the word — or the cry — that got out of too many Configuration Management practitioners at this year’s Config Management Camp.

It was stated very clearly, by many (including myself) and from many different perspectives  that Configuration Management as we know it has come to its tipping point. No surprise that James “purpleidea” Shubin suddenly became a hero by showing his prototype of a CM tool that at its current state implements only a part of the things that people are desperately after. mgmt is the freshest CM tool that has entered the arena since years and people noticed the difference immediately.

But… how did we get here?

The proactive tools

In the beginning, CM tools were designed to be proactive: they ran at regular intervals and corrected any deviation from the desired state. Eventually, that was not enough for certain classes of problems that they were not designed to address.

The on-demand tools

Finally, someone decided that enough was enough and designed new tools. They needed something that applied the desired state on demand and they designed their tools that way, completely scrapping the proactive approach. For some of these tools the proactive approach, for which they weren’t designed, was hacked on top later.

Eventually, other classes of problems came into the picture and proactive tools also fell short.

The adaptive/reactive tools

Neither proactive nor on-demand tools were able to cope with the so-called elastic infrastructure, where virtual machines and containers are continuously spawned and destroyed, sometimes so quickly that neither configuration management tools nor monitoring tools are fast enough to become aware of them. New tools were designed that were able to cope with this class of problems, and again the previous designs were not part of thes tools.

The mishmash

But now we had a problem: the classes of problems for which the different tools were designed often appeared together in the same environment. People started using CFEngine with Salt, Puppet with Ansible… also to install Consul and Consul Templates and use them too. Using many tools together brought the usual challenges, e.g. partitioning the scope of the tools so that they didn’t step on each other toes. Yet, that was not satisfactory enough for some and they started either complementing their CM with something home-made, or writing their tools from scratch.

The homegrown tools

The homegrown additions to CM tools usually built on a shared distributed key/value store or a service bus and events to add, for example: shared state, fleet awareness, orchestration… Is that all? No, it isn’t. There was something more.

Container orchestration

Well, yes, containers. Because, in the end, what tools like kubernetes (for example) do with containers looks quite like configuration management to me, even if in a very well defined class of problems. To me, it’s what configuration management tools use to do with processes, but with fleet awareness — hey, that was about time. And it’s not all.

…and then more

There would be more to add to the list. For example Walter Heck held a presentation at Config Management Camp, again venting some of the communities’ frustrations and desiderata that the tools we used to love don’t address and, in their current incarnations, never will. Walter hasn’t put his slides online yet, but maybe if we nag him hard enough he will eventually do it 😉 The slides of Walter’s talk are now online.

The king is naked

The facts are all here: people cannot afford using only one tool to get the job done and are forced to mix two or more of them. Features like proactive CM, on-demand and adaptive CM, ability to orchestrate workloads on containers, fleet awareness, shared state, parallel execution, resilience… are all features that we need to do configuration management today. There is no way for tools that are not designed from the ground up to support those features to implement all of them properly.

The writing is on the wall for each of today’s CM tools vendors: it’s time to redesign from scratch to properly address the problems we have now and those we’ll hit in the next 5-10 years — or die, because there is no doubt that any new player to do that, even with a barely decent tool, will kill all competitors.