ย้าย workload ขึ้น GCP แบบมืออาชีพ

คำว่า migrating เป็นแกนกลางของสามคำที่ Team Lead บอกมา และเป็นงานจริงที่ DCE ทำบ่อยที่สุด ผู้สัมภาษณ์อยากเห็นว่าเรามี methodology เป็นระบบ รู้จักเครื่องมือ และเคยเจอปัญหาจริงในการย้าย ไม่ใช่แค่รู้ว่ามี 6 Rs จุดที่คนพลาดคือตอบทฤษฎีได้แต่เล่าการลงมือจริงไม่ได้ ทั้งเรื่อง cutover, rollback, dependency และ data validation

Google วาง migration เป็น 4 เฟส:

1. 1Assess (ประเมิน): ทำ inventory ของ workload, วิเคราะห์ dependency, ประเมินต้นทุนและความพร้อม, สร้าง business case
2. 2Plan (วางแผน): จัดลำดับ wave ว่าย้ายอะไรก่อนหลัง, วาง landing zone และ network, กำหนดกลยุทธ์ต่อ workload
3. 3Deploy (ย้ายจริง): migrate ทีละ wave ตามแผน ทดสอบและ validate
4. 4Optimize (ปรับหลังย้าย): right-sizing, ปรับต้นทุน, modernize ต่อ

GCP แมป workload เป็น 3 เส้นทางหลัก ซึ่งสอดคล้องกับ 6 Rs:

• Lift and shift (Rehost): ย้ายตรง ๆ ไม่แก้ เร็วสุด ความเสี่ยงต่ำแต่ยังไม่ได้ประโยชน์ cloud-native เต็ม
• Improve and move / Move and improve (Replatform): ย้ายพร้อมปรับบางส่วน เช่นเปลี่ยนไป managed service
• Rip and replace (Refactor/Repurchase): เขียนใหม่เป็น cloud-native หรือเปลี่ยนไป SaaS

รวมกับ Retire (ปลดระวางของไม่ใช้) และ Retain (คงไว้ on-prem ก่อน) ครบ 6 Rs

หลักคือ workload แต่ละตัวเลือกเส้นทางต่างกันได้ อย่าย้ายทุกอย่างด้วยวิธีเดียว

Assess คือเฟสที่ DCE ทำหนักที่สุดและเป็นจุดสร้างความน่าเชื่อถือ

• Migration Center: hub กลางของ Google สำหรับ discovery, ประเมิน, สร้าง business case และ cost estimate มี discovery client เก็บข้อมูล VM จาก on-prem, vSphere, AWS และ Azure และให้คำแนะนำ right-sizing ด้วย AI
• ทำ dependency mapping: หาว่าระบบไหนผูกกับระบบไหน เพราะ dependency กำหนดว่าอะไรต้องย้ายไปด้วยกัน
• ประเมินด้านธุรกิจ เทคนิค และปฏิบัติการ: business criticality, compliance/data residency, TCO, สถาปัตยกรรมแอป, licensing, data gravity, ทักษะทีม, downtime ที่รับได้
• ผลลัพธ์คือ inventory ที่จับคู่ workload กับกลยุทธ์ 6 Rs และแผน wave

ต้องเรียกชื่อให้ถูกและรู้ว่าใช้เมื่อไหร่:

Migrate to Virtual Machines: (ชื่อเดิม Migrate for Compute Engine หรือ Velostrata) ย้าย VM จาก vSphere on-prem, AWS EC2, Azure และ Google Cloud VMware Engine เข้า Compute Engine แบบ near-zero downtime โดย copy ข้อมูลเบื้องหลังขณะ VM ยังทำงาน เหมาะเส้นทาง lift-and-shift

Migrate to Containers: (ชื่อเดิม Migrate for Anthos) แปลง workload บน VM ให้เป็น container รันบน GKE, GKE Autopilot หรือ Cloud Run เหมาะเส้นทาง replatform ที่อยาก modernize ไป container พร้อมย้าย

Database Migration Service (DMS): ย้าย database แบบ managed รองรับ MySQL, PostgreSQL, SQL Server, Oracle ไปยัง Cloud SQL หรือ AlloyDB ทำได้แบบ minimal downtime ด้วย continuous replication รองรับทั้ง homogeneous และ heterogeneous migration

