ผูกกับ Cloud รายเดียว หรือกระจายความเสี่ยงข้าม Provider: กรอบตัดสินใจสำหรับองค์กร

ลองนึกภาพองค์กรที่วางระบบงานหลักไว้บน cloud รายเดียวมาห้าปี ใช้บริการเฉพาะของแพลตฟอร์มนั้นตั้งแต่ฐานข้อมูลไปจนถึงระบบคิวข้อความ เมื่อถึงรอบต่อสัญญาแล้วเงื่อนไขใหม่ไม่เป็นอย่างที่หวัง ทีมจึงเพิ่งพบว่าการย้ายออกไปใช้ผู้ให้บริการรายอื่นต้องเขียนส่วนสำคัญของระบบใหม่เกือบทั้งหมด ไม่ใช่แค่ยกเซิร์ฟเวอร์ไปวางที่ใหม่ นี่คือคำถามที่แพงกว่าที่คิดตอนเริ่มโครงการ ผูกกับ provider เดียวไปให้สุด หรือกระจายไปสองเจ้าเผื่อไว้ก่อน คำตอบไม่ได้อยู่ที่เทคโนโลยีไหนดีกว่ากัน แต่อยู่ที่องค์กรของคุณมีความเสี่ยงแบบไหนที่ต้องป้องกันจริงๆ

ต้นทุนของการผูกกับ Provider เดียว ที่มักไม่ถูกประเมินตั้งแต่ต้น

การใช้บริการเฉพาะของแพลตฟอร์มเดียว เช่น managed database ที่ผูกกับรูปแบบ query เฉพาะ หรือ serverless function ที่เรียกใช้บริการอื่นในระบบนิเวศเดียวกันโดยตรง ทำให้ทีมพัฒนาเร็วขึ้นในช่วงแรก สิ่งที่มักถูกมองข้ามคือต้นทุนสามอย่างที่ตามมา อย่างแรกคือรูปแบบสิทธิ์การเข้าถึงที่ออกแบบมาเฉพาะของแต่ละแพลตฟอร์ม ซึ่งย้ายไปใช้ที่อื่นต้องออกแบบใหม่ทั้งหมด ไม่ใช่แค่ก็อปปี้ค่ากำหนดข้ามไป อย่างที่สองคือสัญญาแบบผูกมัดใช้งานล่วงหน้าหลายปีเพื่อแลกส่วนลด ซึ่งได้ส่วนลดจากราคาปกติจริง แต่แลกมาด้วยการที่ต่อรองรอบใหม่ทำได้ยากขึ้นเพราะสัญญาเดิมยังไม่หมดอายุ และอย่างที่สามคือรูปแบบการเก็บ log และ monitoring ที่ผูกกับเครื่องมือเฉพาะของแพลตฟอร์ม ซึ่งถ้าย้ายออก ประวัติการทำงานย้อนหลังที่สะสมไว้จะไม่ตามไปด้วยเอง ต้นทุนที่แท้จริงคือแรงต่อรองที่หายไปเมื่อถึงรอบต่อสัญญา และค่าเขียนระบบใหม่ถ้าวันหนึ่งจำเป็นต้องย้ายจริง มากกว่าค่าเช่ารายเดือนที่เห็นในใบแจ้งหนี้

ระดับความผูกพันที่ต่างกัน ไม่ใช่ Lock-in ทุกจุดมีน้ำหนักเท่ากัน

