title: "Cloud-Native Architecture: Tận dụng tối đa tài nguyên Cloud thay vì chỉ "nhấc" code lên Cloud (Lift-and-Shift)"
series: "Software Architecture Masterclass"
part: "Phần 3 — Hệ thống Phân tán & Hạ tầng"
order: 30
audience: "Solutions Architect & Technical Lead"
reading_time: "15 phút"
tags: ["cloud-native", "lift-and-shift", "containers", "auto-scaling", "managed-services", "cloud-migration"]

Cloud-Native Architecture: Tận dụng tối đa tài nguyên Cloud thay vì chỉ "nhấc" code lên Cloud (Lift-and-Shift)

Một công ty vừa hoàn thành "dự án chuyển đổi cloud" sau sáu tháng. Slide tổng kết cho ban điều hành ghi rõ: 40 VM đã di chuyển từ hai trung tâm dữ liệu on-premise lên AWS EC2, downtime migration dưới 2 giờ, không mất dữ liệu. Ăn mừng, đóng dự án, chuyển đội sang việc khác. Mười tám tháng sau, hóa đơn cloud hàng tháng cao hơn chi phí vận hành data center cũ 35%, mà hệ thống vẫn sập đúng kiểu cũ mỗi khi có traffic spike vào đợt khuyến mãi — vì các VM vẫn được cấu hình cứng theo capacity đỉnh, y hệt cách nó được sizing cho on-premise mười năm trước, chỉ là giờ chạy trên hạ tầng thuê theo giờ thay vì mua đứt.

Đây không phải sự cố kỹ thuật. Đây là hệ quả tất yếu của một ngộ nhận kiến trúc: coi "chuyển lên cloud" là một bài toán logistics (di chuyển máy ảo từ nơi này sang nơi khác) thay vì một bài toán kiến trúc (thiết kế lại hệ thống để khai thác mô hình vận hành mà cloud cung cấp). Lift-and-shift — di chuyển nguyên xi VM, OS, cấu hình, kiến trúc monolith stateful lên cloud provider mà không sửa gì — là con đường nhanh nhất để nói "chúng tôi đã lên cloud" và cũng là con đường chắc chắn nhất để trả tiền cloud cho hạ tầng vận hành như on-premise, tức là trả giá cao hơn cho đúng những nhược điểm mà cloud lẽ ra phải xóa bỏ.

Bài này không nói lift-and-shift là sai tuyệt đối — trong nhiều tình huống áp lực thời gian, nó là lựa chọn hợp lý duy nhất. Vấn đề là khi tổ chức coi nó là đích đến thay vì một bước quá độ, và không bao giờ quay lại để trả nợ kiến trúc đó.

The Problem

Sức ép "lên cloud" thường đến từ hợp đồng data center hết hạn, sức ép cắt CAPEX chuyển sang OPEX, hoặc chỉ thị từ ban điều hành muốn "modernize" trong một mốc thời gian cụ thể. Áp lực đó tạo ra một lựa chọn có vẻ an toàn: rehost — dùng công cụ migration (ví dụ AWS Application Migration Service, Azure Migrate hoặc tương đương) để sao chép nguyên trạng VM, giữ nguyên OS, giữ nguyên ứng dụng, giữ nguyên cách nó vận hành, chỉ đổi nơi nó chạy. Về mặt dự án, đây là lựa chọn thắng: rủi ro thấp, thời gian ngắn, không đụng vào logic ứng dụng, không cần re-test toàn bộ nghiệp vụ.

Nhưng cloud không phải là "một data center khác cho thuê". Giá trị cốt lõi của cloud nằm ở mô hình thanh toán theo tài nguyên tiêu thụ thực tế (pay-as-you-go) kết hợp khả năng co giãn hạ tầng theo yêu cầu (elasticity) và một tầng managed service đã giải quyết sẵn phần lớn bài toán vận hành hạ tầng (patching OS, replication, failover, backup). Một VM lift-and-shift chạy 24/7 ở kích thước cố định (provisioned cho tải đỉnh, vì không ai dám giảm size khi không biết traffic pattern thật) không thu được bất kỳ lợi ích nào trong số đó. Nó vẫn trả tiền 24/7 cho capacity đỉnh — chỉ khác là giá theo giờ của cloud, cộng phí egress network, cộng phí storage gắn kèm, thường đắt hơn chi phí biên của phần cứng đã khấu hao ở on-premise.

