L’infrastructure-as-code permet d’utiliser un langage de programmation pour définir son infrastructure. Aujourd’hui, de nombreux outils sont disponibles si bien qu’il n’est pas aisé de s’y retrouver. Dans cet échange, Benoît Latinier, Architect Developer chez theTribe, nous explique les différences entre Terraform et Kubernetes ainsi que leurs évolutions au sein des entreprises.
Benoît, peux-tu nous expliquer ce que sont Terraform et Kubernetes ? Sur quels genres de projets peut-on les utiliser ?
Terraform est un outil d’Infrastructure as Code (IaC) développé par HashiCorp qui permet de décrire son infrastructure serveur et de la versioner en utilisant le langage HCL (HashiCorp Configuration Language).
Il permet ainsi d’appliquer les changements décrits dans ses fichiers sans avoir à se connecter sur les interfaces des services utilisés (AWS, Azure, GCE, Scaleway…). C’est un incontournable pour les architectures multi cloud, mais aussi pour celles un peu complexes. Et dans tous les cas, ça ne fait pas de mal de l’utiliser sur des configurations simples non plus 🙂
Kubernetes est quant à lui un orchestrateur de container. Il permet de gérer les montées en charge, la redondance et la résilience d’une architecture conteneurisée. Lorsque l’on développe son architecture avec des conteneurs et que l’on commence à devoir faire du scaling, c’est un candidat très sérieux !
À ton avis, pourquoi ces deux technos sont-elles de plus en plus utilisées en production informatique ?
L’architecture versionnée avec l’historique des modifications est un avantage qui peut à lui seul justifier l’utilisation de Terraform sur quasiment toutes les architectures. Elle permet de travailler avec une meilleure sécurité (possibilité de revenir en arrière) et une meilleure agilité. De plus Terraform prend en charge un grand nombre de fournisseurs, dont les leaders du cloud (Google Cloud Platform, AWS, Microsoft Azure) et permet de les faire communiquer intelligemment en quelques lignes de code sans avoir à passer par les interfaces des services ce qui procure une certaine efficience. Cette possibilité de communication intercloud offerte par Terraform le rend incontournable notamment pour les architectures multicloud.
Kubernetes fait face à davantage de concurrents (Rancher, Nomad+Consul, Mesos, Docker Swarm…) et bien qu’il se soit imposé comme l’outil d’orchestration de container le plus abouti, ces derniers sont encore bien présents. Cette position de leader et sa robustesse font qu’il est de plus en plus utilisé pour des architectures ayant vocation à scaler. Et comme Docker se démocratise de plus en plus, Kubernetes en profite en étant dans son sillage.
Ces technos sont-elles faciles à installer / apprendre / utiliser ? Quels sont les freins à leur emploi ?
Terraform est assez simple à mettre en place et à utiliser. Les concepts de base sont plutôt faciles à appréhender et on peut atteindre un résultat très satisfaisant en très peu de temps. Terraform n’est pas encore très répandu dans le milieu des développeurs et des entreprises qui n’ont pas encore pu engager d’Ops (ou devOps). À noter que même si Terraform est simple dans ses concepts de base, il faut quand même se plonger dans la documentation technique de chaque plugin pour pouvoir les implémenter correctement. Ainsi une architecture multicloud demande de maîtriser un minimum les concepts de tous les clouds concernés.
Kubernetes est lui plus compliqué à mettre en place et à utiliser. Il est souvent conseillé d’utiliser les outils de Kubernetes managé des Cloud (tous les principaux en fournissent, par exemple GKE pour GCP) car cela évite la mise en place du cluster Kubernetes qui est très technique. Au-delà de ça, les concepts et les objets de Kubernetes sont des notions nouvelles qu’il faut apprendre à manipuler. Cette barrière à l’entrée est son principal frein à l’adoption.
Quels seraient les avantages pour une entreprise de mettre en place ces systèmes dans sa production ?
L’avantage d’implémenter Terraform c’est d’avoir une vision globale et maîtrisée de l’infrastructure et donc l’assurance de ne pas avoir des services/serveurs perdus ou cachés qui sont facturés pour rien. C’est aussi la simplicité dans les modifications de son architecture. C’est la maîtrise de l’évolution des coûts (il est toujours possible de retrouver l’architecture utilisée il y a 1 mois, 3 mois, 6 mois… et de dessiner une tendance dans l’évolution des coûts). Pour résumer, c’est une vraie aide à l’optimisation de l’architecture en place et à venir.
Kubernetes quant à lui est à utiliser dans les bonnes conditions. Si on a qu’un seul service qui a peu d’utilisateurs, ou pas besoin de scaler sur le moyen terme, alors ça sera un gaspillage de ressources (les services internes de Kubernetes demandent eux même un minimum de ressources). Quand l’infrastructure se complexifie et qu’on arrive autour de 3 ou 4 services distincts, il devient plus pertinent d’utiliser Kubernetes pour gérer le scaling, les déploiements et la résilience des services. C’est particulièrement adapté à un SI qui aurait adopté l’architecture en microservice (mais ce n’est pas une condition nécessaire à l’utilisation de Kubernetes).