สิ่งที่ทำให้การประเมิน lock-in สับสนบ่อยครั้งคือการมองว่าทุกบริการที่ใช้จาก cloud provider มีความเสี่ยงเท่ากันหมด ในความเป็นจริงมีอย่างน้อยสามระดับที่ควรแยกจากกัน ระดับแรกคือชั้นโครงสร้างพื้นฐาน เช่น virtual machine, พื้นที่จัดเก็บข้อมูลแบบมาตรฐาน หรือ container ซึ่งย้ายข้ามผู้ให้บริการได้ค่อนข้างตรงไปตรงมา เพราะแนวคิดเดียวกันมีอยู่ในทุกแพลตฟอร์ม ระดับที่สองคือบริการที่มีมาตรฐานเปิดรองรับ เช่น ฐานข้อมูลที่ใช้ภาษา query มาตรฐาน หรือ message queue ที่ใช้ protocol เปิด ซึ่งย้ายได้จริงแต่ต้องทดสอบความเข้ากันได้ก่อนเสมอ ระดับที่สามคือบริการเฉพาะของแพลตฟอร์มที่ไม่มีคู่เทียบตรงๆ ที่อื่น เช่น ระบบวิเคราะห์ข้อมูลขนาดใหญ่เฉพาะของผู้ให้บริการรายนั้น หรือบริการ AI ที่ฝึกด้วยโมเดลเฉพาะของแพลตฟอร์ม ซึ่งย้ายออกเท่ากับต้องออกแบบส่วนนั้นของระบบใหม่ทั้งหมด บางครั้งความเร็วในการพัฒนาที่ได้จากบริการระดับสามคุ้มกับความเสี่ยงที่แลกมาจริง การตัดสินใจที่ดีจึงอยู่ที่การรู้ตัวว่ากำลังใช้บริการระดับไหนอยู่ และตั้งใจเลือกด้วยเหตุผล แทนการสะสมความเสี่ยงไปทีละบริการตามความสะดวก

ต้นทุนของ Multi-Cloud ที่มักถูกมองข้าม

การกระจายระบบไปสอง cloud ฟังดูเหมือนแก้ปัญหา lock-in ได้ตรงจุด แต่สิ่งที่ตามมาคือทีมต้องดูแลเครื่องมือบริหารจัดการสองชุดคู่ขนาน หน้าอธิบาย Azure Arc ของ Microsoft ซึ่งเป็นเครื่องมือที่สร้างมาเพื่อรวมการบริหารจัดการข้าม cloud เริ่มจากปัญหาเดียวกันนี้ว่า แต่ละสภาพแวดล้อมและแต่ละ cloud มีชุดเครื่องมือบริหารจัดการของตัวเอง และรูปแบบการปฏิบัติงานแบบใหม่นำไปใช้ข้ามทรัพยากรได้ยาก ถ้างาน production ต้องการเครือข่ายเฉพาะระหว่างสอง cloud ก็ต้องลงทุนเพิ่ม เช่น บริการของ Google Cloud ที่จัดสรรการเชื่อมต่อทางกายภาพเฉพาะระหว่างเครือข่ายของ Google กับ cloud อีกราย ซึ่งมีค่า port และ attachment ในทั้งสอง cloud รวมถึงค่าโอนข้อมูลขาออกจาก Google Cloud

นอกจากต้นทุนเครือข่ายแล้ว ยังมีต้นทุนอีกสามอย่างที่นับเป็นตัวเลขยากกว่า แต่จ่ายจริงทุกเดือน อย่างแรกคือการรักษามาตรฐานความปลอดภัยให้เท่ากันในสอง cloud เพราะแต่ละแพลตฟอร์มมีรูปแบบสิทธิ์การเข้าถึง การเข้ารหัสข้อมูล และนโยบายด้านความปลอดภัยที่ไม่เหมือนกัน ทีมความปลอดภัยต้องเรียนรู้และตรวจสอบสองชุดคู่ขนานตลอดเวลา ไม่ใช่ตรวจครั้งเดียวจบ อย่างที่สองคือการมองเห็นต้นทุนโดยรวม เพราะแต่ละ cloud มีเครื่องมือคิดค่าใช้จ่ายและบริหารต้นทุนของตัวเอง การจะเห็นภาพรวมค่าใช้จ่ายทั้งองค์กรต้องพึ่งเครื่องมือที่สามมาช่วยรวมข้อมูล ซึ่งเป็นงานที่ทีมต้องดูแลเพิ่มอีกชั้นหนึ่ง อย่างที่สามคือทักษะของทีมเอง เพราะวิศวกรที่ชำนาญ Google Cloud ไม่ได้แปลว่าจะชำนาญ Azure ในระดับเดียวกันทันที การจะดูแลสอง cloud ให้ดีจริงต้องมีคนที่ชำนาญทั้งสองฝั่ง หรือสองทีมที่ประสานงานกันตลอดเวลา ซึ่งเป็นต้นทุนคนที่จ่ายทุกเดือนไม่ว่าจะใช้ความสามารถของ cloud ที่สองมากแค่ไหน เอกสารของ Google Cloud เองก็เขียนไว้ว่า ในบางกรณี ความท้าทายที่มากับกลยุทธ์ multicloud อาจมีน้ำหนักมากกว่าประโยชน์ที่ได้

