Phân tích xu hướng Platform Engineering: xây nền tảng nội bộ

Platform Engineering là xu hướng xây dựng một đội chuyên tạo ra nền tảng phát triển nội bộ (Internal Developer Platform – IDP): tập hợp công cụ, quy trình và dịch vụ tự phục vụ giúp các đội sản phẩm tạo dự án mới, deploy, giám sát và vận hành ứng dụng mà không phải tự lắp ráp hạ tầng mỗi lần. Mục tiêu là giảm gánh nặng nhận thức (cognitive load) cho lập trình viên, chuẩn hóa cách làm an toàn và tăng tốc độ giao phần mềm. Bài phân tích này giải thích vì sao xu hướng này nổi lên, nền tảng gồm những gì và khi nào một doanh nghiệp nên đầu tư.

Vì sao Platform Engineering xuất hiện

Phong trào DevOps với tinh thần "bạn xây, bạn vận hành" giúp phá rào cản giữa phát triển và vận hành. Nhưng khi hệ sinh thái cloud native bùng nổ (container, Kubernetes, hạ tầng dạng mã, service mesh, hàng chục công cụ giám sát và bảo mật), việc bắt mỗi đội sản phẩm tự thành thạo tất cả trở nên quá tải. Hệ quả thường thấy:

• Mỗi đội tự viết pipeline, cấu hình Kubernetes theo một kiểu, khó hỗ trợ lẫn nhau.
• Lập trình viên mất nhiều thời gian cho hạ tầng thay vì tính năng.
• Chuẩn bảo mật, giám sát không đồng đều; lỗ hổng ở đội yếu nhất ảnh hưởng toàn hệ thống.
• Đội vận hành trung tâm thành nút thắt, mọi yêu cầu phải qua ticket và chờ đợi.

Platform Engineering đề xuất một lối đi giữa: đội nền tảng xây "con đường trải nhựa" (golden path), các đội sản phẩm tự phục vụ trên đó.

Phân biệt với DevOps và SRE

Ba khái niệm bổ trợ nhau: nền tảng hiện thực hóa các thực hành DevOps ở quy mô lớn, và tích hợp sẵn các tiêu chuẩn độ tin cậy của SRE.

Một nền tảng phát triển nội bộ gồm những gì

• Cổng thông tin cho dev (developer portal): danh mục dịch vụ, chủ sở hữu, tài liệu, API; mẫu tạo dự án mới. Backstage (dự án mã nguồn mở do Spotify khởi xướng, thuộc CNCF) là công cụ phổ biến.
• Mẫu dự án (template): tạo service mới đã có sẵn cấu trúc, CI/CD, logging, metrics, kiểm tra bảo mật.
• CI/CD chuẩn hóa: pipeline dùng chung, đội chỉ cần khai báo thay vì tự viết.
• Hạ tầng tự phục vụ: tạo database, hàng đợi, bucket lưu trữ, môi trường thử nghiệm qua cổng hoặc file khai báo, với chính sách bảo mật và chi phí áp sẵn.
• Quan sát tích hợp sẵn: mọi service mới tự có log tập trung, metrics, dashboard mặc định; xem bài xây dựng hệ thống logging tập trung.
• Quản lý bí mật và danh tính: cấp khóa, chứng chỉ tự động, không còn chép mật khẩu vào file cấu hình.
• Chính sách dưới dạng mã: kiểm tra tự động cấu hình không an toàn, tài nguyên thiếu nhãn chi phí.

Xây nền tảng theo tư duy sản phẩm

Điểm khác biệt quan trọng nhất là coi nền tảng như một sản phẩm có khách hàng:

1. Phỏng vấn các đội phát triển: họ mất thời gian ở đâu? Tạo môi trường mới mất bao lâu? Bước nào trong deploy gây khó chịu nhất?
2. Bắt đầu nhỏ: giải quyết một hai điểm đau lớn nhất, ví dụ tạo service mới trong vài phút với pipeline chuẩn, thay vì xây "nền tảng toàn diện" mất cả năm.
3. Không ép buộc, hãy hấp dẫn: golden path phải dễ hơn tự làm thì đội mới chọn. Vẫn cho phép đi đường riêng khi có lý do, miễn đáp ứng chuẩn tối thiểu.
4. Tài liệu và hỗ trợ: hướng dẫn rõ ràng, kênh hỏi đáp, thông báo thay đổi trước.
5. Đo lường và lặp lại: thu phản hồi định kỳ, ưu tiên backlog nền tảng như một đội sản phẩm.

Một rủi ro thường gặp là đội nền tảng xây thứ họ thấy hay về mặt kỹ thuật thay vì thứ các đội cần, dẫn đến nền tảng không ai dùng.

Đo hiệu quả

Các chỉ số DORA (từ chương trình nghiên cứu DevOps Research and Assessment) thường được dùng:

• Tần suất deploy.
• Thời gian từ khi commit đến khi chạy trên production (lead time for changes).
• Tỷ lệ thay đổi gây sự cố.
• Thời gian khôi phục dịch vụ.

Bổ sung các chỉ số trải nghiệm: thời gian để một lập trình viên mới deploy thay đổi đầu tiên, thời gian tạo service mới, mức độ hài lòng của dev với nền tảng qua khảo sát, tỷ lệ service đi theo golden path.

Khi nào doanh nghiệp nên đầu tư

• Chưa cần: một hai đội phát triển, vài ứng dụng; một người DevOps với tài liệu tốt là đủ.
• Bắt đầu cân nhắc: nhiều đội, nhiều service, thấy rõ sự lặp lại và không đồng đều về cách deploy, giám sát.
• Nên đầu tư nghiêm túc: hàng chục đội, yêu cầu tuân thủ, bảo mật cao, chi phí cloud cần kiểm soát chặt.

Với doanh nghiệp theo hướng kiến trúc composable hoặc microservices, nền tảng nội bộ gần như là điều kiện để vận hành được số lượng thành phần lớn mà không hỗn loạn.

Bối cảnh Việt Nam

Nhiều công ty công nghệ, ngân hàng và fintech trong nước đã có đội nền tảng hoặc DevOps trung tâm, dù không phải lúc nào cũng gọi bằng tên Platform Engineering. Với các công ty outsource làm nhiều dự án cho khách hàng khác nhau, bộ mẫu dự án và pipeline chuẩn giúp khởi động dự án nhanh và đồng đều chất lượng. Kỹ năng Kubernetes, hạ tầng dạng mã và khả năng làm việc như một đội sản phẩm là những yếu tố cần cho nhân sự nền tảng.

Nền tảng tốt cũng là nơi đưa kiểm thử tự động vào mặc định: mẫu dự án có sẵn khung test và bước chạy test trong pipeline, như trong bài hướng dẫn viết unit test và integration test.