The Twelve-Factor App

Phần 4 | Chương trước: So sánh khách quan | Về mục lục Mỗi chương factor đã có mục “khi nào không áp dụng” riêng. Chương cuối này tổng hợp chúng thành một khung quyết định — và khép lại tài liệu bằng những điều đáng mang theo nhất. 1. Nguyên tắc gốc để suy luận ngoại lệ Toàn bộ 12-Factor suy ra từ một tiền đề (chương 2): hạ tầng tạm bợ, được tự động hóa, app chạy nhiều bản sao. Vậy quy tắc suy ngoại lệ rất gọn: ...

Phần 4 | Chương trước: Case study | Chương sau: Khi nào KHÔNG nên áp dụng Các chương trước đã rải trade-off theo từng chủ đề. Chương này gom chúng thành các bảng so sánh trực diện — công cụ cho các buổi tranh luận kiến trúc, nơi câu hỏi không phải “cái nào hay hơn” mà là “cái nào đúng cho ràng buộc của chúng ta”. 1. Traditional Deployment vs 12-Factor App Tiêu chí Traditional (VM + deploy tay) 12-Factor trên nền tảng tự động Chi phí khởi đầu Rất thấp — một VM, một binary Trung bình — pipeline, registry, nền tảng Tần suất release an toàn Tuần–quý Ngày–giờ Rollback Cầu may Một lệnh, một phút Scale Dọc, có trần, chậm Ngang, theo phút, hai chiều Phục hồi sự cố máy Giờ–ngày (snowflake) Tự động (cattle) Kỹ năng đòi hỏi Sysadmin cơ bản Container, CI/CD, orchestration Điểm hòa vốn Hệ nhỏ, ít thay đổi, 1–2 người Nhiều release, nhiều instance, nhiều người Điểm giống thường bị bỏ qua: cả hai đều cần kỷ luật version control, backup, giám sát — 12-Factor không thay thế những cái đó, nó xây trên chúng. Khi nào chọn traditional: đã phân tích xuyên suốt (chương 1, 26) — hệ nhỏ ổn định, một máy đủ, đội mỏng. Lưu ý chiều ngược: chọn traditional rồi vẫn giữ config-tách-code, log-stdout, Git — 4 factor rẻ nhất không có lý do bỏ ở bất kỳ mô hình nào. ...

Phần 4 – Thực chiến | Chương trước: Chủ đề Principal | Chương sau: So sánh khách quan Chương này ghép mọi mảnh của 24 chương trước thành một hệ thống hoàn chỉnh: dịch vụ đặt hàng orderly — REST API nhận đơn hàng, lưu PostgreSQL, cache Redis, phát sự kiện Kafka cho worker xử lý. Cấu trúc chương: hiện trạng “trước refactor” → kiến trúc đích → code đầy đủ → hạ tầng → pipeline → nhật ký refactor từng bước với lý do. ...

Phần 4 – Principal | Chương trước: Observability | Chương sau: Case study REST API Đến đây, các nguyên lý đã đầy đủ. Chương này trả lời câu hỏi của tầng principal: khi hệ thống và tổ chức lớn lên 10–100 lần, các nguyên lý đó biến hình thế nào? Mỗi mục đi nhanh nhưng đủ khung quyết định. 1. Multi-region Deployment Bài toán. Một region là một miền sự cố (AWS us-east-1 đã nhiều lần chứng minh); latency vật lý (Việt Nam → Singapore ~30–40ms, → US ~200ms); và yêu cầu pháp lý về nơi lưu dữ liệu (data residency). ...

Phần 3 – Engineering | Chương trước: CI/CD | Chương sau: Chủ đề Principal Factor 11 chỉ nói về log — vì năm 2011 hệ thống điển hình là một app monolith vài instance. Hệ phân tán hiện đại cần nhiều hơn: observability — khả năng đặt câu hỏi chưa nghĩ trước về trạng thái hệ thống từ dữ liệu nó phát ra. Đây là “factor 13” không chính thức mà mọi bản cập nhật 12-Factor đều bổ sung. ...