สัญญาณที่บอกว่าความเสี่ยงจาก Lock-in คุ้มที่จะป้องกันจริง

มีสามสัญญาณที่ทำให้การป้องกัน lock-in คุ้มกับต้นทุนที่ต้องจ่าย สัญญาณแรกคือข้อกำหนดด้านกฎระเบียบที่องค์กรต้องปฏิบัติ บังคับให้ข้อมูลหรือระบบต้องพร้อมย้ายออกจาก provider ได้ ไม่ใช่แค่ทางเลือกที่ดีถ้าทำได้ สัญญาณที่สองคือระบบนั้นเป็นจุดเดียวที่ทำให้บริการระดับประเทศหยุดชะงักทั้งหมดถ้า provider รายนั้นมีปัญหา เช่น ระบบที่ประชาชนจำนวนมากต้องพึ่งพาในเวลาเดียวกัน หรือโครงสร้างพื้นฐานที่หน่วยงานอื่นต่อเชื่อมมาใช้งานต่อ ความเสี่ยงจากการพึ่งพาผู้ให้บริการรายเดียวในกรณีนี้ขยายจากเรื่องราคาไปเป็นเรื่องความต่อเนื่องของบริการสาธารณะ สัญญาณที่สามคือสัญญาที่กำลังจะเซ็นมีมูลค่าสูงพอที่การเสียแรงต่อรองทั้งหมดในรอบต่อไปจะกระทบงบประมาณอย่างมีนัยสำคัญ เช่น สัญญาที่ผูกมัดใช้งานหลายปีและคิดเป็นสัดส่วนใหญ่ของงบไอทีทั้งปี ถ้าเข้าข่ายข้อใดข้อหนึ่งในสามข้อนี้ การลงทุนออกแบบให้ย้ายได้ตั้งแต่ต้นคุ้มค่ากว่าการแก้ทีหลัง แม้จะทำให้ช่วงเริ่มต้นโครงการช้าลงกว่าเดิมก็ตาม

สัญญาณที่บอกว่า Multi-Cloud คือต้นทุนเพิ่มโดยไม่มีประโยชน์จริง

ในทางกลับกัน ถ้าระบบของคุณมีผู้ใช้งานหลักในองค์กรเดียว ไม่มีข้อบังคับด้านกฎระเบียบที่ต้องพร้อมย้ายข้าม provider และทีมไอทีมีกำลังคนจำกัดอยู่แล้ว การกระจายไปสอง cloud มักไม่ได้ลดความเสี่ยงลงจริง แต่เพิ่มจุดที่ต้องดูแลเป็นสองเท่า provider รายใหญ่ที่มีลูกค้าระดับองค์กรจำนวนมากไม่ได้หายไปในชั่วข้ามคืน ความเสี่ยงที่แท้จริงในกรณีนี้คือทีมงานเองที่ต้องแบ่งเวลาไปดูแลระบบที่ซับซ้อนขึ้น โดยไม่มีใครในองค์กรได้ใช้ประโยชน์จากความสามารถพิเศษของ cloud ที่สองเลย สัญญาณที่ชัดที่สุดคือเมื่อถามทีมว่าทำไมถึงใช้สอง cloud แล้วคำตอบคือเผื่อไว้ก่อน แทนที่จะชี้ได้ว่าระบบไหนได้ประโยชน์อะไรจากการกระจายนั้น ซึ่งมักแปลว่าต้นทุนที่จ่ายอยู่ทุกเดือนไม่ได้แลกกับความปลอดภัยที่เพิ่มขึ้นจริง

ข้อจำกัดที่ต้องยอมรับตรงๆ

ในมุมของเรา multi-cloud แบบใช้งานจริงคู่ขนาน ไม่ใช่แค่มีบัญชีสำรองไว้เฉยๆ เป็นคำตอบที่ผิดสำหรับองค์กรส่วนใหญ่ ถ้าระบบของคุณไม่เข้าข่ายสามสัญญาณข้างต้น การกระจายไปสอง cloud จะทำให้ทีมช้าลงและมีต้นทุนสูงขึ้นโดยไม่ได้ความปลอดภัยเพิ่มขึ้นจริง

