องค์กรจำนวนไม่น้อยอยากได้ประโยชน์จาก cloud ทั้งความคล่องตัว การขยายระบบตามความต้องการ และการลดภาระดูแลโครงสร้างพื้นฐานเอง แต่ในความเป็นจริงยังมีระบบเดิม ข้อจำกัดด้านการปฏิบัติตามกฎระเบียบ หรือโหลดงานที่ไวต่อ latency ที่ย้ายขึ้น cloud ทั้งหมดไม่ได้ในเวลาอันใกล้ hybrid หรือการผสมผสานระหว่างระบบ on-premise กับ cloud จึงมักเป็นทางเลือกที่สมจริงที่สุดสำหรับองค์กรเหล่านี้ ไม่ใช่การประนีประนอมหรือความล้มเหลวที่ "ไปไม่สุดทาง" อย่างที่หลายคนเข้าใจ
ทำไมองค์กรไทยจำนวนมากเลือก Hybrid แทน All-in Cloud
เหตุผลที่องค์กรเลือกแนวทาง hybrid มีหลายด้าน และส่วนใหญ่มาจากบริบทจริงของธุรกิจ ไม่ใช่ความลังเลใจ
- ระบบและฮาร์ดแวร์ on-premise ที่ลงทุนไปแล้วยังทำงานได้ดี การทิ้งทั้งหมดเพื่อย้ายขึ้น cloud ทันทีไม่คุ้มค่าและเพิ่มความเสี่ยงโดยไม่จำเป็น
- ข้อจำกัดเรื่อง data residency หรือข้อกำหนดด้านกฎระเบียบที่ต้องเก็บข้อมูลบางประเภทไว้ในประเทศ หรือในระบบที่องค์กรควบคุมเองได้
- บางโหลดงานประหยัดกว่าหรือเร็วกว่าเมื่อรันบนระบบ local โดยเฉพาะงานที่ต้องการ latency ต่ำมาก
- ต้องการย้ายระบบแบบค่อยเป็นค่อยไป ทดสอบทีละส่วน แทนที่จะกระโดดข้ามไปทั้งหมดในครั้งเดียวซึ่งมีความเสี่ยงสูง
ความเสี่ยงที่มักถูกมองข้าม
การมีสองสภาพแวดล้อมพร้อมกันก็มาพร้อมความเสี่ยงเฉพาะตัวที่หลายองค์กรเพิ่งมาเจอทีหลัง
- การตั้งค่าที่ผิดพลาด (misconfiguration) เช่น เปิดสิทธิ์เข้าถึงกว้างเกินจำเป็น หรือพื้นที่จัดเก็บข้อมูลที่เปิดสู่สาธารณะโดยไม่ตั้งใจ
- ความเข้าใจที่คลาดเคลื่อนเรื่อง shared responsibility model — ผู้ให้บริการ cloud ดูแลความปลอดภัยของ "ตัวแพลตฟอร์ม" แต่การตั้งค่าการเข้าถึง ข้อมูล และแอปพลิเคชันยังเป็นหน้าที่ขององค์กรเอง
- การมองเห็นและติดตามระบบ (visibility และ monitoring) ที่ไม่ครอบคลุมทั้งสองฝั่งอย่างสม่ำเสมอ ทำให้เกิดจุดบอดที่เครื่องมือ security ฝั่งหนึ่งมองไม่เห็นสิ่งที่เกิดขึ้นอีกฝั่ง
Disaster Recovery ต้องออกแบบตั้งแต่ต้น
สภาพแวดล้อมแบบ hybrid ต้องมีแผน DR (Disaster Recovery) ที่ครอบคลุมทั้งสองฝั่งตั้งแต่ขั้นตอนออกแบบ ไม่ใช่มาคิดเพิ่มทีหลัง คำถามที่ต้องตอบให้ได้ตั้งแต่แรก ได้แก่ ข้อมูลสำรอง (backup) เก็บไว้ที่ไหน กระบวนการ failover ทำงานอย่างไรหากสภาพแวดล้อมฝั่งใดฝั่งหนึ่งล่ม และที่สำคัญไม่แพ้กันคือ แผนนี้ถูกทดสอบจริงบ่อยแค่ไหน แผน DR ที่ไม่เคยถูกทดสอบเลย ก็ไม่ต่างอะไรจากการไม่มีแผน
hybrid ไม่ใช่จุดพักระหว่างทางไปสู่ cloud เต็มรูปแบบ แต่หากออกแบบมาอย่างดี มันคือสถาปัตยกรรมที่ตั้งใจดึงจุดแข็งของทั้งสองโลกมาใช้ร่วมกัน
หลักการออกแบบที่ควรยึด
กำหนดให้ชัดเจนว่าโหลดงานใดควรอยู่ที่ไหนและเพราะเหตุใด ใช้นโยบายความปลอดภัยและการตรวจติดตามชุดเดียวกันครอบคลุมทั้งสองสภาพแวดล้อม แทนที่จะแยกดูแลกันคนละส่วน และทดสอบแผน DR/failover ตามรอบที่กำหนดอย่างสม่ำเสมอ ไม่ใช่ทดสอบเพียงครั้งเดียวตอนเริ่มใช้งาน
