Chương 48. Managed service hay tự host?

Ở các chương trước, ta đã đi qua nhiều lớp hạ tầng:

• Reverse proxy.
• Load balancer.
• API Gateway.
• CDN.
• Firewall/WAF.
• Docker.
• CI/CD.
• Kubernetes.

Chương này nói về một quyết định rất thực tế:

Nên tự host hay dùng managed service?

Ví dụ:

Tự chạy PostgreSQL hay dùng managed PostgreSQL?
Tự chạy Redis/RabbitMQ hay dùng dịch vụ managed?
Tự dựng object storage hay dùng S3/GCS/R2?
Tự dựng Kubernetes hay dùng PaaS/managed platform?
Tự dựng monitoring hay dùng dịch vụ có sẵn?

Thông điệp chính của chương:

> Tự host thường rẻ hơn trên hóa đơn trực tiếp, nhưng tốn công vận hành và tăng rủi ro. Managed service thường đắt hơn, nhưng mua lại thời gian, độ ổn định, backup, nâng cấp, monitoring và sự yên tâm.

---

48.1. Ví dụ dễ hiểu: tự sửa điện nước hay thuê thợ

Bạn có thể tự sửa vòi nước.

Nếu việc nhỏ, bạn tiết kiệm tiền.

Nhưng nếu sửa sai, nước tràn ra nhà.

Bạn có thể tự thay dây điện.

Nếu biết làm, tốt.

Nếu không biết, rất nguy hiểm.

Có việc tự làm rất hợp.

Có việc thuê người chuyên làm lại rẻ hơn nếu tính cả rủi ro.

Hạ tầng cũng vậy.

Tự host không xấu.

Managed service cũng không phải lười.

Vấn đề là:

Bạn đang tối ưu tiền hóa đơn, hay tối ưu thời gian, rủi ro, tốc độ ra sản phẩm, và khả năng ngủ yên?

---

48.2. Tự host là gì?

Tự host nghĩa là bạn tự chạy và vận hành phần mềm/hạ tầng.

Ví dụ:

Tự cài PostgreSQL trên VM.
Tự chạy Redis.
Tự chạy RabbitMQ.
Tự chạy MinIO.
Tự chạy Elasticsearch.
Tự chạy Kubernetes cluster.
Tự chạy Prometheus/Grafana/Loki.

Bạn chịu trách nhiệm:

• Cài đặt.
• Cấu hình.
• Backup.
• Restore.
• Upgrade.
• Security patch.
• Monitoring.
• Alert.
• Scaling.
• High availability.
• Incident response.

Tự host cho nhiều quyền kiểm soát.

Nhưng quyền kiểm soát đi kèm trách nhiệm.

---

48.3. Managed service là gì?

Managed service là dịch vụ được nhà cung cấp vận hành cho bạn.

Ví dụ:

• Managed PostgreSQL.
• Managed Redis.
• Managed RabbitMQ/Kafka.
• S3/GCS/Azure Blob/R2.
• Cloud Run/Render/Fly/Heroku.
• Managed Kubernetes.
• Managed monitoring/logging.
• Managed auth.

Nhà cung cấp lo một phần:

• Provisioning.
• Patch.
• Backup.
• Replication.
• Failover.
• Scaling.
• Monitoring nền tảng.
• Security baseline.

Bạn vẫn phải cấu hình và dùng đúng.

Managed không có nghĩa:

Không cần hiểu gì.

Nó nghĩa là:

Bạn thuê người khác vận hành một phần khó và phổ biến.

---

48.4. Chi phí thật không chỉ là hóa đơn

Tự host có thể rẻ hơn trên hóa đơn cloud.

Ví dụ:

Một VM chạy PostgreSQL rẻ hơn managed PostgreSQL.

Nhưng chi phí thật gồm:

• Thời gian setup.
• Thời gian backup.
• Thời gian restore test.
• Thời gian patch security.
• Thời gian debug incident.
• Thời gian nâng version.
• Rủi ro mất dữ liệu.
• Rủi ro downtime.
• Người trực khi sự cố.
• Cơ hội bị mất vì không làm sản phẩm.

Nếu một managed database đắt hơn 100 USD/tháng nhưng tiết kiệm 20 giờ vận hành và giảm rủi ro mất dữ liệu, nó có thể rất rẻ.