Vấn đề kiến trúc thật sự: hệ thống được thiết kế cho một thế giới nơi hạ tầng là tài sản cố định, dài hạn (bạn mua server, nó tồn tại nhiều năm, bạn tối ưu cho việc dùng hết công suất đã mua) bị đặt vào một thế giới nơi hạ tầng là tài nguyên phù du, theo yêu cầu (bạn trả tiền cho từng giây sử dụng, kiến trúc lý tưởng là scale lên khi cần và scale về 0 khi không cần). Không sửa kiến trúc để khớp với mô hình vận hành mới, bạn nhận lấy chi phí vận hành của mô hình cũ cộng thêm premium giá của mô hình mới.

The Theory

Cloud-native là gì — không phải "chạy trên cloud"

Cloud-native không có nghĩa là ứng dụng chạy trên hạ tầng của một cloud provider. Nó là một tập nguyên tắc thiết kế để khai thác đúng những gì cloud cung cấp mà on-premise không thể (hoặc rất tốn kém để tự xây):

Ứng dụng là phù du (ephemeral), hạ tầng là tài nguyên có thể tạo/hủy theo yêu cầu. Thay vì coi một server là thực thể lâu dài cần được chăm sóc, giữ gìn, patch tại chỗ, cloud-native coi mỗi instance chạy ứng dụng là có thể bị hủy và thay thế bất kỳ lúc nào mà không ảnh hưởng tính đúng đắn của hệ thống. Điều kiện tiên quyết cho việc này: stateless compute — tiến trình xử lý request không giữ trạng thái nghiệp vụ trong bộ nhớ hay đĩa cục bộ; mọi state cần bền vững được đẩy ra một managed store (database, object storage, cache phân tán).
Đóng gói bằng container, không phải VM. Container (Docker và tương đương) đóng gói ứng dụng cùng dependency ở granularity nhỏ hơn nhiều so với VM — khởi động trong giây thay vì phút, mật độ đóng gói trên một node vật lý cao hơn, và cùng một image chạy giống hệt nhau qua các môi trường. Đây là điều kiện hạ tầng để auto-scaling thực sự nhanh và rẻ.
Managed service thay cho tự vận hành hạ tầng. Thay vì tự cài, patch, backup, failover một database trên VM tự quản, cloud-native dùng managed database (RDS, Cloud SQL và tương đương), managed message queue, managed cache. Nhà cung cấp cloud chịu trách nhiệm vận hành tầng hạ tầng đó — đổi lại bạn trả premium cho sự tiện lợi và mất một phần quyền kiểm soát cấu hình sâu.
Auto-scaling theo tín hiệu tải thực tế, không phải theo capacity đỉnh cố định. Hệ thống co giãn số lượng instance chạy dựa trên CPU, số request, độ dài queue — trả tiền gần đúng cho tải thực tế thay vì trả tiền cố định cho tải đỉnh dự phòng quanh năm.
Tách trạng thái khỏi compute một cách triệt để, để mỗi thành phần compute có thể scale độc lập, tự phục hồi độc lập.

Vì sao lift-and-shift không đạt được các thuộc tính trên

Một VM lift-and-shift, dù chạy trên EC2 hay Azure VM, vẫn giữ nguyên các đặc điểm on-premise: OS đầy đủ phải patch thủ công, ứng dụng có thể lưu state cục bộ (session, file upload, cache in-memory không đồng bộ giữa các instance), và vì migration coi mục tiêu là "giữ nguyên hành vi", không ai dám bật auto-scaling thật (vì instance không stateless, scale ra rồi scale vào có thể làm mất dữ liệu phiên). Kết quả: VM chạy cố định 24/7 ở kích thước ước tính cho tải đỉnh — chính là mô hình capacity planning tĩnh của on-premise, chỉ đổi nơi hóa đơn được gửi tới.

