Serverless là gì? FaaS, Cold Start và khi nào nên dùng Serverless

Serverless là mô hình điện toán đám mây cho phép bạn triển khai và chạy code mà không cần quan tâm đến server — cloud tự động cấp phát tài nguyên, scale theo demand và tính tiền theo mức sử dụng thực tế. Bài viết này giải thích Serverless là gì, phân biệt FaaS và BaaS, hiểu rõ vấn đề cold start, vòng đời thực thi function và khi nào nên (hoặc không nên) chọn kiến trúc serverless.

Serverless là gì?

Serverless (hay "không máy chủ") là mô hình điện toán đám mây trong đó nhà phát triển chỉ viết và triển khai code — thường là các hàm (function) riêng lẻ — còn toàn bộ việc cung cấp, vận hành và scale server do nhà cung cấp cloud (AWS, GCP, Azure) đảm nhận hoàn toàn.

Tên gọi "serverless" đôi khi gây hiểu nhầm: server vẫn tồn tại, nhưng bạn không phải quản lý chúng. Bạn không cần lo về cài đặt OS, vá lỗi bảo mật, cấu hình load balancer hay monitor disk. Tất cả được trừu tượng hóa khỏi tầm nhìn của developer.

Hai đặc điểm định nghĩa serverless:

• No server management: Cloud tự động cấp, scale và thu hồi tài nguyên tính toán.
• Pay-per-invocation: Bạn trả tiền cho mỗi lần hàm được gọi và thời gian CPU thực tế, không phải cho server ngồi không.

Serverless bao gồm hai nhánh chính: FaaS (Function as a Service) và BaaS (Backend as a Service). Phần dưới sẽ phân biệt rõ hai khái niệm này.

FaaS vs BaaS

Mặc dù cả hai đều thuộc hệ sinh thái serverless, FaaS và BaaS phục vụ mục đích khác nhau:

FaaS — Function as a Service là mô hình bạn viết từng hàm riêng lẻ, triển khai lên cloud và hàm đó được kích hoạt bởi sự kiện (HTTP request, queue message, cron job…). Hàm chạy xong là cloud thu hồi tài nguyên ngay lập tức. Ví dụ điển hình:

• AWS Lambda — dịch vụ FaaS phổ biến nhất, hỗ trợ Python, Node.js, Go, Java, Ruby…
• Google Cloud Functions — tích hợp sâu với Firebase và GCP ecosystem.
• Azure Functions — mạnh về tích hợp với dịch vụ Microsoft (Event Hub, Service Bus).
• Vercel Edge Functions — tối ưu cho Next.js và web frontend, chạy tại edge node gần user nhất.

BaaS — Backend as a Service cung cấp các dịch vụ backend dựng sẵn mà bạn gọi trực tiếp từ frontend mà không cần viết server code. Ví dụ điển hình:

• Firebase (Google) — realtime database, auth, file storage, push notification.
• Supabase — PostgreSQL + realtime subscriptions + auth + storage, mã nguồn mở.
• AWS Amplify — tích hợp auth (Cognito), GraphQL (AppSync), storage (S3) cho frontend.

Điểm khác biệt cốt lõi: FaaS cho phép bạn viết logic nghiệp vụ tùy chỉnh chạy phía backend, còn BaaS cung cấp infrastructure dựng sẵn cho các nhu cầu phổ biến. Trong thực tế, nhiều dự án kết hợp cả hai — dùng Firebase Auth (BaaS) và AWS Lambda (FaaS) trong cùng một ứng dụng.

API Gateway là gì? Cổng vào của kiến trúc microservice

Cold Start vs Warm Start

Đây là một trong những thách thức thực tế nhất khi dùng serverless — cold start latency.

Warm start xảy ra khi một function vừa được gọi gần đây và container chứa nó vẫn còn sống trong bộ nhớ của cloud. Lần gọi tiếp theo được phục vụ ngay lập tức — latency chỉ là thời gian thực thi code, thường dưới 10ms với business logic đơn giản.

Cold start xảy ra khi:

• Function được gọi lần đầu tiên sau khi deploy.
• Function không được gọi trong một thời gian dài (cloud đã thu hồi container).
• Traffic tăng đột biến vượt quá số instance đang warm.

Trong cold start, cloud phải thực hiện toàn bộ chuỗi khởi tạo:

1. Provision container — tạo môi trường cô lập mới.
2. Load runtime — khởi động interpreter/JVM/runtime cho ngôn ngữ bạn dùng.
3. Nạp deployment package — download và giải nén code của bạn.
4. Init module — chạy code khởi tạo ở cấp module (import, connect DB…).
5. Execute handler — cuối cùng mới chạy hàm thực sự.

Thời gian cold start điển hình theo ngôn ngữ:

Chiến lược giảm cold start:

• Provisioned Concurrency (AWS Lambda): Giữ một số instance luôn warm, loại bỏ hoàn toàn cold start — nhưng tốn thêm chi phí.
• Giảm kích thước package: Loại bỏ dependencies không cần thiết, dùng tree-shaking.
• Tránh heavy initialization: Không connect database trong module scope; dùng lazy initialization.
• Chọn runtime nhẹ: Go và Node.js có cold start ngắn hơn Java/Spring đáng kể.
• Scheduled warm-up: CloudWatch cron ping function mỗi 5 phút để giữ warm.

Execution Lifecycle: từ Trigger đến Terminate

Mỗi lần một serverless function được kích hoạt, nó đi qua một vòng đời cố định gồm 4 giai đoạn:

1. Trigger (Kích hoạt) Một sự kiện từ bên ngoài kích hoạt function — HTTP request qua API Gateway, message từ SQS/Kafka, file upload lên S3, hoặc cron job theo lịch. Cloud nhận sự kiện và quyết định dispatch đến function instance nào (warm hoặc cold start).

2. Init (Khởi tạo) Giai đoạn chỉ xảy ra trong cold start. Cloud tạo execution environment, nạp runtime và chạy toàn bộ code ở cấp module (ngoài handler function). Đây là lý do tại sao các kết nối database, config parsing và import nặng nên được thực hiện ở giai đoạn này để tái sử dụng giữa các warm invocation.

3. Execute (Thực thi) Handler function của bạn được gọi với event object và context object. Đây là phần code bạn viết và trả về kết quả. Với AWS Lambda, đây là hàm lambda_handler(event, context).

4. Terminate (Kết thúc) Sau khi handler trả về, cloud "đóng băng" execution environment — container không bị xóa ngay mà được giữ lại để phục vụ warm start cho lần gọi tiếp theo. Sau một thời gian idle (thường 15–45 phút với Lambda), cloud mới thực sự thu hồi container.

Ví dụ Code thực tế

AWS Lambda (Python)

 1import json
 2import boto3
 3
 4# Init phase: chạy một lần, tái sử dụng cho warm invocations
 5s3_client = boto3.client('s3')
 6
 7def lambda_handler(event, context):
 8    """
 9    Handler chính của Lambda function.
10    event: dict chứa dữ liệu từ trigger (HTTP request, SQS message, v.v.)
11    context: object chứa metadata về execution (request_id, timeout còn lại...)
12    """
13    # Đọc HTTP method và path từ API Gateway event
14    http_method = event.get('httpMethod', 'GET')
15    path = event.get('path', '/')
16    
17    # Logic nghiệp vụ
18    if http_method == 'GET' and path == '/hello':
19        body = {
20            'message': 'Hello from AWS Lambda!',
21            'requestId': context.aws_request_id,
22        }
23        status_code = 200
24    else:
25        body = {'error': 'Not Found'}
26        status_code = 404
27
28    # Trả về HTTP response theo định dạng API Gateway proxy integration
29    return {
30        'statusCode': status_code,
31        'headers': {
32            'Content-Type': 'application/json',
33            'Access-Control-Allow-Origin': '*',
34        },
35        'body': json.dumps(body),
36    }

