Rely on External Modules or Do It In-House?

Written .

In “Ansible Best Practices” Red Hat product manager Timothy Appnel recommends to use command modules sparingly and shell and command only as a last resort. Instead, you should better use a community-provided module.

I do not agree with this, at least not per se. A few days ago I had an issue with the homebrew module which is a community-provided module for ansible. While it works fine, it misses some features (like autoremove) which the command line implementation supports. So I have decided to rather use the direct shell invocation.

Relying on third-party modules means outsourcing responsibility for updates and bug fixes. This is often a great idea, especially for security-related code! However, it also means that a system update which the current module implementation can’t handle will block your deployment. Now you have to wait for the module maintainer to ship a solution. Even if there is a simple fix from the community, the maintainer needs to review, accept and merge the pull request and subsequently release the revised external module before you can use it.

Essentially, you put yourself at the mercy of the package maintainer. Removing the external module and replacing it with your own code may end up being more work than fixing your own code in the first place.

This is obviously a special case of the generic question on whether you should rely on third-party solutions or write everything yourself. The latter is the infamous “not invented here” anti-pattern where you never accept anything else but your own solution, even if there are reliable, well-maintained alternatives out there.