Cloud Foundation and Migration: Build the foundation before moving workloads
วาง Identity, Network, Governance และ Operations ก่อนเลือกย้าย workload ไป Azure, AWS หรือ Google Cloud
การย้าย VM ขึ้น Cloud อาจทำได้รวดเร็ว แต่คำถามที่ตามมาคือใครเข้าถึงระบบได้ ค่าใช้จ่ายเป็นของทีมใด จะเชื่อมกลับสำนักงานอย่างไร และใครตอบสนองเมื่อเกิดปัญหา หากยังตอบไม่ได้ การย้ายสำเร็จอาจเพียงเปลี่ยนที่อยู่ของความเสี่ยงเดิม
Cloud Foundation คือการตัดสินใจและวางระบบส่วนกลางที่ workload ต่าง ๆ ใช้ร่วมกัน ส่วน Migration คือการย้ายแต่ละระบบเข้าสู่สภาพแวดล้อมนั้น ทั้งสองงานต้องเชื่อมกัน แต่ไม่ควรถูกปะปนจนไม่มีเกณฑ์พร้อมใช้งานที่ชัดเจน
เลือกแพลตฟอร์มจากข้อกำหนดของระบบ
Azure มีแนวทาง platform และ application landing zone สำหรับการจัดการหลาย subscription ส่วน AWS Control Tower ช่วยจัดตั้งและกำกับสภาพแวดล้อมหลาย account ขณะที่ Google Cloud มีแนวทาง landing zone สำหรับวาง organization และทรัพยากรร่วม อ่านเพิ่มเติมจาก Azure Landing Zones, AWS Control Tower และ Google Cloud Landing Zone Design
ชื่อบริการต่างกัน แต่การเลือกต้องกลับไปที่ workload ทีมดูแล ข้อกำหนดข้อมูล และต้นทุนรวม รวมถึง traffic ระหว่างสถานที่และเครื่องมือที่องค์กรใช้อยู่แล้ว ไม่จำเป็นต้องใช้หลาย Cloud หากยังไม่มีเหตุผลรองรับ
เรื่องที่ต้องตัดสินใจก่อนย้ายระบบแรก
- โครงสร้าง subscription, account หรือ project และเจ้าของค่าใช้จ่าย
- Identity federation, สิทธิ์ผู้ดูแล และการเข้าถึงฉุกเฉิน
- IP plan, DNS, routing, connectivity และการเข้าถึงบริการแบบ private
- Logging, security baseline, backup และข้อกำหนดการเก็บข้อมูล
- กระบวนการขอทรัพยากร เปลี่ยนระบบ และส่งมอบให้ทีม operations
ตัวอย่างเช่น แอปพลิเคชันที่ย้ายขึ้น Cloud แต่ฐานข้อมูลยังอยู่สำนักงานอาจไวต่อ latency การออกแบบ network จึงต้องอิงรูปแบบการเรียกใช้งานจริง ไม่ใช่ทดสอบเพียง ping ถึงกันได้
จัด migration wave ตาม dependency
เริ่มจาก inventory และความสัมพันธ์ระหว่างระบบ แล้วพิจารณาว่าระบบใดควรคงไว้ ย้ายตามเดิม ปรับแพลตฟอร์ม หรือยกเลิก สำหรับ Windows, SQL Server, .NET หรือ VMware workloads ต้องตรวจ compatibility, license และเครื่องมือที่รองรับแยกตามต้นทางและปลายทาง
แบ่งการย้ายเป็นรอบที่ตรวจรับได้ กำหนดเงื่อนไข replication, data consistency, cutover และ rollback พร้อมเจ้าของการทดสอบฝั่งธุรกิจ การย้ายเครื่องครบไม่ควรเป็นเกณฑ์ผ่านเพียงข้อเดียว
วันรับมอบต้องมองไปถึงวันดูแล
ก่อนปิดโครงการ ทีมปฏิบัติการควรมีสิทธิ์และคู่มือที่ใช้งานได้จริง รู้เส้นทาง escalation และทดสอบ restore ในสภาพแวดล้อมเป้าหมายแล้ว รวมถึงมี baseline ของ performance และค่าใช้จ่ายสำหรับเทียบหลังเปิดใช้
ผลส่งมอบที่ควรตกลงกันตั้งแต่ต้น ได้แก่ architecture decisions, landing zone baseline, migration wave plan, acceptance checklist และรายการความเสี่ยงที่ยังเหลือ การมีเอกสารเหล่านี้ช่วยให้ทีมรับช่วงได้โดยไม่ต้องย้อนถามทุกการตัดสินใจ
In the Cloud ช่วยกำหนดเส้นทาง Cloud Foundation & Migration โดยเริ่มจากข้อกำหนดของระบบเดิมและเป้าหมายธุรกิจ ปรึกษารากฐาน Cloud และแผนย้ายระบบ