จากเอกสารเรื่อง Blowing Up the Monolith: Adopting a Microservices-Based Architecture
จากทาง KongHQ ทำการอธิบายเกี่ยวกับการนำแนวคิด Microservices
มาปรับใช้สำหรับการปรับปรุงระบบเดิมที่มีลักษณะแบบ Monolith ให้ดีขึ้น
ว่าควรพิจารณาในเรื่องใดบ้าง
รวมทั้งควรมี strategy ในเรื่องต่าง ๆ ที่ชัดเจน
หนึ่งในนั้นคือ Transition strategy
จากเอกสารอธิบายไว้ว่า
Transition strategy คือรูปแบบในการนำแนวคิดมาปรับใช้กับองค์กรและระบบงาน
โดยแบ่งออกเป็น 3 รูปแบบคือ
- Ice cream scoop
- Lego
- Nuclear option
มาดูรายละเอียดรวมทั้งข้อดีข้อเสียกันนิดหน่อย
รูปแบบที่ 1 Ice cream scoop
เป็นรูปแบบการแยกส่วนการทำงานออกมาจากระบบเดิม
โดยค่อย ๆ แยกออกมา เหมือนกับการตัก Ice cream มาทีละ scoop
ข้อดีคือ เป็นการทำงานแบบค่อยเป็นค่อยไป
ดังนั้นผลกระทบจากการเปลี่ยนแปลงจะน้อยหรือไม่มีเลย
ผู้ใช้งานยังใช้งานเช่นเดิมเช่นเดิม ไม่มีผลกระทบหรือน้อยมาก ๆ
แต่กว่าจะแยกออกมาหมดก็ต้องใช้เวลามากเช่นกัน !!
รูปแบบที่ 2 Lego
ในระบบงานแบบ Monolith นั้นมีขนาดใหญ่มาก
การจะมาแก้ไขหรือปรับปรุงให้ดีขึ้น
เป็นเรื่องที่ยากหรือเป็นไปไม่ได้เลย
มีอีกแนวทางคือ อย่าไปยุ่งกับของเดิม แต่ก็อย่าสร้างเพิ่ม
ดังนั้น ถ้าต้องการสร้างหรือเพิ่ม feature ใหม่ ๆ
จึงไม่ให้เพิ่มในระบบเดิม แต่ให้แยกออกมาเป็น service ใหม่แทน
แน่นอนว่า ข้อดีคือ ทำการพัฒนาได้อย่างรวดเร็ว
เพราะว่า ไม่ต้องไปแก้ไขของเก่า
แต่ปัญหาที่ตามมาคือ
ทั้งสองระบบต้องสร้างส่วนที่แลกเปลี่ยนข้อมูลกันด้วย
ยกตัวอย่างเช่น API ขึ้นมา
รวมทั้งระบบเดิม ก็ยังคงมีปัญหาเดิมต่อไป
รูปแบบที่ 3 Nuclear option
เป็นรูปแบบที่ใช้น้อยมาก ๆ นั่นคือ
สร้างระบบใหม่ขึ้นมาเลย ออกแนวทาง ทุบหม้อข้าวหม้อแกงก่อนออกรบนั่นเอง
หรืออาจยังคง support ระบบเดิม
แต่ถ้ามี feature ใหม่ ๆ จะเพิ่มไปที่ code ของระบบใหม่เท่านั้น ของเดิมไม่เพิ่ม
ข้อดีของแนวทางนี้คือ เริ่มใหม่คิดใหม่ทำใหม่
แต่ข้อเสียคือ ก็คือการเริ่มสร้างและพัฒนาใหม่นั่นเอง
ต้องใช้ค่าใช้จ่ายและคนเยอะมาก
อีกทั้งตอนที่นำมาใช้แทนที่ของเดิม
ทำให้เกิดผลกระทบต่อผู้ใช้งานสูงมาก ๆ
จากรูปแบบการย้ายไป Microservices ทั้ง 3 แบบ
ต่างมีข้อดีข้อเสียทั้งนั้น
ดังนั้นสิ่งที่เราต้องพิจารณาคือ
ปัญหา เป้าหมายขององค์กรว่า จะมีทิศทางอย่างไร
ก่อนที่จะเลือกรูปแบบที่จะเดินไปข้างหน้า
สามารถนำหลาย ๆ แนวทางมาประยุกต์ เพื่อให้เหมาะสมกับเราที่สุด