Phần 3 – Engineering | Chương trước: Kubernetes | Chương sau: Observability Factor 5 định nghĩa ba giai đoạn build–release–run; chương này xây cỗ máy thi hành chúng: pipeline CI/CD hoàn chỉnh với GitHub Actions, và mô hình GitOps cho phần deploy. 1. Bản chất: CI/CD là gì — tách bạch hai khái niệm CI (Continuous Integration): mọi thay đổi được tích hợp vào trunk thường xuyên, và mỗi lần tích hợp được kiểm chứng tự động (build + test). CI là về niềm tin vào trạng thái của trunk: trunk luôn ở trạng thái ship được. CD có hai nghĩa cần phân biệt: Continuous Delivery — mọi commit qua CI đều sẵn sàng deploy (artifact + quy trình tự động, người bấm nút); Continuous Deployment — bỏ luôn nút bấm, mọi commit xanh tự lên production. Đa số tổ chức trưởng thành dừng ở Delivery cho production và Deployment cho staging — đó là lựa chọn quản trị rủi ro, không phải mức độ “tiến hóa”. Điểm nối với 12-Factor: pipeline chính là ranh giới cưỡng chế của các factor — codebase (chỉ build từ Git), dependencies (verify trong CI), build/release/run (mỗi stage một job), parity (cùng artifact đi xuyên môi trường). Kỷ luật con người thất bại theo thời gian; kỷ luật pipeline thì không. ...

Phần 3 – Engineering | Chương trước: Docker | Chương sau: CI/CD Nếu 12-Factor là hợp đồng phía ứng dụng thì Kubernetes là bên thi hành phía nền tảng. Chương này đọc Kubernetes qua lăng kính đó: mỗi khái niệm K8s là câu trả lời cho một factor — và một app không theo 12-Factor sẽ vô hiệu hóa chính những khả năng bạn trả tiền để có. 1. Mô hình tư duy cốt lõi: declarative + reconciliation Toàn bộ Kubernetes đứng trên một vòng lặp: ...

Phần 3 – Engineering | Chương trước: Golang Patterns | Chương sau: Kubernetes Container không phải một factor — nó là công nghệ hiện thực hóa nhiều factor cùng lúc: F2 (isolate dependencies), F5 (build artifact bất biến), F10 (cùng image mọi môi trường), và là đơn vị của F6/F8/F9 (process/scale/dispose). Chương này đi từ bản chất container đến Dockerfile production tối ưu. 1. Bản chất: container là gì (và không phải là gì) Container không phải VM nhẹ. VM ảo hóa phần cứng (mỗi VM một kernel riêng); container ảo hóa hệ điều hành — mọi container trên một máy dùng chung kernel host, được cô lập bằng hai cơ chế Linux: ...

Phần 3 – Engineering | Chương trước: Admin Processes | Chương sau: Docker Phần 2 đã rải các mảnh code Go theo từng factor. Chương này hệ thống hóa chúng thành bộ pattern hoàn chỉnh của một service Go production-ready: cấu trúc, dependency injection, health check, signal handling, và một bộ khung main() chuẩn có thể tái sử dụng cho mọi service. 1. Cấu trúc project — kiến trúc phản chiếu các factor myapp/ ├── go.mod / go.sum # F2 ├── cmd/app/main.go # composition root — nơi DUY NHẤT wiring mọi thứ ├── internal/ │ ├── config/config.go # F3 — nơi DUY NHẤT đọc env │ ├── logging/logging.go # F11 — slog JSON ra stdout │ ├── server/ # F7, F9 — HTTP server, health, graceful shutdown │ │ ├── server.go │ │ └── middleware/ │ ├── service/ # business logic — KHÔNG import repository/postgres, │ │ └── order.go # chỉ import interface nó tự khai báo │ ├── repository/postgres/ # F4 — implementation của backing service │ ├── queue/ # F4, F8 — producer/consumer │ └── migrate/sql/ # F12 — migration embed └── deploy/ # Dockerfile, k8s/, composeNguyên tắc phụ thuộc: cmd → internal/{server,service,repository}; service chỉ biết interface; config không import gì của app. Vòng phụ thuộc là mùi thiết kế — Go từ chối compile là đồng minh của bạn. ...

