Báo cáo kiến trúc và bài toán khó trong hệ thống PaaS

Ngày viết: 30/05/2026 Phạm vi: hệ thống Platform as a Service ở mức senior/architect, bao gồm public PaaS, internal developer platform, app runtime platform, container/serverless platform, service marketplace và control plane vận hành nhiều team/tenant/app. Không bàn sâu phần cơ bản như "PaaS là gì", "deploy một app hello world", hoặc "container là gì".

1. Tóm tắt thẳng

PaaS không phải là:

Kubernetes + UI deploy app

PaaS là một hệ thống product hóa năng lực platform, giúp developer:

• đưa code thành workload chạy production,
• có runtime chuẩn,
• có route/domain/TLS,
• có secrets/config,
• có logs/metrics/traces,
• có autoscaling,
• có service binding,
• có policy/security guardrails,
• có rollback/release flow,
• có self-service,
• mà không phải hiểu toàn bộ hạ tầng bên dưới.

Điểm khó nhất của PaaS không nằm ở "chạy container". Nó nằm ở:

biến hạ tầng phức tạp thành trải nghiệm developer đơn giản,

nhưng vẫn giữ được isolation, security, cost control, reliability,

operability, extensibility và governance.

Một PaaS tốt phải tạo ra "golden path":

developer làm đúng gần như mặc định,

làm sai bị chặn sớm,

làm đặc biệt vẫn có escape hatch có kiểm soát.

Một PaaS tệ thường trở thành:

• Kubernetes wrapper nửa vời,
• CI/CD glue script,
• portal đẹp nhưng không self-service thật,
• platform team làm ticket thủ công,
• mỗi team tự copy YAML,
• secrets rải rác,
• quota không rõ,
• cost không ai chịu,
• app chạy được nhưng không vận hành được.

2. Cách nghiên cứu

Báo cáo này dựa trên các nhóm nguồn:

Kết luận nghiên cứu:

PaaS trưởng thành không chỉ abstract infrastructure.

Nó chuẩn hóa toàn bộ software delivery lifecycle: build, release, run, observe, scale, secure, govern.

3. PaaS là boundary trách nhiệm, không phải một công nghệ

NIST SP 800-145 định nghĩa PaaS là cloud model nơi consumer deploy application lên platform provider; consumer không quản lý infrastructure nền như network, servers, OS, storage, nhưng kiểm soát deployed applications và có thể kiểm soát cấu hình hosting environment.[^nist-paas]

Nói dễ hiểu:

IaaS: tôi nhận máy/VM/network/storage.

PaaS: tôi đưa app/artifact/config, platform lo runtime/scale/ops nền.

SaaS: tôi dùng luôn phần mềm hoàn chỉnh.

Nhưng trong thực tế, PaaS có nhiều hình thái:

• Heroku-style app platform.
• Cloud Foundry-style enterprise PaaS.
• Google App Engine-style managed runtime.
• Kubernetes-based internal developer platform.
• Serverless/container platform như Knative/Cloud Run-style.
• Data/AI PaaS nội bộ.
• Service marketplace/platform control plane.

Do đó câu hỏi đúng không phải:

Mình dùng Kubernetes thì đã là PaaS chưa?

Mà là:

Developer có một platform product tự phục vụ, có guardrails, có runtime contract, có service lifecycle, có observability và có ownership rõ chưa?

4. Bản chất khó của PaaS

PaaS là giao điểm của ba lực kéo:

Developer Experience

muốn đơn giản, nhanh, tự phục vụ

Platform Operations

muốn chuẩn hóa, ổn định, quan sát được, ít toil

Security/Governance

muốn kiểm soát, audit, compliance, isolation

Nếu nghiêng quá nhiều về developer experience:

• developer deploy dễ,
• nhưng security/cost/runtime chaos.

Nếu nghiêng quá nhiều về governance:

• mọi thứ an toàn trên giấy,
• nhưng developer phải mở ticket và tự bypass.

Nếu nghiêng quá nhiều về ops:

• platform ổn cho platform team,
• nhưng app team không hiểu và không dùng.

PaaS tốt phải cân bằng:

self-service + paved road + policy guardrails + escape hatch

5. Các lớp kiến trúc PaaS

Một PaaS trưởng thành nên được nhìn thành nhiều plane:

Developer plane

- portal/catalog

- CLI/API

- templates/golden paths

- docs

- onboarding

Control plane

- project/app registry

- build/release orchestration

- deployment desired state

- policy/admission

- quota/entitlement

- service broker/catalog

- environment management

Runtime/data plane

- scheduler

- compute nodes/cells

- containers/processes/functions

- routing/ingress

- service mesh/network

- storage/volumes

Operations plane

- logs/metrics/traces

- SLO/health

- incident/runbook

- cost/usage

- audit

- backup/restore

Security plane

- identity/RBAC

- secrets/KMS

- image scanning/signing

- admission policy

- runtime sandbox

- network policy

Sai lầm phổ biến:

