I’m currently working a lot with Microsoft Azure to provide the organisation I work for with a robust, cost effective IT Disaster Recovery platform. Up until a year ago, we operated a rack in a CoLocation facility to provide IT Disaster Recovery services. Whilst a decade ago, that was fit for purpose, in 2018, that was an expensive way of providing IT Disaster Recovery.
This use case in Microsoft Azure is helping me form a vision for what modern infrastructure operations could look like for our organisation.
Whilst considering Infrastructure as Code and how we’d evolve our PowerShell scripts and VMware templates into something more modern, the very next question I had once I’d formed enough of understanding around why the idea for modernising scripts was good, was that it seemed like I needed to consider another tool to execute the idea.
Configuration Management tools are the answer to my question.
Configuration Management tools have two models which seem to carry differing philosophies – imperative versus declaritive models. Microsoft ARM templates – which are the reccomended tool to automate the deployment of resources in Azure – use a declaritive model to get things done. I feel that it could be reasonable to assume that extending that model into the Configuration Management tool could help me make a choice on which to choose from.
When reviewing the wikipedia page on the tools, for now I’ve settled on Ansible to give me some context of how a Configuration Management tool could help us.
These are the reasons why:
- Ansible is a new kid on the block with a hybrid imperative/declerative model.
- I’m already invested into Python, the language Ansible is coded in.
- Ansible Tower is now open sourced as Ansible AWX on CentOS and is also owned and operated by Red Hat. CentOS/Fedora is our choice of Linux distribution.
I’m looking forward to giving the tool a chance to shine over the next couple months and will reflect on my thoughts here when I’m done.