ก่อนเข้า 9 layers — ภาพในใจที่ต้องมีก่อน#

ลองนึก บ้านพักอาศัยหลังหนึ่ง ที่ครอบครัวคุณอยู่ครับ

บ้านหนึ่งหลังไม่ได้มีแค่ “ผนัง” อย่างเดียว มันประกอบด้วยหลายชั้นซ้อนกัน

ใต้พื้นบ้านมี ระบบประปา (สายน้ำในท่อ) ใต้พื้นนั้นอีกชั้นมี ฐานราก (concrete + เหล็ก) ใต้ฐานรากคือ ดินที่บ้านตั้งอยู่

เหนือพื้นบ้านขึ้นมาคือ โครงสร้างผนัง + ระบบไฟฟ้าในผนัง + ระบบแอร์

แล้วถึงจะมี เฟอร์นิเจอร์ + เครื่องใช้ + ของส่วนตัวของคุณ

ระบบ IT ก็เหมือนกันเลยครับ ไม่ได้มีแค่ “แอป” อย่างเดียว มันประกอบด้วย 9 ชั้น ที่ซ้อนกันตั้งแต่ดิน (network) จนถึงเฟอร์นิเจอร์ (data)

แล้วการเช่า cloud ก็เหมือนการ เช่าบ้านในระดับที่ต่างกัน บางคนเช่าตึกเปล่า (ต้องวางระบบเองทุกชั้น) บางคนเช่าคอนโดพร้อมเฟอร์ (vendor วางทุกอย่างให้ ขนของเข้าก็พอ) บางคนเช่าโรงแรม (แม้แต่ผ้าปูที่นอน vendor ก็เปลี่ยนให้)

มาดู 9 ชั้นนี้ทีละชั้น จากล่าง (ดิน) ขึ้นบน (เฟอร์นิเจอร์) กันเลย

Layer 1 — Network: ถนนของข้อมูล#

Network = ระบบที่ทำให้ข้อมูลเดินทางจากเครื่องหนึ่งไปอีกเครื่องหนึ่ง

ในบ้าน เปรียบเหมือน ถนนหน้าบ้าน + สายโทรศัพท์ + สาย fiber internet ที่เข้าบ้านคุณ ถ้าถนนหน้าบ้านพัง คุณออกจากบ้านไม่ได้ ถ้าสาย fiber ขาด ก็ติดต่อโลกภายนอกไม่ได้

ของในชั้น network แบ่งย่อยได้หลายชิ้น:

• Physical cable — สาย Ethernet, fiber optic, สายไฟ
• Wireless — WiFi, 5G, Bluetooth
• Routing equipment — router, switch, modem
• Protocols — TCP/IP, HTTP, DNS, BGP

Cross-link สำคัญ: เรื่อง network ลึกๆ ผมเขียนไว้ใน EP.26.5 — Network Anatomy: 7 ชั้นของถนน (OSI) แล้ว ถ้าอยากเข้าใจ packet flow + 7 layer ของ OSI ลึก กลับไปอ่านก่อนได้ครับ ใน EP นี้ผมรวบ network เป็นชั้นเดียวเพราะมุมที่เรามองคือ “ใครดูแล” ไม่ใช่ “protocol ทำงานยังไง”

ใครดูแล Network ใน cloud:

• On-Premises — คุณซื้อ switch/router/cable เอง วางสาย fiber เอง จ้างคนดูแลเอง
• IaaS-SaaS — vendor ดูแลให้หมด คุณไม่ต้องคิดเรื่อง network hardware เลย แค่จ่ายค่า traffic

Layer 2 — Storage: โกดังเก็บของ#

Storage = ที่เก็บข้อมูลแบบถาวร (ปิดเครื่องแล้วข้อมูลยังอยู่)

ในบ้าน เปรียบเหมือน โกดัง + ห้องเก็บของ + ตู้เสื้อผ้า ที่เก็บของของครอบครัว ของในโกดังไม่หายไปเวลาปิดไฟบ้าน

ของในชั้น storage แบ่งได้หลายแบบ:

ความเร็วต่างกันมหาศาล — SSD อ่าน 1ms ส่วน Glacier ต้องรอ 4 ชั่วโมงกว่าจะอ่านได้ และราคาก็แปรผกผันกัน เร็วแพง ช้าถูก

