Lecture 1 — Introduction to Software-Defined Systems

คาบนี้จะพาไปไหนบ้าง

สไลด์วางลำดับเรื่องไว้ 7 หัวข้อ และหน้านี้เดินตามลำดับเดียวกัน

• Software-Defined Systems คืออะไร
• แรงจูงใจ: ทำให้ DevOps และ CI/CD เกิดขึ้นได้จริง
• ส่วนประกอบพื้นฐานของระบบ
• Cloud กับการจัดหาเครื่อง
• Containers
• Deployment Orchestration
• Software-Defined Networks

หัวข้อที่ 1 ถึง 3 คือกรอบความคิด ส่วนหัวข้อที่ 4 ถึง 7 คือของจริงสี่ชิ้นที่จะเรียนกันทั้งเทอม

ระบบคอมพิวเตอร์หนึ่งระบบมีอะไรบ้าง

ก่อนจะพูดว่า software-defined แปลว่าอะไร ต้องเห็นก่อนว่ามีอะไรให้ define บ้าง

สไลด์วางระบบคอมพิวเตอร์เป็นชั้น ๆ จากล่างขึ้นบนสี่ชั้น ล่างสุดคือทรัพยากรจริงที่จับต้องได้ ได้แก่ CPU หน่วยความจำ และดิสก์ ถัดขึ้นมาคือ operating system ที่แบ่งทรัพยากรพวกนั้นให้โปรแกรมใช้ ถัดขึ้นมาอีกคือเครือข่ายที่เชื่อมเครื่องหลาย ๆ เครื่องเข้าด้วยกัน และบนสุดคือแอปพลิเคชันที่รันกระจายอยู่บนหลายเครื่องพร้อมกัน

จุดสำคัญคือ ทุกชั้นมีเวอร์ชัน software-defined ของตัวเอง

ชื่อทางซ้ายทั้งสี่ตัวคือขอบเขตของวิชานี้ทั้งเทอม

• Orchestration (การสั่งงานหลายบริการพร้อมกัน) ดูแลว่าแอปทั้งชุดต้องรันกี่ตัว ตัวไหนก่อนตัวไหน
• Software-Defined Networks (เครือข่ายที่กำหนดด้วยซอฟต์แวร์) ทำให้เส้นทางของแพ็กเก็ตเปลี่ยนได้ด้วยการเขียนโปรแกรม
• Software-Defined Servers (เซิร์ฟเวอร์ที่กำหนดด้วยซอฟต์แวร์) คือการสร้างเครื่องขึ้นมาด้วยคำสั่ง แบ่งย่อยเป็น virtualization, clouds และ containers
• Software-Defined Storage (ที่เก็บข้อมูลที่กำหนดด้วยซอฟต์แวร์) ทำแบบเดียวกันกับดิสก์

Software-Defined Systems คืออะไร

สไลด์ให้นิยามไว้ว่า Software-Defined Systems คือแนวทางในการจัดหา ตั้งค่า เปลี่ยนแปลง และดูแลระบบกับโครงสร้างพื้นฐาน โดยมีสองแกนหลัก

แกนที่หนึ่ง: ใช้ซอฟต์แวร์เป็นตัวกำหนดระบบ

• แยกฮาร์ดแวร์ออกจากซอฟต์แวร์ ไม่ผูกกันแบบเดิม
• ทำทรัพยากรใน data center ให้เป็นของเสมือน แล้วส่งมอบในรูปแบบ as-a-service

แกนที่สอง: ยืมวิธีทำงานของวิศวกรรมซอฟต์แวร์มาใช้กับโครงสร้างพื้นฐาน

• ทำงานอัตโนมัติ
• ขั้นตอนคงเส้นคงวา ทำซ้ำแล้วได้ผลเหมือนเดิม
• มีเวอร์ชัน ทดสอบได้ ย้อนกลับได้ เหมือนที่ทำกับโค้ด

สไลด์ระบุประโยชน์ไว้ 4 ข้อ

ทำไมเรื่องนี้ถึงสำคัญ: DevOps

