Let's face it, we don't live in a vacuum. We wake up everyday needing to deal with network equipment made by various vendors. We saw the difference between Pexpect and API in previous chapters, and the API integration certainly did not appear out of thin air. Each vendor needs to invest time, money, and engineering resources to make the integration happen. The willingness for the vendor to support a technology matters greatly in our world. Luckily, all the major vendors support Ansible as clearly indicated by the ever increasingly available network modules (http://docs.ansible.com/ansible/list_of_network_modules.html).
Why do vendors support Ansible more than other automation tools? Being agentless certainly helps, having SSH as the only dependency greatly lowers the bar of entry. Engineers who have been on the vendor side know that the feature's request process is usually months long and has many hurdles to jump through. Any time a new feature is added, it means more time spent is on regression testing, compatibility checking, integration reviews, and many more. Lowering the bar of entry is usually the first step in getting vendor support.
The fact that Ansible is based on Python, a language liked by many networking professionals, is another great propeller for vendor support. For vendors such as Juniper and Arista who already made investments in PyEZ and Pyeapi, they can easily leverage the existing module and quickly integrate their features into Ansible. As you will see in the next chapter, we can use our existing Python knowledge to easily write our own modules.
Ansible already has a large number of community-driven modules before its focus on networking. The contribution process is somewhat baked and established or as much an open source project as it can be. The core Ansible team is familiar in working with the community for submission and contribution.
Another reason for the increased network vendor support also has to do with Ansible's ability to give vendors the ability to express their own strength in the module context. We will see in the next section that besides SSH, the Ansible module can also be executed locally and communicated to the devices using API. This ensures that vendors can express their latest and greatest features as soon as they make their API available. In terms of network professionals, this means that you can use the features to select the vendors whenever you are using Ansible as an automation platform.
We have spent a relatively large portion of space discussing vendor support because I feel this is often an overlooked part in the Ansible story. Having vendors willing to put their weight behind the tool means you, the network engineer, can sleep at night knowing that the next big thing in networking will have a high chance of Ansible support, and you are not locked in to your current vendor as your network needs grow.