Hacker News Reader

Comment by c0l0 | Hacker News Reader

So ansible "collections" are the next questionable idea in the neverending back-and-forth between "we ship most generally useful modules with ansible itself" and "better luck getting your modules elsewhere, sucker!" that they first tripped down in, if memory serves, 2014 or so? And they, once again, break existing playbook/role syntax? m(

Seriously, it is beyond me how this glorified paralleized shell-loop spewing gzipped python can get away with something like this time and time again... Ansible really is a steaming pile of ill-thought-out ad-hoc decisions, endlessly retrofitted and then retrofitted again, in all tangible qualities and regards. If only we had something better with a big enough audience/"community" that served a similar purpose... sigh

View on HN

Early in my career, I noticed a mindset among senior developers disparaging ORM's with "I'll write my own SQL, thanks." Although I noted their thoughts at the time, I didn't really do anything with it - there was a mountain of other things to learn and using an ORM made me productive enough to get tasks done.

Of course, years later when I finally dug into SQL and interacting directly with databases, I had a much better understanding of their mindset and wish I would have learned earlier.

Now your mindset feels very similar to me - "I'll write my own shell scripts, thanks." So, to avoid making the same mistake twice, do you have any advice for what to read / learn to better understand your position?

Note: I've written plenty of shell, but the shell I've writen is way to hacky to use as a replacement for ansible.

> Early in my career, I noticed a mindset among senior developers disparaging ORM's with "I'll write my own SQL, thanks."

Hopefully they were justified in their choice.

Most senior developers I've worked with who started with this mindset, be it about an ORM, a framework, or some library that they did not understand or wanted to spend some time to learn, ended up just proving that these abstractions were not completely useless after all. How? By recreating their own vastly inferior and headache inducing implementations.

I believe that there's an additional layer of skills between seniority and mastery. The former seems to be just about time and experience, whereas the latter adds a dimension of pragmatism and detachment. You become just a craftsman using tools with indifference to nimbly navigate complexity. You don't blame your tools, you just understand them, strengths and weaknesses. You know when to leverage them and when to ditch them.

I find that with ORMs you'll inevitably run into some kind of corner cases that is not covered, migration issues, library or framework incompatibility. Some argue for query builders but if you're doing that you might as well just write SQL.

Shell is not the best solution long-term for a largish organization, but if you are indie hacking a simple app it's actually a viable option.

That's also why I chose Bash to teach config management and deployment[0]. Do it in Bash, understand it fully. Then go a pick up a tool of your liking. Or not, if it actually does it job.

[0] https://deploymentfromscratch.com/

> ... but the shell I've writen is way to hacky to use as a replacement for ansible.

You obviously haven't looked at the code for some of the Ansible modules!

Is that about the community supported stuff that got moved out because nobody maintained it?

I think using Ansible is not by itself a problem.

There are many things I don't like about Ansible and I don't think it's particularly robust, but it is an improvement over manually written scripts, most of the time, because writing robust scripts is not easy.

What I think "senior developers" are usually disparaging is using tools like ORMs without appropriate understanding of how they work, and thus being unable to recognize when they don't suit the task at hand.

I'm a heavy ansible user and have not experienced anywhere close to this level of pain with ansible 2.10 and collections. None of my playbooks needed module names updated and this is not a syntax change. A fully qualified module name is simply being more explicit about where your desired module comes from in the infinitely extensible library of modules. If you use builtins or have only one of that module name installed you don't have to update anything. At least that has been my experience, although I primarily use builtin modules for a majority of my work.

I maintain a _lot_ of Ansible playbooks, and so far I have not had one of them break after upgrading to Ansible 2.10.

I think in the long term, there may be a point where it will be more important to consider how the new collections are structured if you use ansible in a typical way, but right now at least, it seems like the new release plays nice with all my existing work.

"glorified paralleized shell-loop spewing gzipped python can get away with something like this time and time again"

That's exactly why it's good. It beat puppet, it beat chef, and saltstack fails to make inroads for the same reasons. They all make useless and difficult abstraction layers on top of what is essentially running shell scripts in loops over what's ultimately an ssh connection or a worse, proprietary version of one.

I won't defend some of the decisions Ansible has made over the years, but its simplicity is the key feature.

> If only we had something better...

I started writing one about the time Ansible debuted because of some of its design decisions that I disliked. A bit later Docker dropped and I decided most of the whole category was approaching obsolescence already and stopped.

Given the above, and that a competitor would have to overcome Red Hat/investor money and mindshare, it doesn't seem there would be much of a demand for this. Ansible is arguably good enough for the niche it occupies.

Maybe the entire idea is too high level and just tries to do too much? This approach creates edge cases where the abstractions break down.

The ideal tool is good in the general case, and still reliable in the edge case.

In my opinion Nothing has been able to beat good old fashioned:

for i in $(cat listofips);do ssh $i “some linuxy thing” ;done

That's what Ansible does, but with a DSL that helps users not shoot themselves in the foot and with scripts that are designed to be idempotent.

Ansible is nice but I like to build my systems the way I like them. Under the hood ansible is just a Python paramiko wrapper anyway. What I like about bash is it’s just there, no need to install anything if you are managing legacy systems

It doesn’t work if the step blocks, needs some error handling, etc. Then comes the fun of writing yet another deployment system that fails to learn from other systems.

Why we keep reinventing wheels in infrastructure management and control beats me

lol ... but it has mindshare.

Reply on news.ycombinator.com