DevOps (การรวมงานพัฒนากับงานดูแลระบบเข้าด้วยกัน) เกิดมาเพื่อย่นรอบจากพัฒนาไปถึงใช้งานจริงให้สั้นที่สุด สไลด์ระบุเป้าหมายหลักไว้ว่าประกอบด้วย

• Continuous Integration (การรวมโค้ดต่อเนื่อง) คือมี pipeline สำหรับ build, test, approve และ deploy
• การทำโครงสร้างพื้นฐานให้อัตโนมัติ ทั้งการจัดหาและการดูแลทรัพยากร
• การเฝ้าดูและวัดผลอย่างต่อเนื่อง

นิยามที่เป็นทางการ

สไลด์อ้างมาตรฐาน IEEE P2675 DevOps Standard for Building Reliable and Secure Systems Including Application Build, Package, and Deployment ซึ่งนิยาม DevOps ว่าเป็นชุดของหลักการและวิธีปฏิบัติที่เน้นการทำงานร่วมกันและการสื่อสาร ระหว่างทีมพัฒนาซอฟต์แวร์กับเจ้าหน้าที่ฝ่าย IT operations รวมถึงผู้จัดซื้อ ผู้ส่งมอบ และผู้มีส่วนได้ส่วนเสียอื่น ๆ ตลอดวงจรชีวิตของระบบซอฟต์แวร์

สังเกตว่านิยามนี้ไม่ได้พูดถึงเครื่องมือเลยสักตัว มันพูดถึงคนกับวิธีทำงาน

หลักการพื้นฐาน 4 ข้อ

1. Collaboration ทุกฝ่ายที่เกี่ยวข้องทำงานร่วมกัน ไม่ใช่โยนงานข้ามกำแพง
2. Infrastructure as Code (IaC) ทรัพย์สินของระบบถูกเก็บเป็นเวอร์ชัน เขียนเป็นสคริปต์ และแชร์กันได้
3. Automation ทำให้อัตโนมัติทั้ง deployment, testing, provisioning และงานมือทุกอย่างที่คนทำแล้วพลาดได้
4. Monitoring วัดทุกตัวเลขในขั้นพัฒนาและขั้นใช้งานจริง ที่ช่วยบอกได้ว่าควรทำอะไรก่อนหลัง

ข้อ 2 คือจุดที่ DevOps กับ Software-Defined Systems มาบรรจบกัน IaC จะเกิดขึ้นไม่ได้เลยถ้าโครงสร้างพื้นฐานยังสั่งด้วยไฟล์ไม่ได้

ผลที่ได้

สไลด์ไล่ประโยชน์ของ DevOps ไว้ 9 ข้อ

• ความผิดพลาดตอน deploy ลดลง
• ใช้เวลาน้อยลงทั้งตอน deploy และตอนแก้ปัญหาที่เจอ
• ขั้นตอนทำซ้ำได้
• pipeline และตัวแอปพร้อมใช้งานต่อเนื่อง
• มีเวลาเหลือไปคิดของใหม่มากขึ้น
• ตอบสนองความต้องการทางธุรกิจได้ไว
• ตามรอยได้ตลอดวงจรชีวิตของแอป
• ระบบนิ่งขึ้นและคุณภาพดีขึ้น
• ได้ feedback ต่อเนื่อง

เครื่องมือที่จะได้ยินชื่อบ่อย

สไลด์ยกชื่อเครื่องมือที่อยู่ในโลกนี้ขึ้นมาให้เห็นภาพ

สไลด์ยังเปิดภาพ CNCF Landscape (แผนที่รวมเครื่องมือของ Cloud Native Computing Foundation) ให้ดูด้วย ซึ่งมีเครื่องมือหลายร้อยตัวอัดกันเต็มหน้า ประเด็นของสไลด์ไม่ใช่ให้จำ แต่ให้เห็นว่าวงการนี้ใหญ่แค่ไหน และทำไมถึงต้องมีแผนที่นำทาง

CNCF Trail Map: ลำดับที่ควรเดิน

CNCF เสนอลำดับ 10 ขั้นสำหรับทีมที่จะย้ายเข้าสู่โลก cloud native สไลด์ยกมาทั้งหมด

