Cloud Native คืออะไร? แล้ว VM, Cloud Run, Kubernetes ต่างกันยังไง
สรุปความเข้าใจพื้นฐานเกี่ยวกับ Cloud Native, VM, Cloud Run และ Kubernetes สำหรับ Backend Engineer ที่อยากเข้าใจภาพรวมของการ deploy และดูแลระบบบน Cloud
Cloud Native คืออะไร? แล้ว VM, Cloud Run, Kubernetes ต่างกันยังไง
ช่วงหลังผมเริ่มสนใจเรื่อง Cloud Native มากขึ้น เพราะจากเดิมที่ผมเข้าใจแค่การเขียน Backend API แล้ว deploy ขึ้น server พอได้ลองทำโปรเจกต์จริงมากขึ้น ผมเริ่มเห็นว่า “การทำให้ระบบรันบน Cloud ได้” กับ “การออกแบบระบบให้เหมาะกับ Cloud” ไม่ใช่เรื่องเดียวกัน
Cloud Native ไม่ได้หมายถึงแค่เอาแอปไปวางบน Cloud แต่คือแนวคิดในการออกแบบระบบให้ deploy ง่าย, scale ได้, recover จากปัญหาได้, monitor ได้ และไม่ผูกทุกอย่างไว้กับเครื่องใดเครื่องหนึ่งมากเกินไป
บทความนี้เป็นสรุปความเข้าใจของผมเกี่ยวกับ Cloud Native โดยเฉพาะความแตกต่างระหว่าง VM, Cloud Run และ Kubernetes
Cloud Native คืออะไร
Cloud Native คือแนวทางการออกแบบและพัฒนาแอปพลิเคชันให้เหมาะกับการรันบน Cloud ตั้งแต่แรก
ระบบแบบ Cloud Native มักมีลักษณะประมาณนี้
- Application รันเป็น container
- Service แยกส่วนกันชัดเจน
- Config และ Secret แยกออกจาก source code
- Deploy ผ่าน CI/CD
- Scale ได้ตาม traffic
- มี health check
- มี logging / monitoring
- ถ้า service ล่ม ระบบสามารถ restart หรือ recover ได้
เป้าหมายของ Cloud Native คือทำให้ระบบมีความยืดหยุ่นและดูแลใน production ได้ง่ายขึ้น
พูดง่าย ๆ คือ
Cloud Native = ออกแบบระบบให้พร้อมสำหรับ production บน Cloud ไม่ใช่แค่ เอาแอปเดิมไปวางบน Cloud
VM คืออะไร
VM หรือ Virtual Machine คือเครื่อง server เสมือนที่เราเช่าจาก Cloud Provider เช่น Google Cloud Platform, AWS หรือ Azure ถ้าใช้ GCP ตัวอย่างของ VM คือ Compute Engine เวลาเราใช้ VM เราจะได้เครื่องมา 1 เครื่อง แล้วเราต้องจัดการหลายอย่างเอง เช่น
- ติดตั้ง runtime
- ติดตั้ง Docker
- ตั้งค่า firewall
- run container
- manage process
- restart service
- update application
- ดู log
- manage disk
- patch OS
ตัวอย่าง architecture แบบ VM
User
↓
VM
├── Backend API
├── Database
├── Upload files
└── Logs
ข้อดีของ VM คือควบคุมได้เยอะ เหมาะกับการเรียน infra และเหมาะกับระบบที่ต้องการ custom environment
แต่ข้อเสียคือเราต้องดูแลเองเยอะ ถ้า VM ล่ม ทุกอย่างที่อยู่บน VM นั้นอาจได้รับผลกระทบ และการ scale ต้องจัดการเอง
Cloud Run คืออะไร
Cloud Run คือ serverless container platform ของ Google Cloud
แนวคิดคือ เรา build application เป็น Docker image แล้วส่ง image ไปให้ Cloud Run จากนั้น Cloud Run จะช่วยรัน container ให้เรา
สิ่งที่ Cloud Run ช่วยจัดการให้ เช่น
- Run container
- Auto scale
- Scale to zero
- HTTPS endpoint
- Revision
- Rollback
- Traffic splitting
- Logs integration
ตัวอย่าง flow
Go / Next.js App
↓
Docker Image
↓
Artifact Registry
↓
Cloud Run
Cloud Run เหมาะกับ service ที่เป็น HTTP API, Web app, Backend service หรือ Microservice ที่ไม่ต้องการดูแล server เอง
ตัวอย่าง architecture
User
↓
Cloud Run Frontend
↓
Cloud Run Backend API
↓
Managed Services เช่น Cloud SQL, Cloud Storage, Secret Manager
ข้อดีของ Cloud Run คือใช้ง่ายมากเมื่อเทียบกับ VM และ Kubernetes เพราะเราแทบไม่ต้องดูแล infrastructure เอง
เราแค่ focus ที่ application, Docker image, environment variables, health check และ deployment pipeline
Kubernetes คืออะไร
Kubernetes หรือ K8s คือ platform สำหรับจัดการ container จำนวนมาก
ถ้า Cloud Run เหมาะกับการ deploy container แบบง่าย ๆ Kubernetes จะเหมาะกับระบบที่มีหลาย service และต้องการควบคุมละเอียดกว่า
Kubernetes ช่วยจัดการเรื่องเหล่านี้
- Run container
- Restart container ถ้าล่ม
- Scale service เพิ่ม/ลด
- Load balance traffic
- Deploy version ใหม่แบบ rolling update
- Rollback version เก่า
- Manage config และ secret
- Health check
- Service discovery
- จัดการ worker, cron job, batch job
พูดแบบง่ายที่สุด
Kubernetes = ระบบจัดการ containerized applications ใน production
หรือ
Kubernetes = container orchestration platform
แนวคิดสำคัญของ Kubernetes: Desired State
Kubernetes ทำงานด้วยแนวคิดที่เรียกว่า Desired State
เราบอก Kubernetes ว่า “อยากให้ระบบเป็นแบบไหน” เช่น
อยากให้ backend service รัน 3 ตัว
ใช้ image version 1.0.0
เปิด port 8080
ถ้า container ตายให้ restart
ถ้า app ยังไม่ ready ห้ามส่ง traffic เข้าไป
จากนั้น Kubernetes จะพยายามทำให้ actual state ตรงกับ desired state อยู่เสมอ
ตัวอย่าง
Desired state: ต้องมี backend 3 pods
Actual state: ตอนนี้เหลือ 2 pods
Kubernetes: สร้าง pod ใหม่ให้กลับมาเป็น 3
นี่คือจุดสำคัญของ Kubernetes
Component หลักของ Kubernetes
1. Cluster
Cluster คือกลุ่มของเครื่องที่ Kubernetes ใช้รัน application
Kubernetes Cluster
├── Control Plane
└── Worker Nodes
ถ้าใช้บน GCP จะเรียกว่า GKE ถ้าใช้บน AWS จะเรียกว่า EKS ถ้าใช้บน Azure จะเรียกว่า AKS
2. Node
Node คือเครื่องที่ใช้รัน workload
มองง่าย ๆ ได้ว่า
Node = VM หนึ่งเครื่องใน Kubernetes cluster
ในแต่ละ Node จะมีหลาย Pod รันอยู่
3. Pod
Pod คือหน่วยเล็กที่สุดที่ Kubernetes ใช้รัน container
ส่วนใหญ่ใน backend service ทั่วไป
1 Pod = 1 application container
เช่น
quotation-service pod
policy-service pod
taskassigner-service pod
แต่ Pod ไม่ใช่สิ่งที่ควรมองว่าอยู่ถาวร เพราะ Pod อาจตายแล้วเกิดใหม่ได้ และ IP ของ Pod ก็เปลี่ยนได้
4. Deployment
Deployment คือ object ที่ใช้บอก Kubernetes ว่า application นี้ควรรันกี่ตัว ใช้ image อะไร และ deploy/rollback ยังไง
ตัวอย่างแนวคิด
kind: Deployment
spec:
replicas: 3
image: backend-api:1.0.0
แปลว่า
ให้ backend-api รัน 3 pods เสมอ
ถ้ามี pod ตัวหนึ่งล่ม Kubernetes จะสร้างใหม่ให้
5. Service
Service คือ stable endpoint สำหรับเข้าถึง Pod
เพราะ Pod IP เปลี่ยนได้ เราจึงไม่ควรเรียก Pod ตรง ๆ แต่ควรเรียกผ่าน Service
frontend
↓
backend-service
↓
backend pods
Service ทำหน้าที่เป็น load balancer ภายใน cluster และ route traffic ไปยัง Pod ที่อยู่ข้างหลัง
6. Ingress
Ingress คือทางเข้าจากภายนอก cluster
เช่น
https://api.example.com/quotation → quotation-service
https://api.example.com/policy → policy-service
https://api.example.com/task → taskassigner-service
Ingress มักทำงานร่วมกับ Ingress Controller เช่น Nginx หรือ Traefik
ถ้าในระบบที่เคยใช้ Traefik หรือ Reverse Proxy เพื่อ route path ไปยัง service ต่าง ๆ แนวคิดนี้คล้ายกับ Ingress มาก
7. ConfigMap
ConfigMap ใช้เก็บ configuration ที่ไม่ใช่ความลับ เช่น
APP_ENV=production
APP_PORT=8080
LOG_LEVEL=info
ถ้าใน VM หรือ Docker Compose เราใช้ .env
ใน Kubernetes มักจะใช้ ConfigMap
8. Secret
Secret ใช้เก็บค่าที่เป็นความลับ เช่น
DB_PASSWORD
JWT_SECRET
API_KEY
ใน production จริง อาจใช้ร่วมกับระบบอย่าง Secret Manager หรือ Vault
จำง่าย ๆ
ConfigMap = config ทั่วไป
Secret = config ที่เป็นความลับ
9. Liveness Probe และ Readiness Probe
Probe คือ health check ของ Kubernetes
มี 2 ตัวที่สำคัญมาก
Liveness Probe = ใช้เช็กว่า app ยังมีชีวิตอยู่ไหม ถ้า fail Kubernetes จะ restart container
Readiness Probe = ใช้เช็กว่า app พร้อมรับ traffic หรือยัง ถ้า fail Kubernetes จะไม่ส่ง request เข้า pod นั้น
ตัวอย่าง endpoint ที่มักใช้
/healthz = liveness
/readyz = readiness
Readiness สำคัญมากตอน deploy version ใหม่ เพราะ Kubernetes จะยังไม่ส่ง traffic เข้า Pod ใหม่จนกว่า readiness จะผ่าน
10. HPA
HPA หรือ Horizontal Pod Autoscaler คือระบบ scale Pod อัตโนมัติ
เช่น
ถ้า CPU > 70%
เพิ่ม pod จาก 3 เป็น 6
ตัวอย่าง
ช่วง traffic ปกติ
backend = 3 pods
ช่วง traffic สูง
backend = 10 pods
11. Job และ CronJob
Job ใช้สำหรับงานที่รันครั้งเดียวแล้วจบ เช่น migration หรือ batch processing
CronJob ใช้สำหรับงานที่รันตามเวลา เช่น daily report, cleanup job หรือ scheduled task
ตัวอย่าง
Database migration → Job
Daily report → CronJob
SLA checker → CronJob
Flow เวลามี Request เข้า Kubernetes
สมมติ user เรียก API
POST /quotation/calculate
Flow แบบง่ายจะเป็นแบบนี้
1. User ส่ง request เข้า Load Balancer
2. Load Balancer ส่งเข้า Ingress Controller
3. Ingress ดู path /quotation
4. Route ไป quotation-service
5. Service เลือก Pod ตัวใดตัวหนึ่ง
6. Pod รับ request ผ่าน backend application
7. Application ทำงาน เช่น validate, process business logic, query service อื่น
8. Return response กลับไปหา user
จำภาพนี้ไว้
User
↓
Load Balancer
↓
Ingress
↓
Service
↓
Pod
↓
Application
Flow เวลามี Deploy Version ใหม่
สมมติเราจะ deploy backend จาก version 1.0.0 เป็น 1.1.0
Kubernetes จะทำ rolling update ประมาณนี้
1. สร้าง Pod version ใหม่ขึ้นมา
2. รอให้ readiness probe ผ่าน
3. เริ่มส่ง traffic เข้า Pod ใหม่
4. ค่อย ๆ ลด Pod เก่าลง
5. ทำซ้ำจนทุก Pod เป็น version ใหม่
ข้อดีคือช่วยลด downtime ตอน deploy
ถ้า Pod ใหม่ไม่ผ่าน readiness probe Kubernetes จะไม่ส่ง traffic เข้าไป
ถ้า deploy แล้วมีปัญหา ก็ rollback กลับ revision ก่อนหน้าได้
Kubernetes แก้ปัญหาอะไร
Kubernetes ช่วยแก้ปัญหาในมุม operation และ runtime เช่น
- Container orchestration
- Auto restart
- Auto scaling
- Load balancing
- Service discovery
- Rolling deployment
- Rollback
- Config / Secret management
- Health check
- Multi-service management
ตัวอย่าง
ถ้า Pod ล่ม → Kubernetes สร้างใหม่
ถ้า traffic เยอะ → HPA เพิ่ม Pod
ถ้า deploy version ใหม่ → Rolling update
ถ้า Pod ยังไม่ ready → ไม่ส่ง traffic เข้าไป
Kubernetes ไม่ได้แก้ปัญหาอะไร
Kubernetes ไม่ได้แก้ business logic ให้เรา
เช่น
- Database transaction ผิด
- Race condition ใน business logic
- Calculation logic ผิด
- SQL query ช้า
- Cache stale
- ไม่มี request_id ใน log
- Schema migration พัง
ดังนั้นต่อให้ระบบรันบน Kubernetes ถ้า application logic ออกแบบไม่ดี ระบบก็ยังพังได้
ประโยคที่ผมคิดว่าสำคัญมากคือ
Kubernetes ช่วยให้ระบบรันและ scale ได้ดีขึ้น
แต่ความถูกต้องของระบบยังขึ้นอยู่กับ application design และ database design
Cloud Run vs Kubernetes
Cloud Run และ Kubernetes ใช้รัน container เหมือนกัน แต่เหมาะกับคนละบริบท
Cloud Run = ง่ายกว่า เหมาะกับ service เดี่ยวหรือระบบที่ไม่ซับซ้อนมาก
Kubernetes = ควบคุมละเอียดกว่า เหมาะกับหลาย service และระบบที่ต้องการ orchestration จริงจัง
| เรื่อง | Cloud Run | Kubernetes |
|---|---|---|
| แนวคิด | Serverless container platform | Container orchestration platform |
| ความง่าย | ง่ายกว่า | ซับซ้อนกว่า |
| การดูแล infra | Cloud provider ดูแลให้เยอะ | ทีมต้องดูแล cluster มากกว่า |
| การควบคุม | ปานกลาง | สูง |
| Auto scale | มีให้ในตัว | มีผ่าน HPA แต่ต้อง config |
| เหมาะกับ | API / Web app / Backend service | Microservices หลายตัว |
| Deployment | Revision / Rollback | Rolling update / Rollback |
| Routing | Service URL / Custom domain | Ingress / Gateway / Service |
| Config / Secret | Env vars / Secret Manager | ConfigMap / Secret / External Secret |
| Use case | ระบบเล็กถึงกลาง | ระบบ production ใหญ่ / หลายทีม |
สำหรับโปรเจกต์ที่มี frontend, backend, database และ storage แบบไม่ซับซ้อน Cloud Run มักเพียงพอแล้ว
แต่ถ้าระบบเริ่มมีหลาย service, worker, cron job, batch job, internal routing, custom deployment strategy และหลายทีม deploy ร่วมกัน Kubernetes จะเหมาะกว่า
VM vs Cloud Run vs Kubernetes
VM, Cloud Run และ Kubernetes เป็นคนละระดับของการรัน application บน Cloud
| เรื่อง | VM | Cloud Run | Kubernetes |
|---|---|---|---|
| แนวคิด | เช่าเครื่อง server | รัน container แบบ serverless | จัดการ container หลายตัว |
| การดูแล OS | ต้องดูแลเอง | แทบไม่ต้องดูแล | ขึ้นกับรูปแบบ cluster |
| Deploy container | ทำได้ แต่ setup เอง | ทำได้ง่าย | ทำได้และควบคุมละเอียด |
| Auto scale | ต้องทำเอง | มีให้ | มีผ่าน HPA |
| Restart เมื่อ app ล่ม | ต้องจัดการเอง | Cloud Run จัดการให้ | Kubernetes จัดการให้ |
| เหมาะกับ | Learning infra / legacy / custom setup | API / web service ทั่วไป | Microservices / platform ขนาดใหญ่ |
| Complexity | กลาง | ต่ำ | สูง |
| Control | สูง | ปานกลาง | สูงมาก |
| ภาระดูแล | สูง | ต่ำ | สูงกว่า Cloud Run |
| ตัวอย่างบน GCP | Compute Engine | Cloud Run | GKE |
ถ้าระบบยังไม่ซับซ้อน Cloud Run มักเป็นตัวเลือกที่ดี เพราะ deploy ง่าย ดูแลง่าย และลดภาระ infra ได้เยอะ
แต่ถ้าระบบมีหลาย service, ต้อง scale แยกแต่ละ service, มี worker, cron job, batch job, internal routing และหลายทีมทำงานร่วมกัน Kubernetes จะเริ่มมีประโยชน์มากขึ้น
จำแบบง่ายที่สุด
VM = ได้เครื่องมา ต้องดูแลเองเยอะ
Cloud Run = ได้ที่รัน container แบบง่ายและ serverless
Kubernetes = ได้ platform สำหรับจัดการ container หลายตัวแบบจริงจัง
ใช้ Kubernetes เมื่อไหร่
Kubernetes เหมาะเมื่อ
- มีหลาย service
- ต้อง scale แต่ละ service แยกกัน
- มี worker / cron / batch job หลายตัว
- ต้องการ rolling update / rollback ที่ควบคุมได้
- ต้องการ service discovery ภายในระบบ
- ต้องการ platform กลางให้หลายทีม deploy
- มีทีมที่ดูแล Kubernetes ได้
- ต้องการใช้ ecosystem เช่น Helm, Argo CD, Prometheus, Grafana
ตัวอย่างระบบที่มักเหมาะกับ Kubernetes
- Food delivery platform
- Banking platform
- Insurance platform
- E-commerce platform
- Payment platform
- Large microservices system
ยังไม่ควรใช้ Kubernetes เมื่อไหร่
Kubernetes อาจยังไม่จำเป็นถ้า
- มีแค่ frontend + backend + database
- ทีมเล็กมาก
- Cloud Run แก้ปัญหาได้พอแล้ว
- ไม่มีคนดูแล cluster
- ยังไม่ต้องการ control ละเอียด
- complexity และ cost สำคัญกว่า flexibility
Kubernetes ไม่ใช่คำตอบของทุกระบบ
บางครั้ง Cloud Run อาจเป็นตัวเลือกที่ดีกว่า เพราะง่ายกว่า ดูแลง่ายกว่า และเพียงพอกับ use case แล้ว
Mapping จาก Docker / Docker Compose ไป Kubernetes
| สิ่งที่เห็นใน repo | ถ้าอยู่บน Kubernetes จะเป็นอะไร |
|---|---|
| Dockerfile | Container Image |
| docker-compose service | Deployment |
| container name / service name | Kubernetes Service |
| Traefik path routing | Ingress / Ingress Controller |
| .env | ConfigMap + Secret |
| Jenkins deploy | kubectl apply / Helm upgrade / Argo CD sync |
| cron job ใน Go | Kubernetes CronJob หรือ app-level scheduler |
| migration command | Kubernetes Job |
| health endpoint | Liveness / Readiness Probe |
| scale service | HPA |
| logs stdout / Zap | Cloud Logging / Loki |
| metrics | Prometheus |
| GCP Secret Manager | External Secrets / CSI Driver / Workload Identity |
การเข้าใจ mapping นี้ช่วยให้เห็นภาพว่า Kubernetes ไม่ได้เป็นคนละโลกกับ Docker แต่เป็นขั้นต่อไปของการจัดการ container ในระดับ production
ความรู้ระดับที่ควรมีสำหรับ Backend Engineer
ถ้าเป็น Backend Engineer ไม่จำเป็นต้องลึกเท่า Platform Engineer ตั้งแต่แรก แต่ควรรู้ว่า Kubernetes ทำอะไร และระบบ backend ที่เราเขียนจะถูกรันบน Kubernetes อย่างไร
สิ่งที่ควรรู้ขั้นต่ำ
- Kubernetes คือ container orchestration
- Cluster / Node / Pod คืออะไร
- Deployment ใช้จัดการ replicas และ rollout
- Service ใช้เป็น stable endpoint
- Ingress ใช้ route traffic จากภายนอก
- ConfigMap / Secret ใช้จัดการ config
- Liveness / Readiness probe ใช้ทำ health check
- HPA ใช้ autoscale
- Job / CronJob ใช้กับ batch หรือ scheduled jobs
- Kubernetes ไม่ได้แก้ business logic หรือ database correctness ให้เอง
สรุป
Cloud Native คือแนวทางการออกแบบระบบให้เหมาะกับ production บน Cloud
VM, Cloud Run และ Kubernetes เป็นคนละระดับของการรัน application
VM = เราได้เครื่องและดูแลเองเยอะ
Cloud Run = เราส่ง container ไปให้ cloud provider รันให้แบบง่าย
Kubernetes = เราใช้ platform เพื่อจัดการ container หลายตัว หลาย service และควบคุม runtime ได้ละเอียด
สำหรับระบบเล็กหรือโปรเจกต์ส่วนตัว Cloud Run มักเพียงพอและดูแลง่ายกว่า
สำหรับระบบใหญ่ที่มีหลาย service, worker, batch job, deployment strategy และหลายทีมทำงานร่วมกัน Kubernetes จะเริ่มมีประโยชน์มากขึ้น
สิ่งสำคัญคือ Kubernetes ไม่ได้ทำให้ระบบถูกต้องโดยอัตโนมัติ มันช่วยด้าน runtime, scaling และ operation แต่ backend logic, database transaction, observability และ system design ยังเป็นหน้าที่ของ engineer ที่ต้องออกแบบให้ดี
ประโยคที่ผมอยากจำไว้คือ
Cloud Native ไม่ใช่แค่ deploy ขึ้น Cloud ได้
แต่คือการออกแบบระบบให้ deploy ง่าย scale ได้ recover ได้ monitor ได้ และพร้อมสำหรับ production