ใครดูแล Storage ใน cloud:

• On-Premises — คุณซื้อ SAN/NAS เอง ทำ RAID เอง replicate ระหว่าง data center เอง
• IaaS-SaaS — vendor จัดการ disk physical ให้หมด คุณแค่บอกว่าจะใช้กี่ GB

Layer 3 — Servers: ตัวเครื่องที่รันของจริง#

Servers = hardware ที่มี CPU + RAM + motherboard — เครื่องคอมพิวเตอร์ที่อยู่ใน data center

ในบ้าน เปรียบเหมือน โครงสร้างบ้าน + ผนัง + หลังคา ตัวแกนของบ้านที่ทุกอย่างยึดติดอยู่กับมัน

ของในชั้น server:

• CPU (Intel Xeon, AMD EPYC, Apple M-series, Graviton ของ AWS) — สมองที่คำนวณ
• RAM (ปกติ 32 GB - 4 TB ใน server ระดับ enterprise) — ความจำชั่วคราว
• Motherboard + power supply + cooling — ส่วนที่ทำให้ทุกอย่างทำงานร่วมกันได้
• Rack + data center — บ้านของ server เอง (rack ขนาด 42U, ห้อง server ที่มีไฟ-แอร์-ตู้กันไฟครบ)

ที่หลายคนไม่รู้ — server ใน data center ของ cloud vendor ราคา 200,000 - 2,000,000 บาทต่อเครื่อง และมีอยู่เป็นแสนเครื่องใน data center ขนาดใหญ่ 1 แห่ง

ใครดูแล Servers ใน cloud:

• On-Premises — คุณซื้อ server เอง สร้าง data center เอง (หรือเช่า rack ใน colocation)
• IaaS-SaaS — vendor ซื้อ server เอง สร้าง data center เอง จัดการ hardware failure ให้หมด คุณไม่เคยเห็นเครื่องจริงเลย

Layer 4 — Virtualization: หั่นเครื่องเป็นห้องๆ#

Virtualization = ซอฟต์แวร์ที่ทำให้ server 1 เครื่อง กลายเป็น หลายเครื่อง virtual ที่ทำงานแยกกัน

ในบ้าน เปรียบเหมือน การแบ่งห้อง ในตึกใหญ่ที่มี 100 ห้องนอน ตึกหลังเดียวกัน แต่แต่ละห้องมี กุญแจของตัวเอง + แอร์ของตัวเอง + มองไม่เห็นว่าห้องอื่นกำลังทำอะไร

ของในชั้น virtualization:

• Hypervisor (ซอฟต์แวร์ที่ทำหน้าที่แบ่ง) — VMware ESXi, Microsoft Hyper-V, KVM (Linux), Xen
• Type 1 (bare-metal) — hypervisor รันตรงบน hardware ไม่มี OS ข้างใต้ → ใช้ใน data center ของ vendor
• Type 2 (hosted) — hypervisor รันบน OS ปกติ → VMware Workstation บน laptop ของคุณ
• VM (Virtual Machine) — เครื่อง virtual ที่ hypervisor สร้าง แต่ละตัวคิดว่าตัวเองคือ server เต็มตัว

ทำไมต้อง virtualize — เพราะ server 1 เครื่องที่ราคาล้านบาท ใช้ไม่เคยเต็ม ปกติ CPU ใช้แค่ 10-20% เลยแบ่งเป็น 10 VMs ขายให้ลูกค้า 10 ราย → vendor ได้กำไรเต็มจากเครื่องเดียว ลูกค้าก็ได้ราคาถูกกว่าซื้อ server เอง

นี่แหละครับหัวใจของ cloud จริงๆ — virtualization ทำให้ “ขายเครื่องเครื่องเดียวให้คนหลายราย” เป็นไปได้

ใครดูแล Virtualization ใน cloud:

• On-Premises — คุณซื้อ VMware license เอง วางระบบ hypervisor เอง (หรือจะไม่ใช้ virtualization เลยก็ได้)
• IaaS-SaaS — vendor ดูแล hypervisor ให้หมด คุณเห็นแค่ VM ของตัวเอง ไม่รู้เลยว่ามีใครแชร์ physical server กับคุณอยู่