Vercel Edge Function (JavaScript)

 1// api/hello.js — Vercel Edge Runtime
 2// Chạy tại edge node gần user nhất, latency thấp hơn Lambda thông thường
 3
 4export const config = {
 5  runtime: 'edge',
 6};
 7
 8export default async function handler(request) {
 9  const { searchParams } = new URL(request.url);
10  const name = searchParams.get('name') || 'World';
11
12  // Edge function nhận Web standard Request, trả về Web standard Response
13  return new Response(
14    JSON.stringify({
15      message: `Hello, ${name}! Powered by Vercel Edge.`,
16      region: process.env.VERCEL_REGION || 'unknown',
17    }),
18    {
19      status: 200,
20      headers: {
21        'Content-Type': 'application/json',
22        'Cache-Control': 's-maxage=60, stale-while-revalidate',
23      },
24    }
25  );
26}

Các loại Event Trigger

Serverless function có thể được kích hoạt bởi nhiều loại sự kiện khác nhau:

HTTP / API Gateway Trigger phổ biến nhất — API Gateway nhận HTTP request và chuyển tiếp đến Lambda dưới dạng event object chuẩn hóa. Phù hợp cho REST API, webhook endpoint, và backend-for-frontend.

Queue Message (SQS / Kafka / Pub/Sub) Function được kích hoạt khi có message mới trong hàng đợi. Lambda poll SQS queue theo batch, xử lý song song nhiều message. Phù hợp cho async task processing và event-driven architecture.

Kafka là gì? Message queue cho hệ thống phân tán

Schedule (Cron Job) AWS EventBridge Scheduler (hay CloudWatch Events cũ) kích hoạt Lambda theo lịch cron — ví dụ: chạy báo cáo lúc 00:00 mỗi ngày, dọn dẹp data mỗi Chủ nhật. Thay thế hoàn toàn crontab trên server truyền thống.

Storage Event (S3 / Cloud Storage) Function tự động kích hoạt khi file được upload lên S3 bucket. Dùng phổ biến cho image processing pipeline — user upload ảnh gốc → S3 trigger Lambda → Lambda resize ảnh thành nhiều kích thước → lưu vào bucket khác.

Database Stream (DynamoDB Streams / Firestore) Mỗi thay đổi trong database (insert/update/delete) tạo ra event kích hoạt function. Dùng để đồng bộ dữ liệu sang ElasticSearch, gửi notification, hoặc invalidate cache.

Serverless vs Container vs VM

Khi thiết kế hệ thống, đây là bảng so sánh thực tế để chọn đúng compute model:

Kubernetes là gì? Container orchestration cho production

Khi nào chọn Serverless:

• Workload không liên tục, traffic thất thường hoặc unpredictable.
• Muốn tốc độ phát triển cao, không muốn tốn thời gian vận hành infrastructure.
• Tác vụ event-driven: xử lý ảnh, webhook, ETL pipeline, scheduled job.
• MVP hoặc microservice nhỏ với budget hạn chế.

Khi nào KHÔNG nên chọn Serverless:

• Function cần chạy liên tục hơn 15 phút.
• Ứng dụng cần giữ state trong bộ nhớ giữa các request.
• Workload liên tục cao tải (chi phí leo thang).
• Cần kiểm soát chi tiết về runtime, network, GPU.
• Latency cực thấp không chấp nhận cold start.

Use Cases thực tế

1. Image Resize Pipeline User upload ảnh gốc → S3 trigger Lambda → Lambda dùng Pillow/Sharp resize thành 3 kích thước (thumbnail 150px, medium 600px, large 1200px) → lưu vào S3 CDN bucket. Chi phí gần bằng $0 khi không có upload, scale tự động khi traffic tăng.

2. Webhook Handler Khi Stripe gửi payment webhook → API Gateway nhận → Lambda xác thực signature, cập nhật order status trong database và gửi email xác nhận. Serverless lý tưởng vì webhook không liên tục — trả tiền đúng theo số lần được gọi.

3. Scheduled Report Job EventBridge Scheduler kích hoạt Lambda mỗi sáng 6h → Lambda query BigQuery/Redshift, tổng hợp báo cáo doanh thu ngày hôm trước → gửi Slack notification đến channel của team. Không cần server chạy 24/7 chỉ để làm công việc 2 phút mỗi ngày.