Tweet This: Tweet
Share on LinkedIn:
By Taylor Owen, Kovarus Automation Solution Architect
As Information Technologies evolves, there are more tools that proliferate the space. Naturally, when talking to customers about how to best manage their on-premises and public cloud infrastructure, tooling is one of the first discussions to come up. To be able to manage infrastructure, three categories of tools are needed:
- A provisioning tool
- An orchestration tool
- A configuration management tool
Often times customers try to find one tool that does all of these things. Unfortunately, there’s not a tool that can do all of these things well, and especially at scale. To help clarify these three items, I’m going to put some definition around them.
Provisioning is the act of creating VPCs, Resource Groups, VMs, EC2 instances, etc. Provisioning and configuration management tend to go hand in hand. When provisioning infrastructure, the tool is often only used at the beginning of the resource creation. This could be anything from scripts to Ansible playbooks, but the key difference between provisioning and configuration management is that once the resource is created it not touched again by the provisioning tool.
Orchestration involves the order of tasks across different resources, e.g. stop the service on one VM, update the configuration on a different VM, update the configuration of a load balancer, and then start the service on the original VM. Orchestration does not declare the final state of the system but is used to execute a series of tasks across different resources and systems.
Configuration Management is ensuring that a resource is in the state it is currently defined as. When I reference configuration management, I’ll be talking about the configuration management of the infrastructure, and the items in the infrastructure. To further extrapolate this, one can think of the configuration management aspect of ensuring that an EC2 instance belongs to a certain target group for a load balancer, but then there is the configuration management of the EC2 instance’s operating system to ensure it is a web server. With configuration management there is an ongoing process to ensure that the resources stay in their defined states in which the concept of idempotency is often applied.
State is the condition a resource is in at a point in time. A resource can be anything from a software package on a system, a line in a configuration file, permissions on a file, a VLAN configuration on a switch, etc. The state we’ll primarily focus on is the combination of all of these resources which make up the state of a system as a whole.
With that said, when looking at the two tools they seem to provide very similar roles when it comes to provisioning, orchestration and configuration management, so which tool should be used when? First, I’ll provide a high-level overview between the tools, and then in the second part of the blog we’ll discuss the synergy between Terraform and Ansible as it is not one to ignore.
Ansible is an easy, powerful tool to getting up and running, and providing an easy way to start automating tasks across many devices. I attribute this to the agentless aspect of the tool, the support of many different vendors and platforms, and its base being written in Python. The YAML format used to execute a series of tasks is easily readable and writable compared to other tools and their respective languages.
In terms of the three key functions listed previously, Ansible can technically do all of them. For small-scale implementations it works well doing all three, but not when it starts to scale out. Often times I’ll see customers go all in with Ansible to only start hitting a wall when they’re starting to manage more infrastructure. The further one gets into using Ansible, there is one piece that starts to stand out: This piece’s statefulness.
Some reading this might say, “Well, I can manage whether or not a package is on a system,” which is true, but to reiterate the state we’re primarily focusing on is the combination of all of these resources which make up the state of a system as a whole.
I’ll go more into this in the second part of this blog.
Terraform has gained a large user base the past few years due to its approach to enabling customers with hybrid/multi-cloud strategies. It is written in Golang and uses a proprietary Domain Specific Language (DSL) called HashiCorp Configuration Language (HCL). In a nutshell HCL is a more simplified version of JSON, and the HCL engine can even parse valid JSON along with HCL. Terraform leverages the APIs of the public cloud providers and other platforms such as VMware. When resources are provisioned, a state file is output as part of the provisioning process which then it uses to check whether or not changes are needed to bring the infrastructure back into its declared state. This will become a key aspect in the 2nd part of this blog.
When referencing the previous three key functions, Terraform can also do all three items, depending on what you’re doing configuration management against. Of the three items, it is weakest on configuration management against operating systems, network devices, etc. out of the box. It is strongest in the first two functions when it comes to provisioning infrastructure and keeping the infrastructure itself under configuration management. When it comes to provisioning, Terraform tries to provision as much infrastructure at the same time as possible. This multi-threaded approach makes Terraform very quick at provisioning infrastructure.
Now that we have discussed the differences between the tools, in part two of this blog we learn about integrating these two tools.
Looking to learn more about modernizing and automating IT? We created the Kovarus Proven Solutions Center (KPSC) to let you see what’s possible and learn how we can help you succeed. To learn more about the KPSC go to the KPSC page.
Also, follow Kovarus on LinkedIn for technology updates from our experts along with updates on Kovarus news and events.