Layer 5 — Operating System: พนักงานต้อนรับของ hardware#

Operating System (OS) = ซอฟต์แวร์ที่ทำหน้าที่ คุย กับ hardware แทนแอปพลิเคชัน

ในบ้าน เปรียบเหมือน แม่บ้าน ที่รู้จักทุกห้องในบ้าน รู้ว่าไฟอยู่ตรงไหน น้ำเปิดยังไง แอร์ปรับยังไง ลูกบ้านอยากให้แอร์เย็นขึ้นก็แค่บอกแม่บ้าน ไม่ต้องไปกดเครื่อง compressor เอง

ของในชั้น OS:

• Linux (Ubuntu, Red Hat, Amazon Linux, Debian) — ครองตลาด server แทบทั้งหมด
• Windows Server — สำหรับ enterprise ที่ใช้ Microsoft stack (Active Directory, .NET)
• macOS Server — เกือบไม่มีคนใช้แล้ว
• Specialized — Cisco IOS (router), VMware ESXi (hypervisor ที่จริงๆ เป็น OS ในตัว)

OS ทำหน้าที่:

• Process management — รันหลายโปรแกรมพร้อมกัน จัดสรร CPU
• Memory management — จัดสรร RAM ระหว่างโปรแกรม
• File system — จัดการไฟล์บน disk
• Device drivers — คุยกับ hardware ทุกชิ้น (network card, disk, printer)
• Security — user account, file permission

OS Hardening = การตั้งค่า OS ให้ปลอดภัย เช่น ปิด service ที่ไม่ใช้ ลบ default account ทำ patch ทุกสัปดาห์ — เรื่องนี้ผมเขียนไว้ละเอียดกว่าใน CISA D4.32

ใครดูแล OS ใน cloud:

• On-Premises + IaaS — คุณต้องลง OS เอง patch เอง harden เอง
• CaaS-SaaS — vendor ดูแล OS ให้ คุณไม่ต้อง login เข้า server เพื่อ apt-get update เอง

Layer 6 — Container Tech: ตู้คอนเทนเนอร์ที่ใส่แอปไปไหนก็ได้#

Container Technology = ซอฟต์แวร์ที่ห่อ แอปพลิเคชัน + dependencies เป็น กล่องเดียว ที่ขนไปรันได้ทุกที่ที่มี container runtime

ในบ้าน เปรียบเหมือน กล่องบรรจุครัวสำเร็จรูป (kitchen-in-a-box) — ในกล่องมีเตา + เครื่องครัว + วัตถุดิบ + สูตรอาหารพร้อม เอาไปวางบ้านไหนก็ทำอาหารได้ทันที ไม่ต้องสร้างครัวใหม่

ของในชั้น container:

• Docker — แพลตฟอร์มที่ทำให้ container ดังขึ้นมา (เปิดตัวปี 2013)
• containerd — container runtime ที่ Kubernetes ใช้เป็น default
• CRI-O — runtime ทางเลือกสำหรับ Kubernetes
• Image = template ของ container (สร้างไว้ก่อน เก็บใน registry)
• Container = instance ที่กำลังรันอยู่จาก image

ทำไมต้องมี container — เพราะ “ที่บ้านผมรันได้ ที่บ้านคุณรันไม่ได้” เป็นปัญหาที่หลอกหลอน developer มา 30 ปี container แก้ปัญหานี้โดยห่อทุกอย่างที่แอปต้องการ (ทั้ง Python version, library, config) ไว้ในกล่องเดียว เอาไปที่ไหนก็รันได้

Container vs VM — VM ห่อ OS เต็มตัว (หนัก 1-10 GB, boot เป็นนาที) ส่วน Container ห่อ แค่แอป + library (เบา 50-500 MB, boot เป็นวินาที) — เรื่องนี้ลงลึกอีกใน EP.33

ใครดูแล Container Tech ใน cloud:

• On-Premises + IaaS — คุณลง Docker เอง บน OS ของคุณ
• CaaS-SaaS — vendor จัดการ container runtime ให้ คุณแค่ส่ง container image เข้าไป vendor จะรันให้เอง

Layer 7 — Runtime: เครื่องที่ execute code ของคุณ#

