Twelve-Factor on Thanh HV's Blog

Chương 26 — Khi nào KHÔNG nên áp dụng 12-Factor (và lời kết)

Sat, 11 Jul 2026 03:00:00 +0700

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:

Chương 25 — So sánh khách quan: đặt 12-Factor cạnh các lựa chọn khác

Sat, 11 Jul 2026 02:00:00 +0700

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.

Chương 24 — Case Study: Xây dựng REST API Golang chuẩn 12-Factor (kèm hành trình refactor)

Sat, 11 Jul 2026 01:00:00 +0700

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.

Chương 23 — Chủ đề Principal: Multi-region, Platform Engineering, GitOps nâng cao, Progressive Delivery, Multi-tenant, Cost

Sat, 11 Jul 2026 00:00:00 +0700

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).

Chương 22 — Observability: Logs, Metrics, Traces và OpenTelemetry

Fri, 10 Jul 2026 23:00:00 +0700

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.

Chương 21 — CI/CD: tự động hóa Build → Release → Deploy

Fri, 10 Jul 2026 22:00:00 +0700

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.

Chương 20 — Kubernetes: nền tảng thực thi hợp đồng 12-Factor

Fri, 10 Jul 2026 21:00:00 +0700

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:

Chương 19 — Docker: đóng gói ứng dụng 12-Factor

Fri, 10 Jul 2026 20:00:00 +0700

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:

Chương 18 — Golang Patterns cho ứng dụng 12-Factor

Fri, 10 Jul 2026 19:00:00 +0700

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/, compose

Nguyê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.

Chương 17 — Factor 12: Admin Processes

Fri, 10 Jul 2026 18:00:00 +0700

“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?

Chương 16 — Factor 11: Logs

Fri, 10 Jul 2026 17:00:00 +0700

“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:

Chương 15 — Factor 10: Dev/Prod Parity

Fri, 10 Jul 2026 16:00:00 +0700

“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.

Chương 14 — Factor 9: Disposability

Fri, 10 Jul 2026 15:00:00 +0700

“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:

Chương 13 — Factor 8: Concurrency

Fri, 10 Jul 2026 14:00:00 +0700

“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, orchestrator

Factor 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.

Chương 12 — Factor 7: Port Binding

Fri, 10 Jul 2026 13:00:00 +0700

“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.

Chương 11 — Factor 6: Processes

Fri, 10 Jul 2026 12:00:00 +0700

“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.

Chương 10 — Factor 5: Build, Release, Run

Fri, 10 Jul 2026 11:00:00 +0700

“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ả:

Chương 9 — Factor 4: Backing Services

Fri, 10 Jul 2026 10:00:00 +0700

“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.

Chương 8 — Factor 3: Config

Fri, 10 Jul 2026 09:00:00 +0700

“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).

Chương 7 — Factor 2: Dependencies

Fri, 10 Jul 2026 08:00:00 +0700

“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 đó.

Chương 6 — Factor 1: Codebase

Fri, 10 Jul 2026 07:00:00 +0700

“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):

Chương 5: Vì sao 12-Factor App ra đời — và cách đọc nó cho đúng

Fri, 10 Jul 2026 06:00:00 +0700

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:

Chương 4: Stateless và Immutable Infrastructure — Hai khái niệm nền móng

Fri, 10 Jul 2026 05:00:00 +0700

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:

Chương 3: Cloud Native — Thiết kế ứng dụng cho môi trường tạm bợ

Fri, 10 Jul 2026 04:00:00 +0700

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:

Chương 2: Cloud Computing — Khi hạ tầng trở thành phần mềm

Fri, 10 Jul 2026 03:00:00 +0700

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.

Chương 1: Ứng dụng truyền thống và những giới hạn của nó

Fri, 10 Jul 2026 02:00:00 +0700

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):

The Twelve-Factor App — Từ First Principles đến Production

Fri, 10 Jul 2026 01:00:00 +0700

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.