1. Containerization มักทำด้วย Docker container แอปขนาดไหนก็ห่อได้ และเมื่อเวลาผ่านไปควรค่อย ๆ แยกแอปที่เหมาะสมออกเป็น microservices
2. CI/CD ตั้งระบบให้การแก้โค้ดกลายเป็น container ใหม่ที่ถูก build ทดสอบ และ deploy ขึ้น staging โดยอัตโนมัติ พร้อมระบบ rollout และ rollback อัตโนมัติ
3. Orchestration & Application Definition Kubernetes เป็นตัวเลือกหลักของตลาด และ Helm chart ช่วยนิยาม ติดตั้ง และอัปเกรดแอปที่ซับซ้อนได้
4. Observability & Analysis เลือกเครื่องมือสำหรับ monitoring, logging และ tracing เช่น Prometheus, Fluentd และ Jaeger
5. Service Proxy, Discovery & Mesh CoreDNS ใช้ค้นหาบริการ ส่วน Envoy และ Linkerd ทำ service mesh พร้อม health check, routing และ load balancing
6. Networking & Policy ใช้เครือข่ายที่รองรับ CNI เช่น Calico, Flannel หรือ Weave Net และใช้ Open Policy Agent เป็นตัวบังคับนโยบาย
7. Distributed Database & Storage เมื่อฐานข้อมูลตัวเดียวไม่พอ มี Vitess สำหรับ MySQL แบบ sharding, Rook สำหรับจัดการ storage, etcd เป็นที่เก็บสถานะของ Kubernetes และ TiKV เป็น key-value store แบบกระจาย
8. Streaming & Messaging เมื่อ JSON-REST ช้าเกินไป มี gRPC และ NATS
9. Container Registry & Runtime Harbor เก็บ ลงลายเซ็น และสแกน image ส่วน runtime ที่ใช้กันมีทั้ง containerd, rkt และ CRI-O ซึ่งล้วนเป็นไปตามมาตรฐาน OCI
10. Software Distribution ถ้าต้องแจกจ่ายซอฟต์แวร์อย่างปลอดภัย ให้ดู Notary ที่เป็นการนำ The Update Framework มาใช้จริง

ข้อ 1 ถึง 3 คือเนื้อหาหลักของวิชานี้ ส่วนข้อที่เหลือจะได้เจอในวิชาต่อ ๆ ไป

แผนที่ของทั้งวิชา: ระบบสี่ชั้น

สไลด์วางโครงของวิชาไว้เป็นสี่ชั้น แต่ละชั้นส่งของขึ้นไปให้ชั้นที่อยู่เหนือมันใช้

อ่านจากล่างขึ้นบน สายและอุปกรณ์เครือข่ายใน Connectivity Layer ทำให้เครื่องใน Resource Layer คุยกันได้ เครื่องพวกนั้นเป็นที่ให้ container ใน Container Layer รัน และ Orchestration Layer เป็นตัวสั่งว่า container ไหนต้องรันกี่ตัว บนเครื่องไหน

จำโครงนี้ไว้ เพราะสี่หัวข้อที่เหลือของคาบนี้ก็คือสี่ชั้นนี้ อ่านสลับลำดับเล็กน้อย

Cloud: เมื่อการมีเครื่องกลายเป็นการเช่าเครื่อง

นี่คือเหตุผลที่ cloud มีอยู่ สไลด์สรุปมุมมองของผู้ใช้ cloud ไว้ประโยคเดียวว่า cloud computing คือการแปลง IT จาก สินค้า ให้กลายเป็น บริการ

ความต่างอยู่ตรงนี้ ถ้า IT เป็นสินค้า คุณต้องซื้อไว้เผื่อจุดที่คนใช้เยอะที่สุด แล้วแบกต้นทุนนั้นไว้ตลอดปี ถ้า IT เป็นบริการ คุณจ่ายตามที่ใช้จริง

สไลด์ระบุเหตุผลที่ควรใช้ cloud ไว้ 4 ข้อ

เกิดอะไรขึ้นตอนกดขอเครื่องหนึ่งเครื่อง

สไลด์แกะขั้นตอนของ Amazon EC2 ตอนที่ผู้ใช้ขอเครื่องหนึ่งเครื่อง ออกมาเป็น 7 ขั้น

