Umbrella chart vs microservices strategy: Khi nào dùng cách nào

Ở phần trước của serie, mình đã đi qua cách quản lý nhiều môi trường với values files và naming convention. Đến phần này, câu hỏi bắt đầu khó hơn một chút: khi hệ thống có nhiều service, nên gom tất cả vào một umbrella chart hay tách thành chart riêng cho từng microservice?

Nếu bạn từng triển khai một stack có web, API, worker, Redis, PostgreSQL và vài thành phần phụ trợ, sớm muộn gì cũng gặp bài toán này. Chọn umbrella chart thì gọn, dễ nhìn, dễ deploy một lần cho cả stack. Chọn chart riêng thì linh hoạt hơn, team nào quản service nấy. Nghe cái nào cũng có lý, vì thật ra cả hai đều đúng trong những bối cảnh khác nhau.

Bài này phù hợp nếu bạn đã quen với Helm cơ bản, biết chart, values.yaml và dependency là gì. Mình sẽ không cố chốt một đáp án tuyệt đối, vì kiểu gì cũng có ngoại lệ. Thay vào đó, mình sẽ mổ xẻ từng strategy theo góc nhìn vận hành: deploy, ownership, độ phức tạp, blast radius và khả năng mở rộng sau này.

Umbrella chart là gì và khi nào nó hợp lý

Umbrella chart là một chart mẹ, bên trong khai báo nhiều subchart hoặc dependency cho từng thành phần của hệ thống. Hiểu nhanh thì nó giống như một gói deploy tổng. Thay vì cài 4 hay 5 chart riêng, bạn chạy một lần helm upgrade --install cho cả stack.

# Chart.yaml
apiVersion: v2
name: my-platform
description: Umbrella chart cho toàn bộ ứng dụng
type: application
version: 0.1.0
dependencies:
  - name: web
    version: 1.4.2
    repository: file://charts/web
  - name: api
    version: 2.1.0
    repository: file://charts/api
  - name: worker
    version: 1.2.3
    repository: file://charts/worker
  - name: redis
    version: 18.17.0
    repository: https://charts.bitnami.com/bitnami

Cái lợi đầu tiên của umbrella chart là sự đơn giản ở mặt vận hành. Một lệnh deploy, một release name, một chỗ gom values chung. Với team nhỏ, điều này cực kỳ đáng giá vì nó giảm số lượng thứ phải nhớ và phải phối hợp. Người trực ca on-call cũng dễ theo dõi hơn, nhìn release là biết cả stack đang ở version nào.

Điểm cộng tiếp theo là shared config dễ quản lý. Ví dụ, bạn có cùng domain suffix, cùng imagePullSecrets, cùng namespace labels, cùng ingress class cho toàn bộ hệ thống. Đặt các giá trị này ở chart mẹ giúp cấu hình thống nhất hơn, đỡ cảnh service A xài kiểu này, service B lại gõ lệch một chút rồi sinh lỗi lặt vặt.

💡 Umbrella chart rất hợp ở giai đoạn đầu, khi ranh giới giữa các service chưa thật sự ổn định và team vẫn cần thay đổi nhiều ở cấp toàn hệ thống.

Nhưng umbrella chart không miễn phí. Cái giá lớn nhất là blast radius. Khi mọi thứ đi chung một release, chỉ cần một thay đổi values sai ở service web cũng có thể kéo theo một đợt upgrade cho API, worker hoặc dependency khác. Có lúc Helm chỉ diff phần thay đổi. Có lúc lifecycle hook, dependency update hoặc template chung làm cả stack rung theo.

Một vấn đề nữa là ownership dễ bị mờ. Lúc đầu team 3 người ai sửa gì cũng được. Sau vài tháng, số service tăng lên, rồi có thêm người phụ trách API, người lo data, người lo frontend. Nếu ai cũng phải chạm vào cùng một chart mẹ và một values file khổng lồ, xung đột review sẽ bắt đầu xuất hiện. Chỗ này không phải do Helm dở, mà vì cách tổ chức chart không còn khớp với cách tổ chức team nữa.

