What is Automation Contoller (formerly Ansible Tower) and What Problem Does it Solve?
What is the history of Automation Controller/Ansible Tower? Who created it and what problem does it solve?
Ansible Tower was created to solve a critical problem in IT automation: how to manage, scale, and control Ansible automation in large or complex environments. This article is a detailed breakdown of its history, origins, and the problem that it was designed to solve.
History of Ansible Tower
The Origins of Ansible (2012)
Ansible itself was created in 2012 by Michael DeHaan, a systems engineer who previously worked on the Cobbler project at Red Hat. He built Ansible to simplify configuration management and orchestration using a minimal, agentless approach based on SSH and YAML playbooks.
The Founding of AnsibleWorks (2013)
To support commercial adoption, DeHaan co-founded AnsibleWorks in 2013. This company would go on to develop Ansible Tower, a web-based UI and API-driven solution to provide enterprise-grade control over Ansible.
The Release of Ansible Tower (2013)
Shortly after the formation of AnsibleWorks, the first version of Ansible Tower was released. Its goal was to address the needs of teams and organizations that required:
- A centralized interface for running Ansible playbooks
- Role-based access control for multiple users
- Auditing and logging of automation activity
- Job scheduling and visual workflows
- Scalability and API access for integration with other tools
The Acquisition of Ansible by Red Hat (2015)
In October of 2015, Red Hat acquired Ansible, including Ansible Tower. Tower became a core part of Red Hat's automation strategy.
The Rebranding of Ansible Tower to Automation Controller
As part of the Red Hat Ansible Automation Platform, Ansible Tower was rebranded as the Automation Controller to better reflect its role as the central command layer in enterprise automation.
What Problem Does Ansible Tower/Automation Controller Solve?
Ansible Tower/Automation Controller was built to solve several practical challenges that arise when using Ansible at scale:
A. A Lack of Centralized Management:
Running Ansible from the command line is fine for individuals, but it becomes unmanageable for teams, especially with hundreds of servers.
B. Access Control and Security:
There's no built-in way to securely manage who can run which playbooks on which hosts when using Ansible alone. Tower/Controller adds RBAC (role-based access control).
C. Auditability and Logging:
Organizations need to track what automation was run, by whom, and when. Tower/Controller provides detailed job logging and audit trails.
D. Job Scheduling:
Tower/Contoller allows scheduled execution of playbooks, which is critical for repetitive tasks like nightly updates or backups.
E. Team Collaboration and Delegation:
Tower/Contoller makes it easier for operations, security, and development teams to collaborate, delegate tasks, and follow change control processes.
F. API and GUI Needs:
Many teams wanted a GUI to manage jobs and an API to integrate Ansible into CI/CD pipelines or ITSM tools.