Si vous avez cliqué sur cet article, c'est sûrement que vous connaissez et utilisez potentiellement l'**Infrastructure as Code** (IaC). Si tel n'est pas le cas, je vais vulgariser un peu ce magnifique terme.
L'IaC est une pratique qui consiste à gérer et provisionner des infrastructures et des assets informatiques à l’aide de fichiers de configuration. Plutôt que de manipuler directement vos ressources informatiques, l’IaC permet de définir et d’automatiser leur mise en place et leur gestion. Techniquement, on pourrait comparer cela à du scripting bash pour déployer vos serveurs, mais en plus poussé.
Ici, on a l'avantage, en IaC, d'avoir "clé en main" une traçabilité, une cohérence et une idempotence de toutes les machines et des assets.

On peut ainsi dire que l’infrastructure est générée en code, que ce soit du code pur (comme c'est le cas avec Pulumi, mais on y reviendra) ou avec des fichiers de configurations YAML, HCL, JSON, etc. 

Ce qui était autrefois une étape manuelle et sujette à des erreurs devient aujourd’hui un processus agile et automatisé, aligné sur les principes du DevOps et de l’intégration continue/déploiement continu (CI/CD).

Maintenant qu'on est plus familier avec ce qu'est l'IaC en tant que tel, passons au vif du sujet.  
Pourquoi le si connu et vanté Pulumi n'est-il pas toujours la meilleure solution pour vos projets ?  
Pourquoi la promesse d'utiliser uniquement votre langage de développement n'est-elle pas forcément gage de bon choix d'outil ?

## Deux philosophies distinctes

[Terraform](https://www.terraform.io/) est un outil d'abord open-source puis propriétaire, développé et maintenu par [HashiCorp](https://www.hashicorp.com/) depuis 2014 (les papas de Packer et Vault notamment). Un fork open-source existe : [OpenTofu](https://opentofu.org/).  
Initialement, l'outil utilisait le langage HCL, un langage créé par HashiCorp (d'où son nom d'ailleurs, HCL voulant dire HashiCorp Configuration Language), puis a introduit d'autres possibilités, notamment le JSON.  
Un avantage majeur de Terraform est sa vaste adoption et sa communauté active. Grâce à cette popularité, Terraform dispose de nombreux [modules et plugins](https://registry.terraform.io/browse/providers) maintenus par la communauté, couvrant presque tous les fournisseurs de cloud majeurs et services tiers.

[Pulumi](https://www.pulumi.com/) est un outil plus jeune, lui aussi open-source, développé par Pulumi Corp. De la même manière, Pulumi se base sur des [modules et plugins](https://www.pulumi.com/registry/) maintenus par la communauté, permettant de couvrir les fournisseurs.  
Ces deux outils demeurent similaires sur beaucoup d'aspects, notamment la gestion d'état, qui est un des éléments clés de ces outils et qui est **vraiment** un game-changer dans le déploiement continu et la maintenabilité de vos infrastructures. Ils diffèrent aussi sur certains points.

En effet, bien que les deux outils utilisent une syntaxe déclarative, l'une des différences majeures est que Pulumi s'oriente davantage vers les développeurs allant vers de l'IaC en utilisant du code natif et des librairies pour travailler sur nos infrastructures. L'avantage réside dans la diversité des langages. Vous y trouverez forcément votre bonheur. Vous pouvez voir tous les langages actuellement disponibles [ici](https://www.pulumi.com/docs/iac/languages-sdks/).

## La documentation

Quand on navigue dans la documentation de Terraform, je trouve que celle-ci est très bien construite, intuitive et très formatrice, de même chez Pulumi, surtout pour les documentations par registre.  
Les registres chez Pulumi sont quasiment tous extrêmement bien fournis avec des exemples dans tous les langages (celle d'[AWS](https://www.pulumi.com/registry/packages/aws/api-docs/s3/bucket/) notamment, que je trouve tout simplement parfaite).

**Par contre**, sur ce même outil, un vrai souci est présent avec [Pulumi IA](https://www.pulumi.com/ai), leur modèle d'IA. Autant je trouve que c'est une idée incroyable sur le papier, autant des lacunes sont présentes. Le code généré par cette IA est parfois absolument catastrophique, avec des complexités ahurissantes. Et, le second souci que je trouve encore plus dérangeant, est qu'une bonne partie de vos recherches Google sur le déploiement d'un service vous renverront sur une documentation sur le site Pulumi, où le code est souvent généré par l'IA Pulumi et souffre donc de ces mêmes lacunes.

## Et quel souci avec Pulumi dans tout ça ?

Un premier souci qui n'en est pas vraiment un et qui tend à se résoudre est le manque d'utilisateurs. En effet, bien que Pulumi soit de plus en plus utilisé, nous revenons vers le point précédent : on finit souvent sur la documentation qui, au final, n'est que du Pulumi IA.  

Le second souci, qui est présent dans les librairies Python et JS (je n'ai pas testé pour le reste), est que l'on retrouve des classes natives avec les mêmes noms dans plusieurs librairies, ce qui est assez déroutant et illisible en termes de codebase, notamment sur les providers AWS.  
Enfin, dès qu'une infrastructure devient très conséquente et avec du traitement de boucles, etc., le déploiement devient très vite long, ce qui est vraiment un gros point pour Terraform qui garde une très forte fluidité, peu importe la complexité de l'infrastructure.

## Quels avantages à utiliser Pulumi ?

Il y a aussi des avantages indéniables, et on ne peut le nier, le principal étant (et oui, je sais, ça va être paradoxal) le fait d'utiliser du code.  
Quoi de mieux que de faire des boucles et toute la syntaxe de votre langage préféré plutôt que d'utiliser du HCL ?

Si on compare cet exemple en HCL :
```
variable "bucket_names" {
  type    = list(string)
  default = ["bucket-1", "bucket-2", "bucket-3", "bucket-4", "bucket-5"]
}

resource "aws_s3_bucket" "my_buckets" {
  for_each = toset(var.bucket_names)

  bucket = each.key
  acl    = "private"

  tags = {
    Name        = each.key
    Environment = "developement"
  }
}
```
Avec ceci en JS avec Pulumi :
```
const bucketNames = ["bucket-1", "bucket-2", "bucket-3", "bucket-4", "bucket-5"];

bucketNames.forEach(name => {
    const bucket = new aws.s3.Bucket(name, {
        bucket: name,
        acl: "private",
        tags: {
            Name: name,
            Environment: "development"
        }
    });
});
```
Le JS est quand même beaucoup plus lisible et maintenable à mon goût.

De plus, développer avec du code natif présente davantage l'intégration dans un outil externe (développement d'une plateforme, par exemple), c'est le **must-have**.

## Mais alors, lequel choisir ?

J'ai envie de dire, c'est selon vos préférences.  

Cependant, je tends toujours vers Terraform, malgré qu'il soit devenu propriétaire (on peut toujours utiliser OpenTofu, qui est le même outil, si on souhaite rester en open-source), qui présente pour moi plus de maturité, de stabilité et de fluidité. 
Bien que Pulumi soit très intéressant dans certains usages, le manque de documentation et les incohérences de librairies me repoussent un petit peu.  
Terraform garde aussi l'avantage, dans un contexte pro, d'être plus facilement transmissible, car il n'y a pas de questions de langage : on est sur du commun et très simpliste. Mais, en contrepartie, on perdra en fonctionnalités de développement pures.  

Si vous venez du développement et que vous n'avez pas vocation à faire du déploiement à grande échelle toute votre vie, Pulumi sera plus approprié. Si il s'agit de déploiements à grande échelle en entreprise, je pense que Terraform demeure - à l'heure actuelle - la meilleure solution des deux.

Tag: IaC

Pulumi vs Terraform: Pourquoi Pulumi n'est pas toujours le meilleur choix