Runtime (language runtime) = ซอฟต์แวร์ที่ทำหน้าที่ execute code ที่คุณเขียน — เปลี่ยน source code ให้กลายเป็นการทำงานจริง

ในบ้าน เปรียบเหมือน เชฟ ที่อ่าน สูตรอาหาร ของคุณ แล้วลงมือทำตามนั้น สูตรเป็นแค่กระดาษ เชฟคือคนที่ทำให้เกิดอาหารจริง

ของในชั้น runtime:

• Node.js runtime — รัน JavaScript บน server
• JVM (Java Virtual Machine) — รัน Java bytecode
• Python interpreter (CPython, PyPy) — รัน Python script
• .NET CLR (Common Language Runtime) — รัน C#, F#
• Go runtime — ฝังอยู่ใน binary เลย ไม่ต้องลงแยก
• PHP-FPM — รัน PHP
• Ruby MRI — รัน Ruby

ทำไม runtime สำคัญ — เพราะ code ที่คุณเขียนเป็น text file ที่คอมพิวเตอร์ไม่เข้าใจตรงๆ ต้องมี runtime แปลและ execute ให้ Node.js 18 รัน code ของ Node.js 22 ไม่ได้ (version ผิด) — เลือก runtime version จึงเป็นหนึ่งในการตัดสินใจสำคัญของทีม dev

มุมผู้บริหาร: เวลา dev team บอกว่า “ต้องอัปเกรด Node.js” หรือ “เปลี่ยน Python 2 → 3” — นั่นคือ runtime migration ที่กระทบ application ทุกตัว ใช้เวลาเป็นสัปดาห์-เดือน และเป็น risk ที่ต้องวางแผนล่วงหน้า

Runtime vs Container Tech — Container Tech (Docker) คือ กล่อง ที่ห่อทั้ง runtime + code + library ส่วน Runtime คือ เครื่องที่อยู่ในกล่อง ที่ execute code อีกทีหนึ่ง container 1 ตัวอาจห่อ Node.js runtime + Express framework + code ของคุณรวมกัน

ใครดูแล Runtime ใน cloud:

• On-Premises + IaaS + CaaS — คุณลง runtime เอง บน OS หรือใน container image
• PaaS-SaaS — vendor จัดการ runtime ให้ คุณแค่ส่ง code ขึ้นไป vendor มี runtime รออยู่แล้ว

Layer 8 — Middleware: คนกลางระหว่างแอปกับโลกภายนอก#

Middleware = ซอฟต์แวร์ที่อยู่ ระหว่าง OS กับ Application ทำหน้าที่ที่ application ไม่ต้องเขียนเอง — เช่น รับ HTTP request จัดคิว message เชื่อมต่อ database

นี่แหละครับชั้นที่หลายคนงงที่สุด เพราะ ตารางใน EP.32 ของผมไม่มี Middleware เป็นแถวแยก — ในตารางนั้น Middleware ถูกรวมไว้กับ Runtime แต่ในความเป็นจริงมันเป็นชั้นแยกที่ใหญ่และสำคัญมาก

ในบ้าน เปรียบเหมือน คนใช้ในบ้าน ที่ทำหน้าที่เฉพาะกัน — คนทำสวน (web server) ดูแลรับแขกหน้าบ้าน, คนครัว (app server) ทำงานหลังบ้าน, คนส่งของ (message queue) เอาของจากครัวไปห้องอาหาร, คนรับโทรศัพท์ (API gateway) คัดกรองว่าใครจะติดต่อบ้านได้บ้าง

ของในชั้น middleware แบ่งเป็นหมวดได้แบบนี้:

Web server — รับ HTTP request จาก browser

• nginx — ครองตลาด performance สูง
• Apache HTTP Server — เก่าแก่ที่สุด ยังใช้กันใน enterprise
• Microsoft IIS — สำหรับ Windows + .NET stack
• Caddy — automatic HTTPS modern หน่อย

Application server — รัน server-side logic ที่ซับซ้อนกว่า static web

• Tomcat, JBoss — Java app server
• Gunicorn, uWSGI — Python app server

API Gateway — รับ API call แล้ว route ไปยัง backend service

• Kong, Tyk, Apigee, AWS API Gateway

Message Queue / Streaming — จัดคิวข้อความระหว่าง service