“Run admin/management tasks as one-off processes” — Chạy tác vụ quản trị như các process một lần. Phần 2 – The Twelve Factors | Nhóm: Operable | Chương trước: Logs | Chương sau: Golang Patterns 1. Problem Statement Ngoài dòng traffic chính, hệ thống nào cũng có tác vụ quản trị: database migration, backfill dữ liệu, sửa dữ liệu hỏng một lần, chạy lại job fail, script thống kê, xóa dữ liệu hết hạn theo lịch. Câu hỏi của factor này: các tác vụ đó chạy ở đâu, bằng code nào, với môi trường nào? ...

“Treat logs as event streams” — Coi log là dòng sự kiện. Phần 2 – The Twelve Factors | Nhóm: Operable | Chương trước: Dev/Prod Parity | Chương sau: Admin Processes 1. Problem Statement Mô hình cũ: app ghi log vào file (/var/log/app/app.log), tự lo rotate, nén, xóa. Trên hạ tầng hiện đại, mô hình đó gãy ở mọi khớp: Filesystem là tạm bợ: container chết là file log chết theo — đúng lúc bạn cần log nhất (điều tra vì sao nó chết) thì log đã bay màu cùng nó. Nhiều instance: 30 pod = 30 file log trên 30 node — “grep file log” đòi hỏi biết pod nào xử lý request nào, điều bạn không thể biết trước. App phải biết quá nhiều: đường dẫn, quyền ghi, rotate policy, dung lượng — toàn tri thức về môi trường, vi phạm nguyên tắc environment coupling ngay từ chương 1. Tệ hơn: ghi vào filesystem phá readOnlyRootFilesystem, và disk đầy vì log là sự cố “tự bắn vào chân” kinh điển. Factor 11 tách đôi trách nhiệm bằng một hợp đồng tối giản: ...

“Keep development, staging, and production as similar as possible” — Giữ các môi trường giống nhau nhất có thể. Phần 2 – The Twelve Factors | Nhóm: Reproducible | Chương trước: Disposability | Chương sau: Logs 1. Problem Statement Câu nói ám ảnh nhất ngành vận hành: “Trên staging chạy mà!” Mọi tầng kiểm thử (unit test, integration test, staging, QA) đều dựa trên một giả định ngầm: môi trường kiểm thử dự đoán được môi trường thật. Mỗi khác biệt giữa hai môi trường đục một lỗ vào giả định đó — và bug sẽ chui đúng qua những lỗ ấy, xuất hiện chỉ trên production, nơi chi phí sửa cao nhất và công cụ debug nghèo nhất. ...

“Maximize robustness with fast startup and graceful shutdown” — Tối đa hóa độ bền vững bằng khởi động nhanh và tắt êm. Phần 2 – The Twelve Factors | Nhóm: Disposable & Scalable | Chương trước: Concurrency | Chương sau: Dev/Prod Parity 1. Problem Statement Chương 2 đã xác lập: trên hạ tầng hiện đại, process của bạn sẽ bị giết — thường xuyên, và phần lớn là có chủ đích. Hãy đếm các sự kiện giết process trong một tuần vận hành K8s bình thường: ...

“Scale out via the process model” — Scale bằng cách nhân bản process. Phần 2 – The Twelve Factors | Nhóm: Disposable & Scalable | Chương trước: Port Binding | Chương sau: Disposability 1. Problem Statement Câu hỏi: “Khi tải tăng, hệ thống lớn lên bằng cách nào?” Hai con đường: SCALE UP (dọc) SCALE OUT (ngang) ──────────────── ───────────────── Máy to hơn: thêm CPU/RAM Nhiều bản sao hơn của process + Không đổi kiến trúc + Không có trần (thêm máy là được) + Đơn giản + Chi tiết hóa: scale đúng phần cần − Có TRẦN vật lý + Kèm luôn HA (một bản chết còn bản khác) − Giá phi tuyến (máy 2x đắt >2x) − ĐÒI HỎI app đúng kiểu: stateless (F6), − Downtime khi nâng cấp port binding (F7), disposable (F9) − Một máy chết = chết hết − Phức tạp hơn: LB, orchestratorFactor 8 chọn scale out, và chỉ rõ đơn vị scale là process (ngày nay: container/pod — một process trong một container). Không có gì tự nhiên ở lựa chọn này — nó là hệ quả: đã stateless (F6) thì nhân bản là an toàn; đã bind port (F7) thì nhân bản là lắp thêm vào load balancer; và ngược lại, chọn scale out thì bắt buộc F6, F7. Các factor khóa lẫn nhau. ...

