Serverless, Container hay VM: Đánh Đổi Thật Sự Là Gì?

Hầu hết các bài viết so sánh Serverless, Containers và VMs đều được viết bởi cloud vendor hoặc những người có lợi ích từ một công nghệ cụ thể. Bạn sẽ thấy những biểu đồ đẹp đẽ, những con số ấn tượng, nhưng hiếm khi thấy ai nói thẳng: “Chúng tôi đã dùng Serverless và hóa đơn tháng đó tăng gấp 5 lần” hay “Kubernetes đã giết chết năng suất của team chúng tôi trong 6 tháng.”

Là một kỹ sư đã từng bị hype đốt cháy nhiều lần, tôi muốn viết bài này theo cách khác — không có marketing, không có vendor bias, chỉ là những đánh đổi thực sự mà bạn cần hiểu trước khi đưa ra quyết định kiến trúc quan trọng nhất cho hệ thống của mình trong năm 2026.

Định Nghĩa Lại Từ Đầu: Ba Paradigm Thực Sự Là Gì?

Trước khi đi vào trade-off, hãy đảm bảo chúng ta đang nói về cùng một thứ.

Virtual Machines (VMs) là phần mềm mô phỏng một máy tính vật lý hoàn chỉnh, chạy trên hypervisor. Mỗi VM có một OS kernel riêng, system libraries riêng, và hoàn toàn tin rằng nó đang sở hữu phần cứng dành riêng. Boot time từ 30 giây đến vài phút. Overhead đáng kể — một Linux VM tối giản vẫn tiêu tốn 256MB–1GB RAM chỉ cho OS. AWS ra mắt EC2 năm 2006, và đó là lúc cloud computing thực sự bắt đầu.

Containers dùng OS-level virtualization thông qua Linux kernel features: namespaces để cô lập process/network/filesystem, và cgroups để giới hạn tài nguyên. Chúng chia sẻ host OS kernel — không cần guest OS. Docker phổ biến hóa containers năm 2013, Kubernetes trở thành chuẩn orchestration vào 2017–2018. Boot time: milliseconds đến vài giây. Overhead tối thiểu — một container có thể chạy với chỉ 4–10MB memory overhead.

Serverless (FaaS) là mức abstraction cao nhất — developer viết functions, cloud provider quản lý toàn bộ infrastructure. Event-driven, billing theo từng invocation và từng millisecond thực thi. AWS Lambda ra mắt năm 2014 và thay đổi cách chúng ta nghĩ về compute. Cold start từ 100ms đến vài giây tùy runtime.

Nguyên tắc cốt lõi cần nhớ: abstraction ladder càng cao thì càng ít control, càng ít ops burden, và càng phụ thuộc vào vendor nhiều hơn. Không có cái nào “tốt hơn” — chỉ có cái nào phù hợp hơn với bài toán cụ thể của bạn.

Chi Phí: Không Ai Chịu Ngồi Tính Toán Thật Sự

Đây là phần mà hầu hết các bài so sánh đều né tránh hoặc làm mờ nhạt.

VMs có chi phí cố định và dự đoán được. Bạn trả tiền cho instance dù nó đang idle hay đang xử lý 100% CPU. Điều này nghe có vẻ lãng phí, nhưng với workload có utilization cao và ổn định, đây thực ra là mô hình rẻ nhất. Một c6g.xlarge trên AWS chạy 24/7 có giá khoảng $100/tháng — và nó xử lý được traffic liên tục mà không có bất kỳ surprise nào trên hóa đơn.

Containers trên Kubernetes hiệu quả hơn nhờ bin-packing — nhồi nhiều workload vào cùng một cluster. Nhưng đừng quên hidden fixed costs: bạn vẫn phải trả cho control plane, load balancers, persistent volumes, và ít nhất 2–3 worker nodes để đảm bảo high availability. Với team nhỏ, Kubernetes cluster overhead có thể chiếm $300–500/tháng trước khi bạn chạy bất kỳ workload thực sự nào.

Serverless nghe có vẻ ma thuật: zero idle cost, chỉ trả khi dùng. Và đúng là vậy — ở quy mô nhỏ. Vấn đề xảy ra khi bạn scale.

Ví dụ thực tế: Một function Lambda xử lý 10 triệu invocations/tháng, mỗi lần chạy 200ms với 512MB memory. Chi phí: khoảng $16.70/tháng. Nghe rẻ. Nhưng nếu bạn có 500 triệu invocations/tháng? Chi phí nhảy lên $835/tháng — trong khi một container trên Fargate hoặc một EC2 instance có thể xử lý throughput tương đương với $80–120/tháng.

Đây chính là khái niệm “break-even invocation threshold” — điểm mà Serverless trở nên đắt hơn Containers. Câu chuyện Basecamp/37signals rời bỏ cloud và tiết kiệm hàng triệu đô la đã minh chứng rõ ràng: ở quy mô đủ lớn, mô hình billing của cloud-native không còn có lợi nữa.

Trong bối cảnh FinOps năm 2026, các team đang buộc phải làm phép tính này một cách nghiêm túc. Nếu bạn chưa tính break-even threshold cho workload của mình, đó là rủi ro tài chính bạn đang bỏ qua.

Performance và Latency: Con Voi Trong Phòng Tên Cold Start

VM boot time tính bằng phút. Container startup tính bằng giây. Serverless cold start từ 100ms đến vài giây — và đây là vấn đề nghiêm trọng với user-facing applications.

Tưởng tượng user click một button, request đến một Lambda function đang “ngủ”, và phải chờ 2–3 giây chỉ để function khởi động. Với Java runtime, cold start có thể lên đến 5–10 giây nếu không được tối ưu.