Đừng chỉ nhìn giá niêm yết.

Hãy nhìn tổng chi phí sở hữu.

---

48.5. TCO là gì?

TCO là Total Cost of Ownership.

Nghĩa là tổng chi phí sở hữu/vận hành.

TCO gồm:

Hóa đơn hạ tầng
+ công người
+ rủi ro downtime
+ rủi ro mất dữ liệu
+ chi phí bảo trì
+ chi phí cơ hội

Ví dụ:

Tự host RabbitMQ:
  VM rẻ.
  Nhưng cần hiểu clustering, disk, memory, queue durability, monitoring, upgrade.

Managed queue:

Hóa đơn cao hơn.
Nhưng giảm nhiều trách nhiệm vận hành.

Senior không chỉ hỏi:

Cái nào rẻ hơn?

Mà hỏi:

Cái nào rẻ hơn sau khi tính cả rủi ro và công vận hành?

---

48.6. Database managed

Database là một trong những thứ đáng managed sớm nhất.

Vì database giữ dữ liệu thật.

Nếu database hỏng, rất đau.

Managed database thường hỗ trợ:

• Backup tự động.
• Point-in-time recovery.
• Replica.
• Monitoring.
• Patch.
• Version upgrade.
• Failover.
• Encryption.
• Access control.

Ví dụ:

• AWS RDS/Aurora.
• Google Cloud SQL/AlloyDB.
• Azure Database.
• Supabase/Neon/PlanetScale tùy nhu cầu.
• Railway/Render managed PostgreSQL ở quy mô nhỏ.

Bạn vẫn phải:

• Thiết kế schema.
• Viết query tốt.
• Tạo index.
• Quản lý connection.
• Test migration.
• Kiểm tra backup restore.

Managed DB không sửa query xấu.

Nhưng nó giảm gánh nặng vận hành nền tảng.

---

48.7. Tự host database khi nào?

Tự host database có thể hợp khi:

• Team có kinh nghiệm DBA/ops.
• Cần tùy biến sâu.
• Cần chạy on-premise.
• Chi phí managed quá cao ở scale lớn.
• Có yêu cầu compliance/hạ tầng đặc biệt.
• Có khả năng vận hành backup/failover/monitoring.

Nhưng nếu team nhỏ, sản phẩm còn đang phát triển, dữ liệu quan trọng:

Managed database thường là lựa chọn thực dụng hơn.

Tự host database production không phải chỉ là:

docker run postgres.

Nó là cả một trách nhiệm.

---

48.8. Queue managed

Queue/message broker cũng là thứ dễ đánh giá thấp.

Tự chạy Redis/RabbitMQ/Kafka nghe đơn giản lúc đầu.

Nhưng production cần:

• Durability.
• Retry.
• Dead letter queue.
• Disk/memory monitoring.
• Connection limit.
• Backup nếu cần.
• Cluster/failover.
• Upgrade.
• Message loss behavior.
• Throughput.

Managed queue có thể là:

• AWS SQS.
• Google Pub/Sub.
• Azure Service Bus.
• CloudAMQP.
• Amazon MQ.
• Managed Kafka.
• Upstash/managed Redis nếu phù hợp.

Queue là xương sống của job nền.

Nếu queue mất message, job có thể mất.

Nếu queue nghẽn, hệ thống chậm.

Managed queue đáng cân nhắc rất sớm nếu job nền quan trọng.

---

48.9. Kafka tự host là một trách nhiệm lớn

Kafka mạnh.

Nhưng tự host Kafka không nhẹ.

Cần hiểu:

• Broker.
• Partition.
• Replication.
• Consumer group.
• Retention.
• Disk.
• Rebalancing.
• Monitoring.
• Schema.
• Upgrade.

Nếu nhu cầu chỉ là:

Chạy job nền.

Kafka thường quá nặng.

Nếu cần event streaming thật sự ở scale lớn, Kafka/managed Kafka có thể rất đáng.

Thực dụng:

> Đừng tự host Kafka chỉ vì muốn kiến trúc trông hiện đại.

---

48.10. Object storage managed

Object storage gần như nên dùng managed trong đa số web app.

