Selleo Labs spółka z o.o.

**Terraform vs Ansible, Ansible vs Terraform** - Google search is full of those queries, but are they true? Is there a war between those solutions and you can use only either-or? Or are they, in fact, a great combination and can or even should be used together? This article aims to solve the confusion and once for all answer the question: **Terraform or Ansible**?

This article is based on research as well as the subjective opinions of developers.

## Terraform

According to Terraform’s website

*Terraform is a tool for building, changing, and versioning infrastructure safely and efficiently. Terraform can manage existing and popular service providers as well as custom in-house solutions.*

[Terraform is used](https://stackshare.io/stackups/ansible-vs-terraform) by **Slack**, **Twitch** (owned by Amazon, which has its own infrastructure building tools like [Cloud Formation](https://aws.amazon.com/cloudformation/)), **Uber**, **Starbucks**. It can be integrated with CloudFlare, Heroku, Microsoft Azure or Google Compute Engine.

## Ansible

Ansible is the simplest way to automate and configure apps and IT infrastructure. An enterprise automation platform for the entire IT organization, no matter where you are in your automation journey.

[Ansible is used](https://stackshare.io/stackups/ansible-vs-terraform) by companies like **9gag**, **Zalando** and **Revolut**. It can be integrated with Docker, Amazon EC2 or Kubernetes.

## Who’s the best?

First of all, it is hard to clearly determine which one is better, because, although they are similar, they were created for different purposes.

Terraform is an **orchestration tool** and Ansible is a **configuration management tool**, however, some of their functions overlap, but are not excluding and can be used together.

I came across a great analogy to explain it: **an orchestra of musicians**. Here, Terraform would be a conductor who ensures that the right number of instruments are playing and sound correct.

If there is an issue, the conductor replaces the broken instrument with a working one. We can say that orchestration tools focus on the end result and make sure that the environment stays in a particular “state”. This makes Terraform a fantastic option for environments that require a steady-state.

Ansible - **the configuration management tool** - in such a situation will behave differently. It will work in order to repair the broken instrument instead of replacing it. However, Ansible is able to perform orchestration tasks, but Terraform is thought to be more advanced and generally a better option for it.

Terraform has built-in parallel mechanisms which allow creating a set of resources (within dependency tree) in threads. To achieve the same, Ansible would require to **creatively use async and poll**, which would probably make you do [async blocks](https://www.ansible.com/blog/ansible-performance-tuning) with a wait period between them.

![](https://s3.amazonaws.com/a.storyblok.com/f/86602/764x307/fdc4cb9ccf/parallel_mechanism.png)

## Procedural or Declarative?

Another division in DevOps tools is **procedural vs declarative**. Those categories describe how tools perform their actions. Here, Terraform falls into the declarative group, which means if your defined environment changes, it will be corrected by Terraform.

Going back to **the analogy of an orchestra** - with Terraform you would have to declare how many more (or less) instruments do you want. So if you have 5 instruments and need 5 more, you would lay it in the code. If you need less you would specify how many you want to be removed.

On the other hand, Ansible would be perceived as a **hybrid** as it can perform procedural-style configuration or make use of modules that perform decorative-style. So it is super important to read the documentation and ensure you understand the behaviour expected.

That being said, Terraform is perfect for configuring **cloud infrastructures** and Ansible is used for **configuring servers** within this infrastructure. Many use Terraform to build servers and Ansible to configure them, even though Terraform lacks a provisioning plugin for Ansible. You can also call necessary Ansible roles from within Terraform.

Going through statistics on stackshare.io however, Ansible is much more popular than Terraform scoring over 12k StackOverflow questions and 41k GitHub stars.

## Conclusion

Terraform was designed with immutability in mind. It is a provisioning tool that deals with immutable infrastructures in a native way. This makes it a good choice when you reject configuration management tools. The tool is more intuitive for infrastructure orchestration because it was created for it and all of its updates are dedicated to that.

Ansible is optimized for configuration management and although it can perform orchestration tasks it is better to use the best (and fastest) tool for the given task.

All in all, both Terraform and Ansible can work as **standalone tools** or **work together**, but remember to always use the right tool for a given job.

Terraform vs Ansible, Ansible vs Terraform - Google search is full of those queries, but are they true? Is there a war between those solutions and you can use only either-or? Or are they, in fact, a great combination and can or even should be used together?

Terraform Vs Ansible - Friends Or Foes? Which Should I Choose?

[TOC]

Created by Google this open-sourced system helps manage containerized applications within cluster environments. It gives developers a better way to deal with related and distributed components as well as services in infrastructure. After Docker became a hit thanks to its wide use of containers, [Kubernetes](https://kubernetes.io/) was added to the Docker community as an additional orchestration engine and it became the biggest name in Cloud Native.

In 2017 Kubernetes officially won the [Container Orchestration War](https://www.cloudhealthtech.com/blog/container-wars-are-over-kubernetes-has-won) beating Mesos, Magnum and Photon, just to name a few. Later that day AWS announced the Elastic Container Service for Kubernetes. Native support was also announced from Pivotal, Docker as well as from Mesosphere.

Kubernetes can be visualized as a system built in layers, with each higher layer abstracting the complexity found in the lower levels.
At its base, Kubernetes brings together individual physical or virtual machines into a cluster using a shared network to communicate between each server. This cluster is the physical platform where all Kubernetes components, capabilities, and workloads are configured.

## The basics

Kubernetes is a system built from layers bringing together virtual and physical machines connected by a shared network. Each of those servers has its own function. One of them is a [master](https://kubernetes.io/docs/concepts/#kubernetes-master) server which handles APIs, therefore, being the brain of operations, communicating with other components and performing scheduling. It is the main point for users and administrators.

A master server has its own components that accept user requests, manage scaling etc. They can be installed on a single machine or across multiple servers.
**`etcd`** is one of the most fundamental master server components and is used to store configuration data. It can help components to configure and reconfigure while maintaining the cluster state.

**[Kube-controller-manager](https://kubernetes.io/docs/admin/kube-controller-manager/)** manages different controllers and regulates the state of the cluster. It performs routine tasks and can be used in application scaling or endpoint adjusting.

**[Kube-scheduler](https://kubernetes.io/docs/admin/kube-scheduler/)** assigns workloads for the available nodes by analyzing the current infrastructure environment. It must know the total capacity and the currently available resources.
What is more, Kubernetes master is a part of the **[Kubernetes Control Plane](https://kubernetes.io/docs/concepts/#kubernetes-control-plane)**, which maintains the desired state across the cluster.

## Nodes

Other machines in the cluster are designated as **nodes**, which run the workloads and are controlled by Kubernetes master. Kubernetes runs services and applications in clusters to help with flexibility and management.
Each node has to have a container runtime that is responsible for starting and managing applications and containers.

**[Kubelet](https://kubernetes.io/docs/admin/kubelet/)** is an interface for communicating between the Kubernetes master and the node. It retrieves information to end from services as well as communicated with the `etcd` store.

**[Kube-proxy](https://kubernetes.io/docs/admin/kube-proxy/)** is a proxy service managing individual hosts and services availability. It performs simple UDP and TCP stream forwarding.

Kubernetes objects represent the state of all of the entities in the system. It is also an extra layer of abstraction over the container interface. They provide resiliency, scaling and life cycle management features.

## Pods

The most basic and the smallest deployable unit that Kubernetes deals with is a [pod](https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/). It represents one or more containers that are to be controlled by a single application. Pods are managed together as a unit, sharing volumes, environment and life cycle. What is more, they have to always be scheduled on the same node.

A pod template and control parameters are defined by an object called a replication controller. It ensures that the number of pods deployed is equal to the number of pods in its configuration. Replication controllers are starting to be replaced with replication sets, which are more flexible. Replication sets are used by deployments as building blocks. They can be modified by changes in configuration and because of that they are the most commonly used Kubernetes objects.

With pods there are also specialized pod controllers: stateful sets and daemon sets. The former create number-based names for each pod. They perform operations following the numbered identifiers. The latter, return a copy of a pod on each node, which helps during deployment of maintenance pods. Jobs is a workload used by Kubernetes. It ensures a task-based workflow and that running components successfully exit after performing their tasks.

Apart from the above-mentioned Kubernetes components we can also distinguish: 

* [services](https://kubernetes.io/docs/concepts/services-networking/service/) \- defining a logical set of pods, acting as a basic internal load balancer and grouping logical collections of pods
* [volumes](https://kubernetes.io/docs/concepts/storage/volumes/) \- a directory to all containers present in a pod, which allows data sharing
* and [namespaces](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/) \- virtual clusters supported by a physical cluster.

## Summary
Kubernetes is a great tool for container orchestration. It allows scaling services, defining and managing applications while preserving high flexibility, reliability and power.
It can be integrated with any cloud portfolio like Google Cloud or AWS. Despite being quite daunting at the beginning, Kubernetes is an amazing tool that will leverage the full capabilities of the platform.


Created by Google this open-sourced system helps manage containerized applications within cluster environments. It gives developers a better way to deal with related and distributed components as well as services in infrastructure.

Read our articles on Selleo Blog

Business

Technology

Terraform Vs Ansible - Friends Or Foes? Which Should I Choose?

Kubernetes 101

Tell us about your project

Company

Our Services

Blog

Other Services

Countries

Awards & Certificates