คำแนะนำของเราในกรณีนี้คือเลือก provider เดียวให้ชัดเจน แล้วเอาเวลาและงบที่เหลือไปออกแบบให้ระบบหลักของคุณย้ายได้ในระดับที่จำเป็นจริงๆ แทน

ข้อโต้แย้งที่ได้ยินบ่อย

ข้อโต้แย้งที่ได้ยินบ่อยที่สุดคือ ถ้า provider เลิกให้บริการ feature ที่เราพึ่งอยู่ หรือขึ้นราคาแบบไม่มีทางเลือกล่ะ คำถามนี้มีน้ำหนักจริง และคำตอบไม่ใช่การเปิดใช้ cloud ที่สองไว้เผื่อ เพราะนั่นแก้ปัญหาผิดจุด สิ่งที่ควรทำคือแยกสถาปัตยกรรมออกเป็นสองชั้น ชั้นแกนหลักที่เก็บข้อมูลและตรรกะทางธุรกิจสำคัญ ควรออกแบบให้พกพาได้ด้วยเทคโนโลยีที่ไม่ผูกกับ provider ใดเป็นพิเศษ เช่น container หรือฐานข้อมูลมาตรฐานเปิด ส่วนชั้นบนที่ใช้ความสามารถเฉพาะของแพลตฟอร์มเพื่อความเร็วในการพัฒนา ยอมรับได้ว่าผูกกับ provider นั้น เพราะย้ายได้ง่ายกว่าถ้าจำเป็นจริง วิธีนี้ลดความเสี่ยงจาก lock-in ได้มากโดยไม่ต้องแบกต้นทุนดูแลสอง cloud คู่ขนาน

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

จะเริ่มตรงไหน

เริ่มจากสำรวจว่าระบบหลักของคุณใช้บริการเฉพาะของ provider กี่จุด และแต่ละจุดอยู่ในระดับไหนตามสามระดับที่กล่าวไว้ข้างต้น จุดที่อยู่ในระดับสามคือจุดที่ต้องตัดสินใจอย่างตั้งใจ ไม่ใช่ปล่อยให้เกิดขึ้นเองจากความสะดวกตอนพัฒนา จากนั้นตรวจสอบว่าระบบไหนเข้าข่ายสามสัญญาณความเสี่ยงที่กล่าวไว้ข้างต้น หากไม่เข้าข่ายเลย ให้ตัดสินใจเลือก provider เดียวอย่างมั่นใจ และนำเงื่อนไขเรื่องสิทธิ์เข้าถึงข้อมูลและความสามารถในการย้ายระบบไปกำหนดไว้ใน TOR ตั้งแต่รอบแรก ไม่ใช่ไปแก้ตอนมีปัญหาแล้ว หากองค์กรกำลังพิจารณาเขียน TOR สำหรับระบบใหม่อยู่แล้ว บทความ เขียน TOR ระบบอย่างไรให้ได้ระบบที่ดูแลต่อได้ ของเราลงรายละเอียดเงื่อนไขที่ควรใส่ไว้ตั้งแต่ต้น และถ้าโจทย์ของคุณคือระบบเดิมที่ผูกกับ provider แน่นจนต้องตัดสินใจว่าจะรื้อใหม่หรือค่อยๆ แก้ บทความ Legacy System ควร Rewrite ทั้งระบบ หรือค่อยๆ Refactor ตอบคำถามนั้นโดยตรง

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

หากต้องการคุยรายละเอียดของโครงการ ติดต่อเราได้ที่ 088-983-9386 หรืออีเมล [email protected] สำนักงานของเราอยู่ที่บางกะปิ กรุงเทพฯ หากคุยแล้วพบว่าโจทย์ของคุณยังไม่ถึงจุดที่ต้องกังวลเรื่อง lock-in เราจะบอกตรงๆ เพราะการลงทุนป้องกันความเสี่ยงที่ไม่มีอยู่จริง มีต้นทุนสูงกว่าการปล่อยผ่านไป