Khi nào nên nghiêng về umbrella chart

• Team còn nhỏ, thường dưới 5 người
• Các service gần như luôn release cùng nhau
• Hệ thống vẫn là một sản phẩm thống nhất, chưa có ownership tách bạch
• Ưu tiên hiện tại là tốc độ setup và sự đơn giản trong vận hành
• Cần chuẩn hoá nhanh một stack có nhiều thành phần phụ thuộc chặt

Microservices chart strategy, khi tách mọi thứ ra riêng

Với microservices chart strategy, mỗi service có chart riêng, version riêng và thường là pipeline riêng. Web chart của bạn có thể lên bản mới 5 lần một tuần, trong khi billing chart chỉ đổi 2 tuần một lần. Cách này phản ánh đúng tinh thần microservices hơn: deploy độc lập, ownership rõ và failure domain nhỏ hơn.

helm upgrade --install web ./charts/web \
  -n production -f values-production.yaml
helm upgrade --install api ./charts/api \
  -n production -f values-production.yaml
helm upgrade --install worker ./charts/worker \
  -n production -f values-production.yaml

Ưu điểm rõ nhất là giảm liên kết và phụ thuộc ở tầng deploy. Một thay đổi nhỏ ở service API không bắt frontend hay worker phải đi cùng. Team phụ trách service nào có thể tự release service đó, rollback service đó và chịu trách nhiệm với SLA của service đó. Với tổ chức lớn, điều này gần như là điều kiện cần để tránh nghẽn cổ chai.

Ở góc nhìn ownership, chart riêng còn có một lợi thế khó thấy lúc ban đầu: repo, pipeline và policy có thể đi cùng service. Team API muốn enforce thêm test cho CRD hoặc policy security riêng thì cứ làm, không phải tranh luận trong một chart mẹ vốn phải phục vụ cả chục thành phần khác nhau.

Đổi lại, hệ thống sẽ có nhiều moving parts hơn. Version coordination khó hơn, secret management dễ phân mảnh hơn, naming convention nếu không siết ngay từ đầu thì vài tháng sau sẽ thành bãi chiến trường. Bạn tách được blast radius ở một chỗ, nhưng sẽ tăng coordination cost ở chỗ khác.

⚠️ Tách chart riêng quá sớm là lỗi khá phổ biến. Nếu service vẫn phụ thuộc chặt, luôn release cùng nhau và cùng một team chăm sóc, bạn chỉ đang tăng số repo, số pipeline và số chỗ phải debug.

Khi nào nên nghiêng về chart riêng cho từng service

• Nhiều team cùng tham gia phát triển và vận hành
• Mỗi service có lịch release khác nhau
• Cần rollback độc lập để giảm ảnh hưởng chéo
• Mức độ trưởng thành CI/CD đã đủ tốt
• Boundary giữa các service đã rõ, không còn kiểu sửa dây chuyền liên tục

Ma trận ra quyết định: chọn cách nào cho đúng

Nếu chỉ nhìn vào lý thuyết, ai cũng thích microservices vì nghe hiện đại hơn. Nhưng khi đụng thực tế vận hành, câu hỏi nên đặt lại rất đời thường: team có đủ người không, release có thật sự độc lập không, số lượng service đã đủ lớn chưa, và mỗi lần thay đổi có cần qua cùng một quy trình phê duyệt hay không.

Nôm na là thế này: nếu bạn còn phải hỏi nhau mỗi ngày rằng web và API có nên đi chung release không, khả năng cao là vẫn chưa tới lúc tách chart quá sâu. Ngược lại, nếu web release liên tục để chạy A/B test còn billing cần kiểm soát chặt, một umbrella chart sẽ sớm trở thành điểm nghẽn.

Lộ trình chuyển đổi: từ monolith sang umbrella rồi mới tách microservices