Ví dụ:

• S3.
• Google Cloud Storage.
• Azure Blob.
• Cloudflare R2.
• DigitalOcean Spaces.

Object storage managed cho:

• Dung lượng lớn.
• Durability cao.
• Lifecycle policy.
• Versioning.
• Access policy.
• Presigned URL.
• CDN integration.
• Cost theo usage.

Tự dựng object storage bằng MinIO có thể hợp khi:

• On-premise.
• Lab/dev.
• Cần kiểm soát đặc biệt.
• Có đội vận hành storage.

Nhưng với app web thông thường, tự lưu file trên disk hoặc tự dựng object storage production là rủi ro không cần thiết.

---

48.11. Auth managed

Auth là một mảng nhiều rủi ro.

Managed auth/provider có thể xử lý:

• Password.
• Social login.
• SSO.
• MFA.
• Password reset.
• Email verification.
• Token.
• Session.
• Security updates.

Ví dụ:

• Auth0.
• Clerk.
• Cognito.
• Firebase Auth.
• Supabase Auth.
• Okta.
• Microsoft Entra ID.
• Keycloak nếu tự host.

Nếu auth không phải năng lực lõi, dùng provider tốt thường rất đáng.

Nhưng cần cân nhắc:

• Vendor lock-in.
• Chi phí theo user.
• Tùy biến flow.
• Data ownership.
• Migration.

Auth tự làm được, nhưng phải làm rất cẩn thận.

---

48.12. Search managed

Search engine như Elasticsearch/OpenSearch có thể khá nặng để vận hành.

Tự host cần lo:

• Heap memory.
• Disk.
• Shard.
• Replica.
• Index mapping.
• Reindex.
• Upgrade.
• Snapshot/restore.
• Query performance.

Managed options:

• Elastic Cloud.
• OpenSearch managed.
• Algolia.
• Meilisearch Cloud.
• Typesense Cloud.

Nếu search là tính năng quan trọng nhưng team nhỏ, managed search có thể tiết kiệm rất nhiều công.

Nếu search đơn giản, PostgreSQL full-text hoặc search nhẹ hơn có thể đủ.

Đừng tự dựng cluster search lớn quá sớm.

---

48.13. Monitoring/logging managed

Observability cũng có thể tự host hoặc managed.

Tự host:

• Prometheus.
• Grafana.
• Loki.
• OpenSearch.
• Jaeger.
• ClickHouse.

Managed:

• Datadog.
• New Relic.
• Grafana Cloud.
• Honeycomb.
• Sentry.
• Cloud provider monitoring.
• Better Stack.

Tự host có thể rẻ hơn ở scale lớn.

Nhưng monitoring hỏng đúng lúc production hỏng thì rất tệ.

Managed observability thường đáng tiền cho team nhỏ vì:

• Setup nhanh.
• Alert dễ.
• Ít vận hành.
• UI tốt.
• Retention rõ.

Quan sát hệ thống là năng lực sống còn.

Đừng để việc tự host monitoring làm bạn không có monitoring.

---

48.14. PaaS và serverless platform

PaaS/Serverless container platform giúp chạy app mà không tự quản nhiều hạ tầng.

Ví dụ:

• Heroku.
• Render.
• Railway.
• Fly.io.
• Google Cloud Run.
• AWS App Runner.
• Azure Container Apps.
• Vercel/Netlify cho frontend/serverless.

Chúng thường lo:

• Build/deploy.
• Routing.
• TLS.
• Scaling cơ bản.
• Logs.
• Environment variables.
• Rollback một phần.

Rất hợp cho:

• Team nhỏ.
• MVP.
• App chưa quá phức tạp.
• Muốn ship nhanh.

Nhược điểm:

• Giới hạn tùy biến.
• Chi phí tăng theo scale.
• Cold start ở một số nền tảng.
• Vendor-specific behavior.

PaaS là lựa chọn rất thực dụng trước Kubernetes.

---

48.15. Managed Kubernetes

Managed Kubernetes giảm gánh nặng control plane.

Ví dụ:

• GKE.
• EKS.
• AKS.

Nhưng bạn vẫn phải lo:

• Node pools.
• Ingress.
• Security.
• RBAC.
• NetworkPolicy.
• Observability.
• Requests/limits.
• Cost.
• Deployment manifests.
• Cluster upgrades ở nhiều phần.

Managed Kubernetes không biến Kubernetes thành đơn giản.

Nó chỉ giảm phần tự dựng cluster.

Nếu team chưa cần Kubernetes, managed K8s vẫn có thể quá nặng.

---

48.16. Tự host rẻ hơn khi nào?

Tự host có thể rẻ hơn thật khi:

• Traffic/usage lớn.
• Team có năng lực vận hành.
• Công cụ ổn định, ít đổi.
• Có yêu cầu tùy biến cao.
• Managed service quá đắt ở scale hiện tại.
• Có hạ tầng sẵn.
• Có người chịu trách nhiệm on-call.

Ví dụ:

Một công ty lớn tự vận hành Kafka/ClickHouse vì usage rất cao và có đội platform.

Ở scale đó, managed có thể rất đắt.

Nhưng công ty cũng có người chuyên vận hành.

Không nên copy quyết định của công ty lớn nếu điều kiện của mình khác.

---

48.17. Managed đáng tiền khi nào?

Managed đáng tiền khi:

• Team nhỏ.
• Cần ship nhanh.
• Dữ liệu quan trọng.
• Không có chuyên gia vận hành.
• Downtime/mất dữ liệu rất đắt.
• Hạ tầng không phải core business.
• Cần backup/failover nhanh.
• Cần compliance/security baseline.
• Sản phẩm đang tìm market fit.

Ví dụ AI Judge:

Core value:
  chấm bài, feedback, workflow giáo dục, AI evaluation.

Không phải core value:
  tự vận hành PostgreSQL cluster
  tự dựng object storage
  tự patch RabbitMQ lúc nửa đêm

Managed giúp team tập trung vào sản phẩm.

---

48.18. Vendor lock-in

Managed service tạo vendor lock-in ở mức nào đó.

Ví dụ:

• API riêng của provider.
• IAM riêng.
• Config riêng.
• Pricing model riêng.
• Data migration khó.
• Feature đặc thù.

Lock-in không luôn xấu.

Nếu lock-in mua lại tốc độ và độ ổn định, có thể đáng.

Câu hỏi đúng:

Lock-in này có chấp nhận được không?
Nếu cần rời đi, khó đến mức nào?
Phần nào nên dùng chuẩn phổ biến?

Ví dụ:

PostgreSQL managed vẫn là PostgreSQL.
S3-compatible object storage dễ đổi hơn custom API quá riêng.

Đừng sợ lock-in đến mức tự làm mọi thứ.

Nhưng cũng đừng khóa mình vào chỗ không có đường ra cho dữ liệu quan trọng.

---

48.19. SLA và trách nhiệm thật

Managed service có thể có SLA.

Nhưng SLA không có nghĩa hệ thống của bạn không lỗi.

Provider chịu một phần:

• Service uptime.
• Nền tảng.
• Một số backup/failover.

Bạn vẫn chịu:

• Code dùng sai.
• Query chậm.
• Migration lỗi.
• Config sai.
• Delete nhầm dữ liệu.
• Permission sai.
• Không bật backup phù hợp.
• Không test restore.

Managed là shared responsibility.

Nhà cung cấp không hiểu nghiệp vụ của bạn.

---

48.20. Managed không có nghĩa không cần backup

Managed database thường có backup.

Nhưng bạn vẫn cần biết:

• Backup bật chưa?
• Retention bao lâu?
• Restore đến thời điểm nào?
• Restore mất bao lâu?
• Có test restore chưa?
• Backup có gồm file/object storage không?
• Ai có quyền xóa backup?

Nếu user xóa nhầm dữ liệu và bạn phát hiện sau retention, backup không cứu.

Nếu object storage không versioning/lifecycle đúng, file vẫn có thể mất.

Managed giúp, nhưng không thay thế trách nhiệm dữ liệu.

---

48.21. Managed không có nghĩa không cần monitoring

Provider có dashboard.

Nhưng bạn vẫn cần observability ở tầng app:

• Error rate.
• Latency.
• Queue backlog.
• Job fail.
• AI timeout.
• Cost per tenant.
• Database slow query.
• Cache hit rate.
• User flow failure.