• RabbitMQ, AWS SQS — message queue
• Apache Kafka, AWS Kinesis — event streaming (high throughput)

Database connector / ORM — เชื่อมต่อ database จากใน code

• JDBC (Java), SQLAlchemy (Python), Prisma (Node.js)

Cache — เก็บข้อมูลที่ใช้บ่อยไว้ใน memory

• Redis, Memcached

Service mesh — จัดการการคุยกันระหว่าง microservice

• Istio, Linkerd, Consul

ทำไมต้องมี middleware — เพราะถ้า application ต้องเขียน HTTP server เอง + queue เอง + database driver เอง + caching เองทั้งหมด — จะเขียน business logic ไม่ทันโลก middleware ก็คือส่วนที่ “ใครๆ ก็ต้องใช้” เลยมีคนเขียนสำเร็จรูปขายให้ใช้

ใครดูแล Middleware ใน cloud:

• On-Premises + IaaS + CaaS — คุณลง + ตั้งค่า + ดูแล middleware เอง
• PaaS — vendor มี middleware พร้อมให้ใช้ — AWS Elastic Beanstalk มี nginx, Heroku มี router built-in
• FaaS-SaaS — middleware ฝังอยู่ในระบบ vendor หมด คุณไม่เห็นและไม่ต้องสนใจ

Layer 9 — Application + Data: ของคุณจริงๆ#

Application = code ของคุณ — business logic ที่คุณเขียนขึ้นมาเพื่อแก้ปัญหาธุรกิจ

Data = ข้อมูลของคุณ ที่ application อ่าน / เขียน / แสดงผล

ในบ้าน เปรียบเหมือน เฟอร์นิเจอร์ที่คุณซื้อมา + ของส่วนตัวที่คุณเก็บไว้ในตู้ ตัวบ้าน vendor สร้างให้ แต่เฟอร์นิเจอร์และของในตู้เป็นของคุณตลอด

ตัวอย่าง Application ที่คุ้นเคยกัน:

• Internal: ระบบ ERP, HR system, CRM, accounting system
• External: website, mobile app, e-commerce, customer portal

ตัวอย่าง Data:

• Transactional: order, customer record, financial transaction
• Analytical: sales report, dashboard metric
• Reference: product catalog, employee directory
• Logs: application log, audit trail

เรื่อง Data ว่าเก็บและจัดการยังไง ผมเขียนเป็นซีรีส์เต็มไว้แล้วใน Database 101 — 16 EP ถ้าอยากเข้าใจชั้น data ลึกกว่านี้ กลับไปอ่านที่นั่นได้เลยครับ

ใครดูแล Application + Data ใน cloud:

• ทุก model — คุณดูแล data ของคุณเองเสมอ (กฎทอง)
• Application: คุณดูแลเอง ยกเว้น SaaS ที่ vendor เป็นคนเขียน application ให้
• FaaS: application แบ่งกัน — คุณเขียน function logic ส่วน vendor จัดการ scalability + parallelization + capacity planning + error handling ให้ทั้งหมด

กลับมาที่ตารางใน EP.32 — ทำไมแต่ละ model ดูแลคนละชั้น#

ตอนนี้คุณรู้จัก 9 ชั้นแล้ว ลองกลับไปมองอีกที — ทำไม PaaS ดูแล Runtime แต่ IaaS ไม่ดูแล?

คำตอบอยู่ที่ ลำดับของชั้น และการ outsource ที่ต้องไปเป็นเซ็ต

แต่ละ cloud model = การตัดสินใจว่า vendor ดูแลขึ้นไปถึงชั้นไหน

ตรงไปตรงมาเลยครับ — ยิ่งคุณ outsource ขึ้นไปสูงเท่าไหร่ vendor ก็ต้องดูแลชั้นที่อยู่ใต้คุณทั้งหมด เพราะแต่ละชั้นต้องอาศัยชั้นล่าง — runtime อาศัย OS, OS อาศัย hypervisor, hypervisor อาศัย hardware

ถ้า vendor บอกว่า “ฉัน outsource Runtime ให้ แต่ไม่ดูแล OS” → ไม่เมคเซนส์ เพราะ Runtime รันบน OS ถ้า OS พัง Runtime ก็พังตามไปด้วย vendor ต้องดูแล OS ให้ด้วยเป็นชุด

