Control-M vs Ansible

• Control-M Advanced File Transfer is a very useful add-on, allowing for a wide variety of file transfers to be configured "out of the box" and then used as part of the standard batch flow. This module is not included in the base price but is available at a relatively small additional cost.
• Using Control-M's GUI (the Enterprise Manager) allows for efficient management of the enterprise and can tie up a lot of "loose ends". Often the first point of tracking problems is to check with the Control-M guys!
• BMC is definitely moving the product forward, the new module "Application Integrator" is very helpful in building and deploying your own bespoke Control-M jobs and allows for closer and more secure integration.
• Although Control-M does open up the enterprise in an operational sense, the security settings (should you choose to implement them) are robust.

Read full review

• Agentless. For our implementation, this is the single biggest factor. If we have to touch the machine and install an agent before we can start managing it, that's already too much effort and slows us down.
• Re-entrant. This is not unique to Ansible, but certainly a huge improvement over custom scripts and such. Because it's such a huge effort to make scripts re-entrant, most of our scripts did not allow an elegant way to recover on failure. Manually cleaning up the half-attempt and re-trying is still too cumbersome, and being able to just re-run Ansible is a great improvement!
• Infrastructure as code. This is new to Ansible, and there are still a few minor bugs with their AWS modules, but it's been a huge help being able to define our infrastructure in an Ansible playbook, commit it to source control, and use one tool for all our DevOps tasks.

Read full review

• Single Major Action per job: this statement needs to be clarified. There are ways to do more than one action per job, and there are pre and post job commands available in most templates. Also some templates like FTP can have many instructions built in, like deleting source files after transfer (these are part of the positives). But basically you can only do one major action, like call one web service, or call one stored procedure per job. I believe this limitation is due to their licensing model, to ensure you will run as many jobs as possible.
• The only other negative is a necessary corollary of a having a powerful product. The learning curve is not simple due to the power of the product. I would recommend dedicate training for the primary operators and users of the product.

Read full review

• Ansible Tower is a paid service, which can be annoying at times. But that is understandable, as it requires an additional level of support from the Ansible team to develop.
• There is a decently large learning curve for someone not familiar with setting up Unix environments. However, there is a very large support community with tons of documentation, so it's not a dealbreaker.

Read full review

• Troubleshooting has improved with multiple groups as they are easily able to determine if data loss/job failure is the reason for a data issue.
• Conversion took significantly longer than was originally estimated by BMC so we had to run two platforms for almost 9 months. This definitely slowed down efficiency as many users did not know which tool to utilize for data load trouble shooting for close to a year.
• Being able to communicate with users across the globe in a universal language and time reference has vastly decreased data issues and greatly improved proficiency in getting new jobs implemented quickly and without problems.

Read full review

• We have been able to deploy solutions to client issues without impacting uptime.
• Most system administration tasks have been automated so I am now free to work on architectural improvements or customer support.
• Our customer support has improved thanks to Ansible as it has allowed me more time away from repetitive system activities so I may assist with customer questions and application testing.

Read full review