Infrastructure-as-code allows you to use a programming language to define your infrastructure. Today, many tools are available, so it is not easy to find your way around. In this exchange, Benoît Latinier Architect Developer at theTribe, explains the differences between Terraform and Kubernetes and how they are evolving within companies.
Benoit, can you explain what Terraform and Kubernetes are? What kind of projects can we use them on?
Terraform is an Infrastructure as Code (IaC) tool developed by HashiCorp that allows you to describe your server infrastructure and version it using the HashiCorp Configuration Language (HCL).
It allows you to apply the changes described in its files without having to connect to the interfaces of the services used (AWS, Azure, GCE, Scaleway...). It is a must for multi-cloud architectures, but also for those a bit complex. And in any case, it doesn't hurt to use it on simple configurations either 🙂
Kubernetes is a container orchestrator. It allows you to manage scalability, redundancy and resilience of a containerized architecture. When you develop your architecture with containers and you start to have to do scaling, it is a very serious candidate!
In your opinion, why are these two technologies increasingly used in IT production?
The versioned architecture with change history is an advantage that alone can justify the use of Terraform on almost any architecture. It allows you to work with greater security (revertability) and agility. In addition, Terraform supports a large number of providers, including the cloud leaders (Google Cloud Platform, AWS, Microsoft Azure) and allows them to communicate intelligently in a few lines of code without having to go through the service interfaces, which provides a certain efficiency. This possibility of inter-cloud communication offered by Terraform makes it indispensable, especially for multi-cloud architectures.
Kubernetes faces more competitors (Rancher, Nomad+Consul, Mesos, Docker Swarm...) and although it has established itself as the most successful container orchestration tool, they are still very much present. This leading position and its robustness mean that it is increasingly used for architectures that are intended to scale. And as Docker is becoming more and more popular, Kubernetes is taking advantage of this by being in its wake.
Are these technologies easy to install / learn / use? What are the obstacles to their use?
Terraform is quite simple to set up and use. The basic concepts are pretty easy to grasp and you can achieve a very satisfactory result in a very short time. Terraform is not yet widely used by developers and companies that have not yet been able to hire Ops (or devOps). Note that even if Terraform is simple in its basic concepts, you still need to dive into the technical documentation of each plugin to be able to implement them correctly. Thus, a multi-cloud architecture requires a minimum mastery of the concepts of all the clouds involved.
Kubernetes is more complicated to set up and use. It is often advisable to use the managed Kubernetes tools of the Clouds (all the main ones provide them, for example GKE for GCP) because it avoids the implementation of the Kubernetes cluster which is very technical. Beyond that, the concepts and objects of Kubernetes are new concepts that you have to learn to handle. This barrier to entry is its main obstacle to adoption.
What would be the advantages for a company to implement these systems in its production?
The advantage of implementing Terraform is to have a global and controlled vision of the infrastructure and therefore the assurance of not having lost or hidden services/servers that are billed for nothing. It is also the simplicity in the modifications of its architecture. It is the control of the evolution of the costs (it is always possible to find the architecture used 1 month, 3 months, 6 months ago... and to draw a trend in the evolution of the costs). To sum up, it is a real help to optimize the architecture in place and to come.
Kubernetes is to be used under the right conditions. If you have only one service that has few users, or no need to scale in the medium term, then it will be a waste of resources (the internal services of Kubernetes require a minimum of resources themselves). When the infrastructure becomes more complex and we get to around 3 or 4 distinct services, it becomes more relevant to use Kubernetes to manage scaling, deploymentsand resilience of services. This is particularly appropriate for an IS that has adopted the microservice architecture (but this is not a necessary condition for using Kubernetes).