CDKTF Đã Chết: Bây Giờ Phải Làm Gì?

Ồ, nhanh thật đấy.

Ngày 10/12/2025, HashiCorp chính thức khai tử CDKTF (Cloud Development Kit for Terraform). Không phải deprecated nhẹ nhàng đâu nhé—họ archive luôn repository trong cùng ngày đó. Không có thời gian chuyển tiếp, không có kế hoạch migration, chỉ là "xong rồi đó."

Nếu bạn đang dùng CDKTF cho infrastructure, tôi thấu hiểu. Cùng bàn xem chuyện gì đã xảy ra và làm sao thoát khỏi tình thế này nhé.

Tóm Tắt Nhanh: CDKTF Là Gì?

CDKTF là công cụ của HashiCorp cho phép bạn viết infrastructure Terraform bằng ngôn ngữ lập trình thật (TypeScript, Python, Go...) thay vì HCL. Ý tưởng khá hay: nếu bạn ghét YAML (ai mà không?) và thấy HCL hạn chế, cứ viết TypeScript đi.

// CDKTF trong TypeScript
import { App, TerraformStack } from "cdktf";
import { AwsProvider } from "@cdktf/provider-aws";
import { Instance } from "@cdktf/provider-aws/lib/instance";

class MyStack extends TerraformStack {
  constructor(scope: Construct, name: string) {
    super(scope, name);

    new AwsProvider(this, "aws", { region: "us-west-2" });

    new Instance(this, "compute", {
      ami: "ami-123456",
      instanceType: "t3.micro",
      tags: { Name: "cdktf-instance" }
    });
  }
}

const app = new App();
new MyStack(app, "my-stack");
app.synth();

Code của bạn sẽ được "synth" ra Terraform JSON, rồi Terraform mới chạy. Bạn có classes, loops, type checking—đủ cả. Nghe ngon lành phải không?

Ừm thì, chuyện không đơn giản như vậy.

Chuyện Gì Đã Xảy Ra?

Ngày 10/12/2025: HashiCorp deprecated CDKTF. Cùng ngày đó: họ archive luôn GitHub repo.

Không có cảnh báo trước, không có thời gian migration, không có câu "chúng tôi vẫn sẽ fix critical bugs trong năm tới đâu." Chỉ archive thôi. Repository giờ chỉ read-only. Không có updates, không bug fixes, không security patches. Vĩnh viễn luôn.

Lý do chính thức? "CDKTF không tìm được product-market fit ở quy mô lớn."

Nói thẳng ra: ít người dùng quá.

Và thật ra họ cũng không sai. Ra mắt từ 2020 nhưng CDKTF chưa bao giờ thực sự phổ biến. Đa số người dùng Terraform vẫn trung thành với HCL. Còn những ai muốn "infrastructure as real code" thì đã chuyển sang Pulumi từ lâu rồi—mà thẳng thắn mà nói thì Pulumi làm tốt hơn nhiều.

