Ansible
Ansible is a universal language, unraveling the mystery of how work gets done. Turn tough tasks into repeatable playbooks. Roll out enterprise-wide protocols with the push of a button.
Ansible is a really nice system that makes a lot of peoples’ lives easier. It has a good community - both directly in the form of frequent updates, chat groups and mailing lists and indirectly in the form of shared configurations. This means it should be easy to really dig into the system, how it is used and how it is architected. It is also written in Python, which is a definite bonus for our team.
Team
- Rutger van den Berg
- Dirk van Bokkem
- Sjoerd van den Bos
- Naqib Zarin
Contributions
Current and future vision of Ansible
Ansible is in the top 10 of the largest and most popular open-source projects on Github. To understand the vision that makes Ansible so successful, we take a look into the end-user mental model as well as the people and companies involved through a stakeholders analysis. Next to that, we unravel Ansible’s following plans with the future roadmap.
Views on Ansible’s Architecture
Relevant Architectural Views
Software Architecture deals with abstraction, (de)composition, style and aesthetics. In order to describe the architecture of Ansible, we use a model composed of multiple views. Views can be seen as perspectives of an architecture. To be able to properly display the architecture of a system, Kruchten came up with 5 different views. We use this so-called “4+1”-view model to give more insight into Ansible. In the next subsections we will cover each view in more detail.
Ansible paying off their technical debt
Now that we have discussed Ansible’s architecture, it is time to dive deeper into the implementation details. Like any other software system, Ansible is prone to the build up of deficiencies in internal quality that make it harder than it would ideally be to modify and extend the system. This deficit in quality is often caused by business pressure on the tech team to meet the milestones. This results in quick and dirty solutions to increase the velocity (see figure below). Interestingly, the Ansible core team has been working on decreasing their technical debt, by migrating all the modules to so-called Collections, which will be laid out in more detail in this essay. Similarly, a major refactoring of the code was done in Ansible 2.0 to pay off the technical debt that had accumulated. To analyze the current technical debt of Ansible, we will first examine the development process. Then we give an analysis of the code quality and finally we will discuss how Ansible is planning to deal with this debt in the future milestones.
Does Conway’s Law Apply to Ansible?
In this post the structure of Ansible will be analyzed. First the structure of the codebase will be discussed. This will be done on the component-level. The most important components will be brought to attention and their mutual coupling will be touched upon. This will be followed up by an in-depth look at the communication and social structure of the development community of Ansible.