Platform Engineering 1 — Nền tảng nội bộ & Golden Path

Mở đầu: khi "mỗi team tự lo" trở thành gánh nặng

Cách đây mười năm, phong trào DevOps hô hào "bạn xây thì bạn vận hành" (you build it, you run it). Mỗi đội phát triển được trao quyền tự chủ toàn bộ vòng đời: viết code, đóng gói container, viết pipeline CI/CD, cấu hình Kubernetes, dựng monitoring, quản lý secrets. Ý tưởng rất đẹp — xoá bỏ bức tường giữa Dev và Ops (xem DevOps 1 — DevOps là gì).

Nhưng khi số lượng đội tăng lên, một tác dụng phụ lộ ra. Một lập trình viên muốn đưa một service mới lên production phải hiểu Terraform, Helm, Argo CD, Prometheus, Vault, network policy, IAM... — hàng chục công cụ chẳng liên quan gì đến logic nghiệp vụ họ được thuê để viết. Người ta gọi đây là cognitive load (gánh nặng nhận thức). Tệ hơn, mỗi đội tự "phát minh lại bánh xe" theo cách riêng: mười đội có mười kiểu viết Dockerfile, mười cách cấu hình logging, mười phiên bản pipeline hơi khác nhau. Kết quả: chậm, thiếu chuẩn, khó bảo mật, khó tuân thủ.

Platform Engineering ra đời để giải bài toán này. Thay vì để mỗi đội tự lo hạ tầng, một đội nền tảng (platform team) xây dựng một Internal Developer Platform (IDP) — nền tảng phát triển nội bộ — và vận hành nó như một sản phẩm phục vụ chính các lập trình viên trong công ty. IDP cung cấp những golden path (đường đi vàng): cách làm chuẩn, đã được đóng gói, tự phục vụ (self-service), để dev triển khai an toàn mà không cần biết chi tiết bên dưới.

Đây là bài mở màn của series "Platform Engineering & GitOps hiện đại". Chúng ta sẽ định nghĩa rõ khái niệm, phân biệt với các vai trò lân cận, phác thảo các trụ cột kỹ thuật, và đặt tất cả trong bối cảnh một ngân hàng như NCB.

Internal Developer Platform là gì

IDP không phải một sản phẩm mua sẵn, cũng không phải một công cụ đơn lẻ. Nó là lớp trừu tượng hoá nằm giữa lập trình viên và hạ tầng phức tạp bên dưới. Hãy hình dung ba tầng:

Điểm mấu chốt: lập trình viên chỉ khai báo ý định ("tôi cần một service với một database"), còn platform lo phần còn lại — sinh pipeline, cấu hình container, gắn logging/monitoring, cấp secrets, áp policy bảo mật. Dev không cần biết cụm Kubernetes nằm ở đâu hay Vault cấu hình ra sao.

Một IDP tốt thường có bốn thành phần theo tài liệu của Humanitec / CNCF:

• Application Configuration Management — quản lý cấu hình ứng dụng theo môi trường.
• Infrastructure Orchestration — tự động cấp phát hạ tầng theo ngữ cảnh (dev/staging/prod).
• Environment Management — tạo/huỷ môi trường tạm theo yêu cầu.
• Deployment Management — điều phối triển khai (thường qua GitOps).

Phân biệt Platform Engineering với DevOps, SRE và Infra team

Đây là điểm gây nhầm lẫn nhiều nhất. Các vai trò này bổ sung nhau, không thay thế nhau.

Cách nhìn hữu ích: DevOps là triết lý (mục tiêu văn hoá), còn Platform Engineering là một cách hiện thực hoá triết lý đó ở quy mô lớn. DevOps nói "hãy trao quyền tự chủ cho dev"; Platform Engineering trả lời "được, nhưng ta sẽ đóng gói sự tự chủ đó thành sản phẩm để dev không chết chìm trong công cụ". SRE tập trung vào độ tin cậy vận hành; nhiều tổ chức lớn có cả platform team lẫn SRE team, trong đó SRE có thể là "khách hàng" hoặc "đối tác" của platform. Infra/Cloud team lo tầng thấp nhất — chính là "hạ tầng" trong sơ đồ trên — và platform team xây golden path trên tầng đó.