Chỉ xây runtime/data plane rồi gọi đó là PaaS.

Nếu không có developer plane và control plane, developer vẫn phải tự hiểu hạ tầng.

6. Cloud Foundry, Heroku, App Engine: bài học từ PaaS lâu năm

6.1. Cloud Foundry

Cloud Foundry có các khái niệm đáng học:

• Cloud Controller nhận app/config và điều phối lifecycle.
• Buildpack + stack + source tạo droplet.
• Diego chịu trách nhiệm scheduling/running apps.
• Gorouter route HTTP traffic tới app instances.
• Service Broker API tích hợp backing services.
• Logs/metrics được stream ra ngoài.[^cf-overview][^cf-diego][^cf-routing][^cf-services]

Bài học:

PaaS cần model app lifecycle rõ: stage/build -> run -> route -> scale -> bind service -> observe.

Không phải developer tự viết deployment YAML từ đầu.

6.2. Heroku

Heroku popular hóa trải nghiệm:

git push

-> buildpack

-> slug

-> release

-> dynos

Heroku cũng làm Twelve-Factor App nổi tiếng: codebase, dependencies, config, backing services, build-release-run, processes, logs, disposability, dev/prod parity.[^heroku-12factor][^heroku-dynos-build]

Bài học:

PaaS tốt ép application contract đơn giản:

config qua environment,

process stateless,

logs ra stdout,

backing services là attached resources,

build/release/run tách rõ.

6.3. Google App Engine

App Engine Standard Environment là ví dụ PaaS managed runtime: app chạy trong sandbox, platform phân phối request qua nhiều server và scale để đáp ứng traffic.[^app-engine-standard]

Bài học:

PaaS có thể cực kỳ opinionated.

Opinionated đúng giúp giảm cognitive load.

Opinionated sai làm developer bị lock-in và khó xử lý edge cases.

7. PaaS hiện đại và internal developer platform

Ngày nay nhiều tổ chức không mua một PaaS monolithic. Họ xây internal developer platform trên Kubernetes/cloud primitives.

CNCF Platform Engineering Maturity Model nhấn mạnh platform không chỉ là technology; business outcomes chỉ đạt được khi cân bằng people, process, policy và technology.[^cncf-platform-maturity]

Backstage là ví dụ developer portal/catalog: software catalog giữ ownership và metadata cho services, websites, libraries, data pipelines trong ecosystem.[^backstage-catalog]

Nhưng:

Developer portal != PaaS.

Portal chỉ là cửa vào. PaaS thật phải có self-service action:

• tạo app/service,
• tạo environment,
• deploy,
• provision database/cache/queue,
• xem logs/traces,
• request secret/access,
• rollback,
• scale,
• xem cost/quota,
• mở runbook.

Nếu portal chỉ là catalog + docs link, nó không phải platform hoàn chỉnh.

8. App lifecycle là xương sống của PaaS

PaaS phải chuẩn hóa lifecycle:

Source

-> Build

-> Artifact

-> Release

-> Deploy

-> Run

-> Observe

-> Scale

-> Update

-> Rollback

-> Retire

8.1. Build, release, run

Twelve-Factor nhấn mạnh build, release, run là ba stage tách biệt.[^heroku-12factor]

Ý nghĩa kiến trúc:

• Build tạo artifact immutable.
• Release kết hợp artifact + config.
• Run chạy release trong runtime.

Không nên:

build trong runtime container khi app start

pull secret rồi generate code trong boot

deploy code mutable không version

8.2. Release object

Một release nên có:

• app id,
• artifact digest,
• config version,
• environment,
• build provenance,
• image/SBOM reference,
• migration plan,
• release notes,
• actor,
• timestamp,
• rollout strategy,
• rollback target,
• policy decisions.

Nếu chỉ có "latest image tag", bạn không có release management.

9. Build system: Dockerfile hay buildpack?

Cloud Native Buildpacks định nghĩa lifecycle và API giữa platform, lifecycle và buildpacks, giúp biến source code thành OCI image mà không cần app team tự viết Dockerfile cho mọi thứ.[^cnb-buildpack-api]

Buildpack phù hợp khi:

• nhiều team/app,
• ngôn ngữ/framework phổ biến,
• muốn standardized base images,
• muốn tự động dependency/runtime updates,
• muốn giảm Dockerfile copy-paste,
• muốn platform team kiểm soát supply chain.

Dockerfile phù hợp khi:

• app có runtime đặc biệt,
• build cần kiểm soát chi tiết,
• workload không theo pattern web/process chuẩn,
• team có năng lực container security.

Đánh đổi:

Nguyên tắc:

PaaS nên support golden path bằng buildpack/template,

và cho Dockerfile như escape hatch có policy.

10. Artifact và supply chain

PaaS chạy code của nhiều team/tenant. Build pipeline là điểm rủi ro lớn.

Cần:

• immutable artifact,
• image digest, không chỉ tag,
• SBOM,
• vulnerability scan,
• provenance/attestation,
• signed images,
• dependency policy,
• base image lifecycle,
• build cache isolation,
• secret redaction,
• reproducible/controlled builds nếu cần.

SLSA là framework từ source tới service để tăng integrity của software supply chain, tập trung vào build provenance, source integrity và build environment security.[^slsa]

10.1. Build cache là attack surface

Build cache giúp nhanh nhưng có rủi ro:

• cross-tenant cache poisoning,
• dependency confusion,
• secrets trong layer/cache,
• compromised builder image,
• stale vulnerable base.

PaaS multi-tenant cần cache isolation/policy rõ.

10.2. Base image lifecycle

Platform team phải xử lý:

• base image update,
• CVE rebuild,
• language runtime EOL,
• forced rebuild,
• deprecation notice,
• rollout theo app,
• exception workflow.

Nếu không, platform sẽ chạy hàng trăm app trên runtime cũ.

11. Runtime scheduling

Kubernetes scheduler là control plane process gán Pod vào Node; scheduler lọc node phù hợp rồi score/rank node khả thi.[^k8s-scheduler]

Cloud Foundry Diego chịu trách nhiệm scheduling và management app processes, cân bằng app load trên host VMs.[^cf-diego]

PaaS phải giải quyết scheduling ở mức cao hơn Kubernetes raw:

• app instances,
• processes/workers,
• cron/jobs,
• one-off tasks,
• CPU/memory,
• GPU/special hardware,
• region/zone,
• affinity/anti-affinity,
• tenant isolation,
• noisy neighbor,
• spot/preemptible nodes,
• priority,
• quota,
• maintenance/drain.

11.1. Scheduling không chỉ là bin packing

Nếu chỉ tối ưu lấp đầy node:

• tenant noisy có thể làm tenant khác chậm,
• app critical nằm cùng node với batch job,
• deploy cùng lúc tạo thundering herd,
• node drain gây outage,
• data locality bị bỏ qua,
• GPU bị fragmented.

PaaS cần scheduling policy theo workload class:

web request-serving

worker/background

cron/batch

stateful

GPU/AI

low-priority jobs

internal platform components

11.2. Workload contract

Developer cần khai báo:

• process type,
• health check,
• readiness/liveness,
• resource requests/limits,
• concurrency,
• autoscaling mode,
• graceful shutdown timeout,
• storage needs,
• network dependencies,
• secrets/config,
• job semantics.

Nếu platform không có contract, nó không thể vận hành workload an toàn.

12. Multi-tenancy và isolation

Kubernetes docs nói multi-tenancy không có một định nghĩa duy nhất; hai cách chia sẻ cluster phổ biến là namespace per tenant hoặc virtualizing control plane per tenant.[^k8s-multitenancy]

PaaS tenant có thể là:

• organization/customer,
• internal team,
• product group,
• app,
• environment,
• project/space.

12.1. Isolation layers

Cần xét:

Identity/RBAC isolation

API/control plane isolation

Namespace/project isolation

Node/runtime isolation

Network isolation

Secret isolation

Image/build isolation

Service binding isolation

Log/metrics isolation

Cost/quota isolation

Không đủ nếu chỉ:

namespace per team

12.2. Soft vs hard multi-tenancy

Soft multi-tenancy:

• teams cùng tổ chức,
• mức trust tương đối cao,
• namespace/RBAC/quota/network policy đủ cho nhiều case.

Hard multi-tenancy:

• tenants không tin nhau,
• public customers,
• regulated workloads,
• hostile code possibility.

Hard multi-tenancy cần:

• dedicated clusters/virtual clusters,
• stronger runtime sandbox,
• network isolation,
• separate node pools,
• stricter admission,
• per-tenant secrets/KMS,
• limited Kubernetes API access.

Kubernetes docs nhấn mạnh hard multi-tenancy thường liên quan tenants không tin nhau và containers chia sẻ kernel nên không mạnh như VM isolation.[^k8s-multitenancy]

12.3. Resource quotas

ResourceQuota giới hạn lượng resources namespace có thể dùng và số lượng objects theo API kind.[^k8s-resource-quota]

PaaS cần quota theo:

• apps,
• instances,
• CPU/memory,
• storage,
• routes/domains,
• build minutes,
• logs retention,
• bandwidth/egress,
• service instances,
• job concurrency.

Quota không chỉ để cost. Quota để chống platform abuse/noisy neighbor.

13. Routing, ingress và traffic management

PaaS phải biến app thành endpoint an toàn:

domain

-> DNS

-> TLS certificate

-> ingress/router

-> route mapping

-> load balancing

-> app instances

Cloud Foundry Gorouter route HTTP traffic tới app/component phù hợp.[^cf-routing]

Knative Serving quản lý route/config/revision và hỗ trợ traffic splitting giữa revisions.[^knative-traffic]

13.1. Routing concerns

Cần:

• custom domains,
• wildcard domains,
• TLS automation,
• route ownership,
• path/host routing,
• blue/green/canary,
• sticky sessions nếu legacy cần,
• websocket/long-lived connections,
• rate limits,
• WAF/security headers,
• mTLS/service mesh nếu internal,
• zero-downtime route switch.

13.2. Route là resource có ownership

Không nên để team tự do claim domain/path tùy ý.

Cần:

• route registry,
• conflict detection,
• domain ownership verification,
• certificate lifecycle,
• audit,
• policy per environment.

14. Deployment, GitOps và reconciliation

Argo CD là declarative GitOps continuous delivery tool cho Kubernetes.[^argo-cd]

Flux dùng Kubernetes API extensions/controllers để sync desired state từ Git/OCI/other sources vào cluster.[^flux]

PaaS cần quyết định:

source of truth là API/platform database,

hay Git desired state,

hay hybrid?

14.1. API-driven PaaS

Developer gọi:

paas deploy app

Platform tạo desired state nội bộ.

Ưu:

• UX đơn giản.
• Platform che giấu Kubernetes/IaC.
• Dễ implement Heroku-style.

Nhược:

• audit/versioning desired state phải tự xây.
• khó integrate với GitOps org.

14.2. GitOps-driven PaaS

Developer thay đổi repo/config, controller reconcile.

Ưu:

• desired state versioned.
• audit qua Git.
• dễ review/promotion.
• drift detection.

Nhược:

• developer phải hiểu repo structure.
• secret/config khó hơn.
• rollback/migration cần thiết kế.
• platform action async, UX cần tốt.

14.3. Hybrid

Portal/API tạo PR hoặc commit vào desired-state repo.

Đây thường là hướng tốt:

self-service UX + Git audit + controller reconciliation

Đánh đổi:

• cần orchestration phức tạp hơn,
• cần trạng thái pending/succeeded/failed rõ,
• cần rollback nếu Git merge thành công nhưng reconcile fail.

15. Progressive delivery và rollback

PaaS không chỉ "apply manifest".

Cần:

• canary,
• blue/green,
• rolling update,
• traffic splitting,
• health gate,
• automatic rollback,
• manual approval,
• environment promotion,
• release freeze,
• migration compatibility,
• feature flag integration.

15.1. Rollback không luôn dễ

Rollback code dễ hơn rollback data.

Cần:

• backward-compatible schema,
• expand/contract migration,
• release phase job,
• idempotent migration,
• data rollback plan,
• feature flags,
• versioned APIs.

Nếu PaaS cho deploy nhanh nhưng không có migration discipline, incident sẽ đến từ database.

16. Service marketplace và service binding

Open Service Broker API cho phép ISV/SaaS providers/developers cung cấp backing services cho workloads trên platforms như Cloud Foundry hoặc Kubernetes; service broker có lifecycle commands thống nhất.[^osbapi]

Cloud Foundry tích hợp services qua Service Broker API, Cloud Controller là client của broker.[^cf-services]

Service lifecycle:

catalog

-> provision

-> bind

-> update

-> unbind

-> deprovision

16.1. Service binding là gì?

App cần dùng database/cache/queue/object storage.

Platform cần:

• provision service instance,
• tạo credentials,
• inject config/secrets vào app,
• rotate credentials,
• revoke khi unbind,
• track ownership/cost,
• backup/restore policy,
• expose connection info an toàn.

16.2. Service broker pitfalls

• broker provision thành công nhưng app bind fail,
• credential rotation không có,
• service plan không match quota,
• delete app nhưng service orphan,
• backup/restore không rõ,
• network access không mở,
• secrets leak vào logs/env dump,
• broker API idempotency yếu.

PaaS tốt phải coi services là first-class lifecycle, không phải external docs link.

17. Infrastructure provisioning và Crossplane/control planes

Crossplane mô tả Compositions như template để tạo nhiều Kubernetes resources thành một composite resource; Crossplane dùng managed resources/providers để quản lý cloud resources.[^crossplane-compositions]

Bài học:

PaaS hiện đại thường là control plane của nhiều control plane.

Nó không trực tiếp tạo mọi thứ bằng script. Nó khai báo desired state:

• app,
• database,
• bucket,
• queue,
• DNS,
• IAM,
• secret,
• monitoring,

rồi controllers reconcile.

Đánh đổi:

• declarative control plane mạnh,
• nhưng debugging reconciliation khó hơn imperative script.

Cần:

• status conditions rõ,
• event trail,
• dependency graph,
• retry/backoff,
• timeout,
• drift detection,
• ownership/finalizers.

18. Config và secrets

Twelve-Factor nói config nên nằm trong environment, tách khỏi code.[^heroku-12factor]

Nhưng PaaS hiện đại cần tinh tế hơn:

• env vars phù hợp simple config,
• secrets nên có secret manager/KMS,
• file mounts cho cert/key khi cần,
• dynamic secrets cho database/cloud credentials,
• secret rotation,
• access audit,
• redaction trong logs,
• per-environment config,
• config version/release binding.

