AWS CDK, le gamechanger ?

AWS CDK, le gamechanger ?

Il y a quelques semaines, AWS annonçait la disponibilité publique de son nouvel outil AWS Cloud Development Kit (AWS CDK).

Plus qu’un nouvel outil parmi d’autres chez AWS, je pense qu’il a le potentiel de changer les règles du jeu en ce qui concerne le déploiement.

Dans ce billet, j’ai pris le parti de ne le comparer qu’aux deux autres solutions populaires sur AWS : CloudFormation, l’outil d’Amazon et Terraform, l’outil open source d’HashiCorp. Pour avoir mon point de vue sur ces outils, je vous invite à lire mon billet associé.

AWS CDK : Kézako ?

AWS CDK est une nouvelle manière de faire ses déploiements sur AWS. Quand on utilise Terraform ou CloudFormation, il s’agit de décrire l’infrastructure cible.

Cela pose régulièrement des soucis quand il s’agit d’avoir un code de déploiement factorisé et réutilisable. Même si des améliorations ont été faites sur ces deux langages, force est d’admettre qu’ils ne sont pas conçus nativement pour gérer les subtilités de certains déploiements.

CDK est parti sur un schéma différent : coder son déploiement, au sens propre.

En exploitant un langage de programmation "classique" (JavaScript et Python en version stable, Java et C# en version préliminaire), il est possible de créer un déploiement complet dans Amazon.

L’intérêt principal étant de manipuler directement des objets du langage associé de manière complètement native.

À côté de ce code, un moteur d’exécution en NodeJS compile le code pour en faire du CloudFormation, et peut même se charger de gérer le déploiement. J’expliciterai ces points en détail plus bas.

Pourquoi je pense que CDK change la donne

Pour avoir joué un peu avec CDK, après avoir beaucoup utilisé Terraform et CloudFormation, je dois admettre que le fait d’avoir un vrai langage de programmation permet de gérer bien plus de subtilités de déploiement.

Je développe actuellement en python. J’ai un usage spécifique qui fait que je génère du code CloudFormation à la volée pour gérer les autorisations des projets de manière centralisée.

Jusqu’à maintenant, j’exploitais la librairie troposphere. Néanmoins, pour moi je voyais au moins deux soucis :

  • Cela crée une adhérence avec une librairie tierce, non maintenue officiellement
  • La documentation du projet n’est pas forcément très claire

Concernant le premier point, il est pour moi rédhibitoire pour deux raisons :

  • L’histoire nous montre pleins de librairies tierces abandonnées du jour au lendemain, parfois même avec les sources associées (petit article qui en parle ici [EN])
  • La mise à jour sur de nouveaux modules peut parfois être plus ou moins lente

L’avantage de CDK est qu’il est maintenu par AWS, qui a la force de frappe nécessaire pour le maintenir à jour. De plus, comme souvent chez Amazon, lorsqu’un nouveau service est disponible ou mis à jour, il y a fort à parier que CDK soit directement compatible avec, comme pour CloudFormation.

Pas de nouveau langage…

Pour moi, la force principale de CDK est de pouvoir directement utiliser un langage qui est souvent déjà présent en entreprise. En effet, que soit le JavaScript ou le Python, ils sont souvent très implantés dans les entreprises depuis plusieurs années et jouissent d’une communauté très dense.

Terraform, bien que simple à prendre en main, nécessite l’utilisation d’un langage spécifique : le HCL. Malgré que ce dernier ne soit pas compliqué à appréhender, avoir une gestion native de ce dernier dans son IDE n’est pas forcément gagné ! C’est un constat que j’ai fait dernièrement avec VSCode…

En utilisant un langage natif, Amazon permet de fait d’utiliser son IDE habituel, de plus cela permet de faciliter la prise en main pour des profils n’étant pas forcément à l’aise avec l’Infra as code.

De plus cela permet de traiter le code fourni pour l’infrastructure comme du code standard, en exploitant des outils de contrôle de qualité de code commun par exemple, ou en faisant du test unitaire.

… Mais un nouvel outil

Bien que CDK permette de ne pas avoir de nouveau langage, il nécessite par contre l’utilisation d’un nouveau binaire.

Tout comme Terraform compile le code soumis, le binaire CDK transforme le code fourni en stack CloudFormation au format JSON.

Ce nouvel outil nécessite bien entendu une prise en main, et il est noté que les mécanismes de base de CDK ne sont pas forcément intuitifs.

Toutefois, une fois pris en main, l’outil est plutôt bien fait. Principal défaut à mon sens : utiliser obligatoirement NodeJS pour le faire fonctionner.

Outre le fait que NPM a tendance à télécharger la moitié d’Internet, lorsque j’écris mon code en Python, avoir NPM + CDK en JS est pour moi bizarre…

Extrait de la documentation officielle : https://docs.aws.amazon.com/cdk/latest/guide/getting_started.html

C’est d’autant plus bizarre que je dois télécharger les librairies avec pip pour Python. Cela alourdit un peu la création de stacks avec CDK.

CDK vs CloudFormation et Terraform

Maintenant que je vous ai parlé de CDK, je vous propose maintenant de vous parler des avantages face aux 2 outils d’Infra as code décrits plus hauts. Concernant les inconvénients, je les ai déjà évoqué plus tôt.

CDK vs CloudFormation

Ce comparatif est un peu biaisé, car comme je l’ai dit CDK exploite en réalité CloudFormation.

Les avantages de CDK sur CloudFormation :

  • Permets d’insuffler du dynamisme dans les déploiements CloudFormation qui sont très rigides
  • Plus facile à valider, au niveau du code (même si des validateurs CloudFormation existent)
  • Facilite la réutilisation de code, les librairies étant plus souples que les templates CloudFormation, de plus cela permet d’avoir une seule stack CloudFormation au moment du déploiement.

CDK vs Terraform

CDK est pour moi un réel challenger face à Terraform, vu qu’il comble certaines de ses lacunes.

Par rapport à Terraform, CDK a les avantages suivants :

  • Plus de dynamisme que Terraform, même si les choses ont évolué avec la 0.13 qui permet bien plus de conditions/boucles
  • Gestion automatique du rollback en cas d’erreur (grâce à CloudFormation)
  • Langage natif, comme expliqué, cela facilite l’adoption

En conclusion

Je suis moi-même un grand fan de Terraform et je peste (très/trop ?) souvent sur CloudFormation qui est à mon sens trop rigide et à un côté "boite noire" parfois très handicapant pour comprendre un déploiement qui ne fonctionne pas.

Néanmoins, je dois admettre que CDK change la donne et se pose comme un réel adversaire face à Terraform.

Je ne pense pas qu’il va remettre en cause le fleuron d’HashiCorp dans les entreprises chez lesquelles il est exploité, par contre, il y a des arguments suffisants pour évoluer de CloudFormation à CDK.

De même, pour une entreprise faisant ses premiers pas sur AWS, cela peut être rassurant d’utiliser un outil natif.

Toutefois, il faut garder en tête que CDK ne fait que de l’AWS, donc pour une infrastructure hybride, Terraform reste le maître incontesté !