Infrastructure - management - Is moving from custom code base in place to Ansible worth it?

Question

Some background:

When I started at my current work place ( in server infrastructure ), a bash, perl and python code base already was in place for remote executing jobs on linux systems, the one guy that wrote and maintain this code base have spent years refining it, since before I started there.

Although the existing code base can do a lot, it's pretty hard to make use of sometimes due to lacking documentation. Some of the script being executed is outdated as well. We're pretty dependent on the author of the code base from this. ( can add; only the author is allowed to edit the scripts involved )

Lately I've been experimenting with Ansible and configuration linux environments, users, groups, firewall, installing packages and running checks. I've suggested started translating basic tasks to Ansible, and with time combine it with Tower or AWX to get a good overview on jobs and their success.

Today, others are not too eager about this idea, especially the author of the code base. Authors argument for not moving to Ansible is that it's "too abstract".

Questions is:

Should I try to push for moving to Ansible?

Pros, the way I see it:

• A lot of functionality is already there through modules.
• Should be easier for new colleagues to pick up on.
• Can be used with a front end, such as Tower or AWX.
• (Probably) Overall safer, as custom scripts require that you write your own checks.
• I imagine Tower/AWX can be usable for other teams at our organization

Cons, the way I see it:

• Learning curve
• Will take quite a bit of work to implement.
• "Another system" to maintain.

Anyone already has been through picking up on Ansible, with an infrastructure already in place, pros and cons with that?

I can add that I'm not "the strongest voice" at my work place, and the code base author is "the most senior" of us all. So a hierarchy is involved, and suggestions from me must be well motivated to be heard.

Glad for any though on this.

PS. Ansible could be any automation tool, regarding your experience. I just happened to pick up on Ansible.

Answer 1

Since your situation obviously isn't only about finding a good way forward from your current situation but also about politics in the workplace it doesn't look as though a purely technical argument will help you all the way.

Practically speaking I would say it's good that you already have a lot of "configuration as code", and especially if you have it version controlled in something like git, the main factor to do something about is readability and working to get rid of the bus factor:

It's bad for the company if important tasks can only be reliably performed by a single person: that's not real job security for the individual but it is a single point of failure for the company.

To introduce new tools, write down a business case to show your manager: what do you expect to gain, and how will this affect his bottom line? Create a proof of concept for some task you regularly do and show how a declarative configuration tool can make a difference in implementation or readability or in the sharing of skills between team members compared to imperative script languages.

And of course there's nothing that says that you have to use only one tool: shell scripts aren't necessarily obsoleted by tools like Ansible, but it sounds like in your company the way they're managed they may be slowing you down.

Answer 2

I think it is worth to speak with and carefully listen to your senior, as you mentioned he's both experienced and a clever guy.

It is essential for your next steps to have a very good understanding of the underlying reasons, why things are the way they are now. Also ask about the challenges or weaknesses that should be solved from his point of view. Quite often there are underlying reasons behind a decision which are difficult to understand for people new to a company.

Depending on the information you received, you may need to answer yourself the question if this company is the right one for you, because the way you portrayed it here rises indeed some eyebrows. If you decide that the job is the right one for you, you should seek to help your senior by focusing on the issues that have been expressed. If not, simply update your CV and start searching new opportunities.

As others have pointed out in the comments, it is not the name of the specific tool that is decisive, but whether it is the most suitable tool for the specific circumstances and company. Given the specific situation, an evolution instead of a revolution could be the right answer.

An evolutionary step, for example, could be to continue to use the existing scripts, but to make them more convenient to work with, while expanding the range of people able to use the function the scripts provide. Maybe version control and the use of tools as Rundeck would be the adequate approach to step forward.

Frequently it helps to present short POCs in which you can show how a specific tool can solve a concrete task in a smarter way. Such an approach is often more effective to convince others than discussions or papers. You also should actively seek for some support within the company, because no matter which tool is chosen, it's how well it's accepted that matters most.

That all being said - personally I like Ansible too, you've already pointed out the perks. However, the way you have presented the situation, proposing Ansible could be mistaken internally as a (negative) revolutionary step or even as opposition.

The bottom line is to listen, and to act with some tact. Good luck!