เล่าย้อนความ: เมื่อเราใช้ Azure Migrate มาช่วยงาน cloud migration ให้เร็วขึ้นได้ [1]
เมื่อวันที่ 7 พฤษภาคม 2565 ที่ผ่านมาผมได้รับเลือกให้ร่วมเป็น speaker บรรยายในงาน #GlobalAzure Thailand 2022 ในหัวข้อ When Azure Migrate helps accelerate cloud migration projects เนื่องจากได้รับจัดสรรเวลาในการบรรยายเพียง 30 นาที (ซึ่งก็ใช้เวลาเขาเกินไปประมาณนึง 555) ทำให้รู้สึกว่ายังไม่ได้ขยายความหรือลงรายละเอียดบางส่วนของการบรรยายได้อย่างเพียงพอ
วันนี้เลยจะนำเรื่องราวที่ได้บรรยายมาสรุปและขยายความเพิ่มเติมให้ทุกคนได้อ่านและแลกเปลี่ยนประสบการณ์กัน เพื่อเป็นประโยชน์ต่อการเรียนรู้ร่วมกันครับ โดยผมจะแบ่งเนื้อหาออกเป็น 3 ส่วนเขียนแยกกัน สำหรับส่วนแรกนี้จะบรีฟความเข้าใจเกี่ยวกับ cloud migration project ครับ
Concept of Cloud Migration
เมื่อพูดถึง Cloud Migration ให้เข้าใจง่ายๆ ก็คือการย้ายระบบไอที เช่น VM, application, database เป็นต้นจากใน datacenter ขององค์กรทั้งที่เป็นเจ้าของเองและเช่าใช้บริการ ไปสู่ระบบ public cloud เพื่อตอบโจทย์ทั้งในมุม business และ technical ขององค์กรนั้นๆ ซึ่งกระบวนการนี้ก็มักจะถูกเปรียบเทียบกับการย้ายบ้าน เหมือนการย้ายทรัพย์สิน ข้าวของเครื่องใช้ สิ่งของต่างๆ ออกจากบ้านเก่าเข้าบ้านใหม่ โดยสรุปมันก็คือการที่เราย้าย digital asset ไปอยู่ใน platform ใหม่นั่นเอง
แนวทางการทำ Cloud Migration
สำหรับแนวทางการทำ cloud migration หลักๆ ก็จะมี 3 รูปแบบ ได้แก่
- Rehost
ว่าโดยย่อก็คือการย้าย VM จาก on-premise ไปอยู่บนคลาวด์ซึ่งโดยมากจะใช้วิธี replication ขึ้นไป provision เป็น VM ที่จะมี OS, disk, data, และ setting ที่แทบจะเหมือนเดิม 100% ทั้งนี้เราสามารถทำ right-sizing คือการปรับขนาดส่วน compute หรือ storage เพื่อให้เหมาะสมกับการใช้งานจริงของแต่ละ VM ได้ เช่นปรับลดจำนวน CPU core หรือ RAM หากเดิมมีจำนวนมากเกินกว่าความจำเป็นในการใช้งานจริง ก็จะช่วยลดค่าใช้จ่ายจากการตั้ง VM ขนาดใหญ่ได้
เนื่องจากเป็นการทำ migration ที่สามารถเริ่มต้นได้ง่าย ใช้เวลาไม่นานมาก เพราะโดยทั่วไปไม่ต้องดำเนินการแก้ไขที่ระดับ application หรือ source code ใดๆ ก่อนการ migration จึงค่อนข้างเหมาะกับการย้ายระบบที่ต้องคง environment เดิมไว้ หรือมีเหตุให้รีบย้าย VM ไปยังคลาวด์ (เช่น obsolete OS ที่การย้ายไปใช้ security support/update บนคลาวด์คุ้มค่ากว่าการเปลี่ยนหรืออัพเกรด OS บน on-premise)
และเราก็มักจะได้ยินชื่อเรียกกระบวนการ migrate นี้ว่า Lift & Shift - Refactor
หรือบางทีจะเรียกว่า Repackage ซึ่งแนวทางการ migrate แบบนี้จำเป็นต้องมีการเปลี่ยนแปลง/แก้ไขเกิดขึ้นที่ระดับ application source code เพื่อให้สามารถนำไปรันบน service ประเภท PaaS (Platform as a Service) อย่างเช่น Azure App Service ได้ รวมถึงเพื่อให้สามารถใช้ service อื่นๆ บน Azure แทนการเรียกใช้ resource ที่ยังอยู่บน on-premise เช่น Azure Active Directory, Azure Key Vault, Azure Blob Storage เป็นต้น
การทำ migration แบบนี้จะใช้เวลาและการดำเนินการที่มากกว่าการทำ Lift & Shift เหมาะสำหรับองค์กรที่พร้อมเปลี่ยนแปลง platform ในการรัน application หรือ database และพร้อมเปลี่ยนผ่านสู่ระบบคลาวด์หรือวางระบบ Infrastructure บนคลาวด์แทนการจัดการใน on-premise - Rearchitect
พูดสั้นๆ คือการปรับเปลี่ยนเชิงโครงสร้างของ application ให้เอื้อหรือสอดคล้องกับการทำ scalability บนคลาวด์ ตัวอย่างที่เห็นชัดที่สุดคือการเปลี่ยนโครงสร้าง application ที่รวม function/module ทุกอย่างไว้ใน solution เดียวซึ่งเป็น single tier ให้แตกออกเป็น module แยกต่างหากกัน เช่น API หรือ Web Service อย่างที่เราๆ เคยได้ยินคำเรียกกันว่า Microservice นั่นเอง
แน่นอนว่าการทำ migration ลักษณะนี้ย่อมใช้เวลาและแรงงานของฝั่ง application development มากยิ่งกว่า Refactor แต่มีประโยชน์ที่สำคัญมากๆ คือการเพิ่ม scalability และยังช่วยเปลี่ยนผ่านการพัฒนา application ไปสู่การทำ DevOps ให้มีประสิทธิภาพมากยิ่งขึ้น
จะเห็นได้ว่าการเปลี่ยนแปลงที่มากกว่าการทำ Lift & Shift ล้วนเพื่อให้ใช้ PaaS แทน VM ในการรัน application ซึ่งมีประโยชน์ต่อ scalability, development cycle รวมถึงลดภาระในการดูแลจัดการระดับ OS และ security เบื้องหลัง
ซึ่งในที่นี้จะเน้นเล่าถึงการใช้ Azure Migrate ช่วยในโปรเจคที่ทำ migration โดยวิธีการ Lift & Shift และ Refactoring นะครับ
Cloud Migration Project
ตรงนี้ผมจะขอเล่าแบบให้เห็นภาพรวมกว้างๆ สำหรับการทำโปรเจคด้าน cloud migration ก่อนที่จะอธิบายเพิ่มเติมในบางหัวข้อนะครับ
ในการทำ migration อย่างที่ทราบกันดีแล้วว่าเพื่อไปคลาวด์แทนการใช้ datacenter เดิมหรือการอยู่ที่ on-premise ก็จะมีกระบวนการที่เกี่ยวข้องหลายขั้นตอนตามแต่โจทย์ ข้อจำกัด หรือนโยบายขององค์กรที่จะทำ migration ในแต่ละโปรเจค แต่โดยส่วนใหญ่แล้วขั้นตอนที่สำคัญและจำเป็นต้องมี ได้แก่
- Discovery & Assessment (D&A)
เป็นกระบวนการขั้นต้นที่ค่อนข้างสำคัญในโปรเจคการย้ายระบบขึ้นคลาวด์ โดยจะมีการเก็บข้อมูลที่จำเป็นและนำมาวิเคราะห์เพื่อวางแผน กำหนดขอบเขต/เงื่อนไข รวมถึงทางเลือกสำหรับการทำ migration ในโปรเจคนั้นๆ - Workshop
ในขณะที่กำลังดำเนินการเก็บข้อมูลในขั้นตอนก่อนหน้า หรือกำลังวิเคราะห์ข้อมูลที่ได้เพื่อทำแผนต่างๆ การทำ workshop จะเป็นการทำความเข้าใจร่วมกันกับองค์กรถึงสภาพแวดล้อมของระบบในปัจจุบัน นโยบายด้าน IT ขององค์กร รวมถึงข้อจำกัดและปัจจัยต่างๆ ที่จะส่งผลต่อการวางแผนและการทำ migration
ข้อสรุปหรือข้อมูลจากการทำ workshop จะช่วยในการเตรียมแผนที่เหมาะสมกับโปรเจคและองค์กรที่ทำ migration ได้มากขึ้น - Planning
การทำแผนงานหลังจากได้ข้อมูลและผลจากการทำ Discovery & Assessment ทั้งหมดแล้ว ซึ่งจะมีทั้งแผนการทำ migration (อาจเป็นแผนที่ finalized มาแล้วหรือมี option ไว้เผื่อด้วย), แผนงานทั้งหมด (ทั้งกระบวนการทำ migration การบริหารจัดการในโปรเจค และการทดสอบต่างๆ) พร้อม timeline, resource ต่างๆ ที่ต้องใช้ และอาจรวมถึงแนวทางการ support ต่างๆ หลังการทำ migration ด้วย - Migration
การดำเนินการตามแผน migration ซึ่งจะมีตั้งแต่การวาง infrastructure บนคลาวด์ ไปจนถึงการพัฒนาหรือแก้ไข app/database/system ตามแต่แนวทางการทำ migration ที่ได้เลือกหรือกำหนดแล้ว - Delivery
การส่งมอบงานหลังจากดำเนินการเสร็จสิ้นทั้งหมด ซึ่งการส่งมอบจะมีทั้งการทำรายงานสรุปผลของโปรเจค, การตรวจรับโดยทางองค์กร (ลูกค้า), เอกสารถ่ายทอดองค์ความรู้ที่เกี่ยวข้องกับโปรเจค/การใช้งาน/best practice และสิ่งอื่นๆ ตามแต่สัญญาการดำเนินงานจะกำหนด - Support & Maintenance
โปรเจคโดยมากเมื่อดำเนินการ migration เสร็จสิ้นแล้ว องค์กรซึ่งเป็นเจ้าของ asset เหล่านั้นก็จะต้องการ support จากผู้ดำเนินการในโปรเจคเพื่อดูแล จัดการ หรือแก้ปัญหาที่อาจเกิดขึ้นภายหลังกับระบบที่ทำ migration ไป ซึ่งส่วนนี้ก็จะแล้วแต่กรณีหรือข้อตกลงของแต่ละโปรเจคไป
Discovery & Assessment (D&A)
Discovery และ Assessment เป็นกระบวนการสำคัญในโปรเจคย้ายระบบขึ้นคลาวด์ที่จะต้องดำเนินการในขั้นต้นเสมอ เพื่อใช้ข้อมูลในการวางแผน กำหนดขอบเขต/เงื่อนไข รวมถึงทางเลือกสำหรับการทำ migration ในโปรเจคนั้นๆ
เพื่อให้เห็นภาพและความสำคัญของกระบวนเหล่านี้ชัดเจนยิ่งขึ้น ผมจะขอขยายความเพิ่มเติมอีกสักหน่อยนะครับ
Discovery
เป็นกระบวนการที่เราจะค้นหา ตรวจสอบ เก็บข้อมูล รวมถึงกำหนดขอบเขตของเครื่องทั้งหมดที่อยู่ใน environment เป้าหมายขององค์กร ซึ่งหลายๆ ครั้งองค์กรอาจเลือกที่จะค้นหาและตรวจสอบเครื่องที่มีอยู่ทั้งหมดในทุกๆ environment ทุกๆ ระบบ ก่อนที่จะนำมากำหนดขอบเขตของการทำ assessment และ migration ในภายหลัง
โดยทั่วไปการทำ discovery จะมีขั้นตอนดังนี้
- การทำ inventory โดยการใช้ tool เพื่อสแกนหรือค้นหา server ทั้งหมดขององค์กร ไม่ว่าจะเป็น app server, database server, file server, หรืออื่นๆ พร้อมกับ spec ของเครื่องเหล่านั้นเพื่อให้ได้ list ของสิ่งที่มีทั้งหมด
- การเก็บข้อมูลพฤติกรรมของ server เหล่านั้น เช่น อัตราการใช้งาน CPU/RAM/Disk, performance, network connection, app dependency หรืออื่นๆ ตามแต่ความสามารถของ tool ที่ใช้ทำ ซึ่งระยะเวลาที่ใช้เก็บข้อมูลเหล่านี้มักจะอยู่ระหว่าง 2–4 สัปดาห์เพื่อให้ได้ข้อมูลที่มากพอนำไปใช้วิเคราะห์ในกระบวนการ assessment
จริงๆ แล้วเรื่องของระยะเวลาการเก็บข้อมูลจะขึ้นอยู่กับเงื่อนไขและสถานการณ์บางอย่างด้วย ตัวอย่างเช่น
○ 1–2 สัปดาห์: หากมีความเร่งรัดของโปรเจค และสามารถกำหนดช่วงเวลาที่จะเห็นอัตราการใช้งาน resource ของเครื่องต่างๆ ได้ทั้งช่วงสูงสุดและต่ำสุด
○ 2–4 สัปดาห์: สำหรับกรณีทั่วไป หรือไม่สามารถกำหนดช่วงเวลาที่จะเห็นอัตราการใช้งาน resource ของเครื่องต่างๆ ทั้งช่วงสูงสุดและต่ำสุดได้อย่างตายตัว
○ ในบางองค์กรมี policy ด้าน security ที่ค่อนข้างเข้มงวด ไม่อนุญาตให้ใช้ software ใดๆ มาเก็บข้อมูลดังกล่าวได้ เราอาจขอให้ผู้ดูแลระบบ export ข้อมูลย้อนหลังที่จำเป็นจาก tool ที่เขาใช้ทำ monitoring อยู่แล้วได้ เราก็ไม่จำเป็นต้องกำหนดระยะเวลาการเก็บข้อมูลเลย - ใช้ข้อมูลข้างต้นมาการกำหนด scope ของ environment ที่จะทำ assessment อาจจะเป็น Dev/Test zone หรือ Production หรือ ของบางแผนก/กลุ่มในองค์กร โดยทั่วไปอาจไม่ต้องกำหนด scope ของ assessment แล้วไปกำหนด scope ของการทำ migration ภายหลังทีเดียวก็ได้ แต่หากมีโจทย์ที่เจาะจงอยู่แล้วของการทำ migration ก็กำหนด scope ตั้งแต่การทำ assessment ได้
Assessment
เป็นกระบวนการที่เราจะใช้ข้อมูลจากการทำ discovery มาวิเคราะห์ ประเมิน สรุปผล และวางแผนเพื่อการทำ migration ต่อไป สิ่งที่จะได้เป็นผลลัพธ์จากการทำ assessment โดยทั่วไปได้แก่
- ความพร้อมของ VM หรือแอพที่จะทำ migration ไปยัง Azure
- แนวทางการปรับรุง แก้ไข หรืออัพเกรดเพื่อเพิ่มความพร้อมให้กับ VM หรือแอพที่จะทำ migration ไปยัง Azure
- Right-sizing ที่พิจารณาจาก performance/utilization และประเภทของ Azure VM ที่เหมาะสมของ VM ที่จะทำ migration
ในกรณีที่ทำ web app migration ก็จะเป็นข้อมูล plan/sizing ของ Azure App Service ที่เหมาะสมกับแอพนั้นๆ - Total Cost of Ownership (TCO) หรือการคำนวณเพื่อเปรียบเทียบราคา/ค่าใช้จ่าย ระหว่างการใช้ datacenter เดิมหรือการอยู่ที่ on-premise กับการย้ายระบบไปเป็นคลาวด์ ให้เห็นความคุ้มค่าของการทำ migration รวมถึงแนวโน้มค่าใช้จ่ายในระยะยาว เช่น 3 ปี หรือ 5 ปี
- อื่นๆ แล้วแต่จุดมุ่งหมายหรือข้อมูลประกอบเพิ่มเติมของแต่ละโปรเจค
ต้องเคลียร์อะไรโปรเจคถึงจะไม่สะดุด?
ไม่ว่ากระบวนการต่างๆ ในแต่ละโปรเจคจะเป็นอย่างไรบ้าง แต่สิ่งสำคัญประการนึงที่จะได้เผชิญกันในโลกแห่งความเป็นจริงอยู่เสมอก็คือ delay!
ความล่าช้าหรือโปรเจคสะดุดเนื่องจากสาเหตุต่างๆ โดยเฉพาะปัญหาด้าน technical เป็นสิ่งที่ควรหาทางรับมือ เตรียมแนวทางหรือแผนสำรองไว้แต่เนิ่นๆ และตัดสินใจดำเนินการอย่างเหมาะสมเพื่อช่วยให้โปรเจคเดินหน้าต่อตามแผนหรือกรอบเวลาได้
ตรงนี้ผมจะขอแชร์ประเด็นและแนวทางเพื่อรับมืออุปสรรคเหล่านี้จากประสบการณ์ส่วนตัวนะครับ
- Prerequisite/Requirement
หลายๆ ครั้งจุดที่ทำให้ความคืบหน้าของงานเป็นไปได้ช้ามาจากเรื่องของการเตรียมความพร้อมของระบบ การตั้งค่า หรือการให้ permission/access ตาม prerequisite/requirement ของแต่ละกระบวนการในโปรเจค ซึ่งอาจเกิดจากการสื่อสารที่เข้าใจไม่ตรงกัน การชี้แจงหรืออธิบายไม่ครบถ้วน/ครอบคลุม จึงจำเป็นต้องสร้างความเข้าใจที่ตรงกันระหว่างผู้ที่เกี่ยวข้องทั้งหมดตั้งแต่เนิ่นๆ - Limitation/Policy
จากข้อก่อนหน้าสิ่งสำคัญที่สุดอีกประการที่อาจเกิดต่อเนื่องกัน คือหากองค์กรมี policy หรือแนวทางปฏิบัติทาง cybersecurity ที่ไม่อนุญาตบางอย่างใน prerequisite/requirement อาจเป็นอุปสรรคระหว่างดำเนินงาน และต้องใช้เวลาหาทางออกหรือทางเลือกในการดำเนินการ ดังนั้นนอกจากการทำความเข้าใจเรื่องการเตรียมการให้ตรงกันแล้ว ยังต้องเตรียมแนวทางสำรองในกรณีที่บางกระบวนการไม่สามารถทำตามวิธีทั่วไปได้ - Know-who in organization
หลายๆ ครั้งเมื่อเกิดปัญหาหรืออุปสรรคต่อการดำเนินงานมักจะติดตรงที่การหา “คนที่ใช่” เข้ามาช่วยแก้ปัญหาหรือดำเนินการให้ โดยเฉพาะกับองค์กรใหญ่ๆ ที่โครงสร้างองค์กรและทีมที่ดูแลด้าน IT มีหลายทีมหรือเป็น hierarchy หลายขั้น
สมมติขั้นตอน A ติดขัดเนื่องจากต้องมี permission บางอย่าง โดย staff A และ B ที่เราทำงานด้วยอาจไม่มีสิทธิให้ permission นั้นๆ ก็จะต้องแจ้งไปยัง supervisor ของทั้งสองคน หรืออาจจะเป็น manager ของ supervisor อีกที
หรือสมมติว่าขั้นตอน B ต้องให้องค์กรของลูกค้าเป็นฝ่ายดำเนินการให้แล้วใช้เวลานานกว่าปกติ เราอาจจะต้องติดต่อผู้ที่มีอำนาจสั่งการหรือสามารถเร่งรัดให้ดำเนินการให้เร็วขึ้นได้
ดังนั้นถ้าเราสามารถ connect กับคนที่ใช่พร้อมข้อมูลที่จำเป็นได้อย่างรวดเร็วก็จะช่วยให้งานเดินต่อได้อย่างง่ายดาย - Holidays/Leave
อาจจะดูเป็นเรื่องขำๆ แต่งาน delay เพราะวันหยุดและวันลากันมานักต่อนักแล้ว เรื่องวันหยุดนักขัตฤกษ์ยังพอคาดการณ์ล่วงหน้าได้ แต่วันลาของทางฝั่งลูกค้าเราอาจเพิ่งมารู้ตอนที่ต้องติดต่อคนคนนั้นก็ได้ สถานการณ์ก็มักจะประมาณนี้ครับ
- ขั้นตอนต่อไปต้องการ input จากฝั่งลูกค้าหรือให้ permission ที่จำเป็น แต่ติดวันลาเลยยังทำให้ไม่ได้
- ทีมลูกค้าติดวันลา ไม่พร้อม test ระบบ
- ทีมทำงานมีทั้งทีมในไทยและทีมต่างประเทศแล้วติดวันหยุดยาวของไทย ทีมต่างประเทศก็ต้องรอทีมไทยอีกที
- มีวันหยุดในปฏิทินของเรากับลูกค้าที่ไม่ตรงกัน บางเทศกาลอาจจะไม่ได้เป็นวันหยุดที่ตรงกันทำให้แผนการทำงานต้องเลื่อนไปได้
ดังนั้นวิธีที่ดี่ที่สุดคือในขั้นตอนวางแผนกรอบเวลาการทำงานจะต้องมี buffer ไว้เผื่อ delay ด้วย
สำหรับการบรีฟความเข้าใจเกี่ยวกับ cloud migration project ก็จะมีประมาณนี้ก่อนพอให้เห็นภาพรวมๆ ในตอนต่อไปจะได้มาเล่าเกี่ยวกับการใช้ Azure Migrate ในการทำ discovery & assessment นะครับ
หากมีข้อแนะนำ หรือต้องการแลกเปลี่ยนความคิดเห็น/ประสบการณ์/ข้อมูลในจุดไหน ก็สามารถคอมเม้นไว้ได้เลยนะครับ ขอขอบคุณทุกคอมเม้นล่วงหน้าครับ
เรียนรู้เพิ่มเติมเกี่ยวการใช้ Azure Migrate ในการย้าย VM และ application ขึ้นคลาวด์ได้ทาง Microsoft Learn
