近年來 Infrastructure as code 一直是很熱的議題，infra 的管理方法從以前的 Command line/Console 到現在 as coding 讓整個系統維運環境大幅改變，除了感嘆工程師真是難做以外，還必須要有一個新鮮的肝。作者是以系統工程師起家的，在這幾年用過各種 IaC 工具，像是 Ansible/Puppet/Chef/SaltStack/Terraform/CloudFormation/Pulumi 等等，以及這篇的重點 CDK 家族。

What is AWS Cloud Development Kit (CDK)

AWS CDK 算是繼 CloudFormation 之後的 IaC 2.0，不僅僅只是用 YAML 編寫 infrastructure 而是用開發者熟悉的程式語言來撰寫 IaC 來達到更高的彈性，除了程式語言本身的邏輯判斷以外更能直接用該語言套件加入到 IaC 的撰寫，不用依賴工具上的限定。

Construct property

CDK 的 Construct 的特性幾乎把 IaC 推上更高的一個層級，Construct 不僅能像其他 IaC 工具代表單一服務 (ex. EC2, S3)、多個服務組成 (ex. Web service) 更能自己開發 Construct library 讓不支援的服務成為可能。

Open Source forks

除了擁有強大的官方支援，Open Source 的特性讓 CDK 的發展獲得社群的大力支援，除了版本的更新速度外，更延伸出 cdktf (Cloud Development Kit for Terraform) 和 cdk8s (Cloud Development Kit for Kubernetes) 這兩個 IaC Tool。

What is Cloud Development Kit for Kubernetes (CDK8S)

cdk8s 是基於 CDK 框架實現 Kubernetes yaml，也因為最後是產生 yaml 檔案讓 kubectl apply 執行，所以 cdk8s 可以應用在任何 Kubernetes cluster 場景，不受 Vender locking 的約束，

awslabs 更在之後推出 cdk8s+ 讓 Kubernetes 的管理方法從 YAML 到 Kubernetes API 實現，用一張表比較出 YAML, cdk8s, cdk8s+ 的差異：

What is Cloud Development Kit for Terraform (CDKTF)

cdktf 與 cdk8s 同樣都是基於 CDK 框架實現 Terraform 的執行方法，不同於前面兩者，cdktf 是由 skorfmann 開源的專案，爾後納入 HashiCorp 的開源專案，但目前主要還是由 skorfmann 維護居多。

cdktf 的出現讓 CDK 家族也因為 Terraform Cross–Platform 特性，從原本的 AWS 一口氣跨足多個平台，以 Cross-Platform 為前提的話，Terraform 說第二個話，應該沒其他工具能說第一了！

cdktf 完全享有 Terraform 的特性之外，Escape Hatch 更能實現 Terraform 不支援的資源，cdktf 雖然不是產生 HCL 格式而是 JSON 格式，但仍可以讓 Terraform 可以看得懂，當 cdktf 做得不好時，也能依靠原生 Terraform 補足

當 cdktf diff 顯示資訊不足，terraform plan 是備案選擇

Why CDK family ?

CDK 漸漸衍生出自己的生態系，雖然目前有些專案仍是 alpha / beta 階段，但也意味者當這個生態系越成熟時，可以大大降低學習門檻，讓學習曲線限縮於：

• 1 種框架
• 1 種程式語言

從另一方面來看，過去系統管理慣用的既定格式如 Console, Command line, YAML 等都漸漸有被汰換的趨勢，其主要原因也歸咎於在這幾年軟體變化的太快，使用既定格式無法滿足所有情境，而程式語言的彈性讓很多事情變成可能更天馬行空。