On-Premise หรือ Cloud: เลือกอย่างไรให้เหมาะกับธุรกิจไทย
เลือก Cloud สำหรับงานที่ปริมาณแปรผัน การเติบโตเร็ว และระบบที่ท่านอยากให้คนอื่นดูแลแทน เลือก On-premise สำหรับงานที่โหลดคงที่คาดการณ์ได้ ระบบที่ไวต่อ Latency และข้อมูลที่ต้องอยู่ในองค์กรตามกฎหมายหรือสัญญา ธุรกิจไทยส่วนใหญ่ลงเอยแบบไฮบริด ซึ่งเป็นปลายทางที่ถูกต้อง ไม่ใช่การตัดสินใจไม่ได้
การถกเรื่อง Cloud กับ On-premise มักถูกนำเสนอว่าจบแล้ว แต่ยังไม่จบ คำตอบที่ถูกขึ้นกับรูปแบบของภาระงาน ความอ่อนไหวของข้อมูล และข้อจำกัดที่มักเฉพาะกับการทำธุรกิจในไทย ทั้งภาระตาม PDPA กฎการจัดซื้อจัดจ้างภาครัฐ และความเป็นจริงเรื่องคุณภาพอินเทอร์เน็ตนอกเมืองใหญ่
บทความนี้เป็นกรอบการตัดสินใจ ไม่ใช่การเชียร์ฝ่ายใดฝ่ายหนึ่ง เราวางและดูแลทั้งสองแบบ
On-premise กับ Cloud เปรียบเทียบแบบสั้น
Cloud เปลี่ยนรายจ่ายลงทุนเป็นรายจ่ายดำเนินงานและโยนปัญหาฮาร์ดแวร์ออกไป โดยแลกกับค่าใช้จ่ายต่อเนื่องที่โตตามการใช้งาน ส่วน On-premise ต้องลงทุนก้อนแรกและต้องมีทีมที่ทำเป็น แต่ถูกกว่าสำหรับโหลดคงที่ในกรอบ 3–5 ปี และให้ท่านควบคุมข้อมูลได้ทางกายภาพ
ตารางด้านล่างคือมุมที่การตัดสินใจส่วนใหญ่ใช้จริง สังเกตว่า "ต้นทุน" พลิกไปมาขึ้นกับกรอบเวลาที่ใช้วัด ซึ่งเป็นสาเหตุความเห็นไม่ตรงกันที่พบบ่อยที่สุดในเรื่องนี้ และทั้งสองฝ่ายมักถูกทั้งคู่ แค่พูดถึงคนละช่วงเวลา
| ปัจจัย | On-premise | Cloud |
|---|---|---|
| ต้นทุนก้อนแรก | สูง ทั้งฮาร์ดแวร์ ลิขสิทธิ์ และการติดตั้ง | เกือบเป็นศูนย์ |
| ต้นทุนรวม 3–5 ปี | ถูกกว่าสำหรับโหลดคงที่คาดการณ์ได้ | ถูกกว่าสำหรับโหลดแปรผันหรือกำลังโต |
| การขยายเพิ่ม | เป็นสัปดาห์ ต้องจัดซื้อและติดตั้ง | เป็นนาที |
| การลดขนาด | แทบทำไม่ได้ เพราะซื้อฮาร์ดแวร์มาแล้ว | ทำได้ทันที และหยุดจ่ายทันที |
| ที่ตั้งข้อมูล | ท่านควบคุมทางกายภาพ | ขึ้นกับ Region ที่เลือก ควรระบุไว้ในสัญญา |
| ใครดูแล | ท่านเอง หรือผู้ให้บริการที่จ้าง | แบ่งกัน ผู้ให้บริการดูแลแพลตฟอร์ม ท่านดูแลสิ่งที่อยู่บนนั้น |
| รูปแบบความล้มเหลว | ฮาร์ดแวร์เสีย ไฟดับ แอร์เสีย น้ำท่วม | ผู้ให้บริการล่ม ตั้งค่าผิด บิลบานปลาย |
| เหมาะกับ | โหลดคงที่ ไวต่อ Latency ต้องการอธิปไตยข้อมูล | โหลดแปรผัน โตเร็ว ทีมกระจายหลายที่ |
เมื่อ Cloud คือคำตอบที่ถูก
Cloud ชนะเมื่อภาระงานแปรผันหรือคาดเดาไม่ได้ เมื่อท่านโตเร็วจนการวางแผนความจุกลายเป็นการเดา เมื่อทีมกระจายอยู่หลายที่ หรือเมื่อท่านไม่อยากจ้างทักษะที่จำเป็นต่อการดูแลฮาร์ดแวร์ให้ดีจริง
สำหรับแอปพลิเคชันใหม่ส่วนใหญ่ การเริ่มที่ Cloud เป็นค่าเริ่มต้นที่สมเหตุสมผล ข้อได้เปรียบชี้ขาดไม่ใช่ราคา แต่คือท่าน "เดาผิดเรื่องความจุได้โดยไม่แพง" On-premise ลงโทษการพยากรณ์ผิดทั้งสองทาง จัดน้อยไปก็ติดขัดเป็นสัปดาห์ จัดมากไปก็ซื้อฮาร์ดแวร์มานั่งว่างห้าปี
ความเสี่ยงของ Cloud ในไทยที่ต้องพูดตรง ๆ คือบิลไหลขึ้นเงียบ ๆ ค่าใช้จ่ายที่เริ่มจากน้อยจะโตขึ้นเรื่อย ๆ ตามที่เพิ่มระบบเข้าไป และหากไม่มีคนทบทวนค่าใช้จ่ายทุกเดือน ระบบ Cloud ที่ถูกกว่าในปีแรกมักแพงกว่าเมื่อถึงปีที่สาม ควรตั้งงบสำหรับการกำกับดูแล ไม่ใช่แค่ค่าประมวลผล
เมื่อ On-premise ยังเป็นคำตอบที่ถูก
On-premise ยังถูกต้องสำหรับภาระงานที่คงที่คาดการณ์ได้ในกรอบ 3–5 ปี ระบบที่ไวต่อ Latency เช่น ระบบควบคุมการผลิตหรือ POS และกรณีที่อธิปไตยข้อมูลเป็นข้อกำหนดทางกฎหมาย สัญญา หรือการจัดซื้อ ซึ่งในไทยมักใช้กับหน่วยงานรัฐและภาคที่มีกฎกำกับ
การจัดซื้อจัดจ้างภาครัฐไทยโดยเฉพาะ มักกำหนดให้ข้อมูลต้องอยู่ในองค์กรหรือในประเทศทางกายภาพ ข้อนี้ไม่ใช่ความชอบส่วนตัวที่จะโต้แย้งด้วยการออกแบบ Cloud Region ให้ดี เมื่อข้อกำหนดนี้บังคับใช้ มันตัดสินคำถามทันที นี่คือเหตุผลที่เราสร้าง VG-X เป็นแพลตฟอร์ม AI ภาษาไทยแบบ On-premise แทนที่จะเป็นบริการแบบโฮสต์
อีกปัจจัยที่พูดถึงกันน้อยคือคุณภาพการเชื่อมต่อ ธุรกิจในกรุงเทพฯ สมมติได้ว่าอินเทอร์เน็ตมีตลอด แต่โรงงานในนิคมอุตสาหกรรมต่างจังหวัดมักสมมติแบบนั้นไม่ได้ และระบบที่หยุดทำงานเมื่อสายหลุด ไม่ใช่การออกแบบที่ยอมรับได้สำหรับงานที่ต้องเดินตลอด
- มีข้อกำหนดทางกฎหมาย สัญญา หรือการจัดซื้อ ที่บังคับให้ข้อมูลอยู่ในประเทศหรือในองค์กรหรือไม่
- ระบบต้องทำงานต่อได้เมื่ออินเทอร์เน็ตหลุดหรือไม่
- ภาระงานคงที่พอที่จะกำหนดขนาดฮาร์ดแวร์ได้แม่นยำสำหรับสามปีหรือไม่
- ท่านมี หรือยอมจ่ายเพื่อให้มี ความสามารถในการดูแลฮาร์ดแวร์อย่างถูกต้องหรือไม่ ทั้งการแพตช์ การทดสอบสำรองข้อมูล และความปลอดภัยทางกายภาพ
- ค่า Latency ระดับหลักหน่วยมิลลิวินาทีเป็นข้อกำหนดเชิงฟังก์ชันหรือไม่
ไฮบริดคือปลายทาง ไม่ใช่การประนีประนอม
ธุรกิจไทยขนาดกลางขึ้นไปส่วนใหญ่ลงเอยแบบไฮบริด คือเก็บระบบที่อ่อนไหวหรือโหลดคงที่ไว้ On-premise และวางงานที่แปรผันและติดต่อลูกค้าไว้บน Cloud นี่คือสถาปัตยกรรมที่ดี ไม่ใช่การตัดสินใจไม่ได้ เป้าหมายคือจับคู่ภาระงานกับสภาพแวดล้อมที่รองรับได้ดีที่สุด ไม่ใช่ความบริสุทธิ์ทางเทคนิค
รูปแบบที่พบบ่อยและได้ผลคือเก็บ ERP หรือฐานข้อมูลหลักไว้ On-premise ที่ซึ่งโหลดคาดการณ์ได้และข้อมูลอ่อนไหว ขณะที่รันเว็บไซต์ พอร์ทัลลูกค้า และงานวิเคราะห์บน Cloud ที่ซึ่งทราฟฟิกขึ้นลงแรง จากนั้นให้การสำรองข้อมูลวิ่งสวนทางกัน คืองาน Cloud สำรองลง On-premise และงาน On-premise สำรองขึ้น Cloud ซึ่งให้การป้องกันแบบนอกสถานที่จริงทั้งสองทาง
สิ่งที่ทำให้ไฮบริดล้มเหลวไม่ใช่สถาปัตยกรรม แต่คือช่องว่างในการดูแล มีสองสภาพแวดล้อม สองชุดทักษะ สองระบบ Monitor และไม่มีใครเห็นภาพครบ หากจะทำไฮบริด การตัดสินใจที่สำคัญที่สุดคือใครถือแผนที่ทั้งใบ
แหล่งอ้างอิง
ต้องการความช่วยเหลือเรื่องนี้ไหม?
บริการดูแลโครงสร้างพื้นฐาน IT