Google Cloud và tài liệu của Gartner (2023) đều dự báo Platform Engineering là một trong những xu hướng công nghệ nổi bật: Gartner ước tính đến năm 2026, khoảng 80% tổ chức kỹ thuật phần mềm lớn sẽ thành lập platform team. Đây là con số Gartner công bố, ghi lại để tham khảo — không phải ước lượng của tôi.

Các trụ cột kỹ thuật của một IDP (định hướng series)

Series này sẽ đi sâu từng trụ cột. Bức tranh tổng thể:

1. Infrastructure as Code (IaC) — mô tả hạ tầng bằng code (Terraform, Pulumi), để tái lập, review và versioning. Nền móng của mọi golden path. Xem Platform 2 — IaC & Terraform và bài nền DevOps 6 — Infrastructure as Code.
2. GitOps — Git là nguồn chân lý duy nhất (single source of truth); một agent (Argo CD / Flux) liên tục reconcile trạng thái cluster về đúng với Git. Xem Platform 3 — GitOps với Argo CD.
3. CI/CD & supply chain security — pipeline chuẩn, ký artifact, SBOM, provenance để chuỗi cung ứng phần mềm an toàn. Xem Platform 4 — CI/CD pipelines và Security 5 — Secrets & supply chain.
4. Observability — metrics, logs, traces chuẩn hoá, cắm sẵn vào golden path qua OpenTelemetry. Xem Platform 5 — Observability & OTel và Observability 1 — Tổng quan.
5. Secrets & policy — quản lý bí mật (Vault) và policy-as-code (OPA/Kyverno) để "an toàn theo mặc định". Xem Platform 6 — Secrets & security và Security 4 — Access & mã hoá.
6. IDP portal / developer experience — cổng self-service (Backstage) gom service catalog, template và tài liệu. Xem Platform 7 — IDP & Backstage.

Trụ cột hạ tầng vận hành production (autoscaling, rollout, disaster recovery) được bàn ở Kubernetes 8 — Production ops, và bối cảnh cloud tổng thể ở Cloud 1 — Tổng quan, Cloud 6 — IaC & DevOps.

Bốn nguyên tắc cốt lõi

1. Platform-as-Product

Đây là tư duy quan trọng nhất và cũng bị bỏ quên nhiều nhất. Platform có người dùng (các lập trình viên nội bộ), có roadmap, có chỉ số trải nghiệm (DX — developer experience). Đội platform phải phỏng vấn dev, thu thập feedback, đo mức độ hài lòng, ưu tiên tính năng — y như một đội làm sản phẩm cho khách hàng bên ngoài. Sai lầm phổ biến: platform team xây thứ họ nghĩ là hay, rồi ép dev dùng. Nếu golden path khó dùng hơn cách tự làm, dev sẽ đi đường vòng (shadow IT) và platform thất bại.

2. Self-service

Dev phải tự làm được, ngay lập tức, không phải mở ticket rồi chờ. Mở ticket "xin cấp một database" và chờ ba ngày là mô hình cũ. Self-service nghĩa là dev chạy một lệnh hoặc điền một form và có ngay tài nguyên trong vài phút.

3. Paved road / Golden path (thin platform)

"Đường đã lát" (paved road) là con đường mặc định được tối ưu, an toàn, dễ đi. Dev được khuyến khích chứ không bị ép đi trên đó — đi trên paved road thì nhanh và an toàn; nếu có nhu cầu đặc biệt, họ vẫn có thể "off-road" nhưng tự chịu trách nhiệm. Triết lý thin platform (nền tảng mỏng): platform nên là lớp trừu tượng mỏng, đủ để đơn giản hoá, tránh xây thành "framework khổng lồ" trói buộc dev.

