Choosing Tools to Deploy and Maintain Applications and Infrastructure – Part 1

Treating your environment as a coding problem

Let’s be real… virtually every new and established business’s internal IT and customer-facing production networks use some form of automation tools to deploy and maintain applications. Without these tools, it would be difficult to compete and meet customer demands. That’s because being competitive means being where customers are – i.e., online and mobile devices. Infrastructure and applications are constantly evolving, and with few exceptions must be available at all times. As such, treating your environment as a coding problem using automation tools, is important now more so than ever.

A sustainable approach to managing complexity

It doesn’t take long for a technical operation to outgrow the capabilities of human intervention. Treating the entire stack as a coding problem and using modern tools is where you need to be. It’s a sustainable approach to managing the ever-growing complexity that comes with making applications available and secure. Tools, much like end-user applications, constantly evolve. And new ones emerge. This leaves many DevOps practitioners wondering if they need to re-write the logic of their infrastructure every time a new tool offers features their existing toolset lacks.

Do I need to choose between tools?

Terraform is a relatively new open-source infrastructure-as-code software tool. It offers many enticing capabilities and features. There is also Ansible – an open-source provisioning, configuration management, and application deployment software tool. You find Ansible commonly used in established infrastructures. If Ansible is already in place, does that mean Terraform is a suitable replacement? If there’s a new initiative in the planning stages, would this be the time to switch to Terraform? Do you need to choose between the two tools? Or, can you use both? It’s a lot to unpack. So let’s jump in and discuss what to consider.

Terraform and Ansible are not competing solutions

Contrary to popular belief, Terraform and Ansible are not competing solutions. Both are proficient infrastructure-as-code tools. However, their approaches are different. This begs the question, “what if instead of choosing between the two software tools, you combine them? Use both for their strengths and purpose?”

In this blog we’ll discuss Terraform’s paradigm of immutable deployment. We’ll look at how it excels at provisioning infrastructure, maintaining state, avoiding configuration drift, and managing the entire deployment lifecycle. We will also demonstrate how Ansible – with its mutable approach to managing infrastructure and applications – masterfully manages configuration management and application software provisioning for initial and ongoing deployments.

I’ll present a few examples and use them to show what happens when you use both together. Using both tools gives you more choices and more flexibility. There’s a lot to unpack here. So let’s jump in to discuss the options and considerations to keep in mind.

Mutable vs. Immutable Infrastructure

Infrastructure can be built to be flexible, or cast in stone. There are pros and cons to consider with both approaches.

Ansible

Ansible is an open-source, procedural configuration tool that is well suited for the flexible (i.e., “mutable”) approach. As an example, say your infrastructure runs on virtual machines. Once deployed, it is updated and configured using configuration management tools such as Ansible. Your Ansible code can update configurations, restart processes, upgrade application code, and so on. You apply changes to one or hundreds of machines and that’s it, right? Well… sort of, but not really. After many upgrades and long periods of time, hosts begin developing their own history of changes. And these may differ from other machines. Consequently, these machines develop what is best described as “configuration drift.” This can make troubleshooting cumbersome because only some machines are behaving in obscure ways, but not others.

Terraform

Terraform, on the other hand, is a declarative provisioning tool. It uses an immutable paradigm for provisioning infrastructure. That is, it is designed to enforce a defined state of your infrastructure. Its strength is in infrastructure provisioning. In our previous example, the virtual machines would be provisioned the first time they are deployed, and re-deployed each time a change is made. Thus, you always know the state of your infrastructure. No configuration drift, and no unique virtual machines with obscure failures to deal with. But wait, does that mean if I do something like change the value of a configuration file, I need to redeploy the entire machine? If you stick with the immutable paradigm, then yes.

Best of both worlds

What if I want to treat part of my infrastructure as immutable and the rest as mutable? It’s possible. But if the 80’s have taught me anything it’s don’t cross the streams unless it’s really necessary. Now, you may have reasons why this makes sense for your infrastructure. Perhaps you aren’t ready to change from immutable to mutable all at once. Or maybe the idea of changing as little as possible without redeploying machines is the best fit for your infrastructure.

In part 2 of this blog, we’ll discuss how to combine Ansible and Terraform to work together. And I’ll provide sample code to support this use case.

Related resources

• Visit the DevNet Networking Dev Center to find use cases, resources, and getting started.
• DevNet Create 2021: Two days of learning and co-creation with apps and infrastructure. Register now for this free, global, virtual event.

---

We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!

Twitter @CiscoDevNet | Facebook | LinkedIn

Visit the new Developer Video Channel