ทั้ง 7 ขั้นไม่มีขั้นไหนที่ต้องมีคนเดินเข้า data center เลย นี่คือ software-defined ในรูปแบบที่ชัดที่สุด

สามวิธีวางแอปลงบนฮาร์ดแวร์

สไลด์เทียบวิธีวางแอปสามแบบ ทั้งสามแบบเรียกรวมกันว่า Software-Defined Servers

Virtualized Deployment ฮาร์ดแวร์หนึ่งเครื่องมี OS แล้วมี hypervisor แบ่งออกเป็น virtual machine หลายตัว แต่ละ VM มี OS ของตัวเองครบชุด

Container Deployment ตัด VM ทิ้ง เหลือ container runtime ตัวเดียวบน OS ของเครื่อง แต่ละ container มีแค่แอปกับไลบรารีที่มันต้องใช้ ไม่มี OS ของตัวเอง จึงเบากว่ามาก

Multi-Tenant Virtualized Container Deployment เอาสองแบบมารวมกัน มี hypervisor แบ่ง VM ก่อน แล้วในแต่ละ VM ค่อยรัน container อีกที แบบนี้ใช้เมื่อต้องแยกขาดระหว่างองค์กร แต่ยังอยากแชร์ทรัพยากรภายในองค์กรเดียวกันได้

สไลด์ไล่คุณสมบัติของทั้งสามแบบไว้ครบ

สามแถวแรกเหมือนกันหมด ที่ต่างกันคือสามแถวล่าง ซึ่งเป็นการแลกกันระหว่างระดับการแยกขาดกับต้นทุน

Containers: เขียนครั้งเดียว รันที่ไหนก็ได้

สไลด์ตอบว่า ต้องห่อโปรแกรมไว้ในหน่วยที่ยืนได้ด้วยตัวเอง มีทุกอย่างที่โปรแกรมต้องใช้อยู่ข้างใน ทั้งโค้ด ไลบรารี และ runtime แล้วหน่วยนั้นต้องรันบนเครื่องต่างกันได้

จาก Dockerfile ถึง container ที่กำลังรัน

Docker (เครื่องมือสร้างและรัน container ที่ใช้กันแพร่หลายที่สุด) แยกเรื่องนี้เป็นสามสิ่งที่ต้องไม่สับสนกัน

image หนึ่งก้อนสร้าง container ได้หลายตัวพร้อมกัน เหมือนไฟล์โปรแกรมหนึ่งไฟล์เปิดเป็นหลาย process ได้

ในตัว Dockerfile จะรวมสี่อย่างเข้าด้วยกัน คือโค้ด ค่าตั้งค่า รายการ dependency และ runtime engine เมื่อ build ออกมาแล้ว ทุกอย่างนี้ถูกผนึกไว้ในก้อนเดียว

บนเครื่องที่รัน โครงจะเป็นชั้น ๆ ตามนี้ คือ infrastructure อยู่ล่างสุด ถัดขึ้นมาคือ host operating system ถัดขึ้นมาคือ Docker และบนสุดคือ container ของแอปหลาย ๆ ตัวที่รันเคียงกันอยู่

ลำดับการทำงานจริงเมื่อพัฒนาแอปแบบ container

สไลด์วางลำดับไว้ 7 ขั้น

Deployment Orchestration: เมื่อแอปมีมากกว่าหนึ่งชิ้น

container แก้ปัญหาว่าโปรแกรมหนึ่งตัวจะรันที่ไหนก็เหมือนกัน แต่แอปจริงไม่ได้มีตัวเดียว

เหตุผลที่หนึ่ง: dependency ชนกัน แอปเวอร์ชัน 1.5 ต้องใช้ไลบรารีชุดหนึ่ง ส่วนเวอร์ชัน 1.6 ต้องใช้อีกชุดที่เลขเวอร์ชันไม่ตรงกัน พอสองเวอร์ชันต้องอยู่บนเครื่องเดียวกัน ก็ชนกัน

เหตุผลที่สอง: มีหลายสภาพแวดล้อม เครื่อง Dev อยู่ที่ IP 10.0.1.40 มี webapp กับ service อย่างละตัว เครื่อง Test อยู่ที่ 11.5.1.93 หน้าตาคล้ายกัน แต่ Production อยู่ที่ 35.8.4.1 กับ 35.8.4.2 มี webapp สองตัวและ service สามตัว โครงไม่เหมือนกันสักเครื่อง แปลว่าทดสอบผ่านบน Test ไม่ได้แปลว่าจะผ่านบน Production