Con đường di chuyển: 6 chữ R

Mô hình phổ biến để nói về mức độ tái kiến trúc khi lên cloud có sáu chiến lược, thường gọi là "6 R": Rehost (lift-and-shift thuần túy), Replatform (đổi nhỏ, ví dụ chuyển database tự quản sang managed database mà không đổi code ứng dụng), Repurchase (thay bằng SaaS), Refactor/Re-architect (tái thiết kế thành container + managed service + stateless), Retire (loại bỏ hệ thống không còn cần), Retain (giữ nguyên tại chỗ, không di chuyển). Điểm quan trọng: đây không phải một lựa chọn nhị phân "lift-and-shift hay cloud-native" cho toàn bộ hệ thống — một tổ chức trưởng thành áp dụng các chiến lược khác nhau cho từng thành phần tùy độ nhạy cảm về chi phí và quy mô của thành phần đó.

The Trade-off

Đây là phần phải rõ ràng, không mập mờ giữa hai lựa chọn.

Lift-and-shift — được gì:

Tốc độ di chuyển nhanh nhất có thể (tuần, không phải quý), vì không đụng vào logic ứng dụng, không cần re-test nghiệp vụ, không cần đội ngũ học stack mới.
Rủi ro migration thấp — hành vi ứng dụng gần như không đổi, dễ rollback, dễ verify tương đương chức năng.
Đáp ứng được deadline cứng (hết hợp đồng data center, chỉ thị compliance, sức ép đóng cửa cơ sở vật lý) mà không cần re-engineering trước.

Lift-and-shift — mất gì, cụ thể:

Chi phí liên tục cao hơn, không phải một lần. VM chạy 24/7 ở size cố định cho tải đỉnh nghĩa là bạn trả tiền cloud cho capacity nhàn rỗi phần lớn thời gian trong ngày — điều mà on-premise "miễn phí" (phần cứng đã mua, không trả thêm khi nhàn rỗi) nhưng cloud tính phí theo giờ chạy. Đây là chi phí lặp lại vĩnh viễn, không phải chi phí dự án một lần.
Không có auto-scaling thật, vì kiến trúc không cho phép. Ứng dụng stateful, session lưu cục bộ, không thể scale ra/vào an toàn — nghĩa là hệ thống vẫn sập theo đúng cách cũ khi traffic vượt ngưỡng đã sizing, chỉ khác là bây giờ sập trên hạ tầng đắt hơn.
Vẫn gánh toàn bộ gánh nặng vận hành hạ tầng như on-premise — tự patch OS, tự cấu hình HA cho database chạy trên VM, tự viết script backup — nhưng không còn lợi thế "đã khấu hao phần cứng" để bù lại. Bạn trả premium managed-cloud-provider cho một mô hình vận hành self-managed.
Nợ kiến trúc bị che giấu, không bị xóa. Vì migration "thành công" theo tiêu chí dự án (di chuyển xong, không downtime), tổ chức dễ coi đây là điểm kết thúc, ngân sách và động lực để tái kiến trúc dần biến mất — nợ kỹ thuật vẫn còn nguyên, chỉ là không còn ai cảm thấy khẩn cấp phải trả.

Cloud-native (refactor) — được gì:

Chi phí bám sát tải thực tế: auto-scaling co vào giờ thấp điểm, scale ra khi cần, trả tiền gần đúng cho những gì thực sự dùng.
Managed service loại bỏ phần lớn công việc vận hành hạ tầng cấp thấp (patch OS database, cấu hình replication, failover) — đội kỹ thuật tập trung vào logic nghiệp vụ thay vì giữ máy chủ sống.
Container hóa cho tốc độ triển khai nhanh hơn, môi trường nhất quán dev/staging/production, mật độ tài nguyên cao hơn trên cùng một node vật lý (giảm chi phí compute nền).
Khả năng phục hồi tốt hơn: vì compute là phù du và stateless, một instance chết không làm mất dữ liệu, orchestrator tự thay thế instance mới mà không cần can thiệp thủ công.