Managed service nói:

Database CPU 90%.

Nhưng app metrics mới nói:

Teacher dashboard query đang scan quá nhiều.

Bạn cần cả hai.

---

48.22. Data portability

Trước khi dùng managed service, hỏi:

Dữ liệu có export được không?
Format gì?
Migrate đi đâu?
Downtime bao lâu?

Với database chuẩn như PostgreSQL, portability khá tốt.

Với dịch vụ rất proprietary, cần cân nhắc hơn.

Ví dụ:

Auth provider:
  export user/password hash được không?

Analytics provider:
  export raw events được không?

Object storage:
  bulk copy ra nơi khác thế nào?

Không phải để rời đi ngay.

Mà để không bị kẹt hoàn toàn.

---

48.23. Compliance và dữ liệu nhạy cảm

Nếu dữ liệu nhạy cảm, managed service cần xem:

• Region.
• Data residency.
• Encryption.
• Audit log.
• Access control.
• Compliance chứng nhận.
• DPA/contract.
• Backup location.
• Subprocessor.

Ví dụ dữ liệu học sinh có thể có yêu cầu riêng tùy thị trường.

Không chỉ hỏi:

Dịch vụ này rẻ không?

Mà còn:

Dữ liệu nằm ở đâu?
Ai có quyền truy cập?
Có audit không?
Có hợp yêu cầu khách hàng không?

---

48.24. Managed service và region

Chọn region ảnh hưởng:

• Latency.
• Data residency.
• Chi phí.
• Availability.
• Dịch vụ có sẵn.

Ví dụ user chủ yếu ở Việt Nam.

Region Singapore có thể hợp hơn US về latency.

Nhưng provider/dịch vụ phải hỗ trợ.

Cũng cần nghĩ:

• Database ở region nào.
• Object storage ở region nào.
• AI provider endpoint ở đâu.
• CDN edge có gần user không.
• Data transfer cross-region có tốn không.

Managed service không tự chọn region đúng thay bạn.

---

48.25. Khi nào nên mua thay vì tự dựng?

Nên nghiêng về mua/managed khi:

Thứ đó không phải lợi thế cạnh tranh chính.
Nó khó vận hành đúng.
Nó giữ dữ liệu quan trọng.
Downtime/mất dữ liệu rất đắt.
Team nhỏ.
Cần ship nhanh.
Managed service đã đủ tốt.

Ví dụ thường nên mua sớm:

• Database.
• Object storage.
• Email sending.
• Payment.
• Auth nếu không muốn tự làm.
• Monitoring/alerting.
• Queue nếu job quan trọng.

Tự dựng khi có lý do rõ.

Không phải vì sĩ diện kỹ thuật.

---

48.26. Khi nào nên tự dựng?

Nên tự dựng khi:

• Managed không đáp ứng yêu cầu.
• Chi phí managed quá cao ở scale lớn.
• Cần kiểm soát sâu.
• Có yêu cầu on-prem/private.
• Có năng lực vận hành.
• Có thời gian và quy trình.
• Công nghệ đó là năng lực lõi.

Ví dụ:

Công ty chuyên hạ tầng search có thể tự vận hành search cluster.

Nhưng một app giáo dục nhỏ tự vận hành search cluster phức tạp có thể là lãng phí.

Tự dựng phải có lý do kinh tế/kỹ thuật rõ.

---

48.27. Hybrid là bình thường

Không phải chọn tất cả managed hoặc tất cả tự host.

Hệ thống thực tế thường hybrid:

Managed PostgreSQL.
Managed object storage.
Self-host app containers.
Managed queue.
Self-host simple worker.
Managed monitoring.

Hoặc:

Self-host Redis cache.
Managed database.
Managed auth.
Cloud Run for API.

Chọn theo từng thành phần.

Mỗi thành phần có rủi ro, chi phí, năng lực team khác nhau.

---

48.28. AI Judge: cái gì nên managed sớm?

Với AI Judge, nên cân nhắc managed sớm cho:

Database:

Submission, GradingResult, User, Course là dữ liệu quan trọng.
Managed PostgreSQL rất đáng.

Object storage:

Bài nộp, report, artifact nên nằm ở S3/GCS/R2.