Rất nhiều đội đi theo một lộ trình tự nhiên hơn là một cú nhảy kiến trúc. Bắt đầu từ manifest rời hoặc một ứng dụng monolith, sau đó gom chúng vào umbrella chart để có cấu trúc rõ ràng hơn, rồi mới tách thành các chart độc lập khi service boundary và team boundary đã chín.

Giai đoạn monolith hoặc manifest rời thường có một đặc điểm: mọi thay đổi đều là thay đổi của cả hệ thống. Lúc này Helm được đưa vào chủ yếu để chuẩn hoá và tái sử dụng template. Umbrella chart là bước đệm rất hợp lý vì nó chưa ép bạn phải giải xong toàn bộ bài toán ownership ngay lập tức.

Sau một thời gian, bạn sẽ bắt đầu thấy dấu hiệu cần tách dần: values file quá dài, pipeline mỗi lần chạy quá lâu, review PR chart có quá nhiều người bị ảnh hưởng, hoặc service nào cũng có chu kỳ thay đổi riêng. Chỗ này là tín hiệu thật, không phải trend. Nếu thấy đủ nhiều tín hiệu như vậy, hãy tách từng phần một, đừng big bang rewrite chart trong một đêm đẹp trời.

# ví dụ values chung trước khi tách
global:
  domain: app.example.com
  imagePullSecrets:
    - regcred
api:
  replicaCount: 3
worker:
  replicaCount: 2

Khi tách chart, hãy giữ lại những gì thật sự là global, ví dụ ingress class, common labels hoặc imagePullSecrets. Còn những giá trị chỉ phục vụ một service thì đưa hẳn về chart của service đó. Nếu cái gì cũng để global, bạn đang mang tư duy umbrella chart sang một kiến trúc đã tách, rồi vô tình tạo coupling lại từ cửa sau.

Ví dụ thực tế: team nhỏ và tổ chức lớn khác nhau thế nào

Ví dụ đầu tiên là một startup 4 người. Sản phẩm có Next.js frontend, API Node.js, worker xử lý nền và Redis. Cả 4 thành phần này gần như luôn thay đổi cùng nhau vì feature mới thường chạm cả frontend lẫn backend. Với bối cảnh này, umbrella chart là lựa chọn hợp lý. Team có thể giữ một chart mẹ, một bộ values cho staging, một bộ values cho production, và triển khai đơn giản theo từng môi trường.

Trong trường hợp đó, việc tách thành 4 chart riêng nghe có vẻ bài bản nhưng lợi ích chưa đủ bù chi phí. Bạn phải quản lý 4 release, 4 version, có thể là 4 pipeline và thêm khá nhiều logic phối hợp phức tạp. Nói vui là chưa kịp chạy nhanh hơn thì đã bận dọn quy trình.

Ví dụ thứ hai là một tổ chức lớn hơn, có team web, team API, team payments, team data platform. Mỗi team có mục tiêu release khác nhau, SLA khác nhau và cửa sổ bảo trì khác nhau. Lúc này umbrella chart sẽ biến thành nút thắt cổ chai vì mỗi thay đổi đều phải đi qua cùng một release bundle. Microservices chart strategy giúp từng team giữ nhịp triển khai riêng, rollback riêng và review policy riêng.

Ở giữa hai thái cực này còn có mô hình hybrid. Chẳng hạn, mỗi domain lớn có một umbrella chart riêng, nhưng các domain khác nhau vẫn deploy độc lập. Ví dụ domain commerce có web, checkout và promotion đi chung; domain data có worker và scheduler đi chung; còn monitoring stack hoặc ingress controller đứng riêng. Đây là cách khá nhiều đội dùng để đi từng bước, không bị ép phải chọn trắng hoặc đen.

Kinh nghiệm thực chiến cho mỗi strategy

Dùng umbrella chart hay chart riêng đều có thể ổn, miễn là bạn có kỷ luật. Thiếu kỷ luật thì chart nào cũng có ngày hoá thành mớ dây điện dưới gầm bàn.