Cloud-native — mất gì, cụ thể:

Đầu tư re-engineering thật, không phải cấu hình lại. Tách state ra khỏi compute, đưa session vào cache phân tán hoặc token, đưa file upload ra object storage, tách monolith thành các thành phần có thể scale độc lập — đây là công việc code, không phải công việc hạ tầng, và cần re-test toàn bộ đường nghiệp vụ liên quan.
Thời gian và rủi ro migration cao hơn nhiều lần so với rehost — tính bằng tháng hoặc quý, không phải tuần, và có rủi ro thay đổi hành vi ứng dụng (bug mới sinh ra từ việc tách state, từ việc container hóa dependency cũ).
Khóa chặt hơn vào managed service của một nhà cung cấp cụ thể (vendor lock-in) — dùng managed database, managed queue, managed identity của một cloud provider nghĩa là logic ứng dụng và vận hành gắn với API/hành vi riêng của provider đó, chi phí chuyển đổi nhà cung cấp sau này cao hơn so với tự vận hành mọi thứ trên VM thuần.
Đòi hỏi năng lực đội ngũ mới — vận hành container orchestration, thiết kế cho failure, debug hệ thống phân tán stateless đòi hỏi kỹ năng khác với vận hành VM truyền thống; nếu đội chưa có năng lực này, refactor vội vàng tạo ra một hệ thống cloud-native nửa vời còn khó vận hành hơn cả VM cũ.

Nói ngắn gọn: lift-and-shift đổi tốc độ và rủi ro migration thấp lấy chi phí vận hành cao liên tục và bỏ lỡ toàn bộ lợi ích co giãn của cloud. Cloud-native đổi đầu tư re-engineering thật (thời gian, rủi ro, năng lực đội ngũ) lấy chi phí vận hành thấp hơn và khả năng co giãn thực sự — nhưng chỉ đáng giá cho những thành phần đủ nhạy cảm về chi phí hoặc quy mô để hoàn vốn đầu tư đó.

The Architecture Diagram

So sánh topology hai cách tiếp cận cho cùng một hệ thống:

flowchart TB
    subgraph LS["Lift-and-Shift: VM nguyên xi trên Cloud"]
        direction TB
        LB1["Load Balancer\n(cấu hình tĩnh)"]
        VM1["VM #1 — size cố định\nOS + App + Session cục bộ\nchạy 24/7"]
        VM2["VM #2 — size cố định\nOS + App + Session cục bộ\nchạy 24/7"]
        DBVM["Database tự quản\ntrên VM riêng\n(tự patch, tự backup)"]
        LB1 --> VM1
        LB1 --> VM2
        VM1 --> DBVM
        VM2 --> DBVM
    end

    subgraph CN["Cloud-Native: Container + Managed Service + Auto-scaling"]
        direction TB
        LB2["Load Balancer /\nAPI Gateway"]
        ASG["Auto-scaling Group /\nContainer Orchestrator"]
        C1["Container instance\n(stateless)"]
        C2["Container instance\n(stateless)"]
        C3["Container instance\n(tạo thêm khi tải tăng,\nhủy khi tải giảm)"]
        Cache[("Managed Cache\n(session, dữ liệu tạm)")]
        MDB[("Managed Database\n(RDS/Cloud SQL...\nprovider tự vận hành)")]
        Obj[("Object Storage\n(file, asset tĩnh)")]

        LB2 --> ASG
        ASG --> C1
        ASG --> C2
        ASG -. "scale theo tải" .-> C3
        C1 --> Cache
        C2 --> Cache
        C1 --> MDB
        C2 --> MDB
        C1 --> Obj
        C2 --> Obj
    end

    style VM1 fill:#b71c1c,stroke:#333,color:#fff
    style VM2 fill:#b71c1c,stroke:#333,color:#fff
    style DBVM fill:#b71c1c,stroke:#333,color:#fff
    style C1 fill:#1565c0,stroke:#333,color:#fff
    style C2 fill:#1565c0,stroke:#333,color:#fff
    style C3 fill:#1565c0,stroke:#333,color:#fff
    style Cache fill:#2e7d32,stroke:#333,color:#fff
    style MDB fill:#2e7d32,stroke:#333,color:#fff
    style Obj fill:#2e7d32,stroke:#333,color:#fff

