Terraform và sự thay đổi với Infrastructure as Code
Vài năm trước, Terraform có mối liên hệ khá trực tiếp với hạ tầng thực tế. Engineer thường viết code cho resource, variable, output và một số module. Khi triển khai, họ thường tham khảo trực tiếp tài liệu Terraform và hiểu rõ từng resource block. Vì vậy, code phản ánh tương đối chính xác hạ tầng được triển khai, và người khác có thể dễ dàng hình dung hệ thống khi xem repository.
Tuy nhiên hiện nay, trong nhiều trường hợp, các kỹ sư đang triển khai những hạ tầng mà họ không hoàn toàn hiểu rõ. Terraform dần trở nên phân lớp hơn.
Ban đầu, việc sử dụng các abstraction được xem là dấu hiệu của sự trưởng thành trong quản lý hạ tầng:
- Module có thể tái sử dụng
- Chuẩn hóa môi trường
- Module VPC dùng chung
- Tagging trên toàn tổ chức
- Pipeline theo tiêu chuẩn
- Platform Engineering
- Golden Path
Tuy nhiên, theo thời gian, nhiều repository Terraform không còn giống các định nghĩa hạ tầng đơn thuần mà trở thành các framework nội bộ.
Thay vì tạo trực tiếp một K8s chẳng hạn, kỹ sư có thể phải gọi một module, module này lại gọi module khác và thêm nhiều lớp abstraction cùng các cấu hình phức tạp.
Trong một số trường hợp, định nghĩa K8s đơn giản bị ẩn sau nhiều lớp module và template riêng của tổ chức. Hạ tầng vẫn hoạt động, nhưng việc hiểu thực tế đang được triển khai những gì có thể mất nhiều thời gian hơn cả việc triển khai.
Điều đáng chú ý là cách tiếp cận nhiều lớp này đôi khi vẫn được xem là “best practice”.
Sự trỗi dậy của "Blind Terraform"
Một điều có thể nhận thấy gần đây là có nhiều kỹ sư chạy Terraform mà không hoàn toàn hiểu điều gì sẽ xảy ra tiếp theo. Không phải vì họ bất cẩn mà vì các hệ thống hạ tầng hiện đại đã trở nên quá trừu tượng, khiến việc nhanh chóng hình dung và phân tích chúng trở nên khó khăn.
Có thể thấy mọi người đang xem xét các plan dài hàng trăm dòng, bao gồm:
- Cập nhật in-place updates
- Các giá trị được tính toán (computed values)
- Các nested module
- Những thay đổi do provider tạo ra
- Các dynamic blocks
- Các output từ remote state
- Các resource được tạo theo điều kiện nằm sâu tới năm layer
Đến một lúc nào đó, lệnh "terraform plan" không còn là một quy trình kiểm tra kỹ lưỡng nữa mà chuyển thành một bài test về lòng tin về:
- Các module
- Quy trình triển khai (pipeline)
- Engineer thực hiện trước đó
- Đội ngũ phụ trách platform (platform team)
- Code do AI tạo ra
Thực tế là môi trường production vẫn ổn sau lần triển khai (apply) gần nhất, tuy nhiên có thể tiềm ẩn nguy cơ từ đây. AI đang đẩy nhanh quá trình này hơn nữa và đây là một khía cạnh ít được đề cập một cách trực tiếp.
Hiện nay, một lượng lớn Terraform code được tạo ra bằng AI. Công bằng mà nói, chất lượng của một phần trong số đó khá tốt.
- Cần một ECS service? Có thể tạo ngay.
- Cần một quy tắc EventBridge? Có thể tạo ngay.
- Cần các IAM policy? Cũng có thể tạo... với điều kiện chúng được cấu hình chính xác.
Vấn đề không phải là AI tạo ra Terraform kém chất lượng. Vấn đề là AI có thể tạo ra Terraform nhanh hơn khả năng hiểu sâu của engineer đối với những gì được tạo ra. Điều này làm thay đổi mối quan hệ của con người với hạ tầng.
Trước đây, việc viết Terraform buộc bạn phải tìm hiểu kỹ về các dịch vụ cloud. Bạn hiểu các dependency vì chính bạn phải thiết lập mối liên kết giữa chúng. Bạn hiểu IAM vì bạn phải trực tiếp xử lý và tìm hiểu các cơ chế phân quyền của IAM.
Giờ đây, mọi người có thể xây dựng hạ tầng production thông qua tính năng autocomplete và các prompt.
Kiến thức về hạ tầng đang dần chuyển từ:
“Tôi hiểu hệ thống này”
sang:
“Tôi biết cách tạo ra hệ thống này.”
Đây là một khác biệt rất quan trọng.
Bởi cuối cùng, hạ tầng được tạo ra vẫn trở thành hạ tầng thực tế. Vẫn sẽ có người phải xử lý các vấn đề về networking, giải quyết các quyền IAM phức tạp, tìm hiểu lý do Terraform muốn tạo lại một phần lớn của stack, hoặc giải thích một khoản chi phí cloud bất thường.
AI có thể tăng tốc đáng kể quá trình xây dựng hạ tầng. Nhưng đồng thời, AI cũng có thể tạo ra một ảo tưởng nguy hiểm về mức độ hiểu biết đối với hạ tầng.
Terraform đã âm thầm trở thành một Platform Interface.
Trong nhiều công ty, Terraform không còn được dùng trực tiếp để triển khai hạ tầng, mà chủ yếu được dùng để sử dụng các platform có sẵn.
Điều này không hẳn là xấu. Platform team cung cấp các module được phê duyệt, security team tích hợp các kiểm soát bảo mật, networking được chuẩn hóa và policy được quản lý tập trung. Ở quy mô lớn, cách này giúp tăng tính nhất quán.
Tuy nhiên, nhiều kỹ sư hiện làm việc cách xa hạ tầng cloud thực tế vài lớp. Họ biết các input của module, GitHub Actions và biến cần thay đổi, nhưng có thể không hiểu rõ các AWS resource thực sự được tạo phía dưới.
Một số kỹ sư vẫn triển khai service thành công dù chỉ hiểu sơ bộ về networking, IAM, security groups, BKE roles, DNS hoặc cross-account access.
Platform đã xử lý tất cả cho họ - cho đến khi sự cố xảy ra. Khi đó, những chi tiết của hạ tầng thực tế nhanh chóng trở thành vấn đề cần hiểu rõ.
Độ phức tạp không biến mất mà chuyển dịch sang nơi khác.
Điểm quan trọng nhất nằm ở việc Terraform không làm hạ tầng đơn giản hơn mà phân bổ lại độ phức tạp.
Trước đây, một repository thường chứa trực tiếp các resource như: VPC, Compute instances, IAM policies, Load balancers, Outputs
Bạn có thể mở code và dễ dàng theo dõi cách các thành phần liên kết với nhau.
Giờ đây, độ phức tạp được phân tán qua modules, pipelines, policy engines, reusable templates, wrapper scripts, platform abstractions, organizational conventions và ngày càng có thêm các lớp do AI tạo ra.
Hạ tầng vẫn ở đó - chỉ là nó ngày càng xa các engineer hơn.
Cách nhìn về “terraform apply” đã thay đổi
Trước đây, việc chạy “terraform apply” thường mang tính trực tiếp hơn. Engineer có thể dễ dàng xác định resource nào sẽ được tạo, thay đổi nào sẽ xảy ra và phạm vi ảnh hưởng (blast radius) trước khi thực thi.
Hiện nay, quy trình này đôi khi tương tự việc deploy compiled code.
Kỹ sư vẫn xác định được mục tiêu cần triển khai, nhưng chi tiết thực tế có thể nằm sau nhiều lớp abstraction, nested modules, generated outputs, organizational wrappers và logic của platform.
Khoảng cách giữa ý định triển khai và hạ tầng thực tế này đang tác động đáng kể đến cách thức engineering được thực hiện và quản lý.
Vậy điều này có thực sự đáng lo?
Câu trả lời là không hẳn. Một số abstraction là cần thiết, và việc tiêu chuẩn hóa cũng mang lại nhiều lợi ích. Platform engineering giải quyết những vấn đề thực tế ở quy mô lớn; không ai muốn hàng chục team tự xây dựng VPC theo những cách hoàn toàn khác nhau.
Tuy nhiên, chúng ta có thể đang tiến đến một điểm mà kỹ sư hạ tầng cần chủ động duy trì sự hiểu biết, đó là cách infrastructure thực sự vận hành, thay vì phụ thuộc quá nhiều vào các abstraction.
Bởi vì cuối cùng:
- Debugging vẫn quan trọng
- Sự cố vẫn xảy ra
- IAM vẫn có thể gặp vấn đề
- Networking vẫn cần được hiểu rõ
- Chi phí vẫn có thể tăng đột biến
- Terraform state vẫn có thể bị lỗi bất ngờ
Và khi sự cố xảy ra, các lớp abstraction có thể nhanh chóng trở nên không còn đủ. Khi đó, cloud infrastructure lại trở thành những hệ thống thực tế mà engineer phải trực tiếp hiểu và xử lý.