HashiCorp phải maintain language bindings cho 5 ngôn ngữ (TypeScript, Python, Go, C#, Java), cập nhật providers, đồng bộ mọi thứ—tất cả chỉ cho một nhóm user rất nhỏ. Đến lúc nào đó thì phải cắt lỗ thôi.

Tại Sao CDKTF Thất Bại?

Nói thẳng luôn: CDKTF từ đầu đã là một giải pháp "đánh đố" mà không ai thực sự cần.

Sự Bất Tương Hợp

Terraform là declarative. Bạn khai báo muốn gì, Terraform tự tìm cách thực hiện. Đó là giá trị cốt lõi của nó.

CDKTF cố nhồi nhét imperative programming vào mô hình declarative. Bạn viết loops và conditionals trong TypeScript, nhưng chúng chạy lúc synth, không phải lúc Terraform chạy. Bạn thử giải thích cho người đang debug xem tại sao vòng for của họ không chạy như mong đợi xem.

// Trông như imperative nhưng thực ra không phải
const instanceCount = process.env.PRODUCTION === "true" ? 10 : 2;

for (let i = 0; i < instanceCount; i++) {
  new Instance(this, `server-${i}`, {
    ami: "ami-123456",
    instanceType: "t3.micro"
  });
}

Vòng lặp này chạy khi nào? Trước khi Terraform khởi động. Terraform track state changes thế nào? Vụng về lắm. Còn khi debug? Bạn phải vật lộn với cả TypeScript errors VÀ Terraform errors.

Gánh nặng nhận thức tăng mà lợi ích không rõ ràng.

Pulumi Đã Thắng Từ Lâu

Nếu bạn thực sự muốn viết infrastructure bằng TypeScript hay Python, Pulumi đã làm tốt hơn từ năm 2017 rồi. Native language runtime, type safety chuẩn chỉnh, IDE autocomplete hoạt động đúng nghĩa, và ecosystem không có vẻ "đắp đi xây lại."

CDKTF chỉ là đuổi theo một cuộc đua mà Pulumi đã thắng từ lâu. Tại sao phải học CDKTF khi Pulumi làm giống vậy mà tốt hơn?

Ưu Tiên Thật Sự Của HashiCorp

HashiCorp hiện đang all-in vào HCP Terraform (nền tảng cloud của họ). Họ đẩy mạnh Terraform Cloud, các tính năng Enterprise, policy-as-code với Sentinel—cơ bản là kéo bạn vào ecosystem của họ và giữ bạn lại.

CDKTF không phù hợp chiến lược đó. Nó là một sự phân tâm. Nên họ cắt luôn.

Lựa Chọn Migration Của Bạn

Okay, đủ chuyện buồn rồi. Nếu bạn đang chạy CDKTF ở production, bạn có 3 lựa chọn thật và 1 lựa chọn giả.

Lựa Chọn 1: Quay Về Terraform HCL

Đây là con đường rõ ràng nhất. Viết lại code CDKTF của bạn thành Terraform HCL bình thường.

Tin tốt: HashiCorp đã cho bạn một công cụ migration trước khi rút lui. Chạy lệnh này:

cdktf synth --hcl

Lệnh này sẽ tạo ra file Terraform HCL chuẩn từ code CDKTF của bạn. Không hoàn hảo đâu—vẫn cần dọn dẹp và refactor—nhưng ít ra bạn có điểm khởi đầu, không phải viết lại từ đầu.

Migration trông thế này:

// CDKTF
new Instance(this, "web", {
  ami: "ami-123456",
  instanceType: "t3.micro",
  tags: { Name: "web-server" }
});

# Terraform HCL (sau khi synth và cleanup)
resource "aws_instance" "web" {
  ami           = "ami-123456"
  instance_type = "t3.micro"

  tags = {
    Name = "web-server"
  }
}

Đúng, bạn vẫn cần refactor HCL được generate ra. Nhưng ít ra không phải bắt đầu từ con số 0.

Ưu điểm: ở lại Terraform ecosystem, được HashiCorp hỗ trợ chính thức, và tận dụng 100,000+ community modules.

Nhược điểm: mất đi các tính năng ngôn ngữ lập trình mà bạn thích ở CDKTF.

Lựa Chọn 2: Chuyển Sang Pulumi

Nếu ban đầu bạn chọn CDKTF vì muốn dùng TypeScript/Python cho infrastructure, thì Pulumi mới là câu trả lời đúng từ đầu.

// Pulumi (TypeScript)
import * as aws from "@pulumi/aws";

const web = new aws.ec2.Instance("web", {
  ami: "ami-123456",
  instanceType: "t3.micro",
  tags: { Name: "web-server" }
});

export const publicIp = web.publicIp;

Pulumi cảm giác như code thật vì nó là code thật. Loops thật, conditionals thật, type checking thật—không phải "giả lập" lúc synth.

Công sức migration tương đương HCL, nhưng bạn sẽ đến được chỗ tốt hơn nếu các tính năng lập trình quan trọng với bạn.

Nhược điểm: rời khỏi Terraform ecosystem hoàn toàn. State management khác, tooling khác, pricing model khác (Pulumi Cloud có tiers).

Lựa Chọn 3: AWS CDK (Nếu Bạn Chỉ Dùng AWS)

Nếu infrastructure của bạn toàn AWS và bạn dùng CDKTF chủ yếu vì nó giống AWS CDK, HashiCorp khuyến nghị chuyển sang AWS CDK thật luôn.

AWS CDK là công cụ "infrastructure as code" của AWS dùng TypeScript/Python. Nó AWS-native, được support tốt, và không lo biến mất.

Chỉ hợp lý nếu:

• Bạn 100% AWS (không có GCP, Azure, providers khác)
• Bạn đã dùng AWS CDK constructs với CDKTF
• Bạn sẵn sàng commit với infrastructure chỉ AWS

Không liên quan đến đa số setup multi-cloud, nhưng đáng đề cập vì HashiCorp nói rõ điều này.

Lựa Chọn 4: Không Làm Gì (Không Khuyến Nghị)

Bạn có thể... cứ tiếp tục dùng CDKTF. Code của bạn vẫn chạy tốt. Bây giờ thôi.

Nhưng đây là những thứ sẽ hỏng dần:

• Terraform providers mới sẽ không có CDKTF bindings
• Providers hiện tại sẽ update và phá compatibility (không có CDKTF updates để fix)
• Lỗ hổng bảo mật sẽ không được patch
• Node.js/Python/Go versions sẽ tiến lên và phá dependencies
• Cloud provider APIs sẽ thay đổi

Infrastructure của bạn đang trên đồng hồ đếm ngược. Đừng là người để đến 2 giờ sáng khi prod sập mới vội.

Cách Migrate Cụ Thể

Chọn đường đi của bạn (HCL hay Pulumi), rồi theo plan thô này:

Tuần 1-2: Kiểm kê toàn bộ

Chạy cdktf list và cdktf synth để xem bạn có gì. Đếm stacks, resources, dependencies. Trung thực về độ phức tạp nhé.

Tuần 3-4: Bắt đầu từ việc nhỏ

Chọn stack đơn giản nhất—có thể là IAM roles hay một S3 bucket.

Nếu đi HCL: chạy cdktf synth --hcl trên stack đó, dọn dẹp output, rồi deploy vào test environment.

Nếu đi Pulumi: viết lại bằng Pulumi. Deploy vào test environment.

Phá đi. Học hỏi.

Tuần 5-8: Import resources hiện tại

Đây là phần nhàm. Bạn cần import infrastructure hiện tại vào Terraform state (hoặc Pulumi state).

Với Terraform:

terraform import aws_instance.web i-1234567890abcdef0
terraform plan  # Phải hiện "No changes"

Với Pulumi:

pulumi import aws:ec2/instance:Instance web i-1234567890abcdef0
pulumi preview  # Phải hiện không có thay đổi

Tuần 9-16: Test, validate, cutover

Test ở staging. Test lại. Lên lịch maintenance window. Import production resources. Validate. Tắt CDKTF.

Tuần 17-20: Dọn dẹp

Archive (đừng xóa) code CDKTF. Update docs. Train team. Xóa CDKTF khỏi CI/CD.

Xử Lý Các Phần Khó

Nếu bạn dùng nhiều dynamic features của CDKTF, đây là cách map:

Loops:

CDKTF:

for (let i = 0; i < 5; i++) {
  new Instance(this, `server-${i}`, { ... });
}

HCL:

resource "aws_instance" "server" {
  count = 5
  ami   = "ami-123456"
  # ...
  tags = { Name = "server-${count.index}" }
}

Pulumi (dùng loop thật luôn):

const instances = [];
for (let i = 0; i < 5; i++) {
  instances.push(new aws.ec2.Instance(`server-${i}`, {
    ami: "ami-123456",
    instanceType: "t3.micro"
  }));
}

Stack dependencies:

CDKTF cho phép reference stacks khác trực tiếp. HCL dùng remote state data sources. Pulumi dùng stack references. Cả hai đều ổn, chỉ khác syntax.

FAQ Không Ai Hỏi Nhưng Nên Hỏi

Q: Tôi có thể dùng CDKTF cho dự án mới không?

Không. Bạn nghiêm túc đấy à?

Q: Code CDKTF của tôi có hỏng ngay lập tức không?

Không, nhưng rồi sẽ có. Có thể tháng sau khi provider update. Có thể năm sau khi Node.js version thay đổi. Có thể ngày mai khi AWS đổi API. Bạn đang đánh bạc đấy.

Q: Có tool converter không?

Có. cdktf synth --hcl tạo ra Terraform HCL từ code CDKTF của bạn. Output cần cleanup và refactor, nhưng tốt hơn nhiều so với viết lại thủ công. Dùng đi.

Q: Còn cdk8s (CDK cho Kubernetes) thì sao?

Dự án khác, vẫn còn. Chỉ CDKTF chết thôi.

Q: HCL hay Pulumi?

HCL nếu muốn ở lại Terraform ecosystem và không ngại học syntax mới. Pulumi nếu thật sự coi trọng programming language features và sẵn sàng đổi tool hoàn toàn. Cả hai đều ổn.

Bài Học Từ Đây

Cái chết của CDKTF dạy ta điều quan trọng: đôi khi "dùng ngôn ngữ bạn thích" không phải là câu trả lời.

HCL tồn tại có lý do. Nó bị hạn chế vì infrastructure cần constraints. Bạn không thể vô tình viết infinite loop. State management có thể dự đoán. Resource relationships rõ ràng. Terraform có thể phân tích và optimize dependency graph.

Cố gắng gắn OOP vào declarative infrastructure tool tạo ra nhiều vấn đề hơn là giải quyết. Layer abstraction thêm vào tăng complexity mà lợi ích không đủ để biện minh.

Nếu muốn TypeScript cho infrastructure, dùng Pulumi—nó được thiết kế như vậy từ đầu. Nếu muốn Terraform, dùng HCL. Cố có cả hai là sai lầm.

Bạn Nên Làm Gì Ngay Bây Giờ

Nếu có CDKTF ở production:

1. Kiểm kê infrastructure (tệ đến mức nào?)
2. Chọn đích migration (HCL hay Pulumi)
3. Block thời gian trên lịch (việc này không tự nhiên mà xong)
4. Bắt đầu migrate những thứ không quan trọng trước
5. Đặt deadline (3-6 tháng là hợp lý cho đa số setup)
6. Thật sự làm nó (đừng trì hoãn)

CDKTF đã archive. Không support, không updates, không patches. Mỗi ngày bạn đợi là một ngày gần hơn với việc có gì đó hỏng ở production lúc 3 giờ sáng.

Đừng là team đó.

Tài Nguyên

Docs chính thức:

• CDKTF GitHub (archived)
• Terraform HCL docs
• Terraform import guide

Phân tích và hot takes:

• env0: What the CDKTF Deprecation Means
• Pulumi: CDKTF is Deprecated (có bias rõ ràng)
• The New Stack: HashiCorp Sunsets External Language Support

Nếu đi HCL:

• My Terraform tutorial series (học đúng cách luôn)
• HashiCorp Learn

Nếu đi Pulumi:

• Pulumi getting started
• Migrating from Terraform to Pulumi

Nghe này, tôi hiểu mà. Bạn chọn CDKTF vì nó trông như best of both worlds. TypeScript với Terraform ecosystem. Đó là lựa chọn hợp lý năm 2023.

Nhưng HashiCorp đã khai tử nó rồi, giờ bạn phải move on. Chọn một đường đi, lập plan, và bắt tay vào làm. Bạn tương lai sẽ cảm ơn bạn hiện tại vì đã không trì hoãn.

Chúc may mắn nhé.

Updated: 2025-12-30

Disclaimer: Đây là phân tích của tôi dựa trên thông tin công khai và thảo luận cộng đồng. Check official CDKTF repo để biết chi tiết chính thức.