18.1. Secrets pitfalls

• secrets trong build logs,
• secrets baked into image,
• secrets commit vào Git,
• secrets xuất hiện trong crash dump,
• env var bị expose qua debug endpoint,
• shared secret giữa apps,
• rotation phá app vì không reload,
• secret không bị xóa khi app bị xóa.

Nguyên tắc:

Build không nên cần production secrets.

Runtime secret access phải scoped, auditable và rotatable.

19. Autoscaling

Kubernetes HPA tự động scale workload theo metrics như CPU/memory/custom metrics.[^k8s-hpa]

Knative Serving hỗ trợ autoscaling theo incoming demand và có thể scale to zero khi không có traffic.[^knative-autoscaling]

KEDA hỗ trợ event-driven autoscaling cho workloads dựa trên external event sources/queues.[^keda]

19.1. Autoscaling modes

19.2. Autoscaling traps

• CPU không phản ánh latency.
• scale-to-zero gây cold start.
• node autoscaler chậm hơn app autoscaler.
• DB/backend không scale theo app.
• queue backlog scale quá mạnh làm downstream chết.
• autoscaling oscillation.
• tenant noisy làm scale toàn pool.
• không có min/max bounds.

PaaS phải cung cấp sane defaults và workload-specific scaling templates.

20. Observability

OpenTelemetry là vendor-neutral observability framework để instrument, generate, collect và export traces, metrics, logs.[^opentelemetry]

PaaS cần hai lớp observability:

App observability:

developer thấy app logs, traces, metrics, errors, deploy history.

Platform observability:

platform team thấy scheduler, router, builders, queues, brokers, controllers, nodes, policy, costs.

20.1. Developer-facing observability

Developer cần:

• logs realtime/historical,
• request traces,
• error rate,
• latency,
• instance health,
• resource usage,
• deployment events,
• release diff,
• config version,
• route errors,
• autoscaling decisions,
• service binding health.

Không nên trả lời mọi lỗi bằng:

kubectl logs pod-xyz

Developer không nên cần biết pod name để debug app cơ bản.

20.2. Platform SLO

PaaS có SLO riêng:

• build success/failure latency,
• deploy latency,
• routing availability,
• control plane API availability,
• scheduler pending time,
• log ingestion lag,
• metrics freshness,
• service broker latency,
• autoscaling reaction time,
• platform incident MTTR.

Google SRE dùng SLO/error budget để cân bằng reliability và release velocity.[^google-sre-slo]

20.3. DORA metrics

DORA metrics giúp đo delivery performance: deployment frequency, lead time for changes, change failure rate và failed deployment recovery time.[^dora-metrics]

PaaS nên giúp cải thiện DORA, nhưng không được optimize hình thức:

• deploy nhiều nhưng fail nhiều là xấu,
• lead time ngắn nhưng change risky là xấu,
• MTTR thấp nhưng incident nhiều là xấu.

21. Security và hardening

NIST SP 800-190 là Application Container Security Guide, tập trung rủi ro container image, registry, orchestrator, host OS và runtime.[^nist-container]

NSA/CISA Kubernetes Hardening Guidance nêu các phức tạp khi secure Kubernetes và khuyến nghị hardening cho deployment/management.[^nsa-cisa-k8s]

PaaS security phải cover:

• source/build pipeline,
• artifact registry,
• admission control,
• runtime sandbox,
• network policy,
• secrets,
• IAM/RBAC,
• tenant isolation,
• logs/data leakage,
• admin access,
• vulnerability response.

21.1. Admission control

Kubernetes admission controllers có thể validate/mutate requests trước khi object tồn tại; Kubernetes docs cũng ghi ResourceQuota admission controller phải enabled nếu dùng ResourceQuota.[^k8s-admission]

OPA/Gatekeeper và Kyverno là hai hướng policy-as-code/admission phổ biến; Kyverno nhận AdmissionReview callback từ Kubernetes API server và enforce policies.[^opa-gatekeeper][^kyverno]

Policy nên chặn:

• privileged containers,
• hostPath tùy tiện,
• hostNetwork/hostPID,
• running as root,
• latest image tag,
• unsigned images,
• missing resource requests/limits,
• public ingress không policy,
• secrets từ namespace khác,
• unsafe capabilities,
• missing labels/owner/cost center.

21.2. Pod Security Standards

Kubernetes Pod Security Standards định nghĩa các policy levels như Privileged, Baseline, Restricted.[^pod-security-standards]

PaaS nên mặc định:

restricted/baseline cho app thường,

privileged chỉ cho platform components có review.

21.3. Sandbox choice

Runtime isolation options:

• container default runtime,
• gVisor/Kata/Firecracker-style sandbox,
• VM per tenant,
• cluster per tenant,
• dedicated node pool.

Đánh đổi:

• container rẻ/nhanh nhưng isolation yếu hơn VM,
• sandbox/VM an toàn hơn nhưng cold start/cost/ops cao hơn.