4. Đo lường (DORA + DX)

Không đo thì không biết platform có hiệu quả. Hai nhóm chỉ số:

• DORA metrics: Deployment Frequency (tần suất triển khai), Lead Time for Changes (thời gian từ commit đến production), Change Failure Rate (tỉ lệ thay đổi gây lỗi), Mean Time to Restore (thời gian khôi phục). Bốn chỉ số này đo hiệu năng giao hàng phần mềm.
• Developer Experience: thời gian onboard một dev mới, thời gian tạo một service mới, mức độ hài lòng, tỉ lệ dev tự phục vụ thành công.

Ví dụ minh hoạ một golden path

Dưới đây là minh hoạ cách một golden path hoạt động: dev chỉ khai báo ý định trong một file YAML ngắn, còn platform sinh ra toàn bộ phần còn lại. Đây là manifest minh hoạ, không phải cú pháp của một sản phẩm cụ thể.

# service.yaml — dev chỉ cần viết chừng này
apiVersion: platform.ncb.internal/v1
kind: Service
metadata:
  name: loan-scoring-api
  team: risk-analytics
spec:
  language: python
  runtime: fastapi
  resources:
    database: postgres      # platform tự cấp, tự backup, tự gắn secret
    cache: redis
  expose:
    public: true            # platform tự cấu hình ingress + TLS
  compliance: pci-dss       # platform tự áp policy tương ứng

Khi dev commit file này, platform tự động thực hiện (minh hoạ luồng):

Dev không viết một dòng Terraform, Helm hay network policy nào. Bảo mật và tuân thủ được "nướng sẵn" (baked in) vào golden path.

Khi nào cần platform team — và rủi ro over-engineering

Platform Engineering không dành cho mọi tổ chức. Với một startup 5 kỹ sư và 3 service, xây IDP là lãng phí — chi phí xây và bảo trì platform vượt xa lợi ích. Đây chính là over-engineering: giải một bài toán quy mô mà bạn chưa có.

Dấu hiệu nên cân nhắc platform team:

• Nhiều đội (thường > 5–8 đội) lặp lại cùng một việc hạ tầng.
• Cognitive load rõ rệt: dev than phiền mất quá nhiều thời gian cho hạ tầng thay vì nghiệp vụ.
• Nhu cầu chuẩn hoá bảo mật/tuân thủ trên toàn tổ chức (đặc biệt ngành có quy định).
• Thời gian onboard hoặc thời gian đưa service lên production quá dài.

Nguyên tắc an toàn: bắt đầu mỏng. Đừng xây một "siêu platform" từ đầu. Hãy đóng gói golden path cho một trường hợp phổ biến nhất (ví dụ "deploy một REST API"), đo xem dev có dùng và có nhanh hơn không, rồi mở rộng dần theo nhu cầu thật. Platform xây theo kiểu "big bang" thường thất bại vì không ai dùng.

Bối cảnh ngân hàng: chuẩn hoá & tuân thủ qua platform

Ở ngân hàng, lập luận cho Platform Engineering còn mạnh hơn. Mỗi service đụng dữ liệu khách hàng đều phải tuân thủ hàng loạt yêu cầu: mã hoá dữ liệu, phân quyền tối thiểu, ghi log audit, phân loại dữ liệu, kiểm soát thay đổi (change control). Nếu để mỗi đội tự lo, sẽ có đội quên bật mã hoá, có đội log thiếu, và mỗi lỗ hổng là một rủi ro pháp lý.

Golden path giải quyết bằng cách gắn compliance vào đường đi chuẩn. Khi một service được sinh ra qua golden path "banking-grade", nó tự động có: mã hoá at-rest/in-transit, secret lấy từ Vault (không hard-code), audit log bật sẵn, policy-as-code chặn cấu hình không an toàn, và network policy mặc định "deny-all". Dev đi đúng đường thì tuân thủ tự động — an toàn theo mặc định (secure by default). Đây là cách nối kỹ thuật với quản trị dữ liệu; xem Governance 1 — Tổng quan. Bài Platform 8 — Nền tảng cho ngân hàng sẽ đi sâu kiến trúc này.

