4 ms·

I think Puppet makes for an interesting example. Having spent the last decade of my life mired in config management systems from CFEngine to Ansible, it seems

by subway 9y ago

I think Puppet makes for an interesting example. Having spent the last decade of my life mired in config management systems from CFEngine to Ansible, it seems like the pattern is for a complex system to be replaced with a "simple" system, the "simple" system quickly gains complexity, and then we see a shift back to a simple alternative. I'm starting to strongly suspect the root of the problem (at least within this context of config mgmt systems) is that everyone wants to write libraries, nobody wants to write a config. By this, I mean if a Puppet user wants to install and a simple single site, instead of a simple manifest or internal cookbook with just a package resource and template, they frequently reach for a Apache module from the forge. Similarly, if an Apache module doesn't exist in the forge, they will try to publish one. This results in vast dependency graphs of questionably maintained modules, and new users to the ecosystem saying "Wow, this is way too complex. Oh hey, Chef looks simple." A short while later you get the Supermarket, and the cycle continues. I'd argue centralized repositories of config management modules/cookbooks lead to the decline of any given config management system, and the best way to avoid that is to use a real config management system (chef/puppet/whatever), but stick to the basic resources, and avoid 3rd party modules at all costs -- they will quickly go unmaintained. And seriously, do you think you'll need to deal with that obscure setting for apache on irix that the popular community module supports?

marcosdumay 9y ago
I do avoid 3rd party modules. Not at all costs, but enough for them being less of a problem than the puppet updates themselves. Not to talk about how it got from a simple "write your configurations here" repository into something that requires that you think about testing and staging envs for your configs. I am still not sure if that's a net positive either. There is an inherent problem on the complexity itself. The previous piles of scripts I had before it had the complexity right there, on your face. They were clearly hard to manage, but it was bounded. By using Puppet I exchanged that for a lot of hidden complexity, that is ever increasing and once in a while shows its face (always on a bad time). Or, rephrasing the rant, why does software have to keep growing? If it didn't I could evaluate what is a good trade-off and keep it.

by subway 9y ago

marcosdumay 9y ago

I do avoid 3rd party modules. Not at all costs, but enough for them being less of a problem than the puppet updates themselves. Not to talk about how it got from a simple "write your configurations here" repository into something that requires that you think about testing and staging envs for your configs. I am still not sure if that's a net positive either. There is an inherent problem on the complexity itself. The previous piles of scripts I had before it had the complexity right there, on your face. They were clearly hard to manage, but it was bounded. By using Puppet I exchanged that for a lot of hidden complexity, that is ever increasing and once in a while shows its face (always on a bad time). Or, rephrasing the rant, why does software have to keep growing? If it didn't I could evaluate what is a good trade-off and keep it.