Điểm khác biệt cấu trúc cốt lõi: ở nhánh lift-and-shift, số lượng và kích thước VM cố định bất kể tải thực tế, state nằm rải rác trong từng VM, và database tự vận hành mang theo toàn bộ gánh nặng patch/backup/failover thủ công. Ở nhánh cloud-native, compute là các container phù du được orchestrator tạo/hủy theo tín hiệu tải, mọi state được đẩy ra managed store bên ngoài vòng đời của container — đây chính là điều kiện cho phép auto-scaling an toàn.

Implementation Guardrails

Không bao giờ tuyên bố lift-and-shift là "hoàn thành di chuyển cloud". Ghi rõ trong roadmap (ADR hoặc tài liệu kiến trúc — xem Bài 6) rằng rehost là bước quá độ, kèm danh sách cụ thể các thành phần cần refactor tiếp theo và tiêu chí kích hoạt (ví dụ: chi phí compute vượt X% ngân sách, hoặc traffic pattern biến động đủ lớn để auto-scaling hoàn vốn). Không có deadline hay tiêu chí cụ thể, "giai đoạn tiếp theo" sẽ không bao giờ xảy ra.
Ưu tiên tái kiến trúc theo mức độ nhạy cảm chi phí/quy mô, không theo thứ tự dễ làm trước. Xác định 20% thành phần chiếm 80% chi phí compute hoặc chịu tải biến động lớn nhất (traffic theo giờ trong ngày, theo mùa, theo sự kiện) — đó là nơi đầu tư re-engineering hoàn vốn nhanh nhất. Refactor những thành phần ổn định, ít traffic trước chỉ vì chúng dễ làm là lãng phí ngân sách kiến trúc.
Điều kiện tiên quyết bắt buộc trước khi bật auto-scaling: xác nhận stateless thật, không phải "gần như stateless". Trước khi bật scale-in tự động cho bất kỳ nhóm compute nào, phải chứng minh được một instance bị hủy đột ngột không làm mất dữ liệu nghiệp vụ hay phiên người dùng — session phải nằm ở cache phân tán/token, upload phải đi thẳng object storage, không có ghi file cục bộ mang tính bền vững. Bật auto-scaling trên hệ thống chưa thật sự stateless chỉ tạo ra mất dữ liệu ngẫu nhiên, không tạo ra tiết kiệm chi phí.
Managed service không có nghĩa là hết trách nhiệm giám sát. Dùng managed database/queue/cache giảm việc vận hành hạ tầng, nhưng vẫn cần giám sát cấu hình (kích thước instance, connection limit, chi phí theo mức sử dụng) — nhiều đội bị bất ngờ bởi hóa đơn managed service tăng vọt vì không ai theo dõi auto-scaling của chính managed service đó tương ứng với tải thực tế.

Architect's Verdict

Lift-and-shift là một bước đầu chấp nhận được — thậm chí đúng đắn — khi deadline buộc bạn phải rời data center trước khi có thời gian tái kiến trúc. Cái sai không nằm ở việc chọn nó, mà ở việc coi nó là đích đến. Nếu sau migration, không ai còn nói về "giai đoạn hai", bạn đang trả giá cloud mỗi tháng cho một kiến trúc chưa từng được thiết kế để tận dụng cloud — và hóa đơn đó sẽ chỉ tăng, không tự giảm. Đặt lịch tái kiến trúc ngay khi ký hợp đồng migration, không phải sau khi nhận hóa đơn đầu tiên gây sốc.

🔗 Bài viết liên quan: Serverless Architecture · Infrastructure as Code (IaC)

Bài trước: Disaster Recovery · Bài tiếp theo: Security by Design