Queue:

Nếu grading job quan trọng, managed queue giúp giảm rủi ro vận hành.

Email:

Password reset, notification nên dùng provider.

Monitoring:

Job fail, queue backlog, AI cost cần nhìn thấy sớm.

Auth:

Nếu cần Google/Microsoft school login, OIDC provider/managed auth rất đáng.

Những thứ này không phải phần tạo khác biệt chính của AI Judge.

---

48.29. AI Judge: cái gì có thể tự làm?

AI Judge nên tự làm phần core domain:

• Assignment workflow.
• Submission lifecycle.
• Rubric model.
• Grading orchestration.
• Feedback UX.
• Teacher override flow.
• Cost attribution theo course/assignment.
• AI prompt/evaluation logic.
• Permission domain giáo dục.

Đây là phần tạo giá trị sản phẩm.

Không nên tốn quá nhiều năng lượng tự dựng hạ tầng phổ biến nếu nó làm chậm core product.

Tư duy:

Mua nền móng phổ biến.
Tự xây phần khác biệt.

---

48.30. AI Judge: đừng tự host chỉ vì ban đầu ít tiền

Khi mới bắt đầu, tiết kiệm là quan trọng.

Nhưng cần phân biệt:

Tiết kiệm thông minh.

và:

Chuyển rủi ro sang tương lai.

Ví dụ tự chạy PostgreSQL trên một VM không backup tử tế có thể rẻ hôm nay.

Nhưng nếu mất dữ liệu bài nộp, chi phí uy tín rất lớn.

Có thể chọn managed tier nhỏ trước.

Scale lên khi cần.

Đừng bắt đầu bằng cấu hình enterprise đắt đỏ.

Nhưng cũng đừng bỏ qua backup/restore chỉ để tiết kiệm vài đô.

---

48.31. AI Judge: chi phí AI cũng là managed service cost

AI provider như Gemini/OpenAI/Claude cũng là managed service.

Bạn mua:

• Model.
• Infra inference.
• Scale.
• API.
• Reliability ở mức provider.

Nhưng bạn vẫn phải quản:

• Rate limit.
• Quota.
• Retry.
• Timeout.
• Cost per job.
• Prompt version.
• Data privacy.
• Fallback.
• Monitoring.

Managed AI không tự làm sản phẩm đúng.

Nó chỉ cung cấp năng lực model.

AI Judge vẫn phải thiết kế queue, worker, rubric, feedback, evaluation, cost control.

---

48.32. Migration khỏi managed service

Nếu lo vendor lock-in, hãy chuẩn bị vừa đủ:

• Dùng chuẩn phổ biến khi có thể.
• Export dữ liệu định kỳ nếu cần.
• Không rải API provider quá sâu trong domain code.
• Có abstraction nhẹ ở boundary.
• Ghi rõ dependency.
• Biết đường migrate nếu dịch vụ tăng giá hoặc không phù hợp.

Không cần over-engineer abstraction cho mọi thứ.

Nhưng với provider quan trọng, nên có boundary rõ.

Ví dụ:

ObjectStorage interface.
EmailSender interface.
AIProvider adapter.

Abstraction ở biên giúp đổi provider đỡ đau.

---

48.33. Managed service vẫn cần kiến thức nền

Dùng managed PostgreSQL vẫn cần hiểu:

• Index.
• Transaction.
• Connection pool.
• Slow query.
• Migration.

Dùng managed queue vẫn cần hiểu:

• Retry.
• Visibility timeout.
• Dead letter queue.
• Idempotency.

Dùng object storage vẫn cần hiểu:

• Presigned URL.
• Permission.
• Lifecycle.
• Metadata.

Dùng managed auth vẫn cần hiểu:

• Authentication.
• Authorization.
• Token.
• Session.

Managed giảm vận hành.

Không thay thế hiểu biết hệ thống.

---

48.34. Những lỗi phổ biến

Lỗi 1:

Tự host database không backup/restore test.

Lỗi 2:

Chọn managed service đắt nhưng không dùng hết, không theo dõi cost.

Lỗi 3:

Tự host Kafka/Elasticsearch quá sớm.

Lỗi 4:

Dùng managed nhưng config sai nên vẫn mất dữ liệu/downtime.