เหตุผลที่สาม: ขั้นตอน deploy ยาวและเปราะ สไลด์ยกตัวอย่างขั้นตอนจริงมาให้ดู

adduser dbadm:pass1
setenv DB_HOST= 35.8.4.1, 35.8.4.2
pip install db_driver
mkdir /opt/db
db_install
chown -r dbadm .
chmod 777 -r /opt/db
start service_A
# หลัง service_A ขึ้นแล้ว จึงสั่ง
start service_B
# รอจน service_B พร้อม จึงสั่ง
init main

เหตุผลที่สี่: ระบบเปลี่ยนตลอดเวลา สไลด์ยกผลสำรวจที่เทียบองค์กร IT สามระดับ

สไลด์เขียนตัวเลขจริงกำกับไว้ด้วยว่า Amazon deploy ทุก 11.6 วินาที Netflix ใช้เวลาจากคอมมิตถึงขึ้นจริง 16 นาที และ Amazon มีอัตราการเปลี่ยนแปลงที่ทำให้พังราว 0.001%

ตัวเลขพวกนี้เป็นไปไม่ได้เลยถ้ายังพิมพ์คำสั่งเองทีละบรรทัด

ทางออก: เขียนสิ่งที่ต้องการลงไฟล์

version: "3.8"
services:
  todo:
    image: "todo:release-2"
    container_name: todo
    ports:
      - 8000:8000
    environment:
      REDIS_HOST: redis
    networks:
      - todo-net
  webapp:
    image: "todo-webapp:release-1"
    container_name: webapp
    stdin_open: true
    ports:
      - 3000:3000
  redis:
    image: "redis:7.0.12"
    container_name: redis
    networks:
      - todo-net
networks:
  todo-net: {}

สั่ง docker compose up ครั้งเดียว ได้ผลลัพธ์แบบนี้

หมายเหตุเล็กน้อย สไลด์ติดป้ายบริการ todo ว่า Front-End Service และ webapp ว่า Back-End Service ซึ่งดูจะสลับกันกับสิ่งที่ไฟล์บอก เพราะ todo คือตัวที่คุยกับ Redis ส่วน webapp คือตัวที่เปิดพอร์ต 3000 ให้เบราว์เซอร์เข้า ให้ยึดตามไฟล์เป็นหลัก

ได้อะไรกลับมา

สไลด์สรุปประโยชน์ของ deployment orchestration ไว้ 5 ข้อ

• ทำให้การ deploy แอปที่ซับซ้อนง่ายขึ้น
• ลดความผิดพลาดที่เกิดจาก dependency และจากคน
• deploy ได้เร็วขึ้นและมีประสิทธิภาพกว่าเดิม
• ทำ automated test และ regression test ได้สะดวก
• ย้อนกลับไปเวอร์ชันก่อนหน้าได้เมื่อต้องการ

Software-Defined Networks: ยกสมองออกจากอุปกรณ์

สามหัวข้อที่ผ่านมาอยู่ในโลกของเครื่องและโปรแกรม หัวข้อสุดท้ายลงไปที่ชั้นล่างสุด คือเครือข่าย

Middlebox: กล่องที่โผล่มาเต็มเครือข่าย

RFC 3234 นิยาม Middlebox (กล่องที่แทรกอยู่กลางทาง) ว่าเป็นกล่องใด ๆ ที่แทรกอยู่บนเส้นทางระหว่างต้นทางกับปลายทาง แล้วทำงานอื่นนอกเหนือจากงานมาตรฐานของ IP router

สไลด์ไล่ให้ดูว่ามันอยู่ทุกที่จริง ๆ

ทิศทางที่วงการเดินไปมีสี่ขั้น