นี่แหละครับเหตุผลที่ column ในตาราง EP.32 มีสีแดงไล่ขึ้นจากล่าง ไม่ใช่กระจัดกระจาย

มุมผู้บริหาร: ตอนเลือก cloud model ให้ระบบใหม่ — คำถามที่ต้องตอบคือ “ทีมเรามี expertise + bandwidth พอที่จะดูแลชั้นใต้ก่อนถึงชั้นที่เราเลือกให้ vendor ขึ้นไปไหม” ถ้าทีมเล็ก ไม่มี DBA ไม่มี SRE — เลือก SaaS / FaaS / PaaS ดีกว่าครับ แม้จะแพงกว่ารายเดือน เพราะคุณจ่ายค่า “ไม่ต้องมีทีมดูแลชั้นล่าง”

คำถามที่ผู้บริหารควรถาม CIO ได้ทันที#

พอเข้าใจ 9 ชั้นแล้ว ในห้องประชุมครั้งต่อไป ผู้บริหารถามคำถามแหลมๆ แบบนี้ได้เลย:

1. “ระบบ [X] ของเรา outsource ถึงชั้นไหน?” → ตอบไม่ได้ทันที = ทีมไม่รู้ว่าใครรับผิดเวลามี breach
2. “ชั้นไหนที่เรายังดูแลเอง — มี headcount พอไหม?” → ตอบไม่ได้ = ไม่รู้ว่ามีชั้นไหน under-staffed อยู่จนเสี่ยง
3. “ถ้าย้ายระบบ [X] จาก IaaS ไป PaaS — เราจะลด headcount ได้กี่คน เพิ่ม cost เท่าไหร่?” → คำถาม trade-off ที่ตอบได้ก็ต่อเมื่อรู้จัก stack
4. “data ของเราอยู่ในชั้น 9 — เรามี control อะไรบ้าง?” → คำถามที่ board ควรถามทุกครั้งก่อน sign cloud contract
5. “ถ้า vendor หลักของระบบ [X] ปิดบริการพรุ่งนี้ — เราจะย้ายไปไหนและใช้เวลาเท่าไหร่?” → คำถาม vendor lock-in ที่ขึ้นกับชั้นที่ outsource ออกไป

ถ้า CIO ตอบ 5 คำถามนี้ได้ทันทีในทุก critical system = บริษัทเข้าใจ stack ของตัวเองจริง ถ้าตอบไม่ได้ = budget item ของไตรมาสหน้าคือ stack audit

ปิดบท — 9 ชั้นเดียวนี้ใช้ได้กับทุกระบบ#

EP.32.5 จบที่นี่ครับ ผมขอย้ำ 3 เรื่องเล็กๆ ก่อนกลับไปอ่าน EP.33 (Container + Kubernetes) ต่อ:

1. 9 ชั้นนี้ใช้ได้กับทุกระบบ IT — ไม่ใช่แค่ cloud ทุกระบบในโลกประกอบด้วย 9 ชั้นนี้เสมอ cloud แค่เปลี่ยนคำถามจาก “เราซื้ออะไรเอง” เป็น “เราเช่าถึงชั้นไหน” เท่านั้นเอง

2. ชั้น Data เป็นของคุณตลอด — ทุก cloud model vendor ไม่เคยรับผิดต่อ data ที่คุณ upload ของคุณ access ที่คุณ grant password ที่คุณตั้งเอง

3. คนที่เข้าใจ stack = ตัดสินใจ make vs buy ได้ทุกชั้น — ผู้บริหารที่อ่านตาราง EP.32 แล้วเข้าใจชั้นใต้ทุกชั้น = ตัดสินใจ outsource ระบบใหม่ได้แบบรู้ trade-off ไม่ใช่กดตามที่ vendor pitch มา

EP.33 ที่กำลังตามมาจะ zoom เข้าไปที่ Layer 6 (Container Tech) + Kubernetes ซึ่งเป็น orchestrator ของ container — เพราะนี่คือชั้นที่เป็นพระเอกของยุค modern infrastructure (Netflix, Spotify, Uber รัน production บน Kubernetes กันหมด)

→ EP.33 — Container + Kubernetes: ตู้คอนเทนเนอร์และผู้จัดการ warehouse