Choosing Ansible or Terraform for F5 Application Services

Choose one or the other - or both - to deploy and operate F5 Application Services.

The open source movement has always focused on freedom. The freedom to choose the solution that works best for you given skills, budgets, architecture, and goals. That principle continues to be a significant factor today when it comes to building repeatable infrastructure for the deployment pipeline.

There are a lot of great options out there for automating the provisioning and operation of application services. Two of the more popular choices are RedHat Ansible and HashiCorp Terraform. 

Let me stop here and mention that F5 fully supports Ansible and Terraform. We work with both to ensure interoperability and integration, so you don't have to. No matter your choice, we've got your back.

But we have noted during customer engagements that for some tasks, Ansible excels while at others, it's Terraform that shines. That's because automating - and maintaining - a pipeline require different sets of tasks.

Terraform excels at orchestration - the management of the state of an environment. What that means is that Terraform understands what an environment should look like and how it should behave. If something isn’t right, Terraform can flag it for review.

Ansible excels at configuration management. That means its focus is on maintaining the state of individual components. If there's a problem with an individual component in the environment, Ansible can adjust the configuration to address the problem. 

The different focus of each tool means it's not a surprise when we see them used together to automate the deployment lifecycle. 

To see how these two tools work with F5 Application Services, it's a good idea to set common ground with a view of the deployment lifecycle: 

Just as there's a lifecycle for applications with a corresponding delivery pipeline, there's a lifecycle for application services with a corresponding deployment pipeline. That lifecycle requires multiple steps:

1. Provision
   a. Provisioning is the process of actually spinning up an instance - whether a virtual machine or container, whether in a public or private cloud.
2. Onboard
   a. Onboarding is necessary to setup the networking required to operate in the environment in which BIG-IP has been deployed.
3. Deploy
   a. During the deploy phase of the lifecycle, an application service is defined, configured, and launched.
4. Operate
   a. Ongoing operations require monitoring and analytics. F5 Telemetry Streaming enables BIG-IP to plug-in to telemetry pipelines to share desired metrics and data.
5. Change
   a. Change is the process of modifying existing configurations (specified initially during the deploy phase).

Both Ansible and Terraform can be the primary automation provider for all five phases. However, each excels at different phases and thus using both can actually be a better strategy. We are more likely to see Ansible used for the deploy and change (configuration management) phases while Terraform is more often used to provision and onboard (orchestration).

We also know that many customers want to standardize their toolchains - for good reason. Maintaining expertise in multiple tools can be difficult - not to mention operating and maintaining the infrastructure necessary to run multiple toolchains. In that case, there are ways to choose which one of these awesome tools to standardize on.

1. Infrequent changes to infrastructure
   In this scenario, you're making changes to application services but not necessarily to the infrastructure, i.e. BIG-IP. This is often the case when taking advantage of an existing BIG-IP to deploy new applications. Ansible is a good choice here as it excels at configuration management and that's primarily what you'll be doing. Ansible supports a wide range of languages and API styles, making it a great fit for both DevOps and NetOps teams to make changes to application services. You can use Ansible to configure F5 Application Services via F5 Ansible modules or via F5 AS3. Or you can use both depending on your specific needs. For a deeper dive on how to choose your Ansible approach, check out this great blog from Mani Gadde and Andrius Benokraitis.
2. Frequent changes to infrastructure
   Cloud - particularly public cloud - is often chosen to facilitate a high rate of changes in applications and their supporting infrastructure. Immutable infrastructure often aids in managing volatility in this situation, i.e. tearing down and redeploying an entire infrastructure. Terraform is a great choice for this scenario as it excels at provisioning and onboarding entire infrastructures with alacrity. Its design and focus on orchestration is a good fit for creating consistent, repeatable infrastructures at scale, especially in volatile environments like that of cloud. 
3. Frequent change to the infrastructure and application services
   Terraform + Ansible can be great combination for managing high rates of change across both infrastructure and application services. Because you're expecting frequent changes to the state of the environment and individual components, you'll want both change management and orchestration tools to help maintain the availability of applications and their supporting application services

No matter what you choose - Ansible, Terraform, or both - F5 is committed to supporting your choice with native integrations and prepackaged templates along with a community actively contributing and refining both.