1. เริ่มจากฮาร์ดแวร์ปิดเฉพาะของแต่ละเจ้า
2. ขยับไปใช้ฮาร์ดแวร์แบบ whitebox ที่เปิด API มาตรฐานให้
3. ทำให้ตัวอุปกรณ์โปรแกรมได้ในระดับพื้นฐาน ด้วยรูปแบบ match กับ action
4. ย้ายการแข่งขันไปอยู่ที่ซอฟต์แวร์ โดย SDN รวมศูนย์การควบคุมและการตั้งค่าไว้ทางตรรกะที่เดียว ส่วน Network Functions Virtualization (การทำหน้าที่ของอุปกรณ์เครือข่ายให้เป็นซอฟต์แวร์) ทำให้บริการเครือข่ายรันบนเครื่องธรรมดาได้

ทำไมอินเทอร์เน็ตถึงยอมให้ทำแบบนี้ได้

ต้องย้อนไปที่รูปทรงของโปรโตคอลอินเทอร์เน็ต

ชั้น network มีโปรโตคอลเดียวคือ IP และทุกอุปกรณ์ที่ต่ออินเทอร์เน็ตหลายพันล้านเครื่องต้องพูดมันได้ ส่วนชั้นอื่นมีทางเลือกมากมาย ชั้นบนมี HTTP, SMTP, QUIC, DASH, RTP ชั้นล่างมี Ethernet, WiFi, Bluetooth, PPP, PDCP และลงไปถึงสายทองแดง คลื่นวิทยุ และไฟเบอร์ คอขวดตรงกลางนี้เรียกว่า thin waist

สไลด์เล่นมุกต่อว่า พอนาฬิกาทรายอายุมากขึ้น มันก็มี "ห่วงยางรอบเอว" ขึ้นมา ซึ่งก็คือ middlebox ทั้งหลายอย่าง NAT, firewall, cache และ NFV ที่ไปทำงานอยู่ข้างใน network แทนที่จะอยู่ที่ขอบ

ความฉลาดควรอยู่ตรงไหน

RFC 1958 บันทึกหลักคิดของอินเทอร์เน็ตไว้ว่า เป้าหมายคือการเชื่อมต่อ เครื่องมือคือ Internet Protocol และความฉลาดอยู่ที่ปลายทางทั้งสองข้าง ไม่ใช่ซ่อนอยู่ใน network

RFC เดียวกันยังตั้งข้อสังเกตไว้อย่างตรงไปตรงมาว่า หลายคนในชุมชนอินเทอร์เน็ตจะเถียงว่ามันไม่มีสถาปัตยกรรม มีแต่ธรรมเนียมที่ไม่เคยถูกเขียนลงกระดาษเลยตลอด 25 ปีแรก

ความเชื่อหลักสามข้อคือ การเชื่อมต่อต้องเรียบง่าย IP คือคอขวดที่แคบตรงกลาง และความซับซ้อนกับความฉลาดควรอยู่ที่ขอบของเครือข่าย

สไลด์เทียบสามยุคให้ดู

แยก control plane ออกจาก data plane

หัวใจของ SDN คือการแยกสองงานนี้ออกจากกัน

• Data plane (ส่วนที่ส่งแพ็กเก็ตจริง) คือการรับแพ็กเก็ตเข้ามาแล้วส่งออกไปทางไหน ทำงานเร็วมาก ระดับทุกแพ็กเก็ต
• Control plane (ส่วนที่ตัดสินใจเส้นทาง) คือการคำนวณว่าตารางส่งต่อควรมีหน้าตาอย่างไร ทำงานนาน ๆ ครั้ง

แบบเดิม ทุก router รัน routing algorithm ของตัวเอง แล้วคุยกันผ่านโปรโตคอลจนได้ตารางส่งต่อของแต่ละตัว เมื่อแพ็กเก็ตเข้ามา router จะอ่านค่าใน header แล้วเทียบกับตารางว่าจะส่งออกทางพอร์ตไหน

แบบ SDN ยก routing algorithm ออกไปไว้ที่ remote controller ตัวเดียว controller คำนวณตารางให้ทุกตัวแล้วส่งลงไปติดตั้ง ตัวอุปกรณ์เหลือแค่หน้าที่ส่งแพ็กเก็ตตามตาราง

สไลด์ให้เหตุผลว่าทำไมการรวมศูนย์ทางตรรกะถึงดีกว่า