Use case thực tế: NCB — team dữ liệu tự triển khai pipeline qua golden path

Bối cảnh (mô phỏng thực tế tại NCB). Trước đây, để đưa một pipeline dữ liệu mới lên production — ví dụ job trích xuất giao dịch để tính hạn mức tín dụng — data engineer phải: (1) mở ticket xin tài nguyên compute; (2) chờ infra team cấp; (3) tự viết Dockerfile, cấu hình scheduler, xin secret kết nối database; (4) tự dựng monitoring; (5) qua vòng review bảo mật thủ công. Chu kỳ này ước lượng mất khoảng 2–3 tuần cho mỗi pipeline mới, phần lớn là thời gian chờ và làm thủ công lặp lại.

Giải pháp golden path. Platform team đóng gói một golden path cho "data pipeline": data engineer chỉ khai báo một manifest ngắn (nguồn, đích, lịch chạy, mức nhạy cảm dữ liệu). Platform tự cấp compute, sinh pipeline CI/CD, gắn secret từ Vault, cắm observability, và áp sẵn policy phân loại dữ liệu.

Kết quả (số liệu ước lượng minh hoạ).

Điểm cốt lõi: đội dữ liệu không còn chờ infra team cho từng việc nhỏ, mà tự phục vụ trên đường đã lát sẵn; infra/platform team chuyển từ "xử lý ticket" sang "cải tiến sản phẩm platform". Các con số trên là ước lượng minh hoạ cho mô hình, không phải số đo chính thức đã kiểm chứng.

Ghi nhớ

• Platform Engineering = xây và vận hành một Internal Developer Platform (IDP) như một sản phẩm cho lập trình viên nội bộ, nhằm giảm cognitive load và chuẩn hoá cách làm.
• Golden path / paved road: con đường chuẩn, tự phục vụ, an toàn theo mặc định — dev khai báo ý định, platform lo phần còn lại.
• Platform Engineering bổ sung chứ không thay thế DevOps (triết lý), SRE (độ tin cậy) và Infra/Cloud team (hạ tầng nền).
• Sáu trụ cột của series: IaC, GitOps, CI/CD & supply chain, observability, secrets & policy, IDP portal.
• Bốn nguyên tắc: platform-as-product, self-service, paved road (thin platform), đo lường (DORA + DX).
• Chỉ nên lập platform team khi quy mô đủ lớn (nhiều đội lặp việc); startup nhỏ làm IDP là over-engineering. Hãy bắt đầu mỏng và mở rộng theo nhu cầu thật.
• Ở ngân hàng, golden path gắn sẵn bảo mật/compliance giúp tuân thủ tự động — an toàn theo mặc định.
• Đo lường bằng DORA metrics và developer experience; nếu golden path khó dùng hơn tự làm, dev sẽ đi đường vòng và platform thất bại.

Nguồn tham khảo

• Matthew Skelton & Manuel Pais — Team Topologies: Organizing Business and Technology Teams for Fast Flow (IT Revolution, 2019) — nền tảng khái niệm platform team & giảm cognitive load.
• Evan Bottcher — "What I Talk About When I Talk About Platforms" (martinfowler.com, 2018) — https://martinfowler.com/articles/talk-about-platforms.html
• CNCF Platforms White Paper — CNCF App Delivery TAG — https://tag-app-delivery.cncf.io/whitepapers/platforms/
• Nicole Forsgren, Jez Humble & Gene Kim — Accelerate: The Science of Lean Software and DevOps (IT Revolution, 2018) — nguồn gốc bộ DORA metrics.
• Internal Developer Platform — tài liệu cộng đồng (Humanitec) — https://internaldeveloperplatform.org/
• Backstage Documentation — CNCF — https://backstage.io/docs/