Lỗi 5:

Không biết dữ liệu export/migrate thế nào.

Lỗi 6:

Để mọi thứ vendor-specific tràn vào domain code.

Lỗi 7:

Không tính công vận hành vào chi phí tự host.

Lỗi 8:

Chọn Kubernetes tự vận hành khi PaaS đơn giản đã đủ.

Lỗi 9:

Tin managed service nên bỏ monitoring app-level.

Lỗi 10:

Tự dựng hạ tầng phổ biến nhưng bỏ bê phần sản phẩm cốt lõi.

---

48.35. Checklist chọn managed hay tự host

Hỏi:

• Thành phần này có giữ dữ liệu quan trọng không?
• Nếu nó chết 1 giờ thì hậu quả gì?
• Nếu mất dữ liệu thì hậu quả gì?
• Team có kinh nghiệm vận hành nó không?
• Có backup/restore plan không?
• Có monitoring/alert không?
• Managed service tốn bao nhiêu?
• Tự host tốn bao nhiêu công mỗi tháng?
• Nâng cấp/security patch ai làm?
• Có yêu cầu compliance/region không?
• Có cần tùy biến sâu không?
• Có đường migrate ra không?
• Nó có phải năng lực lõi của sản phẩm không?
• Nếu sự cố lúc nửa đêm, ai xử lý?

Câu cuối rất quan trọng.

Nếu không ai muốn nhận cuộc gọi đó, managed service đáng cân nhắc.

---

48.36. Bảng chọn nhanh

| Thành phần | Thường nên nghiêng về | |---|---| | Database production | Managed nếu team nhỏ/vừa | | Object storage | Managed gần như mặc định | | Queue job quan trọng | Managed hoặc đơn giản tự host có monitoring tốt | | Kafka/event streaming lớn | Managed nếu không có đội vận hành mạnh | | Auth/SSO/MFA | Managed nếu auth không phải core | | Email/payment | Managed/provider chuyên dụng | | Search đơn giản | DB full-text/search nhẹ | | Search phức tạp | Managed search đáng cân nhắc | | Monitoring/logging | Managed rất hữu ích cho team nhỏ | | Kubernetes | Managed K8s nếu thật sự cần, PaaS nếu chưa cần | | Core domain logic | Tự xây |

---

48.37. Tóm tắt bằng AI Judge

Với AI Judge, lựa chọn thực dụng có thể là:

Managed PostgreSQL:
  giữ dữ liệu bài nộp, điểm, user, course.

Managed object storage:
  giữ file bài nộp, feedback report, artifact.

Managed queue hoặc queue vận hành đơn giản có monitoring:
  giữ grading jobs.

Managed email/auth nếu cần:
  password reset, school SSO.

Managed monitoring:
  queue backlog, job fail, AI timeout, cost.

Tự xây:
  workflow nộp bài
  rubric
  grading orchestration
  feedback UX
  permission domain giáo dục
  cost attribution

Đừng tự host hạ tầng phức tạp chỉ để chứng minh mình làm được.

Hãy tự xây phần tạo giá trị khác biệt.

Hãy mua hoặc dùng managed cho phần phổ biến nhưng vận hành đau.

---

48.38. Kết luận của chương

Managed service hay tự host không phải câu hỏi danh dự kỹ thuật.

Nó là quyết định kinh tế, vận hành và rủi ro.

Tự host cho kiểm soát và có thể rẻ hơn ở một số quy mô, nhưng đòi hỏi năng lực vận hành thật.

Managed service đắt hơn trên hóa đơn, nhưng thường mua lại backup, failover, patch, scaling, monitoring nền tảng, và rất nhiều giờ làm việc.

Thông điệp cần nhớ:

> Đừng chỉ hỏi "cái nào rẻ hơn?". Hãy hỏi "cái nào giúp hệ thống an toàn hơn, team đi nhanh hơn, và rủi ro nằm trong khả năng chịu được?".

Ở chương tiếp theo, ta sẽ bước sang phần observability và reliability: vì sao không đo thì chỉ đoán, log/metrics/trace khác nhau thế nào, và vì sao quan sát hệ thống là điều kiện để debug, scale và ra quyết định kiến trúc đúng.