Các giải pháp mitigation đều tồn tại, nhưng đều có chi phí:

• AWS Lambda SnapStart (cho Java): giảm cold start lên đến 90% bằng cách pre-initialize execution environment. Tốt, nhưng chỉ cho Java và có giới hạn.
• Provisioned Concurrency: giữ một số lượng function instances luôn “warm”. Hiệu quả, nhưng bạn đang trả tiền idle — đúng cái bạn muốn tránh khi chọn Serverless.
• Cloud Run minimum instances: tương tự, luôn giữ ít nhất một container chạy. Lại là chi phí cố định.

Về throughput ceilings: VMs có thể được tune cho raw performance — bạn có thể tối ưu network stack, memory allocation, CPU affinity. Serverless có concurrency limits (mặc định 1000 concurrent executions trên Lambda) và execution time caps (15 phút tối đa). Với long-running jobs, Serverless đơn giản là không phải lựa chọn.

Với GPU và AI/ML workloads — đây là lĩnh vực mà VMs và bare metal vẫn thống trị tuyệt đối cho training jobs. Serverless GPU functions (Modal, Replicate) đang nổi lên cho inference workloads ngắn hạn, nhưng vẫn còn nhiều hạn chế về memory và execution time.

Operational Complexity: Ai Thực Sự Quản Lý Cái Gì?

Hãy thành thật về “undifferentiated heavy lifting” spectrum:

VMs yêu cầu bạn tự quản lý toàn bộ: OS patching, network configuration, security groups, auto-scaling policies, load balancer setup, và monitoring. Cần sysadmin expertise thực sự. Nhưng bạn có full control — không có gì là hộp đen.

Containers trên Kubernetes shift ops burden sang orchestration layer. Và Kubernetes không hề đơn giản. Năm 2026, “Kubernetes fatigue” là có thật — các team nhỏ đang đặt câu hỏi nghiêm túc liệu việc maintain một K8s cluster có xứng đáng với overhead không. Bạn cần hiểu Deployments, Services, Ingress controllers, RBAC, NetworkPolicies, PodDisruptionBudgets, HorizontalPodAutoscaler… danh sách cứ dài ra mãi. Đây là lý do tại sao Render, Railway, và Fly.io đang thu hút nhiều team hơn — họ cung cấp container deployment mà không cần bạn trở thành K8s expert.

Serverless offloads gần như mọi thứ về infrastructure. Nhưng nó tạo ra các vấn đề operational khác:

• Function sprawl: Một dự án lớn có thể có hàng trăm Lambda functions, mỗi cái có IAM role riêng, environment variables riêng, và configuration riêng.
• IAM permission creep: Mỗi function cần permissions cụ thể. Theo thời gian, nếu không được quản lý chặt, bạn sẽ có một mạng lưới permissions rối rắm không ai hiểu rõ.
• Distributed tracing nightmares: Debug một request đi qua 7 Lambda functions, 3 SQS queues, và 2 DynamoDB tables là một trải nghiệm không ai muốn lặp lại.

Vendor Lock-in và Portability: Rủi Ro Không Ai Định Giá

Containers win tuyệt đối về portability. OCI-standard images chạy được trên bất kỳ cloud nào, on-premises, hoặc laptop của bạn. Đây là điều gần nhất với “write-once-run-anywhere” trong thế giới infrastructure.

Serverless là proprietary nhất. Lambda trigger integrations, event source mappings, IAM execution roles, Layer system — tất cả đều deeply AWS-specific. Migrate một ứng dụng Lambda phức tạp sang Google Cloud Functions không phải là “lift-and-shift” — đó là viết lại. Bạn có đang định giá rủi ro này không?

VMs nằm ở giữa: AMIs là AWS-specific, nhưng OS và application stack hoàn toàn portable với effort hợp lý. Terraform + Packer giúp việc này dễ hơn nhiều.

Middle ground đang phát triển nhanh nhất là serverless containers: AWS Fargate, Google Cloud Run, Azure Container Apps. Bạn deploy OCI containers nhưng không cần quản lý cluster. Container portability kết hợp với serverless operational model. Nhưng lưu ý: API và configuration vẫn là cloud-specific.

Một xu hướng đáng theo dõi: WebAssembly (WASM) đang nổi lên như một fourth option với stronger portability và sandboxing promises — đặc biệt ở edge computing với Cloudflare Workers và WasmEdge.

Bảo Mật: Isolation, Attack Surface, và Compliance

VMs cung cấp isolation mạnh nhất — hardware-level hypervisor boundary. Đây là lý do tại sao các workload compliance-heavy (PCI-DSS, HIPAA, FedRAMP) vẫn ưa chuộng VMs. Một VM compromise không tự động dẫn đến compromise của VM khác trên cùng host.

Containers chia sẻ host kernel — một kernel exploit có thể theoretically escape container boundary. Log4Shell đã phơi bày rõ ràng supply chain risks trong deep dependency chains của container images. Bạn có biết tất cả những gì đang chạy trong base image của mình không?

Serverless giảm attack surface theo một nghĩa nào đó — không có persistent servers để patch. Nhưng nó introduces function permission sprawl và third-party event source trust issues. Ai có thể trigger Lambda function của bạn? Event source đó có được validate đúng cách không?

Shared responsibility model shifts theo abstraction level: càng nhiều abstraction thì càng nhiều security responsibility được giao cho cloud provider. Đây có thể là feature hoặc risk tùy thuộc vào compliance posture của tổ chức bạn.

Workload Fit: Paradigm Nào Cho Bài Toán Nào?

Đây là phần thực tế nhất:

• VMs phù
  
  Post Views: 13
  11 views