22. Policy và governance

PaaS cần policy ở nhiều điểm:

create app

build

deploy

provision service

expose route

scale

access secret

run one-off task

delete app

Policy không nên chỉ nằm trong docs.

Cần:

• policy-as-code,
• admission checks,
• runtime checks,
• audit logs,
• exception workflow,
• policy versioning,
• ownership metadata,
• compliance reports.

22.1. Golden path vs guardrail

Golden path:

• template tạo service chuẩn,
• buildpack chuẩn,
• default alerts,
• default autoscaling,
• default security.

Guardrail:

• chặn deploy thiếu owner,
• chặn app không resource limits,
• chặn public route thiếu auth,
• chặn image chưa scan,
• chặn privileged pod.

Escape hatch:

• cho use case đặc biệt,
• cần approval,
• có expiration,
• có audit.

23. Developer experience

PaaS là product cho developer.

Developer experience tốt không phải UI đẹp. Nó là:

• time-to-first-deploy ngắn,
• failure message rõ,
• self-service thật,
• docs đúng tại chỗ,
• paved road,
• local/prod parity,
• debug dễ,
• templates chuẩn,
• không bắt developer học mọi low-level tool,
• escape hatch khi cần.

23.1. Developer portal

Backstage Software Catalog giữ ownership/metadata cho software ecosystem.[^backstage-catalog]

Portal nên có:

• service catalog,
• ownership,
• health,
• docs,
• APIs,
• dependencies,
• deployments,
• logs/traces links,
• cost/quota,
• templates,
• self-service actions,
• runbooks,
• scorecards.

Nhưng portal không thay platform engine.

23.2. CLI/API

PaaS nên có:

• CLI cho dev workflow nhanh,
• API cho automation,
• portal cho discovery/ops,
• GitOps mode cho governance.

Không nên chỉ có UI.

24. Cost và quota

PaaS giấu hạ tầng khỏi developer, nhưng không được giấu cost khỏi tổ chức.

Cần:

• cost per app/team/project,
• build minutes,
• CPU/memory requested vs used,
• idle resources,
• egress,
• logs/metrics cost,
• storage,
• service instances,
• orphaned resources,
• environments left running,
• GPU/AI cost.

24.1. Quota là product feature

Quota cần:

• org/team quota,
• app quota,
• environment quota,
• service plan quota,
• burst limits,
• build concurrency,
• route/domain quota,
• log retention quota.

Quota UX phải rõ:

Bạn vượt quota vì X.

Đề xuất: scale down Y, tăng quota, hoặc upgrade plan.

Không nên để developer chỉ thấy "deployment failed".

25. State và data trong PaaS

PaaS thích stateless app, nhưng platform thực tế phải hỗ trợ state.

State categories:

• app config,
• secrets,
• persistent volumes,
• managed databases,
• object storage,
• queues,
• caches,
• backups,
• migrations,
• environment data.

Nguyên tắc:

App runtime nên stateless khi có thể.

Stateful services nên được quản lý qua service broker/control plane rõ ràng.

Sai lầm:

• lưu file local trong container,
• deploy app stateful không backup,
• scale app có local state,
• delete app làm orphan database,
• backup không gắn với app/environment.

26. Environments và promotion

PaaS cần model môi trường:

dev

preview/review

staging

production

region/cell

tenant-specific env

Câu hỏi khó:

• preview env tạo/xóa thế nào?
• data seed/masking?
• secrets khác nhau ra sao?
• production promotion có build lại hay promote artifact?
• config drift giữa env?
• migration chạy ở env nào?
• approval cho prod?

Nguyên tắc:

Build một lần, promote artifact nhiều môi trường.

Config/release thay đổi theo môi trường.

27. Critical flows

27.1. Create app

Developer chọn template

-> platform tạo repo/app record

-> tạo ownership metadata

-> tạo pipeline/build config

-> tạo environments

-> set default policies

-> tạo routes nội bộ

-> tạo observability dashboard

-> tạo runbook/docs skeleton

27.2. Deploy app

Commit/source

-> build

-> scan/sign/provenance

-> create release

-> policy check

-> deploy desired state

-> scheduler places workload

-> route traffic

-> health gates

-> exposure/log release event

27.3. Bind service

Developer request database

-> check entitlement/quota

-> provision via broker/control plane

-> create credentials

-> inject secret/config

-> update release

-> app restarts/rolls if needed

-> record dependency/cost/backup policy

27.4. Rollback

Incident detected

-> identify bad release

-> check migration compatibility

-> shift traffic/redeploy previous release

-> preserve logs/events

-> mark release failed

-> postmortem/action items

27.5. App deletion

Delete app request

-> verify owner/policy

-> stop route

-> stop workloads/jobs

-> archive logs/audit

-> handle services: retain/delete/export

-> delete secrets

-> clean DNS/certs

-> update catalog/cost

28. SOTA/practice theo lớp

29. Những bẫy senior phải tránh

