3 ms·

> 5 — Implement Ansible, Puppet, Chef, Kubernetes, OpenShift, Terraform… Irrespective of personal feelings on these individual projects, they're all aimed at a

> 5 — Implement Ansible, Puppet, Chef, Kubernetes, OpenShift, Terraform… Irrespective of personal feelings on these individual projects, they're all aimed at automating something? I don't get the point of this item? What's wrong with them?

m0llusk 8y ago
It is extremely easy to overload on new and shiny. Sometimes a web app can be scaled with a minimum of tool work. If something can be automated that is great, but probably not everything needs to be automated right away. This is a special case of You Probably Aren't Going To Need It.
jbb67 8y ago
I think sometimes they are implemented as a solution looking for a problem. I've seen many times when the automated solution is much more complicated than the manual solution. Sure, it's more reliable, except that it breaks when you change something. The tools are good, but use them when you need them and when they help, not just because someone told you it was best practice.
rhizome31 8y ago
I think the point here is not to focus on tools for the sake of tools but instead focus on delivering value to the organization. Quite often, improving a workflow can be done more effectively by improving how you use your existing tools rather than by adding or replacing tools. Fear of missing out can drive us away from considering our existing workflow and how it can be optimized.
bloopernova 8y ago
Putting Puppet on top of an environment that is poorly designed will not solve that poor design. I implemented Puppet to manage a hugely complex application/environment. Because the architects of that app didn't think of Puppet, they threw up roadblocks at every opportunity. Things like refusing the allow the install package to be simply changed to RPM, or allowing a large part of install logic to be moved from shell scripts to Puppet. Or allowing an automated push from the release branch of the Puppet repository to any of the Puppet environments. A lot of stuff that was initially planned that would have greatly simplified install, configuration, rollbacks, verification, etc etc, was all refused because it had been invented by the ops team instead of the architects. So we ended up making things worse because management wanted Puppet, but didn't want to lay down the law to the architects to update their stuff.
theevilsharpie 8y ago
The "anti-pattern" wasn't about the tools themselves, but on focusing excessively on tooling at the expense of other aspects of DevOps.

m0llusk 8y ago

It is extremely easy to overload on new and shiny. Sometimes a web app can be scaled with a minimum of tool work. If something can be automated that is great, but probably not everything needs to be automated right away. This is a special case of You Probably Aren't Going To Need It.

jbb67 8y ago

I think sometimes they are implemented as a solution looking for a problem. I've seen many times when the automated solution is much more complicated than the manual solution. Sure, it's more reliable, except that it breaks when you change something. The tools are good, but use them when you need them and when they help, not just because someone told you it was best practice.

rhizome31 8y ago

I think the point here is not to focus on tools for the sake of tools but instead focus on delivering value to the organization. Quite often, improving a workflow can be done more effectively by improving how you use your existing tools rather than by adding or replacing tools. Fear of missing out can drive us away from considering our existing workflow and how it can be optimized.

bloopernova 8y ago

Putting Puppet on top of an environment that is poorly designed will not solve that poor design. I implemented Puppet to manage a hugely complex application/environment. Because the architects of that app didn't think of Puppet, they threw up roadblocks at every opportunity. Things like refusing the allow the install package to be simply changed to RPM, or allowing a large part of install logic to be moved from shell scripts to Puppet. Or allowing an automated push from the release branch of the Puppet repository to any of the Puppet environments. A lot of stuff that was initially planned that would have greatly simplified install, configuration, rollbacks, verification, etc etc, was all refused because it had been invented by the ops team instead of the architects. So we ended up making things worse because management wanted Puppet, but didn't want to lay down the law to the architects to update their stuff.

theevilsharpie 8y ago

The "anti-pattern" wasn't about the tools themselves, but on focusing excessively on tooling at the expense of other aspects of DevOps.