“Export services via port binding” — Xuất khẩu dịch vụ qua việc bind port. Phần 2 – The Twelve Factors | Nhóm: Disposable & Scalable | Chương trước: Processes | Chương sau: Concurrency 1. Problem Statement Factor này khó cảm nhận với dev Go — vì Go mặc định đã đúng. Để hiểu nó giải quyết gì, phải nhìn về mô hình mà nó phủ định: ứng dụng sống ký sinh trong một app server. ...

“Execute the app as one or more stateless processes” — Chạy ứng dụng như một hoặc nhiều process stateless. Phần 2 – The Twelve Factors | Nhóm: Disposable & Scalable | Chương trước: Build, Release, Run | Chương sau: Port Binding Đây là factor trung tâm của cả 12 — nếu chỉ được giữ một factor, hãy giữ factor này. Nền lý thuyết đã trình bày kỹ ở chương 4; chương này tập trung vào thực chiến: nhận diện state ẩn, refactor, và các tình huống xám. ...

“Strictly separate build and run stages” — Tách bạch nghiêm ngặt các giai đoạn build và run. Phần 2 – The Twelve Factors | Nhóm: Reproducible | Chương trước: Backing Services | Chương sau: Processes 1. Problem Statement Câu hỏi factor này trả lời: “Từ code đến process đang chạy, chuyện gì xảy ra — và có đảo ngược được không?” Trong thế giới chương 1, ba việc trộn làm một: build trên máy dev, copy lên server, sửa config tại chỗ, có khi sửa cả code tại chỗ. Hệ quả: ...

“Treat backing services as attached resources” — Coi mọi backing service là tài nguyên gắn kèm. Phần 2 – The Twelve Factors | Nhóm: Configurable | Chương trước: Config | Chương sau: Build, Release, Run 1. Problem Statement Backing service = bất kỳ dịch vụ nào app tiêu thụ qua mạng để hoạt động: database (PostgreSQL, MySQL), cache (Redis, Memcached), message broker (Kafka, RabbitMQ), object storage (S3, MinIO), SMTP, dịch vụ bên thứ ba (payment gateway, Maps API), và cả các service khác trong chính hệ thống của bạn. ...

“Store config in the environment” — Lưu config trong môi trường (triển khai). Phần 2 – The Twelve Factors | Nhóm: Configurable | Chương trước: Dependencies | Chương sau: Backing Services Đây là factor được trích dẫn nhiều nhất, bị hiểu máy móc nhiều nhất, và có nhiều cập nhật hiện đại nhất. Đọc kỹ mục Trade-off. 1. Problem Statement Config là gì? Định nghĩa của 12-Factor rất chính xác: config là mọi thứ thay đổi giữa các deploy (dev/staging/production): URL và credential của database, cache, message broker; credential của dịch vụ ngoài (S3, payment gateway); giá trị theo môi trường (hostname, log level, port). ...

“Explicitly declare and isolate dependencies” — Khai báo tường minh và cô lập dependency. Phần 2 – The Twelve Factors | Nhóm: Reproducible | Chương trước: Codebase | Chương sau: Config 1. Problem Statement Câu hỏi factor này trả lời: “Ứng dụng cần chính xác những gì để chạy?” — và câu trả lời phải nằm trong codebase, không nằm trong trí nhớ của ai đó hay trạng thái của một máy nào đó. ...

“One codebase tracked in revision control, many deploys” — Một codebase trong version control, nhiều deploy. Phần 2 – The Twelve Factors | Nhóm: Reproducible | Chương sau: Factor 2: Dependencies 1. Problem Statement Câu hỏi mà factor này trả lời nghe có vẻ tầm thường: “Code nào đang chạy trên production?” — cho đến khi bạn gặp các tình huống sau (tất cả đều là chuyện thật ở các doanh nghiệp): ...