Datastream: บริการ change data capture และ replication แบบ serverless sync ข้อมูลจาก database ปฏิบัติการเข้า BigQuery หรือ Cloud Storage แบบ latency ต่ำ ต่อกับ Dataflow template เพื่อโหลดเข้า Cloud SQL หรือ Spanner ได้

Storage Transfer Service: ย้ายข้อมูลจากคลาวด์อื่น, แหล่งออนไลน์ หรือ on-prem เข้า Cloud Storage

Transfer Appliance: อุปกรณ์ hardware สำหรับขนข้อมูลก้อนใหญ่ระดับหลายร้อยเทระไบต์ถึงเพตะไบต์แบบ offline มีขนาด 100TB และ 480TB เหมาะเมื่อโอนผ่าน network ไม่คุ้มหรือช้าเกินไป

BigQuery Data Transfer Service: โอนข้อมูลแบบตั้งเวลาจาก SaaS, Amazon S3, Azure Blob และ Teradata เข้า BigQuery

VMware HCX / Google Cloud VMware Engine: ย้าย VMware ทั้ง stack ไปรันบน VMware Engine โดยไม่ต้องแปลง เหมาะลูกค้าที่ผูกกับ VMware หนัก

Active Assist / recommenders: หลังย้าย ใช้แนะนำ right-sizing จับ instance และ node pool ที่ใช้ไม่เต็มเพื่อลดต้นทุนในเฟส Optimize

• แบ่งการย้ายเป็น wave: เริ่มจาก workload ที่ไม่ critical และ dependency น้อยก่อน เพื่อสร้างความมั่นใจและเรียนรู้
• ทำ pilot migration: ย้ายไม่กี่ระบบก่อน validate แล้วค่อยขยาย ลดความเสี่ยงก้อนใหญ่
• จัดกลุ่มตาม dependency: ระบบที่ผูกกันแน่นควรย้ายใน wave เดียวกันเพื่อไม่ให้ latency ข้ามสภาพแวดล้อมทำให้พัง
• กำหนด success criteria ต่อ wave: อะไรคือ "ย้ายสำเร็จ" ก่อนไป wave ถัด

นี่คือจุดที่ Team Lead เจาะลึกที่สุดเพราะสะท้อนประสบการณ์จริง

• กลยุทธ์ cutover: big-bang (สลับทีเดียว เร็วแต่เสี่ยง) กับ phased/parallel-run (รันคู่ขนานแล้วค่อยสลับ ปลอดภัยกว่าแต่ซับซ้อนและแพงกว่า) เลือกตามความ critical และ downtime ที่รับได้
• Cutover window: เลือกช่วง traffic ต่ำ วางแผนขั้นตอนละเอียดเป็น runbook
• Rollback plan: ต้องมีทางถอยเสมอ ถ้าย้ายแล้วมีปัญหาต้องกลับไประบบเดิมได้ เก็บระบบเดิมไว้จนมั่นใจ
• Data validation: ตรวจว่าข้อมูลครบและถูกต้องหลังย้าย เทียบจำนวน record, checksum, ทดสอบ business flow จริง
• Minimal downtime DB migration: ใช้ DMS ทำ initial load แล้ว replicate การเปลี่ยนแปลงต่อเนื่อง (CDC) จน sync แล้วค่อย cutover ตอน traffic ต่ำ ลด downtime เหลือน้อยที่สุด
• การทดสอบหลังย้าย: performance test, integration test, security check ก่อนประกาศว่าเสร็จ

• Network: bandwidth พอไหมสำหรับ replicate, latency ระหว่าง on-prem กับ cloud ช่วง parallel run, IP range ชนกันไหม
• Licensing: license OS และ database ย้ายแบบ BYOL ได้ไหม หรือต้องเปลี่ยนรูปแบบ
• Dependency ซ่อน: บาง integration หรือ hardcoded IP ที่ไม่มีใน inventory มักโผล่ตอนย้าย
• Performance หลังย้าย: อาจต้อง right-size ใหม่ เพราะสเปกเดิมไม่ตรงกับ cloud
• People และ process: ทีมพร้อมดูแลของใหม่ไหม มี runbook และการ handover ไหม
• Compliance และ data residency ตลอดการย้าย

โจทย์: ลูกค้ามีราว 50 VMs และหลาย database บน on-prem/VMware อยากย้ายมา GCP

