Gérer manuellement une infrastructure cloud est devenu un anti-pattern reconnu. L'Infrastructure as Code (IaC) a résolu bon nombre de problèmes liés à la cohérence et à la reproductibilité, mais la première génération d'outils -- notamment AWS CloudFormation avec ses templates YAML verbeux -- a introduit ses propres frictions. Le AWS Cloud Development Kit (CDK) représente l'étape suivante : définir l'infrastructure avec de vrais langages de programmation plutôt qu'avec des fichiers de configuration.
Cet article explore pourquoi CDK est devenu le choix privilégié des équipes qui construisent sur AWS, comment démarrer, et comment il se compare aux alternatives comme Terraform.
Pourquoi le YAML CloudFormation montre ses limites
CloudFormation a été une avancée majeure lors de son lancement. Déclarer son infrastructure dans un template et laisser AWS gérer le provisionnement représentait un progrès considérable. Mais quiconque a maintenu un projet CloudFormation de taille moyenne connaît les points de friction.
Les templates YAML deviennent rapidement ingérables. Une application modérément complexe peut nécessiter des milliers de lignes de configuration. Il n'y a pas de support natif pour les boucles, les conditions sont maladroites, et la réutilisabilité repose sur des nested stacks ou des macros personnalisées qui ajoutent de la complexité. Le refactoring est risqué -- une indentation mal placée ou une faute de frappe dans une propriété de ressource peut provoquer des échecs de déploiement difficiles à diagnostiquer. Le support IDE est limité : au mieux du syntax highlighting, mais pas d'autocomplétion pour les propriétés des ressources, pas de vérification de types, pas de validation à la compilation.
CDK résout tous ces problèmes en permettant d'écrire les définitions d'infrastructure en TypeScript, Python, Java, C# ou Go. On dispose de toute la puissance d'un langage de programmation : variables, fonctions, classes, héritage, boucles et conditions. L'IDE fournit l'autocomplétion, la documentation en ligne et la sécurité de typage. Les erreurs sont détectées avant le déploiement, pas pendant.
Concepts fondamentaux : Constructs, Stacks et Apps
CDK organise l'infrastructure autour de trois abstractions clés.
Les Constructs sont les briques de base. Ils représentent une ou plusieurs ressources AWS configurées ensemble. CDK propose trois niveaux de constructs. Les constructs L1 sont des mappings directs vers les ressources CloudFormation -- ils offrent un contrôle total mais exigent la configuration de chaque propriété. Les constructs L2 sont des abstractions de niveau supérieur avec des valeurs par défaut judicieuses. Par exemple, un construct L2 pour un bucket S3 configure automatiquement le chiffrement et bloque l'accès public, sauf indication contraire explicite. Les constructs L3, parfois appelés patterns, combinent plusieurs ressources en architectures courantes, comme un service Fargate avec load balancer.
Les Stacks sont l'unité de déploiement, équivalents à un stack CloudFormation. Chaque stack se traduit en un seul template CloudFormation lors de la synthèse. On peut définir plusieurs stacks dans une même application CDK et gérer les dépendances entre eux.
Les Apps constituent la racine de l'arbre de constructs. Une app contient un ou plusieurs stacks et sert de point d'entrée pour la CLI CDK.
Démarrer avec CDK
La mise en place d'un projet CDK est simple. Il faut avoir Node.js installé (même si l'on prévoit d'écrire en Python ou dans un autre langage, la CLI CDK fonctionne sur Node). On installe la CLI CDK globalement, puis on initialise un nouveau projet avec cdk init en choisissant le langage et le template souhaités.
Le workflow typique suit un cycle prévisible. On écrit les définitions d'infrastructure dans le code, on exécute cdk synth pour générer le template CloudFormation, on examine le résultat, puis on exécute cdk deploy pour provisionner les ressources. La commande cdk diff est particulièrement précieuse -- elle montre exactement quels changements seront appliqués avant de s'engager dans un déploiement.
En TypeScript, définir l'infrastructure se fait naturellement. On crée une classe qui étend Stack, on instancie des constructs dans le constructeur et on configure les propriétés via des objets typés. Si l'on tente de passer une propriété invalide, le compilateur la détecte immédiatement. Si l'on a besoin de créer dix ressources similaires avec de légères variations, on écrit une boucle. Si l'on souhaite partager des configurations communes entre projets, on extrait un construct dans une bibliothèque partagée et on le publie comme paquet npm.
CDK vs. Terraform : choisir le bon outil
Terraform est l'outil IaC le plus largement adopté, et à juste titre. Il supporte plusieurs fournisseurs cloud, dispose d'un écosystème massif de modules communautaires, et sa gestion d'état est bien comprise. La comparaison avec CDK demande de la nuance.
CDK est spécifique à AWS. Si l'infrastructure s'étend sur plusieurs fournisseurs cloud, Terraform (ou CDK for Terraform, cdktf) est probablement un meilleur choix. CDK excelle quand les workloads sont principalement ou exclusivement sur AWS. Il s'intègre profondément avec les services AWS, et les nouvelles fonctionnalités sont souvent disponibles dans CDK dès le jour de leur lancement.
La différence de langage compte plus qu'il n'y paraît. Le HCL de Terraform est conçu spécifiquement pour la configuration. Il est lisible et cohérent, mais il manque de l'expressivité d'un langage généraliste. La logique complexe en HCL mène souvent à des contournements alambiqués. CDK permet d'utiliser le même langage que celui de l'application, ce qui réduit le changement de contexte et facilite la contribution des développeurs applicatifs au code d'infrastructure.
La gestion d'état est un autre facteur de différenciation. Terraform maintient son propre fichier d'état qui doit être stocké de manière sécurisée et verrouillé pendant les opérations. CDK s'appuie sur la gestion d'état intégrée de CloudFormation, ce qui élimine toute une catégorie de préoccupations opérationnelles.
En revanche, le workflow plan/apply de Terraform est plus mature que le cycle diff/deploy de CDK. L'écosystème de providers Terraform couvre des services et plateformes que CDK ne peut tout simplement pas atteindre. Et les équipes ayant une expertise Terraform établie peuvent trouver le coût de migration difficile à justifier.
Conseils pratiques pour la migration
Si l'on envisage de passer de CloudFormation YAML ou Terraform à CDK, une approche progressive fonctionne le mieux.
Commencer par les nouveaux projets. Ne pas tenter de réécrire toute l'infrastructure d'un coup. Choisir un nouveau service ou microservice et construire son infrastructure en CDK en partant de zéro. Cela permet à l'équipe d'apprendre l'outil sans la pression de migrer des workloads de production.
Utiliser cdk import pour placer des ressources existantes sous la gestion de CDK sans les recréer. Cette fonctionnalité permet d'adopter CDK de manière incrémentale, ressource par ressource, sans interruption de service.
Investir tôt dans des bibliothèques de constructs partagées. L'une des plus grandes forces de CDK est la réutilisabilité. Si l'organisation a des standards pour la configuration des bases de données, des files d'attente ou des API, il faut encoder ces standards dans des constructs personnalisés L2 ou L3. Les équipes peuvent ensuite utiliser ces constructs et obtenir une infrastructure conforme par défaut.
Écrire des tests pour l'infrastructure. CDK supporte le snapshot testing (pour détecter les changements non intentionnels) et le assertion testing granulaire (pour vérifier des configurations spécifiques de ressources). C'est quasiment impossible avec des templates YAML bruts et difficile avec Terraform.
Mettre en place un pipeline CI/CD pour les déploiements CDK. Utiliser cdk diff dans les vérifications de pull request pour que les reviewers puissent voir les changements d'infrastructure avant le merge. Déployer via un pipeline, pas depuis les postes des développeurs.
Quand utiliser CDK
CDK est le choix le plus pertinent quand l'équipe construit principalement sur AWS, valorise la sécurité de typage et l'ergonomie pour les développeurs, et souhaite exploiter le même langage de programmation pour le code applicatif et l'infrastructure. Il est particulièrement adapté aux organisations qui veulent imposer des standards d'infrastructure à travers des bibliothèques de constructs partagées.
Il est moins adapté aux environnements multi-cloud, aux équipes profondément investies dans l'écosystème Terraform, ou aux projets simples où quelques lignes de YAML suffiraient.
L'Infrastructure as Code n'est plus optionnelle pour les opérations cloud sérieuses. CDK la rend plus accessible, plus maintenable et plus puissante que les alternatives qui l'ont précédée. Pour ceux qui ne l'ont pas encore exploré, c'est le moment idéal pour commencer.