Với umbrella chart

• Khóa version dependency rõ ràng. Đừng để subchart trôi theo latest rồi chờ sự cố nhắc bạn nhớ.
• Tách values theo môi trường. Nếu chưa xem phần trước về multi-environment, bạn nên đọc lại bài đó để tổ chức values file gọn hơn.
• Test chart tổng thường xuyên. Dùng helm lint, helm template và nếu có thể thì thêm chart testing trong CI.
• Giới hạn shared config. Chỉ giữ thứ thật sự chung, đừng biến global thành chỗ nhét mọi thứ.
• Document blast radius. Team cần biết thay đổi nào có thể ảnh hưởng toàn stack và rollback sẽ diễn ra ra sao.

Với microservices charts

• Chuẩn hoá semantic version. Chart version, app version và release notes phải đọc được, không đoán mò.
• Quản dependency ở mức contract. Team A cần biết team B cam kết gì về API, schema, event hay secret shape.
• Giữ repo và naming convention nhất quán. Tên release, label, annotation, secret key nên có quy ước chung.
• Testing không chỉ ở chart. Cần thêm smoke test, contract test và kiểm tra rollback ở mức service.
• Observability phải là lớp dùng chung. Chart có thể tách, nhưng log, metrics và tracing nên nhìn được toàn hệ thống.

ℹ️ Bài cuối của serie sẽ đi sâu hơn vào các thực hành production như versioning, rollback, secret management và quy trình release an toàn. Bạn có thể theo dõi tại phần 12 về production best practices.

Faq: các câu hỏi hay gặp khi chọn kiến trúc chart

Có nên dùng một umbrella chart cho mọi thứ, kể cả database và monitoring?

Thường là không nên gom quá tay. Database stateful, monitoring stack và ingress controller thường có vòng đời khác ứng dụng chính. Nếu đi chung chỉ để tiện một lệnh deploy, về lâu dài bạn sẽ trả giá bằng blast radius và rollback khó kiểm soát.

Microservices thì bắt buộc mỗi service một chart riêng?

Không bắt buộc. Nếu vài service vẫn thuộc cùng một bounded context, cùng team quản và cùng lịch release, gom chúng vào một umbrella chart nhỏ vẫn rất hợp lý. Kiến trúc chart nên phản ánh nhu cầu deploy thực tế, không phải khẩu hiệu kiến trúc.

Dấu hiệu nào cho thấy đã đến lúc tách umbrella chart?

Values file quá dài, PR chart thường kéo quá nhiều reviewer, release của service này cứ phải chờ service kia, rollback khó khoanh vùng và ownership không còn rõ. Nếu các dấu hiệu này xuất hiện đều, chart mẹ đã bắt đầu quá tải.

Có thể quay ngược từ chart riêng về umbrella chart không?

Có thể, nhất là khi team thu gọn hoặc sản phẩm đổi hướng. Helm không cấm bạn làm vậy. Cái cần cẩn thận là dependency, release naming, secret ownership và quy trình CI/CD để không gây gián đoạn khi gom lại.

Tổng kết

Umbrella chart không hề lỗi thời. Microservices chart strategy cũng không tự động tốt hơn. Câu trả lời đúng thường nằm ở chỗ cấu trúc deploy có khớp với cấu trúc team và vòng đời thay đổi của hệ thống hay không. Team nhỏ, release đi cùng nhau, dependency còn chặt thì umbrella chart rất sáng cửa. Team lớn, ownership rõ, nhịp release lệch nhau thì chart riêng sẽ bớt nghẽn hơn.

Nếu còn đang phân vân, cách an toàn nhất là đi theo hướng tiến hoá: chuẩn hoá trước bằng umbrella chart, quan sát điểm nghẽn thật, rồi tách dần khi có đủ lý do vận hành. Làm như vậy chậm hơn một chút, nhưng thường đỡ đau đầu hơn rất nhiều.