• จัดการง่ายกว่า ลดโอกาสตั้งค่า router ผิด และปรับเส้นทางของ traffic ได้ยืดหยุ่นกว่า
• โปรแกรม router ได้ การส่งต่อแบบอิงตาราง เช่นที่ OpenFlow API ทำ เปิดให้เขียนโปรแกรมสั่ง router ได้ การคำนวณตารางที่เดียวแล้วแจกออกไปนั้นง่ายกว่าการให้ทุกตัวคำนวณเองแล้วมาตกลงกัน
• เปิด ไม่ผูกกับเจ้าใดเจ้าหนึ่ง เมื่อ control plane เป็นของเปิด ใครก็เข้ามาทำของใหม่ได้

สี่อย่างที่ทำให้เครือข่ายหนึ่งเป็น SDN

1. การส่งต่อแบบอิง flow ในรูปแบบทั่วไป เช่น OpenFlow
2. แยก control plane ออกจาก data plane
3. ฟังก์ชันของ control plane อยู่นอกตัว switch ที่ทำหน้าที่ data plane
4. มี control application ที่โปรแกรมได้อยู่ข้างบน เช่น routing, access control และ load balancing

ข้อ 4 คือจุดที่น่าสนใจที่สุด เพราะมันแปลว่าฟังก์ชันเครือข่ายกลายเป็นแอปพลิเคชันที่เขียนเพิ่มเองได้

สิ่งที่ยังเป็นโจทย์อยู่

สไลด์ปิดหัวข้อด้วยความท้าทายที่ยังแก้ไม่จบ

• ทำให้ control plane แข็งแรงพอ ต้องเป็นระบบกระจายที่เชื่อถือได้ ทนต่อความล้มเหลว ขยายขนาดได้ และปลอดภัย โดยออกแบบความปลอดภัยเข้าไปตั้งแต่วันแรก ไม่ใช่มาแปะทีหลัง
• รองรับความต้องการเฉพาะทาง เช่นเครือข่ายที่ต้อง real-time หรือต้องเชื่อถือได้และปลอดภัยระดับสูงมาก
• ขยายไปทั้งอินเทอร์เน็ต ตอนนี้ SDN ทำงานได้ดีภายในองค์กรเดียว การขยายข้าม autonomous system ยังเป็นโจทย์
• 5G SDN เป็นชิ้นส่วนสำคัญของเครือข่ายมือถือ 5G

คำถามปลายเปิดที่สไลด์ทิ้งไว้คือ ในอนาคตฟังก์ชันของเครือข่ายจะถูกทำด้วยโปรโตคอลแบบกระจายต่อไป หรือจะถูกคำนวณจากส่วนกลางแบบ SDN สไลด์ยกตัวอย่างว่าแม้แต่ congestion control ก็อาจย้ายมาทำแบบรวมศูนย์ได้ โดยให้ controller กำหนดอัตราการส่งของแต่ละต้นทาง จากระดับความแออัดที่ router รายงานเข้ามา

ทุกอย่างมาบรรจบกันตรงไหน

กลับไปที่รูปแรกอีกครั้ง ทั้งสี่หัวข้อที่ผ่านมาคือชั้นเดียวกันนั้น

• Cloud ทำให้ได้ เครื่อง มาด้วยคำสั่ง
• Container ทำให้ โปรแกรม รันที่ไหนก็เหมือนกัน
• Orchestration ทำให้ แอปทั้งชุด ขึ้นมาพร้อมกันได้จากไฟล์เดียว
• SDN ทำให้ เครือข่าย ที่เชื่อมทุกอย่างถูกสั่งด้วยโปรแกรมได้

ทั้งสี่อย่างใช้ความคิดเดียวกัน คือย้ายสิ่งที่เคยต้องทำด้วยมือกับของจริง ไปเป็นไฟล์ที่ซอฟต์แวร์อ่านแล้วลงมือทำแทน พอมันเป็นไฟล์ ทุกวิธีที่วงการซอฟต์แวร์ใช้กับโค้ดมาสามสิบปี ทั้งการเก็บเวอร์ชัน การทดสอบ การ review และการย้อนกลับ ก็ใช้กับโครงสร้างพื้นฐานได้ทันที