Hacker News Reader

Hacker News

Comment by pricechild | Hacker News Reader

Full thread

pricechild

> 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?

View on HN

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.

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.

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.

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.

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

Reply on news.ycombinator.com