Phần 1 – Foundation | Chương trước: Stateless & Immutable Infrastructure | Chương sau: Factor 1: Codebase Bốn chương trước đã dựng đủ bối cảnh. Chương này ghép mọi thứ lại thành bức tranh hoàn chỉnh về 12-Factor App: nó từ đâu ra, nó thực chất là gì, cái gì đã lỗi thời, cái gì trường tồn, và đọc nó với thái độ nào. 1. Nguồn gốc lịch sử 2011. Adam Wiggins, đồng sáng lập Heroku, cùng các kỹ sư Heroku công bố The Twelve-Factor App. Bối cảnh quan trọng để hiểu đúng tài liệu gốc: ...

Phần 1 – Foundation | Chương trước: Cloud Native | Chương sau: Vì sao 12-Factor App ra đời Nếu phải chọn hai khái niệm mà toàn bộ 12-Factor xoay quanh, đó là Stateless (ở tầng ứng dụng) và Immutable Infrastructure (ở tầng hạ tầng). Hiểu sâu hai khái niệm này thì 12 chương factor phía sau trở nên hiển nhiên. PHẦN A — STATELESS 1. Problem Statement Stateless bị hiểu sai phổ biến nhất là “ứng dụng không có state”. Điều đó vô nghĩa — mọi ứng dụng hữu ích đều có state (user, đơn hàng, session…). Định nghĩa đúng: ...

Phần 1 – Foundation | Chương trước: Cloud Computing | Chương sau: Stateless & Immutable Infrastructure Chương 2 kết luận: hạ tầng hiện đại là tạm bợ và được điều khiển bằng API. Chương này trả lời: một ứng dụng được thiết kế đúng cho môi trường đó trông như thế nào? — đó chính là định nghĩa thực chất của Cloud Native. 1. Problem Statement “Cloud Native” là một trong những thuật ngữ bị lạm dụng nhất ngành. Cần gạt bỏ hai hiểu lầm phổ biến: ...

Phần 1 – Foundation | Chương trước: Ứng dụng truyền thống | Chương sau: Cloud Native Chương 1 kết thúc với một ứng dụng bị trói vào một máy chủ cụ thể. Chương này trả lời câu hỏi: điều gì đã thay đổi ở tầng hạ tầng khiến cách viết ứng dụng cũ trở nên lỗi thời? 1. Problem Statement Bài toán của hạ tầng truyền thống Trước cloud, muốn có một server bạn phải: dự báo nhu cầu trước 6–12 tháng → xin ngân sách → mua phần cứng → chờ giao hàng → lắp đặt vào datacenter → cài OS → bàn giao. Chu kỳ tính bằng tháng. ...

Phần 1 – Foundation | Chương trước: Mục lục | Chương sau: Cloud Computing Trước khi nói về 12-Factor App, chúng ta phải hiểu thế giới mà nó sinh ra để giải quyết. Nếu bạn chưa từng trải qua nỗi đau của việc vận hành một ứng dụng truyền thống, mọi nguyên lý của 12-Factor sẽ chỉ là một checklist vô hồn. Chương này tái hiện lại thế giới đó. 1. Problem Statement Một ứng dụng truyền thống trông như thế nào? Hãy hình dung một hệ thống rất phổ biến ở các doanh nghiệp Việt Nam giai đoạn 2005–2015 (và thực tế vẫn còn tồn tại rất nhiều đến hôm nay): ...

Bộ tài liệu chuyên sâu về 12-Factor App và phát triển backend Cloud-Native hiện đại Ngôn ngữ: Tiếng Việt (thuật ngữ chuyên ngành giữ nguyên tiếng Anh) Code minh họa: Golang · Docker · Kubernetes · GitHub Actions Đối tượng: Backend/Senior Backend Engineer, DevOps/Platform Engineer, Tech Lead, Solution/Software Architect Cách đọc tài liệu này Tài liệu không bắt đầu bằng việc liệt kê 12 nguyên tắc. Nó đi theo mạch: ứng dụng truyền thống có vấn đề gì → hạ tầng thay đổi ra sao → Cloud-Native là gì → vì sao 12-Factor ra đời → từng factor giải bài toán gì, trade-off gì, khi nào không nên áp dụng → thực chiến Go/Docker/K8s → các chủ đề principal → case study hoàn chỉnh. ...