Assess: ใช้ Migration Center รัน discovery เก็บ inventory และ dependency, ประเมิน TCO และ right-sizing, จับคู่ workload กับ 6 Rs เช่นระบบเก่าที่ไม่คุ้มแก้ก็ Rehost, ระบบที่ได้ประโยชน์จาก managed ก็ Replatform, ระบบที่ไม่ใช้แล้วก็ Retire

Plan: วาง landing zone (resource hierarchy, IAM, network, security baseline) ก่อน, แบ่ง wave เริ่มจากระบบ non-critical dependency น้อย, จัดกลุ่มระบบที่ผูกกันไว้ wave เดียวกัน, กำหนด cutover window และ success criteria

Deploy: VM ส่วนใหญ่ใช้ Migrate to Virtual Machines ย้ายแบบ near-zero downtime, ระบบที่อยาก modernize ใช้ Migrate to Containers ไป Cloud Run/GKE, database ใช้ DMS ทำ initial load + CDC แล้ว cutover ตอน traffic ต่ำ, ข้อมูลก้อนใหญ่ที่โอนผ่าน network ไม่คุ้มใช้ Transfer Appliance, ทำ pilot ก่อนแล้วขยาย validate ทุก wave

Optimize: ใช้ Active Assist right-size, ปรับต้นทุนด้วย committed use discount, ค่อย modernize ระบบที่ Rehost ไปก่อนสู่ managed service

เล่า trade-off: เริ่ม Rehost ให้เร็วเพื่อ momentum และลดความเสี่ยง แล้วค่อย modernize; parallel run สำหรับระบบ critical เพื่อ rollback ได้; แยก wave เพื่อจำกัด blast radius

ปิดด้วย business value: ย้ายได้อย่างมีระบบ ความเสี่ยงต่ำ เลิกภาระ hardware เปลี่ยน CapEx เป็น OpEx และเปิดทางสู่การ modernize ต่อ

ถาม: "ลูกค้ามี 50 VMs อยากย้ายมา GCP เริ่มยังไง" ตอบ: เดินเฟส Assess ด้วย Migration Center แล้ว wave planning, เลือก tooling ตามชนิด workload, cutover พร้อม rollback, validate, แล้ว optimize

ถาม: "จะย้าย database ที่ห้าม downtime ยังไง" ตอบ: DMS ทำ initial load แล้ว CDC replicate ต่อเนื่องจน sync แล้ว cutover ตอน traffic ต่ำ พร้อม rollback

ถาม: "big-bang กับ phased cutover เลือกยังไง" ตอบ: ดูความ critical และ downtime ที่รับได้ ระบบสำคัญใช้ parallel run/phased เพื่อปลอดภัยและ rollback ได้ ระบบเล็กอาจ big-bang

ถาม: "เคยเจอ migration ที่มีปัญหาไหม แก้ยังไง" ตอบ: เล่าเคสจริง เน้นการวิเคราะห์ root cause และการกู้สถานการณ์ เช่น dependency ซ่อนหรือ network ที่ไม่คาดคิด

ถาม: "ข้อมูลก้อนใหญ่มากโอนผ่าน network ไม่ไหว ทำยังไง" ตอบ: Transfer Appliance สำหรับ offline bulk transfer

ตอบทฤษฎี 6 Rs ได้แต่เล่าการลงมือจริงไม่ได้; เรียกชื่อเครื่องมือเก่า; ลืม rollback plan; ไม่พูด data validation; มองข้าม dependency และ licensing; เสนอ big-bang กับระบบ critical; ย้ายทุกอย่างด้วยวิธีเดียว; ลืมว่า Assess คือเฟสที่สร้างความน่าเชื่อถือ; ไม่โยงกับประสบการณ์จริง

migration คือจุดชี้ขาดของรอบสอง ใช้ 4 เฟส Assess-Plan-Deploy-Optimize และ 3 เส้นทางที่แมปกับ 6 Rs เฟส Assess ใช้ Migration Center สร้าง inventory และ business case รู้จักเครื่องมือปัจจุบัน (Migrate to VMs, Migrate to Containers, DMS, Datastream, Storage Transfer Service, Transfer Appliance) และใช้ให้ถูกงาน วาง wave และ pilot ก่อนขยาย ให้ความสำคัญกับ cutover, rollback และ data validation ซึ่งเป็นจุดที่ Team Lead เจาะลึก และเล่าทุกอย่างโยงกับประสบการณ์จริงเพื่อพิสูจน์ว่าย้ายของจริงเป็น