29.1. Bẫy "Kubernetes là PaaS"

Kubernetes là platform primitive/control plane cho containers. Nó không tự động cho bạn:

• developer portal,
• golden path,
• build/release lifecycle,
• service marketplace,
• app-level SLO,
• cost per app,
• support UX,
• safe defaults.

29.2. Bẫy "portal là platform"

Backstage/catalog rất hữu ích, nhưng nếu mọi action vẫn là ticket/manual script, đó không phải PaaS.

29.3. Bẫy "để developer tự viết YAML"

Nếu mỗi team copy Deployment/Ingress/Secret/HPA:

• security drift,
• resource drift,
• observability drift,
• cost drift,
• incident khó xử lý.

PaaS cần app abstraction hoặc templates có guardrails.

29.4. Bẫy "build thành công là deploy thành công"

Build chỉ tạo artifact.

Deploy còn cần:

• policy pass,
• secrets/config,
• scheduling,
• health checks,
• route,
• migrations,
• downstream services.

29.5. Bẫy "secrets qua env là xong"

Env vars tiện nhưng không giải quyết:

• rotation,
• audit,
• redaction,
• dynamic credentials,
• least privilege,
• secret exposure qua debug.

29.6. Bẫy "multi-tenancy chỉ là namespace"

Namespace không đủ cho hard multi-tenancy.

Cần xét control plane access, node/runtime isolation, network, secrets, logs, resource quotas và trust model.

29.7. Bẫy "autoscaling sẽ tự cứu"

Autoscaling sai signal có thể làm incident tệ hơn.

29.8. Bẫy "policy chỉ là docs"

Docs không chặn deploy privileged container.

Policy phải enforce ở admission/control plane.

29.9. Bẫy "platform team là ticket team"

Platform engineering đúng là product engineering.

Nếu platform team chỉ nhận ticket tạo resource, PaaS chưa thành công.

30. Roadmap xây PaaS thực dụng

Phase 0: Platform product framing

• Chọn user: app teams, data teams, ML teams, external customers?
• Chọn workloads: web, worker, cron, batch, AI, functions?
• Chọn trust model: internal soft multi-tenant hay customer hard multi-tenant?
• Chọn abstraction: app model hay raw Kubernetes?
• Chọn golden paths.
• Chọn compliance/security baseline.

Phase 1: Runtime foundation

• Cluster/runtime/cell model.
• App registry.
• Namespace/project model.
• Routing/domain/TLS.
• Logs.
• Basic deploy/rollback.
• Quotas.
• RBAC.

Phase 2: Build/release foundation

• Buildpacks/template Dockerfile.
• Artifact registry.
• Release object.
• Image scanning.
• Config/secrets.
• Health checks.
• Deployment history.

Phase 3: Developer self-service

• Portal/catalog.
• CLI/API.
• Service templates.
• Golden path creation.
• Environment creation.
• Docs/runbooks.
• Ownership metadata.

Phase 4: Services and bindings

• Service catalog.
• Broker/Crossplane provisioning.
• Credential injection.
• Backup/restore policy.
• Cost tracking.
• Orphan cleanup.

Phase 5: Guardrails and supply chain

• Admission policy.
• Pod Security Standards.
• Image signing/provenance.
• SBOM.
• Secret scanning.
• Network policies.
• Exception workflow.

Phase 6: Advanced delivery and operations

• GitOps/hybrid reconciliation.
• Canary/blue-green.
• Autoscaling templates.
• SLO dashboards.
• Incident/runbook integration.
• DORA metrics.
• Cost/showback.

Phase 7: Multi-tenancy hardening

• Virtual clusters or cluster-per-tenant for hard cases.
• Cell-based architecture.
• Tenant/app isolation tiers.
• Dedicated node pools.
• Runtime sandbox.
• Region/data residency.

31. Architecture review checklist cho PaaS

32. Mô hình tư duy riêng cho PaaS

Nếu dùng lens riêng cho PaaS, tôi đề xuất 12 lens:

1. Developer-product lens: developer cần làm gì nhanh hơn, ít cognitive load hơn?

2. Lifecycle lens: source -> build -> release -> run -> observe -> retire ra sao?

3. Abstraction lens: app model che gì, expose gì, escape hatch ở đâu?

4. Runtime lens: workload được schedule/run/scale/heal thế nào?

5. Tenancy lens: team/customer/app/environment được cô lập ra sao?

6. Service lens: backing services provision/bind/rotate/backup/delete thế nào?

7. Delivery lens: deploy, promote, canary, rollback, migration thế nào?

8. Security lens: supply chain, admission, secrets, network, runtime sandbox thế nào?

9. Observability lens: developer và platform team debug bằng gì?

10. Policy lens: guardrails enforce ở đâu, exception thế nào?

11. Cost lens: quota/showback/idle cleanup theo team/app ra sao?

12. Evolution lens: platform mở rộng workload/provider/region mà không thành spaghetti thế nào?

33. Kết luận

PaaS trưởng thành không phải là hạ tầng được bọc UI.

Nó là:

developer product

+ application lifecycle engine

+ runtime abstraction

+ service marketplace

+ policy guardrails

+ observability

+ security/supply-chain controls

+ operations/cost governance

Kiến trúc nên đi từ:

developer workflows

-> app lifecycle

-> control plane

-> runtime/scheduler/routing

-> build/release/supply chain

-> services/secrets/config

-> observability/security/policy

-> cost/governance/evolution

chứ không đi từ:

Kubernetes cluster + deploy YAML + portal

Câu chốt:

PaaS tốt làm cho cách đúng trở thành cách dễ nhất,

và làm cho cách nguy hiểm bị chặn trước khi vào production.

34. Nguồn tham khảo

[^nist-paas]: NIST, "SP 800-145: The NIST Definition of Cloud Computing": https://csrc.nist.gov/pubs/sp/800/145/final [^cf-overview]: Cloud Foundry Docs, "Cloud Foundry overview": https://docs.cloudfoundry.org/concepts/overview.html [^cf-diego]: Cloud Foundry Docs, "Diego components and architecture": https://docs.cloudfoundry.org/concepts/diego/diego-architecture.html [^cf-routing]: Cloud Foundry Docs, "Cloud Foundry routing architecture": https://docs.cloudfoundry.org/concepts/cf-routing-architecture.html [^cf-services]: Cloud Foundry Docs, "Services": https://docs.cloudfoundry.org/services/overview.html [^heroku-12factor]: Heroku, "Building Twelve-Factor Apps on Heroku": https://www.heroku.com/blog/twelve-factor-apps/ [^heroku-dynos-build]: Heroku, "Dynos - Build Process": https://www.heroku.com/dynos/build/ [^app-engine-standard]: Google Cloud, "App Engine standard environment docs": https://cloud.google.com/appengine/docs/standard [^cncf-platform-maturity]: CNCF TAG App Delivery, "Platform Engineering Maturity Model": https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/ [^backstage-catalog]: Backstage Docs, "Software Catalog": https://backstage.io/docs/features/software-catalog/ [^cnb-buildpack-api]: Cloud Native Buildpacks, "Buildpack API": https://buildpacks.io/docs/reference/spec/buildpack-api/ [^slsa]: SLSA, "Supply-chain Levels for Software Artifacts": https://slsa.dev/ [^k8s-scheduler]: Kubernetes Docs, "Kubernetes Scheduler": https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/ [^k8s-multitenancy]: Kubernetes Docs, "Multi-tenancy": https://kubernetes.io/docs/concepts/security/multi-tenancy/ [^k8s-resource-quota]: Kubernetes Docs, "Resource Quotas": https://kubernetes.io/docs/concepts/policy/resource-quotas/ [^knative-traffic]: Knative Docs, "Traffic management": https://knative.dev/docs/serving/traffic-management/ [^argo-cd]: Argo CD GitHub, "Declarative Continuous Deployment for Kubernetes": https://github.com/argoproj/argo-cd [^flux]: Flux Docs, "Flux Documentation": https://fluxcd.io/flux/ [^osbapi]: Open Service Broker API, "Open Service Broker": https://www.openservicebrokerapi.org/ [^crossplane-compositions]: Crossplane Docs, "Compositions": https://docs.crossplane.io/latest/composition/compositions/ [^k8s-hpa]: Kubernetes Docs, "Horizontal Pod Autoscaling": https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/ [^knative-autoscaling]: Knative Docs, "About autoscaling": https://knative.dev/docs/serving/autoscaling/ [^keda]: KEDA Docs, "KEDA - Kubernetes Event-driven Autoscaling": https://keda.sh/docs/ [^opentelemetry]: OpenTelemetry Docs, "Documentation": https://opentelemetry.io/docs/ [^google-sre-slo]: Google SRE, "Service Level Objectives": https://sre.google/sre-book/service-level-objectives/ [^dora-metrics]: DORA, "DORA's software delivery performance metrics": https://dora.dev/guides/dora-metrics/ [^nist-container]: NIST, "SP 800-190: Application Container Security Guide": https://csrc.nist.gov/pubs/sp/800/190/final [^nsa-cisa-k8s]: CISA, "CISA and NSA Release Kubernetes Hardening Guidance": https://www.cisa.gov/news-events/alerts/2021/08/02/cisa-and-nsa-release-kubernetes-hardening-guidance [^k8s-admission]: Kubernetes Docs, "Admission Controllers": https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/ [^opa-gatekeeper]: Open Policy Agent, "OPA Gatekeeper": https://www.openpolicyagent.org/ecosystem/entry/gatekeeper [^kyverno]: Kyverno Docs, "How Kyverno works": https://kyverno.io/docs/introduction/how-kyverno-works/ [^pod-security-standards]: Kubernetes Docs, "Pod Security Standards": https://kubernetes.io/docs/concepts/security/pod-security-standards/